2 Replies Latest reply on Jan 24, 2012 5:23 AM by objectiser

Using BPMN2 choreography in place of WS-CDL

objectiser Jan 17, 2012 5:58 AM

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
1. 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.
2. 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
1. 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).
2. 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)
3. 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.
4. 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.

Thoughts?

PurchaseGoods.bpmn.zip 2.9 KB

1. Re: Using BPMN2 choreography in place of WS-CDL

jeffdelong Jan 23, 2012 11:38 PM (in response to objectiser)
This looks really great.

1. SCA/Java - not so important. I mainly saw it as an experiement with Savara CDL while SwitchYard was still in incubation. I am much more interested in creating SwitchYard services.

2. BPMN2 Process Definition
     1. The challenge here is what to really generate in terms of a BPMN2 Process model. What you have generated is a sequence of receive and send activities. What would be more interesting is a sequence of service tasks that perform the work, e.g., SwitchYard service tasks, in the same way that the BPEL process flow is a sequence of invokes on Web Services. I want to try drawing this orchestration manually, and then we can review it and see if it could be generated from the choreography. (I attached a first cut).
     2. I don't think a collaboration diagram is required. Perhaps Intermediate Message Events?
3. BPEL / SwitchYard BPEL
     I think what you have here is fine, being able to generate both, though I can see in the future dropping the pure BPEL generation and only supporting SwitchYard.

PurchaseGoods_Store_Process.bpmn2.zip 2.2 KB
Actions
2. Re: Using BPMN2 choreography in place of WS-CDL

objectiser Jan 24, 2012 5:23 AM (in response to jeffdelong)

Hi Jeff
Jeff DeLong wrote:

1. SCA/Java - not so important. I mainly saw it as an experiement with Savara CDL while SwitchYard was still in incubation. I am much more interested in creating SwitchYard services.

Agree - the integration is currently too restrictive, so in its current form it will be of limited use, and is hard to maintain. So is useful to demontrate being able to simulate a scenario against an executing service, but once we have a good integration with switchyard, this will be the template for future integrations - so we may need to drop the tuscany support unless a better way of integrating with it can be found.

2. BPMN2 Process Definition
1. The challenge here is what to really generate in terms of a BPMN2 Process model. What you have generated is a sequence of receive and send activities. What would be more interesting is a sequence of service tasks that perform the work, e.g., SwitchYard service tasks, in the same way that the BPEL process flow is a sequence of invokes on Web Services. I want to try drawing this orchestration manually, and then we can review it and see if it could be generated from the choreography. (I attached a first cut).
2. I don't think a collaboration diagram is required. Perhaps Intermediate Message Events?

Yes I think this is a challenge - we need to look at this from different perspectives.

If looking at this from a generic BPMN2 perspective, then if a communication occurs between two participants at the choreography level, then this must be represented by a send/receive of the message in the process. This can either be modelled as send/receive tasks, or using the intermediate message events as you mention.

However we also need to consider how this process may be executed in different environments (including switchyard).

The pure approach described above would be fine if the BPMN2 process is being executed within a process engine that is communicating through some integration layer (e.g. Web service stack). So this is the message driven process approach.

However what jBPM currently focuses on, and what your example represents, is a more task driven process. In this scenario, is the invocation of a particular task equivalent to an 'invoke' (i.e. a synchronous RPC call) and can therefore be considered equivalent to a request/response MEP in a choreography? If so, how do we associate that task(s) with the choreography participant they represent, and how do we associate multiple service tasks with the same participant?

My problem with the type of diagram you have provided is that it loses the information regarding the source/destination of the interaction. The same could be said about the process model currently generated by Savara, although internally within the model it would have the information, and if represented as a collaboration diagram, then each of the other participants would be graphically represented in the diagram as an empty pool.

So in summary I agree that we need to be able to generate something that can be executed within a BPMN2 engine embedded in switchyard (or any other ESB). The issue for me at the moment is whether the process model should change, or the BPMN2 engine integration. For example, if a BPMN2 process model is about integration with other participants, then possibly the ESB should just provide the wiring of the participant to an external service - so the BPMN2 process just sends or receives messages to/from a participant - and at execution time the ESB handles routing these messages to/from a service to which the participant has been mapped.

Not saying that the use of the 'service task' to invoke switchyard services is not useful, but this could be seen more as a mechanism for supporting the internal implementation of the process.

Regards
Gary
Actions

Go to original post