| Author |
Message
|
| mqdevuk |
 Posted: Mon Jul 04, 2011 7:55 am Post subject: SOAP nodes reply identifier as message id |
 |
|
Newbie
Joined: 04 Jul 2011
Posts: 2
|
Hi all,
We are looking at developing a SOAP web service which will have the SOAPInput node and the SOAPReply nodes in different flows within the same execution group.
The design has flow 1 receiving the SOAP request, creating an MQ message containing the SOAP reply identifier and placing it on a cache queue then creating another MQ message which contains the request which is routed to a backend system. The backend system responds to the requests by sending out an MQ message which is received by flow 2. Flow 2 retrieves the cache message (using the correlation id in the response) to get the SOAP reply identifier and responds to the SOAP client.
This works fine.
One of our team suggested using the SOAP reply identifier as the request message's message id. This would be sent to the backend system which would then return it in the correlation id of the response message. We have tried this and it appears to work OK.
My concern is that it isnt one of the methods suggested by IBM:
https://www.ibm.com/developerworks/webservices/library/ws-soapnode/
| Quote: |
| One way to save the ReplyIdentifier between flows is to store the value on a queue, then use an MQGet node in the reply flow to retrieve it. Other possibilities include saving it in a database or an WebSphere MQ RFH2 header. |
I realise that this isnt a complete list of how to do it but I havent been able to find anything that suggests its OK to use the SOAP reply identifier as a message id.
Any thoughts?
Thanks |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Jul 04, 2011 8:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
IMHO, and as long as you are fully aware of the length & formats of the MQMD.MsgId/MQMD.CorrelId vs the SOAP Identifier then there is nothing wrong with your solution.
There are usually several ways to do most things in Broker. If it works for you AND your devs understand the limitations (as there is in any solution, even with using a holding queue) AND it is documented then carry on using it.
SOAP is by default a Request/Reply model. (yeah I know it can be used Async)
WMQ is by default Async but can be made to use a Request/Reply format thus turning it into a Synchronous Model. This usually involves the MsgId & CorrelId fields in the MQMD and changing the Message type to Rqst/rply
There does not seem to be anything wrong there.
If I am completely barking mad (or just plain wrong) then the Hursley guys will be along soon to shoot me down in flames.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 05, 2011 5:04 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
A faster way to save and retrieve context is using a Singleton. Of course, as many would point out here, you need to know Java to use Singletons from a JCN.
In-memory Singletons save the latency that would otherwise be spent writing to a queue or saving to a database.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 05, 2011 5:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| A faster way to save and retrieve context is using a Singleton. Of course, as many would point out here, you need to know Java to use Singletons from a JCN. |
Singleton! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jul 05, 2011 5:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
A faster way to save and retrieve context is using a Singleton. Of course, as many would point out here, you need to know Java to use Singletons from a JCN.
In-memory Singletons save the latency that would otherwise be spent writing to a queue or saving to a database. |
But... using the OP's existing method has no local storage requirements. He's using the ReplyId in the MQ Message. Within certain limitations, it is very elegant solution. Even a Java Singleton method has IMHO limitations.
Then again, Singletons are not the answer to life, the Universe & everything.
Singleton on the other had is a nice village near Goodwood in Sussex. The Weald & Downloand Museum is well worth a visit.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 05, 2011 5:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I shall check out that village next time I am in UK.
Another issue with the queue storage method for context lookup is: if you run the WMB runtime at high enough TPS (over 30) for extended periods (several days), you may find that the WMB connection to its QMGR fails.
There are several PMRs on this issue, and it relates to the fact that there is no let-up in processing to allow the WMB runtime to reset its connection pool.
It is true that Singletons have limitations, but these are only limited by the available memory. Increase the available memory, and your capacity goes up similarly.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqdevuk |
| Posted: Tue Jul 05, 2011 6:57 am Post subject: |
|
|
Newbie
Joined: 04 Jul 2011
Posts: 2
|
| lancelotlinc wrote: |
| Another issue with the queue storage method for context lookup is: if you run the WMB runtime at high enough TPS (over 30) for extended periods (several days), you may find that the WMB connection to its QMGR fails. |
Really?
We havent had any problems with this. Our transactional web site relies heavily on Message Broker which processes hundreds of messages per second spread over a variety of message types and flows. Not all of them, but quite a few, use the 'message on a cache queue' method for the request/response messages so that it can augement the responses (data in request but lost in response) and send them back to the correct client (store reply to details).
Do you have any details of this fault?
Thanks |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 05, 2011 7:17 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqdevuk wrote: |
| lancelotlinc wrote: |
| Another issue with the queue storage method for context lookup is: if you run the WMB runtime at high enough TPS (over 30) for extended periods (several days), you may find that the WMB connection to its QMGR fails. |
Really?
We havent had any problems with this. Our transactional web site relies heavily on Message Broker which processes hundreds of messages per second spread over a variety of message types and flows. Not all of them, but quite a few, use the 'message on a cache queue' method for the request/response messages so that it can augement the responses (data in request but lost in response) and send them back to the correct client (store reply to details).
Do you have any details of this fault?
Thanks |
We had multiple POJOs (different machines) submitting messages to broker (v7.0.0.2). The messages were metered in to the queues at a steady rate, equating to about 30 transactions per second. After about 5 days, the broker's qmgr connections started to fail.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue Jul 05, 2011 7:53 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| lancelotlinc wrote: |
| We had multiple POJOs (different machines) submitting messages to broker (v7.0.0.2). The messages were metered in to the queues at a steady rate, equating to about 30 transactions per second. After about 5 days, the broker's qmgr connections started to fail. |
ATM, this is still anecdotal evidence though.
| Quote: |
| There are several PMRs on this issue |
Now if those could be shared it would be better evidence for your case  |
|
| Back to top |
|
|
| k.v.hanumesh |
| Posted: Mon Dec 30, 2013 3:09 am Post subject: SOAPReplyIdentifier |
|
|
Newbie
Joined: 30 Dec 2013
Posts: 2
|
Can't we store SoapReplyIndentifier in Shared Row anyways we need to deploy your flows in the same execution group if Soapreply different flow s.
Regards,
Hanumesh |
|
| Back to top |
|
|
| k.v.hanumesh |
| Posted: Mon Dec 30, 2013 4:33 am Post subject: |
|
|
Newbie
Joined: 30 Dec 2013
Posts: 2
|
| Sorry we can't use to store SOAP reply Identifier in Shared row . So we have option to store Database or queue or (Global Cache in MBV8.0) |
|
| Back to top |
|
|
|
|
