|
Home > Archive > WebSphere Application Server > December 2005 > Exposing queue based service as WebService using SIBus
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Exposing queue based service as WebService using SIBus
|
|
|
| I want to implement the following using SIBus in WAS 6:
A client calls a webservice (using SOAP/http) on the SIBus, the request is routed to a JMS destination (a queue) as XML and a Java component (e.g. a message driven bean) processes the request and replies to a SIBus JMS destination (a queue) using XML. The
SIBus then routes this as reply to the original webservice request.
Client -- SOAP/http -> SIBus -- XML/JMS -> Java Component -- XML/JMS -> SIBus -- SOAP/http -> Client
Is this possible? If so are there any tutorials/articles on how to do this. All I can find are articles showing how this is done in the following scenarios:
Client -- SOAP/http -> SIBus -- SOAP/http -> Webservice (external) -- SOAP/http -> SIBus -- SOAP/http -> Client
Client -- XML/JMS -> SIBus -- SOAP/http -> Webservice (internal) -- SOAP/http -> SIBus -- XML/JMS -> Client
Not being able to find a small tutorial/article on the subject is making me nervous, and looking at the documemntation has not made me much wiser
| |
| David Currie 2005-12-13, 7:56 am |
| First off the sanity check - is there a particular reason why you need
to receive XML/JMS? Could you not just use WAS as a gateway performing
protocol conversion from SOAP/HTTP to SOAP/JMS?
That out the way, yes, you can achieve this. I'm not aware of any
articles describing this capability but the logic would be along the
following lines: define an inbound SOAP/HTTP service but create a normal
JMS queue to use as the service destination. Apply a mediation to the
JMS queue that transforms the SOAP message to your XML format. The MDB
then listens on this JMS queue.
You have two options for handling the response:
1) If the endpoint listener is only used for this service then just
ensure that your initial mediation leaves the reverse routing path
unchanged, have your JMS application use the reply-to address from the
request message, and then apply another mediation to the endpoint
listener's reply destination that performs the XML to SOAP conversion.
2) If the endpoint listener is shared with other services then create a
second JMS queue. Have the first mediation add this queue on to the
front of the reverse routing path. When the JMS application uses the
reply-to address now, the message will be sent to this JMS queue first.
Apply your XML to SOAP conversion here and then let it follow the
remainder of the routing path on to the listener's response destination.
Clear as mud I'm sure!
Regards,
David
| |
|
| Thanks for the speedy reply. I was just starting to set up a test environment to try something similar out. As for the sanity check this is the situation:
There is a requirement for all services to be available as both SOAP/http and XML/MQ (e.g. XML/JMS - not SOAP/JMS). However for the internal application architecture we would prefer to be asyncronous (hopefully I got the spelling correct) in all communica
tion between components. Therefore we would like to implement the services once (using XML/JMS) and just put a http frontend on to satisfy the http-interface requirement. There are many reasons for wanting to be asyncronous in internal communication, but
key architectual points are to use a reliable protocol (which http is not) and provide a graceful degradation of service once the load is higher than the throughput (in peak periods).
| |
| David Currie 2005-12-14, 7:50 am |
| Thanks for the explanation. I've seen a variant on this before where the
WSGW has been used to transform SOAP/HTTP to SOAP/JMS and then Message
Broker has been used to strip off the SOAP elements before passing the
message on to the common XML/MQ destination.
Regards,
David
|
|
|
|
|