Author |
Message
|
jamesyu |
Posted: Fri Feb 02, 2007 3:27 am Post subject: "SOAP over JMS" vs. wsdl:requestresponse |
|
|
Acolyte
Joined: 31 Jan 2007 Posts: 70
|
Hi All,
By looking at the way of how WSDL is generated from toolkit, there is something in toolkit I think either doesn't make sense or I am still missing some points. Below is a specific sample of following Wizards provided in toolkit. Please advise.
1. Create a message category file with Category usage of "wsdl: requestresponse"
2. Generate WSDL by selecting this message category file and "SOAP over JMS"
3. Assign a JNDI name to JMS destination (Notice that this JMS destination specifies what queue to take the request)
In this WSDL, it only specifies what JMS destination to take the request, it doesn't tell outside world what JMS destination to retrieve the response from. How come an outside Web service client created from this WSDL, say in RAD knows where to pick up the response from since this is a two-way operation with "wsdl: requestresponse"?
My flow begins with a MQInput node and ends with a MQOutput node. My Web service client generated based on this WSDL in RAD is able to send a request message over to MQInput node. But since this is a "requestresponse" operation, it just waits for response until timed out. It just simple doesn't know where to pick up the response from. Meanwhile, the response is already there on the MQOutput node in broker.
Any thoughts on this? How can I call such a Web service (SOAP over JMS, requestresponse type, created in broker) from, say a J2EE web application?
Thanks,
James |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Feb 02, 2007 3:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Your flow should end with an MQReply node.
The job of the requestor in any request/reply pattern over MQ/JMS is to instruct the server where to put the reply. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
pathipati |
Posted: Fri Feb 02, 2007 7:02 am Post subject: |
|
|
Master
Joined: 03 Mar 2006 Posts: 296
|
|
Back to top |
|
 |
jamesyu |
Posted: Fri Feb 02, 2007 7:50 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007 Posts: 70
|
jefflowrey wrote: |
Your flow should end with an MQReply node.
The job of the requestor in any request/reply pattern over MQ/JMS is to instruct the server where to put the reply. |
I tried it with two options:
1. replaced the MQOutput node with MQReply node
2. modified SOAP/JMS URI in WSDL by addind an additional parameter of replyToQueue jndi name, such as "&replyToQueue=jms/aReplyQueue"
Both didn't work. For option 2, I re-generated service client in RAD based on this revised WSDL. Still the client is waiting for the response. One thing I am not certain is, since I added a "replyToQueue" jndi name to URI in WSDL, how to configure this on WAS? Is there any default connection factory name and default jms destination name I should go with? Not sure how RAD handels this "replyToQueue=jms/aReplyQueue" when generating the service client... |
|
Back to top |
|
 |
jamesyu |
Posted: Fri Feb 02, 2007 7:59 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007 Posts: 70
|
Thanks for your URL. But the situation is little different from my case. That article demostrates how to create a web service from an EJB. Also, a JMS router MDB is generated automatically to be able to send a reply message back to JMS sender with some special settings like "jms/WebServicesReplyQCF" which can be used by MDB to listen on a reply....
In my case, the Web service is a message flow. When I import the WSDL to RAD, it only generates some Java proxy classes for me, no MDB or anything allowing me to lister on the reply at all....
Any thoughts? |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Feb 02, 2007 8:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You don't need to put the replytoqueue in the WSDL. WSDL is modelled on http, so it assumes that the reply destination is the same as the client, and the client address is not in the WSDL.
The JMS Sender needs to set it on the JMS message. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
jamesyu |
Posted: Fri Feb 02, 2007 8:23 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007 Posts: 70
|
jefflowrey wrote: |
You don't need to put the replytoqueue in the WSDL. WSDL is modelled on http, so it assumes that the reply destination is the same as the client, and the client address is not in the WSDL.
The JMS Sender needs to set it on the JMS message. |
Do you any sample programs / articles related to this topic? such as how to invoke a broker web service (must be SOAP over JMS) from a client? In my case, I need to invoke this SOAP over JMS web service from a servlet running on WAS...
The sample test JSPs & some Java proxy classes I am using now is generated by the Wizard provided in RAD based on the WSDL generated in toolkit. I can send the request over to broker service through the TestClient.jsp (part of generation), but it doesn't know where to pick up the response from, even with replyTo specified. It waits there until timed out.
Thanks,
James |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Feb 02, 2007 4:15 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Read up on JMS.
The JMSReplyto Destination can be dynamic or like in your case static. You already know where the answer will be. You just need to tell your program where it will be so that it can look for it.
Happy programming.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jamesyu |
Posted: Mon Feb 05, 2007 5:47 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007 Posts: 70
|
fjb_saper wrote: |
Read up on JMS.
The JMSReplyto Destination can be dynamic or like in your case static. You already know where the answer will be. You just need to tell your program where it will be so that it can look for it.
Happy programming.  |
Thank you for your response.
The thing is, RAD automatically generates a Java proxy based on the WSDL from toolkit. The client program just simply talks to this Java proxy via a method to send a request (a Java object) over and get a response (a Java object) back. All the low-level JMS implementation has been hidden from clients. So the client has no reference to any JMS/MQ APIs in client's code. How can I tell my client where the response is since I am not coding a JMS/MQ sender?
I could write a JMS/MQ program to send a request and retrieve a response from "replyToQueue". But this is not the way of calling a Web service from clients, isn't it?
Thanks,
James |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Feb 05, 2007 2:08 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Then you need to conform to your wsdl and make sure you can send the reply to the requester.
This requires you to use an MQReply node and to have a default MQ path to the requester.
One way or the other there is some work in it, to get it working. You may need to change the wsdl some to specify the reply to destination in the wsdl.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Calvino |
Posted: Thu Mar 08, 2007 7:59 am Post subject: |
|
|
 Novice
Joined: 06 Mar 2004 Posts: 19 Location: Scotland
|
Hi James
Did you ever get this working? We are currently looking at replacing our "in-house" jms-based API with a SOAP / wsdl based interface.
Currently our MQ messages come into our QMs with an MQMD ReplytoQ and ReplytoQM set by the client, but we are struggling to find out how to set this in the jms uri. We're using the standard Websphere SOAP transport and can't see anything in the code which allows you to set up a replytoQ - only seems to support temporary dynamic queues (and with large volumes of messages we don't want this extra overhead!) We geneally have a standard reply Q but we want to be able to set this up via a QCF and add it to the wsdl. Seems like a pretty basic jms / MQ property so we're surprised to be having so much difficulty getting this to work . . .
Cheers
Corrine |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Mar 08, 2007 4:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Calvino wrote: |
Hi James
Did you ever get this working? We are currently looking at replacing our "in-house" jms-based API with a SOAP / wsdl based interface.
Currently our MQ messages come into our QMs with an MQMD ReplytoQ and ReplytoQM set by the client, but we are struggling to find out how to set this in the jms uri. We're using the standard Websphere SOAP transport and can't see anything in the code which allows you to set up a replytoQ - only seems to support temporary dynamic queues (and with large volumes of messages we don't want this extra overhead!) We geneally have a standard reply Q but we want to be able to set this up via a QCF and add it to the wsdl. Seems like a pretty basic jms / MQ property so we're surprised to be having so much difficulty getting this to work . . .
Cheers
Corrine |
If you are coming from WAS I would not be too worried about the overhead for dynamic queues. The Pool keeps some of them handy just for that purpose. The contact admin stuff is that the dynamic temporary queue will not accept any persistent messages. For those you should use a static permanent queue.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Calvino |
Posted: Fri Mar 09, 2007 5:12 am Post subject: |
|
|
 Novice
Joined: 06 Mar 2004 Posts: 19 Location: Scotland
|
That's the rub though - how can you specify a static replytoQ via the jms uri? We have come to the conclusion that you can't - it only seems to support temporary dynamic queues - and this is a showstopper as far as we are concerned (and seems to be a huge restriction which could easily be removed)
Yes, you can set this up using native jms code, or you could use WSIF (still documented in v6 infocenter, but no activity on this for 4 years ...) but that appears to be the end of it as far as we can see  |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Mar 09, 2007 5:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Um. The JMSReplyTo field is just a Destination.
You should, for example, be able to configure a JNDI resource that points to a predefined, static, queue. Then look that resource up, and get the Destination and put that in the ReplyTo field.
Then the server application can natively open the ReplyTo destination, or can use the JMS methods for sending replies.
And the client application can open the destination for reading the reply. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Calvino |
Posted: Fri Mar 09, 2007 8:11 am Post subject: |
|
|
 Novice
Joined: 06 Mar 2004 Posts: 19 Location: Scotland
|
Sory Jeff, I don't think I'm being as clear as I could be here.
Yes we can define the reply Q as a jndi resource. We can set JMSReplyTo to that queue name. We can (using native jms code) have the JMSReplyTo mapped automatically to the MQMDReplytoQ - and we have an example working which does this.
The problem we're having is in specifying a valid jms uri string which can be interpreted by the inbuilt websphere soap engine. The rationale in using this soap engine is that (a) it is IBM supported (b) we can define the interface implementation in a wsdl and shield our developers from it (c) we can then change that implementation if we wanted to .... all using IBM supported code which we don't write or maintain.
Here's a sample soap:address value:
<soap:address location="jms:/queue?destination=STUART.IN&connectionFactory=myQCF&initialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory&timeout=5000&targetService=Product_Version_V002JMS_SOAP_Service&initialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory&jndiProviderURL=file:/h://bindings&replyDestination=STUART.REPLY"/>
This translates into the followng jms folder in the MQ message
<jms><Dst>queue:///STUART.IN?persistence=1</Dst><Rto>queue://DEV001X7/AMQ.45E17B6D2003AC01?persistence=1</Rto><Tms>1173283498538</Tms><Exp>1173283798538</Exp><Dlv>1</Dlv></jms>
Can you specify a replytoQ in the jms uri and what's the correct snytax - doesn't seem to be documented and doesn't seem to be any code in the soap engine to do this .... |
|
Back to top |
|
 |
|