| Author |
Message
|
| au@kosa |
 Posted: Tue Nov 17, 2009 12:58 am Post subject: Fan out in Aggregation (parallel or serial) |
 |
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
yesterday, when i was going through the forum, i read that FANOUT from the aggregation node is not parallel and they work in serial (I do not remember the Query) but no one has objected that line.
Till now i am having the understanding that fan out from the Aggregation Control node works in parallel and the order of execution is random.
Please correct me where ever i am wrong.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
 |
| au@kosa |
| Posted: Tue Nov 17, 2009 3:23 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 17, 2009 8:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
No the fan out is not parallel but the calls being made to the other services can be. Imagine each fan out ending with an MQOutput node.
Once the flow (fan out) is committed all the flows triggered by the messages put to MQ will start in parallel.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| au@kosa |
| Posted: Wed Nov 18, 2009 3:39 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
What if in each fan out request there is web service invocation (SOAP/ Http). My understanding came from below quotes given in Message_Broker_Message_Flows.pdf (page 99)
| Quote: |
WebSphere Message Broker provides three message flow nodes that support aggregation: v AggregateControl v AggregateRequest v AggregateReply When you include these nodes in your message flows, the multiple fan-out requests are issued in parallel from within a message flow. This is in contrast to the standard operation of the message flow in which each node performs its processing in sequence.
|
| Quote: |
These nodes also provide an opportunity for an improvement in response time, because slow requests can be performed in parallel and do not have to follow each other sequentially. If the subtasks can be processed independently, and do not have to be handled as part of a single unit of work, they can be processed by separate message flows. You can design and configure a message flow that provides a similar function without using the aggregate nodes, by issuing the subtask requests to another application (for example, using the HTTPRequest node) and recording the results of each in the LocalEnvironment. After each subtask has completed, you can merge the results from the LocalEnvironment in a Compute node, and create the combined response message for propagating to the target application. If you do this, all the subtasks are performed sequentially, and do not provide the performance benefits of parallel operation that you can achieve using the aggregate nodes.
|
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 18, 2009 6:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And have you had a look at the exemples?
You do not want to set the webservices between the Fan out and the request node...
Say you set up your SOAP call as a web service / Request Reply via MQ.
So you have multiple of these set up.
Your fanout goes to an MQOutput then Aggregate Request...
The response goes to your MQInput connected to the Fan-in -> compute->MQReply
Set transactionality to true. Each branch of the fan-out will be executed one after the other. On commit the messages hit the input queues for your SOAP services calls. Those get executed in parallel and send the reply to the MQInput node connected to the Fan-in node....
Now check it out, play with it and have fun!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sapana |
| Posted: Wed Nov 25, 2009 3:41 am Post subject: |
|
|
Apprentice
Joined: 16 Apr 2007
Posts: 33
Location: Pune
|
|
| Back to top |
|
|
|
|
