| Author |
Message
|
| Herbert |
 Posted: Thu Jan 21, 2010 6:00 am Post subject: Aggregate nodes with a mix of MQ and SOAP requests? |
 |
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
Hi,
Is it possible to use the Aggregate nodes with a mix of MQ and SOAP requests?
The documentation suggest that it is not limmited to MQ only:
"The aggregation nodes work correctly only for transports that use a request/reply model; for example, WebSphere® MQ Enterprise Transport."
"If you use WebSphere MQ Enterprise Transport, the responses that are received by the fan-in flow must be valid reply messages that contain the reply identifier"
"This node must be an input node that supports the request/reply model, such as an MQInput node, or a mixture of these nodes"
However I can not find examples that use a other transport then MQ and instructions how to set reply ID's for other nodes then MQ.
The webservice I want to use does use the request/reply MEP.
Below a outline what I want, is this possible?
| Code: |
Request flow:
/--> compute --> MQOutput --> AggregateRequest
MQInput --> AggregateControl --
\--> compute --> SOAPAsynchronousRequest --> AggregateRequest
Response flow:
MQInput --\
--> AggregateReply --> Compute --> MQOutput
SOAPAsynchronousResponse --/
|
Kind Regards, Herbert
Last edited by Herbert on Mon Jan 25, 2010 6:20 am; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jan 21, 2010 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Make it easy on you and set the call to the Web site as a separate flow triggered by an MQ message. You then have your aggregation fan out call that flow.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nathanw |
| Posted: Thu Jan 21, 2010 9:11 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
Agree with ^^^^^
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| Herbert |
| Posted: Fri Jan 22, 2010 2:28 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| fjb_saper wrote: |
| Make it easy on you and set the call to the Web site as a separate flow triggered by an MQ message. You then have your aggregation fan out call that flow. |
Indeed, that will work fine. However, I have a problem 'selling' this to company/project architects.
Before I started in this project (building a ESB with WMB that uses SOAP for all Consumers and for some Providers) there was a IBM consultant and he did say something like below. (according to my project-leader)
"A common thing that WMB developers will do when when working with HTTP in a WMB environment is that they transfer it right away to MQ because that is what they understand, make sure your WMB developers wil not do that."
And because the WMB manuals suggests that the aggregation nodes are not limited to MQ (see below quoute) I did ask this question.
"The aggregation nodes work correctly only for transports that use a request/reply model; for example, WebSphere® MQ Enterprise Transport."
So I'm still wondering if it is save to say to other people in the project: "The concept of aggregation is not limited to MQ, the current implementation inside WMB is limited to MQ" |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Jan 22, 2010 3:56 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
Actaully i would say something along the lines of
having the Agrregation node fire a MQ message to a separate flow to trigger thr HTTps responses and then back into Aggregation would allow you to more efficiently debug any issues and increase the supportableness(?) of the solution by not mixing the transposrtts in one particular flow
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth |
|
| Back to top |
|
|
| Herbert |
| Posted: Fri Jan 22, 2010 4:57 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| nathanw wrote: |
Actaully i would say something along the lines of
having the Agrregation node fire a MQ message to a separate flow to trigger thr HTTps responses and then back into Aggregation would allow you to more efficiently debug any issues and increase the supportableness(?) of the solution by not mixing the transposrtts in one particular flow |
At a technical level for sure I agree with you, but it opens a lot of discussions I don't want. If below statement is thrue then there is no room for discussions.
"The concept of aggregation is not limited to MQ, the current implementation inside WMB 6.1 is limited to MQ" |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2010 7:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's some additional commentary I'd like to make here.
Consider the HTTP transport in general. It is a *synchronous* protocol, in exactly the same way that MQ is an *asynchronous* protocol.
In the same way that MQ allows you to do "pseudo-synchronous" communications, one can do "pseudo-asynchronous" communications with HTTP by sending a request, receiving a reply, and then sending another request later for another reply.
Well, okay, asynchronous HTTP is *slightly* more sophisticated than that. But you still get a synchronous reply to the initial request, and then later on you get a SECOND reply on an additional port.
The aggregation nodes are not in any way built for this kind of multi-reply scenario.
But Collector node is happy to stuff together any random pile of input messages you'd like to give it. |
|
| Back to top |
|
|
| Herbert |
| Posted: Wed Jan 27, 2010 9:24 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
Thanks for the reply, I'm learning a lot in this project (building a ESB with WMB that uses HTTP/SOAP for all the Consumers and HTTP/SOAP for some Providers, most providers are legacy apps that uses MQ)
| mqjeff wrote: |
| Consider the HTTP transport in general. It is a *synchronous* protocol, in exactly the same way that MQ is an *asynchronous* protocol. |
Thats the reason that I have implemented the MQ wrapper flow that does the HTTP request as 2 different flows, the first with SOAPAsyncRequest and the second with SOAPAsyncResponse.
| mqjeff wrote: |
| But you still get a synchronous reply to the initial request |
yes, I saw that, AFAIK it's only a HTTP response code, but if the remote webservice does not send it for some reason then the Async benefits are gone.
| mqjeff wrote: |
| But Collector node is happy to stuff together any random pile of input messages you'd like to give it. |
Indeed, because our consumers are also SOAP/HTTP I also use it to transfer the SOAP.Reply.ReplyIdentifier from the Consumer-Request flow with the same Aggregation to the Consumer-response flow, making the communication between the Consumers and the ESB also asynchronous. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2010 10:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I was suggesting you could use Collector exclusively instead of Aggregation.
The only way *to* use Aggregation with AsynchSOAP, as far as I can tell, IS by wrapping the SoapAsycn nodes in an MQ Request/reply flow. So if you want to take that extra step, you can.
But collector is also asynchronous - all of the inputs are on their own threads, and the output is on a new thread from any of those. |
|
| Back to top |
|
|
|
|
