This page will be used to outline design thoughts related to the RiftSaw version 3.
The aim of RiftSaw 2.x has been to provide a JBossAS server component that integrates with jbossws and jbossesb to provide the communication layer. This has meant integrating with two different technologies, each with their own APIs. If we also wanted to support REST, then we would have had to deal with a further set of APIs, without even considering whether the REST support is provided by jbossws-cxf or RestEasy. Similarly there will be other integration technologies that may need support in the future, and it is not feasible or sensible that these different integrations should be handled in the riftsaw project.
Therefore the intention is that RiftSaw version 3 becomes the BPEL component implementation within the Switchyard project, and thus delegates integration issues to the Switchyard project, allowing riftsaw to concentrate on providing the management and execution of BPEL processes within a JBoss environment.
Components of the Project
This section will discuss the various components that will form the architecture for RiftSaw 3, and generally also maps onto the top level modules within the git repository for the project.
The main aim of this project is to isolate the code and dependencies necessary to run an embedded version of an ODE 1.x BPEL engine, and provide a simple API to enable (a) a BPEL process to be invoked, and (b) a BPEL process to invoke other services.
To achieve this, the engine will need to support
- ability to use an embedded db, to minimise initial setup for simple installations
- ability to use external dbs when configured into production environments
- integration into clustering environments
- deployment of BPEL processes into a repository
- invocation of BPEL process instance
- configuration of an external service invocation provider
Management of BPEL Processes
In RiftSaw 2.x, the BPM console is used to management BPEL process definitions and instances using information stored in the ODE database, as well as the Activity Monitoring Event tables. The console is deployed as a Web App.
The intention is to continue with this approach, with the management console being separately deployable into a suitable container, and configured to locate the appropriate riftsaw database.
When RiftSaw is bundled with other projects (e.g. switchyard), then those projects can distribute and deploy the console as an integral part of their solution.
The management capabilities will probably be enhanced to include manually invoked commands for creating the schema in external databases, rather than the current approach which is used, where a JBoss mbean performs this automatically.
Currently riftsaw recognises when the app server is shutting down, and processes are not really being undeployed. Similarly on startup, if a process definition already exists in the db, this is not an issue. However in a Switchyard deployment we need to make sure the same is true, otherwise process definitions may be undeployed incorrectly, causing long lived process instances to be terminated. The aim is to (where appropriate) support the same approach as used by RiftSaw 2.x - which may not apply for the truely embedded environment.
This module will provide the bridge between the implementation of a Switchyard component (for BPEL) and the RiftSaw embedded engine described above.
Clustering support in SwitchYard
Refer to this page for the clustering feature in switchyard.
Although Switchyard uses the SCA assembly model, it is not fully SCA compliant. Therefore it may be useful for the project to also provide an SCA component implementation that can be included in the Tuscany SCA implementation. Although Tuscany currently has a BPEL implementation, this requires pre-configuration of a database, and does not deal with the issues of BPEL processes being deployed and undeployed when the infrastructure is started and stopped, thus causing long lived process instances to be deleted, or considered invalid due to UUID changes.