Difference between revisions of "Stardust/Knowledge Base/Modeling/Deploying multiple Models"

Revision as of 05:19, 4 May 2012

Deploying Multiple Models

Stardust supports deployment of multiple models to the Audit trail. This facility can be used to:

• Separate model elements into libraries of data/message structures, applications, basic process definitions and participants (Use A)
• Design process skeletons, where parts (sub-process definitions, applications) might be overwritten in a concrete deployment scenario (Use B)
• Design implementations for subprocesses and applications used in Type B scenarios (Use C)
• Process models or sets of these which have no reference to other deployed models (Use D)

The mechanism is also useful for exposing processes with service interfaces, as described in article Process as Service. Use cases for multiple models include:

• Projects separate and distribute work to multiple teams (A)
• An operational template provides process model elements for re-use across an organization (A)
• An organization deploys core processes with regional/departmental variations (A,B,C)
• Environments that serve multiple customers/tenants with different levels of service/process(A,B,C)
• Departments deploy models in isolation to a shared audience (D)

Terminology

In multiple model environments, a processs definition can have type 'Producer, 'Consumer', and 'Implementer'. A Producer provides an 'Process Interface' through which Consumers can re-use elements specified in that interface. An Implementer is a processes that replaces a specific process (usually sub-process) within a target model. Any combination of model type can be packaged together as a 'Process Model Set', and deployed to the Audit trail as part of a 'Bulk Deployment'

Figure 1. Model element re-use	Figure 2. Model Sets and references

In Figure 1, consumer model M2 is reusing the public elements A1 & D1, and process P1 of producer M1. In Figure 2, M1 and M2 form a model set S1, and are deployed together. M3 consumes or provides implementation for M1 & M2 elements, therefore must be deployed within S1 or after S1. More information on deployment follows.

For now, refer to the process models in StardustMultiModels1.zip that follow these examples.

Defining Interfaces

In the Eclipse IDE, the Process properties dialog includes a 'Process Interfaces' section. Here the default (no interface, for normal processes) can be changed to Provides Process Interface or Implements Process Interface.
When providing an interface, data in/out can be selected (Parameters) from those used by that process definition. Additional options (Invocation) allow this interface to be specified by a REST or SOAP service. These services can then be located through the IPP Process Interface Endpoint URL i.e. <server>/services/soap/InfinityBpmService.wsdl?

For a Consumer or Implementor Process to access elements in another model, a reference must exist to that model. External Model information is a top level element for IPP process models. Connections can be either to files on the local file system, or a network repository, with the latter usually used with distributed development. At deployment these models will be linked and local/remote connections are overriden by IPP engine linking (see deployments).

Bulk Deployment

Since references exist between models, deployment order is important to manage correct linking between multiple parallel deployments of a models or their versions. Multiple deployments at runtime mean that design time associations are no longer unique. Circular ‘uses‘ associations are prohibited and must rejected.

1. Start with a given model deployment.
2. Add all other deployments linked as Producer.
3. Add all other deployments linked as Consumers.
4. Recurse for any deployment added during 2. or 3.
   

Runtime Configuration

In Figure 3, the three deployed models are shown. Consumer models icons (blue arrow facing left) are disabled so that only Producer model references are shown. Here is is clear that M3 references M1, M2, and M2 references M1, as in Figure 2. If multiple versions of a model have been deployed that is also indicated

Note M1 has runtime configuration available as a gear icon. This dialog (Figure 4) allows P1 or P1' to be set as the active model. This choice will be actioned for each new P1 instance once selected.

Figure 3. Portal (Administration) Model Management	Figure 4. Process Implementation selection