| Author |
Message
|
| pottas |
 Posted: Fri Mar 28, 2008 5:35 am Post subject: Collector Node design question |
 |
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Guys,
I have the following design question around a flow in WMB 6.1 using a Collector Node:
I have a Business Requirement to design a message flow that exposes a Web service within WMB.
This Web Service contains a number of operations that needs to be split into separate operations that will invoke the various services on the back-end. The responses from the back-end will then be merged into the original request that will be sent back to the consumer.
So my flow will look like this:
HTTPInput -->
Compute (splitting the operations into separate services) -->
SOAPRequest Nodes (to call the individual back-end operations) -->
Collector Node (collecting all the responses from the back-end services) -->
Compute (to merge the resulting data into the response that will be sent back to the consumer)
Will this work or am I smoking my socks?
and if the above proposed flow is in order then my question is: why bother with Aggregation nodes if we have a very nifty collector node at our disposal?  |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Mar 28, 2008 5:39 am Post subject: Re: Collector Node design question |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pottas wrote: |
| why bother with Aggregation nodes if we have a very nifty collector node at our disposal? |
Because Collector nodes are new, and may well sound the death knell for the Aggregation node. I won't be too disapointed if that's true.
The design looks fine, but I've had no oppertunity to experiment with the Collector so I'll defer to those with more hands-on experience.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Mar 28, 2008 6:02 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
pottas,
The intent for the Collector node is to take input from Input nodes and not from a compute node (or any other node). I don't know if the collector node will work taking input from non-Input nodes.
So, your design would work if you were using Async SOAP services. The collector node is collecting things based on correlation ID (of some sort). To use Async SOAP services, the service end needs to support such a thing.
Async SOAP services have the advantage of waiting only the longest time of one of the requests rather then the total time of all the requests. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 28, 2008 6:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is an Aggregation Scenario.
Use an Aggregation pattern instead of a Collection pattern.
Also note JosephGramig's comment about 'ASync'.
There's no need to use the Aggregation* nodes or the Collector node when you are making synchronous request/replies! They will come back in the same flow!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Mar 28, 2008 6:48 am Post subject: Crazy Talk |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Perhaps what you want are two mythical nodes...
Let's call them Fork and Join.
Fork would take one input message tree and have a definable number of output terminals which will spin up one thread for each of them to process a copy of the message tree.
The Join node will have a definable number of input terminals and one output terminal out of which it will burp a collection of message trees.
But that is just crazy talk. 
In the mean time, jefflowrey's suggestion should work fine.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| pottas |
| Posted: Sun Mar 30, 2008 11:02 pm Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Guys,
Thanks a lot for your replies. That was exactly what I wanted - I really value your input and appreciate your views.
I agree with jeff - rather stick with the devil you know - so I will opt for the Aggregation Node solution. Just one more question though...
jeff, your comment:
| Quote: |
| There's no need to use the Aggregation* nodes or the Collector node when you are making synchronous request/replies! They will come back in the same flow! |
Maybe my question is a bit premature at this stage because I havent really investigated this, but if it is a synchronous request and I do it in-line, what would my message tree look like?
You see, maybe I've worked for the wrong companies since I started with Broker, because I haven't really had the requrement to use Aggregation - I guess its about time...  |
|
| Back to top |
|
|
| pottas |
| Posted: Tue Apr 08, 2008 3:40 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Thanks for the options you guys proposed.
Apologies for the long delay, I designed some flows as examples and I came up with an Aggregation flow that (sort of) works for me (so, jeff, I followed your suggestion)- hence the next question I have.
jeff, you wrote:
| Quote: |
| There's no need to use the Aggregation* nodes or the Collector node when you are making synchronous request/replies! They will come back in the same flow! |
I'm not sure what you mean by this from a design perspective. The way I see it, is to do the calls to host in a sequential order and packing the result into the Environment tree? Can you guys please provide a bit more guidance?
My requirement is that I need to design a flow that has a WSDL as input that will be split into a number of services that invokes the back-end. These host responses should then be merged back into the WSDL as one message and sent back to the requestor. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2008 4:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, you can string a bunch of HTTP/SOAP request nodes in series, and either configure the properties or use a compute node after each one, to put the reply into a location that won't get overwritten by the next reply.
You probably need the compute node anyway, to build the new request.
Or you can use Aggregation anyway, and create individual flows that use copies of the input message (from a queue), and execute your synchronous requests in parallel instead of series.
It depends on if you want the total operation to take as long as all operations, or only as long as the longest operation.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
