|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (6)
View Page History
...
{children:excerpt=true} 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 Figure 3 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.
!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.
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.
...<bpel:extensionActivity>
<inva:invokeaddressing name="invoke1"
<inva:invokeaddressing name="invoke1"
partnerLink="asynProvider"
portType="wpsServiceNS:RasterResampling"
operation="ExecuteProcess_RasterResampling_ASYNC"
inputVariable="wpsAsynServiceInputMessage"
outputVariable="wpsAsynServiceOutputMessage"
header="rasterCallback" />
</bpel:extensionActivity>
</bpel:extensionActivity>
...