The following extends the previous discussion, although focused more on the technical issues related to different possible riftsaw configurations that could be used.

Generally SCA components are defined in the context of a configuration, and are only applicable in that context.

BPEL components are slightly different as it depends on the scope of the engine and backing db. If shared with other BPEL components in different SCA composites, then there is potential for conflicts between process definition versions, and we also need to ensure messages are routed to the correct SCA composites when sent by the BPEL process instances.

So the obvious solution would be for each SCA composite, and the configured BPEL components within it, to have their own isolated BPEL engine. However this approach has its own set of issues, as outlined below:

1) Multiple engines and databases

So if we have a configuration where each BPEL component, or atleast composite (application), has its own engine and database, then isolation in terms of the application will be ideal. Each deployment does not need to care about other SCA applications.

The issue is how to handle management of the BPEL process definitions and instances from a console. In ODE, the engine and the database have information relevant to the console. If we have multiple of each, then it becomes difficult for the console to locate and manage all of this information.

It would be difficult from a deployment perspective, as each SCA/switchyard application would be required to contain the engine configuration, and the administrator would be required to manage multiple databases.

Although the isolation benefits make this option attractive, in general it is better to keep the configuration information for the BPEL engine as part of the container, managed by the container administrator, rather than within each application.

2) Multiple engines and single database

Slight variation on the previous setup.

As this configuration shares a database, the process definitions deployed across different SCA composites/applications could impact each other. Only one version of a particular process definitions would be active at any one time, so if used in multiple composites, then a version change would need to be synchronized.

On initial consideration this approach offers the benefit of an engine that is specific to the SCA application, and therefore avoids routing issues on requests issue from a process in the engine to the containing SCA application. However in reality each of the multiple engines would effectively be acting as a cluster around the single db, and therefore under certain circumstances the process instance may be loaded into another engine instance (possibly running the same process definition) and send the request message into the wrong SCA application.

So this is not really a suitable option, and therefore will be ignored.

3) Single engine and database

The various issues have been discussed in the previous two options, so we only need here to discuss what this configuration would offer.

Advantages are related to the console, being able to access active and historic information as before (in Riftsaw 2) from a single source, and the ease of database and container administration.

Disadvantages are due to no isolation, so process definitions/versions between SCA applications could impact each other, and routing of requests from processes running in the engine to the appropriate SCA application. To overcome this second issue it will be necessary for the process instance to carry context information regarding which SCA application to route messages to - to be investigated.

Thoughts:

If a single engine/db approach is used, some of the problems can be avoided by scoping the process definitions to the application by name. This may need to be manually done, so puts the burden on the user to ensure this level of isolation. Would be good if this could be achieved automatically, but may not be possible without significant changes to ODE.

Although this approach may cater for sharing process instances across SCA applications, not sure there is a use-case for this, and would be problematic, as we would not be sure where to route outgoing requests from the process instance.

In an SCA (ESB) context, its possible that more transient process definitions would be used. However this would still have the same process definition management, and outbound request routing, issues that a persistent process definition would have.

Currently I think we need to work on the assumption that we have a single engine and database, and require the user to deal with process definition version issues across SCA applications. This is not that different to the user's responsibility with riftsaw 2, where they still needed to be aware of different process definitions and versions deployed within the app server.

Therefore the remaining issue that needs to be solved in this scenario is the routing of messages to the correct SCA application.

Therefore the remaining issue that needs to be solved in this scenario is the routing of messages to the correct SCA application.

I think the best way to deal with this at the moment is to simply state that SCA/switchyard apps within a particular SCA domain must have distinct BPEL process names - so if it is necessary to have the same process in different composites, then they would need to have different names.

Based on having unique names, we can statically initialise an understanding of what processes have outbound references to which services.

In terms of management/database issues, this could also be on an SCA domain basis - but that is for later consideration when looking at how best to integrate the BPEL console with other Switchyard management tools.