| Author |
Message
|
| pottas |
 Posted: Tue Oct 16, 2012 6:30 am Post subject: Message Broker vs Process Server |
 |
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Just some details you might require:
We are running the following Broker version:
WebSphere Message Broker Toolkit - Message Broker
Version: 7.0.0.2
Build id: 7.0.0.2-20101130_1524
We had a discussion on site with all the middleware techies about hosting flows on Message Broker v.s. Process Server.
We have a message flow that does a number of orchestrated calls to various back-end Web Services. The design challenge we face, is that we cannot use aggregation because every next call is depended on the response of the previous call. So this takes up a lot of processing on Broker.
What was said around the table, is that we need to move the flow to Process Server - so now I have a challenge.
My thought was, we have some alernative options:
1. Increase the memory on AIX by adding more memory modules;
2. Set additional instances on the 'heavy' flows so that it can handle multiple threads;
3. Move the 'heavy' flows to it own execution group;
4. Increase the JVM heap size even more;
5. Move to Process Server.
So, in short, that is my question - what kind of approach should we take...
Any suggestions at this stage will assist a lot.
Thanks in advance |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Oct 16, 2012 6:35 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Great post! Provided alot of needful information relevant to your problem.
WMB provides two main strengths:
1. Transformation
2. Context-based routing.
It is not intended to be used for orchestration.
It can and does work in concert with other orchestration engines, like Case360, IBM WPS, and IBM Business Process Choreographer.
http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html
You should allow the BPEL/orchestration/choreography engine to drive transactions through WMB rather than making WMB track all the history of very long running transactions.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| pottas |
| Posted: Tue Oct 16, 2012 7:01 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
| I am very grateful for your reply, thanks a lot - the link provided a lot of useful info. And that was actually what I expected - the move to Process Server, but I was hoping for something else. the challenge now is, to move all of this in good time.... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 16, 2012 7:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would choose option 3.
And then I'd deploy to more than one unique EG, to spread out the load. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Oct 16, 2012 7:04 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
By the way, you want to update your WMB to at least 7.0.0.4. Doing so you will notice alot of improvement, especially in compile times cut in half, as well as alot of bug fixes.
Also I would like to point out, I did not say move it to WPS, I said drive transactions through WMB from WPS. A purist SOA approach would utilize the WMB as an ESB and WPS as the orchestration engine.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 16, 2012 7:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Also I would like to point out, I did not say move it to WPS, I said drive transactions through WMB from WPS. A purist SOA approach would utilize the WMB as an ESB and WPS as the orchestration engine. |
I'd like to point out that this may already be the case, where the intent here is to create an ESB level service that is orchestrated by a larger WPS process. But the services that the ESB are calling are at a lower granularity than the ESB service, and so they still need to be assembled.
Think of something that wants to present a list of customer accounts and the last 10 transactions on each. You'd maybe need to call services like GetCustomerFromID and then GetCustomerAccounts and then GetLast10Transactions for each account. At the ESB level, the service supplies Last10TransactionsForAllAccounts. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Oct 16, 2012 7:28 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
lower granularity ... they still need to be assembled.
Think of something that wants to present a list of customer accounts and the last 10 transactions on each. You'd maybe need to call services like GetCustomerFromID and then GetCustomerAccounts and then GetLast10Transactions for each account. At the ESB level, the service supplies Last10TransactionsForAllAccounts. |
In general, good SOA design principles keep the ESB (WMB) stateless. As long as the ESB is issuing combinations of stateless transactions, I can agree with your comment.
The moment state is needing to be tracked, as the OP has said is his/her business requirement, the state needs to be promoted out of the ESB to an orchestration engine. It is never a good idea to track state in WMB.
I've seen two examples, both banking, where they tried to track state in WMB and it became a morass. The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards. A correlation set allows a BPEL process instance to hold conversations with partners involved in its work. The use of a correlation set in process instances initiate activities and non-initiating receive activities. These (correlation and delivery) are two entirely different functions and should not ever be combined into the ESB. The ESB should mediate (deliver) the conversations and the WPS should be the brains (correlate) of the duo.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Tue Oct 16, 2012 7:53 am; edited 2 times in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 16, 2012 7:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| mqjeff wrote: |
lower granularity ... they still need to be assembled.
Think of something that wants to present a list of customer accounts and the last 10 transactions on each. You'd maybe need to call services like GetCustomerFromID and then GetCustomerAccounts and then GetLast10Transactions for each account. At the ESB level, the service supplies Last10TransactionsForAllAccounts. |
In general, good SOA design principles keep the ESB (WMB) stateless. As long as the ESB is issuing combinations of stateless transactions, I can agree with your comment.
The moment state is needing to be tracked, as the OP has said is his/her business requirement, the state needs to be promoted out of the ESB to an orchestration engine. It is never a good idea to track state in WMB.
|
I agree. But the OP didn't say they needed to track state, merely use the result of one service call as part of the input to the next service call - ala the example I gave where the service calls are cascaded. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Oct 16, 2012 8:39 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
