One more JBI component : SOAP Proxy

I just developped a new JBI component for Petals ESB. This component, named ‘petals-bc-soapproxy’ is based on the work I did on the standard SOAP binding component and provide an easy way to proxify SOAP based Web services with Petals ESB.

This component, based on Apache Axis2, uses a small part of WS-Addressing to provide the proxy feature. ‘Small part’ means that for now, by using Axis2, I need to bypass the mustUnderstand attribute of the WS-Addressing elements. Why? Because I need to use the WSA:To element to specify the Web service I want to finally invoke and I need to set the mustUnderstand attribute to false to bypass one implementation detail on Axis2 which is not ‘friendly’ with my own implementation. Why (again)?… By setting some mustUnderstand attribute to true in the SOAP message header, it means that the SOAP engine (ie Axis2) must understand the header during message processing. A mustUnderstand attribute set to true in the WS-Addressing header means that the SOAP engine must handle the WS-Addressing information and here I do not want to. If I set this attribute to true, I need to add the Axis2 addressing module, which will handle the WS-Addressing header, and will put all the addressing information in the Axis2 message context. I can do that and get the information from this context for for some reason it does not work like I expect… Maybe an Axis2 update will fix this…Need some time to investigate, and for now time is not my friend… So, here is how it work :

1. The SOAP client sends the SOAP message to the Petals SOAP Proxy (by default this service is exposed at http://localhost:8085/petals/services/SOAPProxyWebService). The SOAP message header contains the WS-Addressing information which will be used to reach the final Web service. A SOAP message sample is for example :


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsap="http://wsapi.petals.dsb.soa4all.eu/">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://wsapi.petals.dsb.soa4all.eu/HelloService/sayHello</wsa:Action>
<wsa:To>http://localhost:7600/petals/ws/HelloService</wsa:To>
</soapenv:Header>
<soapenv:Body>
<wsap:sayHello>
<!--Optional:-->
<arg0>Say hello!</arg0>
</wsap:sayHello>
</soapenv:Body>
</soapenv:Envelope>

where http://localhost:7600/petals/ws/HelloService is the final Web service I want to invoke.

2. The SOAP message is handled by the SOAP proxy component, transformed as JBI message and sent to the right JBI endpoint.

3. The JBI endpoint gets the WS-Addressing information from the JBI message, the SOAP message from the JBI message payload and send all of this stuff to the final Web service. Invokcation response is sent back to the initial consumer through the ESB.

A simple schema of what happens with three ESB nodes is given in the figure below :

So, the main question is why using such a proxy and why not invoking the service directly? There are many answers to these questions and since I already said that the time is a missing resource, it will be probably part of a future article…

The first version of the component is available on the OW2 SVN repository under my sandbox (have a look to http://websvn.ow2.org/listing.php?repname=petals&path=%2Fsandbox%2Fchamerling%2Fproxy%2Fpetals-bc-soap%2F#path_sandbox_chamerling_proxy_petals-bc-soap_)

Note : Using SOAPUI for WS-Addressing testing works fine (even if I had some exchanges with SOAPUI guy (http://twitter.com/olensmar) on Twitter…)… Sorry to have doubts on SOAPUI!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s