This exercises exploits standard web services communication mechanisms to perform a simple distributed computing operation. In this scenario, an information is sent to a partner via web service communication channel, and then a transformation is applied, before sending the information back to the original requester. In this case, we ask you to apply a trivial transformation: however, it's not hard to imagine, once you substitute our "encoding" tool with some serious encryption algorithm, to use a similar scenario to implement a secure communication channel among different web services.
The exercise require you to take advantage both of BPEL service orchestration technology and ESB.
The BPEL process has to meet the following requirements:
It has to expose two different SOAP operations, which will serve as input/output access points.
The first operation accept a message of type string as input parameter, and returns a string as well. This is the operation that has to be invoked directly.
The second operation instead will receive a message comprising a message and a process ID (both of which are strings): this is the operation intended to be used by Reverser service to communicate back to BPEL process. The second operation also returns a message of type string.
The BPEL process will forward the message M to the Listener service, together with a process ID uniquely identifying the process.
It will then wait for the Reverser service to contact it and send it the reversed message.
It then reverses the original message, and check if it corresponds to the one received from Reverser.
If it match, returns 'OK' to the Reverser Service, otherwise returns 'Wrong'.
Remember to define a correlation set on step 5 (the operation that waits for incoming messages). If you follow the steps listed before, you should have all data needed to enable correlation in messages exchanged by BPEL process with its partners.
The Mule ESB application must contain the following service components (svc):
Listener: this svc is exposed as a webservice, and it will be invoked from the BPEL application by sending a message M to this component. The Listener component will receive the message M and send it via p2p communication to Reverser service component.
Reverser: this svc is listening a message from the Listener svc. Once it receives the message M, it reverses the character order of the message and dispatch it to a webservice that will be defined by the user in the BPEL application.
We will use CXF for exposing a service component as a webservice (JAX-WS), and AXIS or CXF for invoking webservice from our service component.
Hint
Use the Mule webservice documentation: http://www.mulesoft.org/documentation/display/MULE2USER/Using+Web+Services
Diagram
This is a general view of how the message will flow in the ESB application. The process starts when a message is received from the BPEL application to the webservice of the Listener component. The listener component sends the message via p2p to the Reverser component which will reverse the order of the received string. Finally, the Reverser component will invoke a webservice defined in the BPEL application for sending the reversed message.
Important: When BPEL invokes the Listener, it will send also a process identifier (id) that should be send it back without modifying its value.
BPEL implementation (50%)
- Defining WSDL and XSD for process correctly
- Implement correlation correctly
- Implement the reverse operation as required
- Integration finished with ESB
ESB implementation (50%)
- Implement Listener service component correctly
- Implement Reverser service component correctly
- P2P communication
- Integration finished with BPEL