Asynchronous Web Service

Question

I am looking for an approach to decouple my sytem. Traditional approach I have done before is to construct custom xml message, send the message to JMS queue. Another process (MDB) retrieve the message from the queue, parse the message and invoke the corresponding services.
This approach is working, however, it involves a lot of work (to construct and parse the xml message).
I am looking for the new approach based on asynchronous Web Service.
Read through the document:
http://e-docs.bea.com/wls/docs81/webserv/jmstransport.html#1054482
In weblogic 8.1, you can use JMS transport to invoke a webLogic web service. Also, you can create asynchronous client to invoke web service. Have some questions here:
1. the document did not emphasize the advantage to use JMS based web service. It sounds like it's just an alternative approach comparing the traditional http based approach. does JMS based web service mean more reliable?
2. for me, to use JMS base web service with RPC (synchronous) type of client sounds funky. Is there a way to specify that the JMS based web service is for aynchronous client only?
3. the way asynchronous client work is to create a temp response queue to receive the web service response. Is there any performance penalty? For my case, I never expect any result to come back - all actions return void (why? cause all the services interact with the same database).
4. continue to question 3. Is there a way to specify that the asynchronous client never expect any result and don't create a temp response queue? Also, if the return result is void, whether or not the response queue is still created?
Ok, here's the short question - what I am looking for is an alternative approach to replace the traditional approach. Sounds for me, it should be a combination of JMS based web service and asynchronous client. Weblogic seperate them into two seperate features. How to efficiently use them together?
thanks.

Answer 1

1. the document did not emphasize the advantage to
use JMS based web service. It sounds like it's just
an alternative approach comparing the traditional
http based approach. does JMS based web service mean
more reliable? JMS transport is not emphaized because it is not a
standard. You can not use JMS transport and interop
with other vendors.
>
2. for me, to use JMS base web service with RPC
(synchronous) type of client sounds funky. Is there a
way to specify that the JMS based web service is for
aynchronous client only? Sorry, no.
>
3. the way asynchronous client work is to create a
temp response queue to receive the web service
response. Is there any performance penalty? For my
case, I never expect any result to come back - all
actions return void (why? cause all the services
interact with the same database).
4. continue to question 3. Is there a way to specify
that the asynchronous client never expect any result
and don't create a temp response queue? Also, if the
return result is void, whether or not the response
queue is still created?The response queue is created when the JMS connection is
created. Hence the temp queue is created always. I agree
that it is nice to have an option to turn it off. Will try
to add it in 9.0
>
Ok, here's the short question - what I am looking for
is an alternative approach to replace the traditional
approach. Sounds for me, it should be a combination
of JMS based web service and asynchronous client.
Weblogic seperate them into two seperate features.
How to efficiently use them together? You are right, JMS transport and async client can be
combined to form a scalable system. It is not
optimized for this use case in 8.1, because the focus
was on portability (async client is WLS specific) and
interop.
An alternate approach will be to expose a POJO as
web service. POJO can drop the incoming data to a
JMS queue. Then use an MDB to drain the queue to
do the actual work. This way, the client will have
a typed interface (in WSDL) to work with and it can
use the normal HTTP transport. Since the POJO is
just doing an enqueue, I think it can scale well too.
Regards,
http://manojc.com