Scribble.orgCommunity Documentation

Chapter 5. WS-BPEL Services

5.1. Generating
5.1.1. Known Issues
5.2. Deploying
5.2.1. ActiveBPEL

5.1. Generating

Note

TO DO: This documentation is specific to running the loan approval examples - needs to be made more general.

Now it is time to generate the WS-BPEL. This is achieved by selecting the "Choreography->Generate->WS-BPEL" menu item from the context menu for the 'loanapproval.cdl' file. This creates a new sub-folder called 'loanApprovalProcess_wsbpel' containing a .bpel file per BPEL process and a .wsdl file per BPEL process, which contains additional definitions related to partner link types.

At this stage it would be appropriate for an implementer to modify these BPEL definitions to insert custom code in place of locations where 'silentAction' CDL activities had been defined. However, in this example there are no such activities - everything is generated into the three deployable processes.

Note

Currently the 'customer' participant is also generated, although this cannot be deployed as a BPEL process because it is the client.

  1. Initial Receives

    If an endpoint project results in activities occuring prior to the first receive, then WS-BPEL deployment errors will occur. Static verification will be performed to detect this situation prior to projection of these endpoints.

    In the example CDL that can be run, you will see that the conditions have all been defined as 'globalizedTrigger' functions. This is to make sure that the condition is not projected incorrectly to the LoanApprover? and LoanAssessment? processes. Otherwise this would result in the initial receive activities for those processes being contained within a switch activity.

  2. Detection of multples receives for the same message within a choice

    At the moment, the example projects the behavior for the LoanApprover? service as having a choice between two paths, both triggered by the same 'approve' operation.

    This does not result in an error within the ActiveBPEL engine, and so has been left at present. However, verification for this situation will be added, to prevent a projection having a choice with two identical receives, as this results in an ambiguity as to which path should be selected.

    To overcome this ambiguity in the supplied example, we have just ensured that both paths have the same behavior.

  3. Sub-Choreographies

    Use of sub-choreographies is supported. The only area where there is currently no support is where the behavior associated with a particular participant is initiated inside a sub-choreography.

    Isolated choreographies and choreography completion conditions are not mapped currently.

  4. CDL Functions

    In general, only the 'getVariable' and 'globalizedTrigger' CDL functions are currently supported. Use of any other function will result in a WS-BPEL specific validation error being produced.

    The only exception is the 'when' CDL activity, which can only be used with the 'hasDeadlinePassed' and 'hasDurationPassed' CDL functions, which is used to wait for the specified deadline or duration (i.e. it maps onto the WS-BPEL wait activity).

If other WS-BPEL endpoint projection issues are found, then please report them to the Bugs tracker on the pi4soa sourceforge site, preferrably with a CDL example that demonstrates the issue.

5.2. Deploying

Deploying a WS-BPEL process is currently platform specific, as there is no standard for defining how a BPEL should be packaged, with its relevant artefacts, for deployment into a runtime environment. Therefore this section outlines the deployment mechanisms used for each of the supported WS-BPEL runtime environments. If the relevant runtime environment is not supported, then it will be the responsiblity of the user to manually package the BPEL processes (and other artefacts) in the appropriate manner. If you would like you WS-BPEL platform to be supported by the pi4soa tools suite, then please register a Feature Request at our sourceforge site.

Note

This documentation is specific to deploying the example - need to make more generic.

The next step is to create a deployment package for each of the BPEL processes, that can be distributed to the ActiveBPEL runtime engine.

This is achieved by selecting the 'Choreography->Deploy->WS-BPEL' menu item from the context menu for the 'loanapproval.cdl' file. This creates a '.bpr' file for each of the BPEL processes within the 'loanApprovalProcess_wsbpel' folder.

Before copying the deployment (.bpr) files into the ActiveBPEL “bpr” runtime directory (e.g. in the Tomcat root directory), first remove (or move) any existing files from that directory that represent the ActiveBPEL implementation of the example. In ActiveBPEL1.1, these files are called 'bpel_example.bpr' and 'bpel_example_web_services.wsr'. In ActiveBPEL2, the file is called 'loan_approval_services.wsr'.

Then copy the new ".bpr" files into this directory and start the engine (e.g. if Tomcat, then use the startup script in the bin folder).