Oracle Service Bus, invoke asynchronous webservices

In this blog i will give a short overview on how to invoke asynchronous webservices from the Oracle Service Bus, and route the callback from the service back to some other endpoint (service) on the bus.
The flow we will create will look like this

Asynchronous webservice
To communicate from the Oracle Service Bus to an asynchronous webservice i used this (http://www.ewernli.com/web/guest/12) tutorial to get a service up and running on my glassfish.
After deployment the service (wsdl) will be available at : http://localhost:8080/AsyncTestImplService/AsyncTestImpl?WSDL
In this example the response (callback) is mocked in SoapUI.

Let’s test the service first in SoapUI.

In the top left you will see the request payload of the service, and at the top right the response of it (acknowledge).
At the bottom left you will see the mockservice running which will capture the callback from the service.
The response we will get back from the mock is :

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Header>
		<RelatesTo xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">ws:uniqueAddress</RelatesTo>
	</S:Header>
	<S:Body>
		<ns2:response xmlns:ns2="http://ewe.org/">
			<arg0>hello you [http://127.0.0.1:7777/]</arg0>
		</ns2:response>
	</S:Body>
</S:Envelope>

In our scenario will will not be mocking the callback, but route it back to an other resource on the service bus. In this case a new proxy service which will deal with the callback response.

Oracle Service Bus
For this scenario we will need the next list of resources

  • requestps – start endpoint of the osb flow, based on the wsdl of the the service deployed in the glassfish.
  • requestbs – service based on the endpoint of the service running in the glassfish (this will eventually execute the service logica)
  • responseps – any soap service which will receive the callback of the asynchronous service call.
  • responsebs – any soap service with jms endpoint, which will put the received callback in the queue.
  • testwsdl – the imported wsdl of the service running in the glassfish
  • XMLSchema_738301149 – generated xsd used by the imported wsdl

We will start with a call to the requestps service.

This service will route the request 1 on 1 to the requestbs. The requestbs is a wsdl-based http service based on the wsdl of the asynchronous webservice, with ‘http://127.0.0.1:8080/AsyncTestImplService/AsyncTestImpl
‘ as endpoint (glassfish). To inform this service where to deliver the callback response we need to just edit the soap-header which we will send to the service.

The flow of the requestps will look like this :

The route will look like this :

In the assign we will assign this to the header variable :

<soap-env:Header xmlns:ns1="http://schemas.xmlsoap.org/ws/2003/03/addressing">
	<ns1:MessageID>ws:uniqueAddress</ns1:MessageID>
	<ns1:ReplyTo>
		<ns1:Address>http://localhost:7001/AsyncTest/invoke/responseps</ns1:Address>
	 </ns1:ReplyTo>
 </soap-env:Header>

In here we will assign the address to which the service can reply the callback. In our case this will be a new endpoint on the service bus (resource responseps).
This doens’t have to be a static xml payload.

The responseps proxy service will receive the callback. This proxy service is an any soap proxy service and will receive the whole soap-envelope of the callback.

This service will route 1 on 1 to the responsebs.
This is a any soap business service with jms transport (endpoint jms://localhost:7001/TestCF/TestQueue). So the whole soap-envelope will be stored in the TestQueue queue.
In weblogic we created both the TestCF connection factory and the TestQueue queue.

Test the flow
Go to the sbconsole and use the testconsole of the requestps to invoke the service on the bus

And the response of the invoke :

We received back an empty sayHelloResponse. This is because we will receive the callback on the responseps resource on the bus.
Now go the queue to see the content :

It looks like the flow ended correctly. We invoked a service on the bus, this service routed the request to the asynchronous webservice running in glassfish. This service came back with a callback and this call is routed on the service bus to the queue which resists in weblogic.

SoapUI
Create a new project in SoapUI based on the wsdl of the requestps resource on the bus (endpoint http://localhost:7001/AsyncTest/invoke/testps/?WSDL).
Request payload

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ewe="http://ewe.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <ewe:sayHello>
         <!--Optional:-->
         <arg0>eric</arg0>
      </ewe:sayHello>
   </soapenv:Body>
</soapenv:Envelope>

Response

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
   <S:Body>
      <ns2:sayHelloResponse xmlns:ns2="http://ewe.org/"/>
   </S:Body>
</S:Envelope>

And the payload in the queue

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Header>
		<RelatesTo xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">ws:uniqueAddress</RelatesTo>
	</S:Header>
	<S:Body>
		<ns2:response xmlns:ns2="http://ewe.org/">
			<arg0>hello you [http://localhost:7001/AsyncTest/invoke/responseps]</arg0>
		</ns2:response>
	</S:Body>
</S:Envelope>

Resources
sbconfig.jar (export of oracle service bus resources)

Original blog

Share this Post:
Digg Google Bookmarks reddit Mixx StumbleUpon Technorati Yahoo! Buzz DesignFloat Delicious BlinkList Furl

4 Responses to “Oracle Service Bus, invoke asynchronous webservices”

commenter

Hi Eric,

very good post.
Is the OSB also able to provide asynchronous web services?
Regards,
Mike

commenter

Hello Eric,
Can you please provide your recommendation on design for below use case.
Use case: Poll for orders from the table and then perform customer synchronization(could take a while) and then submit the Order

For this use case I was thinking to leverage OSB to poll for orders from the table and then make async call to bpel process which will do customer synchronization. Once OSB callback proxy receives the callback from BPEL, OSB could perform order submission to Siebel. Does this design make sense? OSB being stateless, I am not sure though that how the initial payload from table will be preserved so that osb callback proxy could call siebel order service?

Would you recommend above approach? or you would rather recommend to implement using typical mediator-bpel combination(no OSB)

Thanks

Leave a Reply:

Name (required):
Mail (will not be published) (required):
Website:
Comment (required):
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>