{children:excerpt=true}

Main results of Genesis concern works on Petals ESB and the BPEL engine.



h1. Petals ESB as an Event Driven Architecture (EDA)

* [WS-Notification|http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn] library implemented
* [Broker component|wsstar:How to use libraries - Samples] according to the Brokered Notification,
* These results allow to build a distributed system of alerts sent by several environmental sensors and brokered to several alerts processing services. Final reports summarizing alerts are sent to the GENESIS portal. The following figure represents an example of architecture available with Petals ESB.

{center}
!ESB-EDA.png|border=1,width=600!
Petals ESB as an Event Driven Architecture.
{center}

Partners 1, 2, 3 or 4 can either be consumers or producers of notifications. The se-notification is a broker managing and aggregating subscriptions and registrations.

h1. Petals ESB enhanced for Geo-processing workflow compliance:

h2. Petals ESB Service extension of geo-processing workflow administration

Petals ESB is by default a JBI-based bus, with JBI mechanisms of service deployment and invocation. In particular, configuration artefacts are defined for service deployment:
* The Service Unit (SU) is a zip file containing a configuration file with information about interface / service / endpoint deployed, a WSDL describing the service to be deployed, and specific files related to the service. For example, a SU built to deploy a BPEL process will contain a BPEL file (and WSDLs of its partnerlinks).
* The Service Assembly (SA) is also a zip file containing a set of SUs that are assembled according to a particular service project.


{center}
!BPEL_SA.png|border=1,width=600!
List of deployed endpoints for a BPEL process.
{center}

These SAs are generally deployed onto the bus thanks to JMX connection. In the context of a BPEL process deployement, the following SUs are to be expected:
* A SU providing the BPEL process service (representing the W1 red endpoint in the figure).
* A SU exposing this BPEL process service outside the bus (in order to be visible by the portal for instance). This is represented in the figure by the W1 blue endpoint.
* Some SUs importing external Web Services (S1, S2, … Sn) involved in the BPEL process and making them visible inside the bus.

In the GENESIS context, workflow deployment is expected to be performed according to a specification (based on WPS). Basically it consists in a XML file containing WSDLs, XML Schemas and the BPEL to deploy. In order to be compliant with this mechanism, an additional administration interface (represented by the A blue endpoint in the figure) has been developed. It consists in an automatic generation of the SAs described above that is then deployed in a nominal way.

This is done thanks to a Petals ESB service extension (see the how-to for Services extensibility of Petals ESB (DSB?)).

h2. EasyBPEL extension for WS-Addressing compliance

EasyBPEL has been enhanced in order for the engine to be able to invoke asynchronous Web Service using WS-Addressing (see the [how-to on EasyBPEL extended activity|easybpel:How to implement an extended activity in EasyBPEL?]).

WS-Addressing is a specification from the W3C, defining basically means for Web Services addressing. It defines EndpointReference type and message information headers. The first construct contains an address localizing a Web Service. The second construct allows to correlate message exchanges between each other (messageID).
It is used in GENESIS context in SOAP headers of messages sent by services. In the following figure, WS-Addressing is used in the portal request in order for the BPEL engine to know where to send the final callback, and by the BPEL process itself in order to tell the Service A where to send the callback.

{center}
!bpel_genesis.png|border=1,width=800!
Typical BPEL extract from Genesis.
{center}

BPEL is represented as a set of nodes containing an activity:
* First, the receive activity allows a BPEL process to receive a message coming from the external environment (the portal for instance). As a BPEL process is defined by a WSDL and is considered itself as a Web service, the receive activity corresponds to an input message of an operation of an interface defined for this BPEL process.
* The assign activity allows copying some data into variables or partnerlinks.
* The reply activity allows the BPEL process to answer a request by sending a message. It corresponds to the output message of an operation of an interface defined for the BPEL process.
* The invoke activity allows to call Web services, called partnerlinks.
* The pick activity allows to wait for multiple incoming messages or alarms.
* The sequence of the represented BPEL process is to receive an incoming message from the portal, to reply a acknowledgement in order to tell the requester the processing is accepted or not. Then the BPEL process sends the request to the real Web service (Service A) that sends it self an acknowledgement. Then the pick activity waits for the Service A callback (until a defined time out). The callback is finally forwarded to the portal thanks to the last invoke.

This asynchronous mechanism of callbacks implies the use of metadata information in order for services to know where to send them. This is done, in the context of Genesis, thanks to the WS-Addressing specification, that will be explained in the next section. It allows basically to add callback address in message exchanges.

WS-Addressing is used in order to manage services asynchronism. It implies that the BPEL engine executing the workflow is able to send messages containing meta-data about callback address. It is done thanks to an extended activity developed upon EasyBPEL engine.
It consists in adding a specific attribute into invoke activities, corresponding to a variable containing particular EndpointReference (e.g a ReplyTo construct). This attribute is then used to build the SOAP header of the external message sent to the Web Service.
WS-BPEL extensibility is foreseen and consists in our case in the following extracts to add in the BPEL file.
First we have to define the WS-Addressing extension as following:
{code:xml}
<ns6:extensions>
<ns6:extension
namespace=
"http://easybpel.ebmwebsourcing.com/extension/activities/package/invokeaddressing"
mustUnderstand="yes">
</ns6:extension>
</ns6:extensions>
{code}

Then WS-Addressing headers have to be set. We use here the BPEL Assign activity:

{code:xml}
<bpel:assign name="affectReplyTo">
<bpel:copy>
<bpel:from>
<bpel:literal>
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>
http://soap-genesis.ebmwebsourcing.com/petals/services/RasterResamplingCallbackPort
</wsa:Address>
</wsa:ReplyTo>
</bpel:literal>
</bpel:from>
<bpel:to variable="rasterCallback" />
</bpel:copy>
</bpel:assign>
{code}

We assign here a ReplyTo value to the rasterCallback variable.
Finally a special invoke has to be used:
{code:xml}
<bpel:extensionActivity>
<inva:invokeaddressing name="invoke1"
partnerLink="asynProvider"
portType="wpsServiceNS:RasterResampling"
operation="ExecuteProcess_RasterResampling_ASYNC"
inputVariable="wpsAsynServiceInputMessage"
outputVariable="wpsAsynServiceOutputMessage"
header="rasterCallback" />
</bpel:extensionActivity>
{code}

The additional attribute header is used to add WS-Addressing metadata in the message going to be sent by the BPEL engine.