-
Notifications
You must be signed in to change notification settings - Fork 5
Technical Introduction
This is a 'gentle' technical introduction to the Description-Driven Framework. It does not use the meta-modelling theory to explain the concepts and it is entirely based on the packages, classes and files available in the cristalise-kernel project.
The idea of Description-Driven Framework was originated from CRISTAL, a system which was developed at CERN to manage the construction of the CMS/ECAL detector. Due to the scientific nature and the extended time-scale of the construction (5+ years), the users (physicists/engineers) wanted to gradually define and evolve detector elements, their data structures, construction steps and scientific calculations in order to produce the best possible device. In order to meet these requirements the team had to develop a system which could cope with change by design. Such a unique constraint has inspired the research and development teams at UWE/CERN to design and develop a so-called Description-Driven System in which all logic and data structures have “descriptions” which can be modified and versioned to reflect changes required by physicists.
The original CRISTAL software was a fully functional Description-Driven System, which had to be configured and installed so it could be used like a CRM or WFM system. The current version, named the cristalise-kernel, offers building blocks to build fully functional description-driven system hence the name Description-Driven Framework (DDF).
The cristalise-kernel has packages and classes to implement the description-aware functionalities common to many software systems. This list of packages is the result of careful and gradual re-factoring and abstraction of the original CRISTAL software.
Entity implements the fundamental building-blocks of DDF, like Objects in an object-oriented language.
-
Item is the heart of cristalise-kernel as it abstracts business objects and their logic into process-driven, version-controlled and document-oriented data that are managed on-the-fly for specific user domains. Item is fully audited as it stores all Events generated during the execution of its LifeCycle. Items are also communication end-points (CORBA) and have unique IDs (UUID) to support lookup in a distributed environment.
-
Agent is an Item with Roles to authorise it to execute Steps/Activities defined in the LifeCycle of an Item.
-
Property is a name and value pair associated with Item or Agent. They are used for identification and typing, and for domain specific naming.
LifeCycle implements the process-driven aspect of Item. It holds the domain specific logic required by the business object. Currently it is implemented as an extremely flexible Workflow.
-
Composite Activity contains complete layout for all Activities (Elementary or Composite), connected in a directed graph that enforces the execution order of the constituent Activities.
-
Workflow, the top-level Composite Activity, is the container for all Activities in an Item. It resolves all activity paths from execution requests to individual Activities, and passes requests to them. Its also contains a list of non-persistent PredefinedSteps which are key to create new Items (see next section).
-
Elementary Activity captures the parameters of each atomic execution Step, defining what data is to be supplied (Outcome) and by whom (Role). The execution is performed by Agents.
-
State Machine specifies the possible States and Transitions of Activity. The Transition defines the Event, completion Events generate data stored as Documents, also knows as Outcomes. Events are stored in the History of Item enabling the Item to log all Events, Outcomes and Viewpoints thereby capturing complete provenance information associated with it.
This package is the version-controlled document-oriented persistency aspect of Item. Its persistency mechanism (ClusterStorage) allows different kernel objects to be stored in different back-ends. For instance, Properties may be stored in LDAP, while Events, Outcomes and Viewpoints could be stored in a relational database. The preferred backend is a native XML database like exist-db.
-
Outcome is piece of XML fragment (Document) that were produced by an Agent during the execution of an Activity. Its structure is defined by an XML Schema (XSD) which is the primary Data Definition Language in cristalise-kernel.
-
Viewpoint is a named link to an Outcome, usually either the latest Outcome generated by a particular Activity, or of a particular XMLSchema.
Collection declares relationships between Items. Each collection has a name, and holds properties. Each Item is referenced by a Slot object, which holds additional properties about the link.
-
Aggregation is Collection with layout and fixed, typed slots.
-
Dependency is single typed flexible sized Collection, like a java List.
The most important functionality of cristalise-kernel is the ability to read descriptions to initialise Items together with their constituting objects. In other words Item objects are instantiated from the Item class and are initialised from 'Description' objects. You may have noticed that in the section before there was no separate Description package because Description objects are Item objects as well.
XML is the key technology in cristalise-kernel, for two reasons; firstly several libraries exist to marshall/unmarshall Java objects to/from XML, meaning workflows can store and version Outcomes/Documents easily. Secondly XML can be described using XML Schema, which is itself XML. Consequently, every object and piece of domain specific data, from product characterisation data and its definitions, to workflow, workflow description, application logic scripts, queries and collection definitions are stored in the same way, as XML fragments in Items. This design uses the same data representation for all aspects of the system which makes it simpler to manage and manipulate.
----- bellow text is only notes which needs to be rewritten
- provide elementary building blocks of Descriptions
- explain how Descriptions are used to create Item and associated objects
- explain why Predefined Steps are essential
- Item Creation sequence based on CreateItemFromDescription Predefined Steps
Each Item is instantiated with a set of Properties created from the PropertyDescription outcome of its Description Item.
On creation, an Item contains no Events, Outcomes or Viewpoints. These are explicitly generated later during execution of its workflow processes.
Initially an Item contains Properties to identify it, its Workflow and any Collections it may need, with all slots empty. The initial set of Properties are created in the process of rendering a property input form (which is user editable) by exploiting the Property Description (itself an Outcome stored in the Item Description), and submitting it as an Activity Outcome of the description Item. It is this standardised and managed treatment of the workflow-driven, version controlled 'Items’ that is novel in a description-driven system and enables the flexibility of such systems.
How Roles are defined and used to create an Agent???
Instantiated from a self-contained CompositeActivity Description Item.
Defined as XMLSchema, stored and versioned in an OutcomeDescription Item.
The following paper explains the full concept of Description-Driven Approach in great details:
- Getting started
- Key features
- Documentation
- Tutorials
- Basic: Create Patient
- Adv: Patient Tracking
- Selected papers
- Maven Deploy Travis
- Maven-Deploy-Travis-GPG2