Wanted to discuss the issues that may be involved in deploying riftsaw as a component implementation in Switchyard. Switchyard uses the SCA assembly model, and may incorporate some other aspects of SCA over time.
Some of the issues that need to be resolved are:
1) Interface to BPEL implementation
The SCA spec allows components to be defined by an interface, and currently supports Java, WSDL 1.1 and WSDL 2.0 as the interface type systems.
If Java was to be used, then we would need tool support (either prior to packaging or on deployment) to create the relevant Java types for the WSDL interface.
Therefore for some deployment, support for the interface.wsdl construct would be better. Need to check whether this is supported in switchyard, or on the plans.
If we want the BPEL process to be used from both a WSDL interface and other components, then it may be good to have the WSDL to Java mapped classes available.
SCA and I am assuming switchyard have no concept of versioning - dispite the fact that SCA supports stateful components. This is generally because an ESB is used for processing mediation between services, and therefore only one version of the mediation rules/policies is relevant at a time.
However BPEL process instances are potentially long lived and therefore process versioning is necessary. In RiftSaw currently versioning is handled by leaving the previous deployed process definition in place, and deploying a new jar with the new BPEL process definition as a new version number. This enables existing process instances to continue to use the old process, while new processes use the new version.
One of the issues with the current approach is that, even though the old process instances use the old version of the BPEL process, only the web services associated with the latest version are made available. So if the WSDL interface has changed, then this will impact the older process instances.
Therefore one possible solution is to package the new BPEL process, along with the older process definitions that are stil relevant, in a single switchyard deployment - with the WSDL interfaces that need to be relevant to all of the versions. This ensures that the user continues to be aware that the WSDL interface needs to be backward compatible.
One other issue is that this would mean the BPEL process definitions must be unique across all switchyard deployments, as otherwise it would cause a name conflict. Therefore if a BPEL process needs to be reused, it must be done by invoking the service made available through a particular switchyard deployment.
3) Long running processes
BPEL processes can live for a long time, and the persistence support in riftsaw can cater for this. However individual invocations may also take some time to complete. Generally this needs to be within two minutes, as this is the default timeout for the http/soap transport - so most BPEL processes will generally be written to complete a req/resp within this timescale.
However we need to understand whether switchyard would be capable of handling a large number of invocations of this nature.
4) Clustering support
Need to understand how any clustering support in switchyard would work with riftsaw. Should not be a problem though.