Package de.aristaflow.adept2.model.activitymodel

TODO This is completely outdated. It needs to be updated. The activity model provides and manages all information that is needed to describe components for using them in a process template. This includes the name of the class to call at runtime, its configuration, its input and output parameters, the interactions the component supports and much more.
Application integration is based on the interface ExecutableComponent. This provides all the functions needed to execute the (possibly wrapped) application when executing a corresponding process, for instance the initialisation or the actual execution. A component needs a specific context to run which needs to be specified beforehand, which is its input and output parameters, a graphical user interface, an appropriate configuration,...

To simplify the application integration, executable components can also be wrappers for specific components, applications or services, for instance, an executable component may call Java methods, another one may call arbitrary web services. This is reflected in the activity model via Operations.
Each operation represents the actual logic called at runtime. It is therefore more fine-grained than an executable component. An executable component may support just one operation or several operations or it may also be generic and support a wide range of operations (for instance, calling Java methods). An operation has a well-defined "interface" that is it defines input and output parameters.
However, operations are not the right granularity to use for modelling process templates. This is achieved by ActivityTemplates which are located just below operations. They may provide additional information to operations and represent the logic which is provided at nodes in a process template.

TODO complete TODO always check inheritance (overriding) before retrieving value TODO difference activity template and activity TODO revision: The manager needs to adapt all child entities atomically (for instance, an operation, the configuration set and the ATD). TODO configuration description: check whether all configuration values correspond to the entries when creating an activity template. When changing the type of an entry, the value may not be right any more! Therefore each executable component All information to call an ExecutableComponent needs to be provided at runtime. It can stem either from the corresponding process model or configurations that apply at runtime (the global configuration and the local configuration of the runtime manager executing the component). To simplify deployment and configuration, the information is subject of inheritance and overriding. The definite entry point for the inheritance (the root of the branch of activity model entities) is an ExecutableComponentDescription.
The ExecutableComponentDescription provides Operations which in turn have ActivityTemplateDefinitions. These may be dragged to nodes in a process templates and thus provide the information in the process model needed later at runtime (see above).

An ExecutableComponentDescription is the logical counterpart of the physical entity that is called at runtime, the "ExecutableComponent". As its name implies, it contains the basic information on the ExecutableComponent, for instance the name of the class implementing the ExecutableComponent-interface, the class path, licence information and a description. Additional data like a revision or a state allows to organise and manage the descriptions and provide a life cycle and change management.

The activity model consists of further entities (Operations, ActivityTemplateDefinitions) that belong to an ExecutableComponentDescription. These entities are organised in a hierarchy where child entities may provide additional information but also may override information provided by parent/ancestor entities. Overridable attributes have two different semantics for null values: a null value can either specify an undefined value for this attribute or undefined for the current entity only, that is it the value is inherited from the parent entity.

Each entity of the activity model has a well-defined life cycle which is made up of a revision and a State. Each entity starts IN_DEVELOPMENT. When finished editing, it transitions to IN_PRODUCTION and may then be used in a process (dragged to a node). The life cycle ends OUTDATED when the entity may not be used any more. Besides the state each entity has a revision which allows for versioning of this entity.
While being IN_DEVELOPMENT an entity may be changed arbitrarily. The only exception is the identifier, which is the name for the ExecutableComponentDescription. This may only be changed in revision 0. As soon as the state changes to IN_PRODUCTION the entity is available for usage. No changes are allowed any more. It remains there until it should not be used any more and becomes OUTDATED or it needs to be modified. Modification require the creation of a new revision, which is initially set to IN_DEVELOPMENT while the former revision keeps its state. However, as soon as the new revision gets IN_PRODUCTION, the former one automatically gets OUTDATED. Therefore at most one revision is IN_PRODUCTION at a time.

Changes are critical concerning the inheritance. Therefore to keep this consistent, a new revision of a parent entity always leads to a new revision in all of its child entities transitively. This will also apply if no direct attributes of the child entities are changed - the inherited attributes may have changed.
The propagation of a new revision to child entities just copies all values of the latest revision to the next revision and increases the revision count. The state of the revision stays the same as before; if it had been IN_PRODUCTION, it would stay there but the former revision would be set to OUTDATED. In case of a revision IN_PRODUCTION it just remains there; however, the changes of the parent should be reviewed and overridden if needed. This straight versioning (no branches are allowed) keeps the model simple. Additionally, a child IN_PRODUCTION does not need to know the revision of its parent; it is the revision being currently IN_PRODUCTION. If there is currently no revision IN_PRODUCTION, the child entity may not be used, that is, the state is somewhat inherited. It will become usable again if a parent entity revision is set to IN_PRODUCTION.

An ExecutableComponentDescription is identified by its name. As stated above, this may only be changed while being IN_DEVELOPMENT. Afterwards this name is used to identify the executable component; in the activity model as well as in the global configuration and the configuration of local runtime managers. The name must not be changed again since this would require massive changes in the configurations. If a new version of an executable component renders the corresponding configurations incompatible, create a complete new ExecutableComponentDescription with a different name. This way existing configurations do not apply any more. The Operation represents a callable part of an ExecutableComponent. This allows for generic components like a Java wrapper, that may call arbitrary Java methods, whereas every method is represented by another operation. Otherwise operations may directly correspond to an executable component, for instance a component automatically creating a form based on input and output parameters. And there may also be components that provide a well defined set of operations, for instance a component allowing to read and write files whereas reading and writing is an operation of its own.

Author:
Ulrich Kreher