Some work has been done on moving to BPMN2 as the choreography representation, to eventually replace WS-CDL within the Savara tools.
If you want to try the current snapshot version, I would first suggest setting up a separate Eclipse Indigo JEE environment and then downloading and installing the latest set of plugins (all plugins under both Savara and Savara Dependencies categories). The reason for using a separate fresh Eclipse environment each time these plugins are downloaded is that they contain snapshot plugins which don't change their name (e.g. id) with each build - so if you tried to install a later version of this nightly build, it wouldn't actually change the plugins, so you would still be using the old version - so best to avoid any potential confusion by using a fresh environment each time.
The plugins include the Eclipse BPMN2 modeller, which is a work in progress currently. There are some issues when creating choreographies from scratch, and some opportunities to improve usability, but these will be addressed as a separate task. In terms of this thread, I just want to focus on how a ready made choreography would be used - so have attached a complete example as the focus of these discussions.
There are a couple of issues that may need discussion:
- Firstly, the SCA Java generation is not working, so this is a known issue.
- BPMN2 process generation
- Currently this is not executable, although this would eventualy be the aim. This will require additional information within the generated process definition (e.g. message definitions), but will also need to cater for users adding implementation details. Depending upon whether the implementation details are going to be specified using rules, or Java code, we may need to generate different types of project - and possibly include relevant dependencies. We need some thought about whether the 'generator dialog' needs to be changed to indicate different flavours of target container.
- Should external message exchanges be represented using a collaboration diagram - so additional pools, but empty as the diagram only shows the details of one participant? Or should the message details just be part of the underlying model and not represented in the diagram? Or should this be optional?
- BPEL/Switchyard BPEL generation
- Current known issue is that the client side wsdl is also generated with the server (e.g. Logistics service also includes the wsdl for the Store).
- Unlike the WS-CDL based generation, the XSD files are not currently copied from the choreography project (note: I have only attached the choreography file, as the xsds are not copied anyway)
- Given the new focus on the next generation ESB platform (e.g. switchyard) which has riftsaw embedded as its BPEL component, not sure whether there should be a separate 'BPEL' generation option, which was previously used for Riftsaw as a standalone module within JBossAS 5 and 6. One alternative would be to turn this generation option into a more pure Apache ODE BPEL generator - so for people not using Switchyard, they have a generic option for generating relevant artifacts.
- The most important issue has been left until last - currently the namespace of generated WSDLs and BPEL processes is the target namespace of the BPMN2 choreography, as this is the only place a namespace can be easily defined within the BPMN2 choreography. The issue is that the generated Artifacts.wsdl does not like importing multiple wsdl's associated with the same namespace. In general each service should be in its own namespace anyway. We have a couple of options as I see it - (a) find a way to enable the namespace to be associated with the participant, or (b) derive a namespace based on the combination of the target namespace and the participant name. The easiest option is obviously (b), and may provide a good initial solution, but it should also be possible to associate a participant with existing service interface (and namespace). This could be achieved by defining the service interface in the BPMN2 choreography, and then associating the participant with it. So possibly if no interface has been defined, then by default derive a participant specific namespace, but if defined we then use the specified one.
PurchaseGoods.bpmn.zip 2.9 K