Use-cases

Version 2 by Julien Lesbegueries
on Apr 21, 2011 16:38.

<< Changes from 1 to 2

compared with

Current by Julien Lesbegueries
on Apr 21, 2011 16:40.

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (2)

View Page History

...

h1. EasyBPEL use-cases

This guide explains how to use EasyBPEL thanks to 2 use cases. These 2 use cases show main supported features.

For each use-case, a description and objectives (what is tested) is made. The first use-case is a concrete well-known use-case: Travel Agency booking. The second use-case is more technical and presents late-binding BPEL intrinsic features.

[Petals Studio|http://www.petalslink.com/produits/petals-studio] is used to build theses use-cases. We advise to use it since it contains a certain number of eases and, in particular, an embedded version of the BPEL validator tool provided by EasyBPEL.

You can get more information in the [Easy BPEL Javadoc|http://easybpel.petalslink.org/javadocs.html].

h2. Travel Agency use-case

h3. Summary

This use-case is a booking service corresponding to an orchestration process of 3 partners services. The client has to give his name and address, his departure and arrival dates and places.

The process returns to the client a message to indicate either the booking has successfully occurred and his reservation Ids, either the booking of one of the partners failed.

These partners are an airline booking service implemented by a Web Service, an hotel booking service implemented by a batch file deposit and the car booking service, that is based on a WSDL 2.0 description. The car booking service is implemented by a Web Service.

It can be noticed that there is no functional fault handling in this use-case. Although try/catch features have been already implemented, it is not used since compensation feature is not yet available. A further significant work will consist in adding compensation, that should be tested in this use-case.

h3. Objectives

This process validates the flow activity, asynchronous invoke (thanks to the hotel partner), correlation and WSDL 2.0 compliance.

h3. Description

You can find the needed files [here|^travelAgency.tgz] (partners folder), that is to say the BPEL file, its WSDL and partners WSDLs. You should see the following BPEL process.  !screenshotbpel.png|align=center!

In order to test this use-case, you can use this request for the first Receive:

{code:lang=xml|title=Request message for the first BPEL process Receive (launches the process).}<payload xmlns:agen="http://org.ow2.petals/demo/travelagency/agency/">
<agen:lastname>Lele</agen:lastname>
<agen:firstname>Juju</agen:firstname>
<agen:startDate>2001-10-26T21:32:52</agen:startDate>
<agen:endDate>2001-12-26T21:32:52</agen:endDate>
<agen:address>chezwam</agen:address>
<agen:from>A</agen:from>
<agen:to>B</agen:to>
</payload>{code}

For the asynchronous confirmation of the hotel, you can simulate it thanks to a xml file containing:

{code:lang=xml|title=Hotel partner response file.}
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<agen:hotelConfirmationRequest xmlns:agen="http://org.ow2.petals/demo/travelagency/agency/">
<agen:lastname>Lele</agen:lastname>
<agen:firstname>juju</agen:firstname>
<agen:validated>true</agen:validated>
<agen:reservationId>987654321</agen:reservationId>
</agen:hotelConfirmationRequest>{code}

Be sure the lastname in this message is equal to the lastname of the first message, because of the correlation. Indeed, the correlation used in this use-case is defined here:

{code:lang=xml}<bpel:correlationSets>
<bpel:correlationSet name="hotelCorrelation" properties="ns1:clientName"></bpel:correlationSet>
</bpel:correlationSets>{code}

It is initialized in the invoke:

{code:lang=xml}<bpel:invoke name="InvokeHotel" partnerLink="hotelpartner"
operation="bookRoom" inputVariable="hotelpartnerRequest">
<bpel:correlations>
<bpel:correlation initiate="YES" set="hotelCorrelation" />
</bpel:correlations>
</bpel:invoke>{code}

The correlation is set thanks to a property, defined in processArtifact.wsdl. This property is linked to at least two aliases:
{code:lang=xml}<vprop:property name="clientName" type="xsd:string"/>
<vprop:propertyAlias messageType="wsdl1:bookRoomRequest" part="parameters" propertyName="tns:clientName">
<vprop:query><\!\[CDATA\[\]\]></vprop:query>
</vprop:propertyAlias>
<vprop:propertyAlias messageType="wsdl2:hotelConfirmationRequest" part="hotelConfirmationRequest" propertyName="tns:clientName">
<vprop:query><\!\[CDATA[/wsdl2:lastname]\]></vprop:query>
</vprop:propertyAlias>

{code}

h3. Use-case as a Junit Test

You can test this use-case thanks to this [zip|http://easybpel.petalslink.org/doc/easybpel.usecase.travelagency-1.0.zip]. Unzip it and launch the script../junittest.sh or .\junittest.bat
You also have in this archive all the needed files that you should have created reading this use-case.

h3. Use-case deployment and test run in Petals ESB (with Petals BPEL engine)

It is possible to use EasyBPEL in Petals ESB thanks to petals-se-bpel JBI component. Indeed this component encapsulates EasyBPEL library and allows it to receive or send JBI messages in the bus.

To build this use-case, you have first to prepare partners.

First one is the Airline partner represented by a Web-Service (a war file to install in the webapp folder of your application server). You can find this war [here (airlineWS.war)|http://easybpel.petalslink.org/doc/usecase1travelagency.zip].

The second one is the Hotel partner represented by a batch file. You have to define a MYHOME variable representing your home folder, and then to create the following tree in it:
{code:lang=xml}TP
| -partners
|-hotel
|-INCOMING_RESERVATION
|-OUTGOING_CONFIRMATION
{code}

The last partner is the car booking service. It is implemented by a Web Service (Axis2 aar to depose in services folder of Axis2 webapp) and it is described thanks to a WSDL 2.0 description (available in the same archive).

Once partners are ready you can create SUs in order to prepare their invocation in the bus.

For airline and car booking partners, you have to create for each one a SU "Provide" for the BC SOAP component in order to import the Web Service into the bus, thanks to the Petals Studio's import service (SOAP).

For the hotel partner, you have to create a SU to export the Incoming Reservation folder thanks to the BC FileTransfer, and to create a SU to import the Outgoing Confirmation folder thanks to the same component.

Once you created all the SUs thanks to Petals Studio, you have to install them on a running Petals, where BPEL, SOAP and FileTransfer Components are installed and started.

You have also to install a SU for the BPEL component, in order to set the Travel Agency reservation.

Once your BPEL project is validated (thanks to the BPEL validator available [here|https://forge.ebmwebsourcing.com/frs/download.php/43/easybpel.model.bpel.tools.validator-1.0-with-dependencies.zip] or by using embedded validator in Petals Studio), you can transform it as a Service Unit for the [Petals BPEL engine|http://download.forge.objectweb.org/petals/petals-se-bpel-1.0.zip], in order to test it in Petals BUS.

h2. Dynamic Invocation use-case

...

h3. Summary

This use-case is useful to understand the invoke mechanism in BPEL. When a partner is defined, only the interface can be provided. The endpoint to call at run time can be dynamically defined. In this use-case, the endpoint (EndPointReference) is filled once thanks to a in message, once with a static assign.

h3. Objectives

The process validates the dynamic assign of an endpoint.

h3. Description

You have to create a SU for BPEL component thanks to Petals Studio thanks to needed files available [here|http://easybpel.petalslink.org/doc/usecase2dynamicinvocation.zip]. The message to send as input of the BPEL process is the following:
{code:lang=xml}
<dpl:dplOperation xmlns:dpl="http://j2ee.netbeans.org/wsdl/dpl"
xmlns:add="http://www.w3.org/2005/08/addressing">
<dpl:DPLRequest>
<ServiceRequest>Hello World\!\!\!</ServiceRequest>
<dpl:EPR>
<add:EndpointReference>
<add:Address>
{http://j2ee.netbeans.org/wsdl/echo/}echoService::echo1Port
</add:Address>
</add:EndpointReference>
</dpl:EPR>
</dpl:DPLRequest>
</dpl:dplOperation>
{code}

You can see that an EndpointReference is embedded in this message. It corresponds to the endpoint of a service invoked during the BPEL process (called echoService). It is an address defined in a EndpointReference tag. The syntax is the service as a QName with the standard syntax, then the endpoint (or port) separated by "::":
{code:lang=xml}
{namespace}service::endpoint
{code}

Here is an example of assign to dynamically set an endpoint. If the "from" part would be defined thanks to a first invoke to a endpoints registry partner, we could have a real dynamic invocation at runtime:
{code:lang=xml}
<bpws:assign name="Assign3" validate="no">
<bpws:copy>
<bpws:from>
<bpws:literal>
<sref:service-ref xmlns:sref="http://docs.oasis-open.org/wsbpel/2.0/serviceref">
<ns1:EndpointReference xmlns:ns1="http://j2ee.netbeans.org/wsdl/echo/">
<wsa:Address xmlns:wsa="http://www.w3.org/2005/08/addressing">
{http://j2ee.netbeans.org/wsdl/echo/}echoService::echo2Port
</wsa:Address>
</ns1:EndpointReference>
</sref:service-ref>
</bpws:literal>
</bpws:from>
<bpws:to partnerLink="echoPartnerLink"/>
</bpws:copy>
</bpws:assign>
{code}

EasyBPEL Overview

Use-cases

Changes (2)