| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Flow Design |
« View previous topic :: View next topic » |
| Author |
Message
|
| lung |
 Posted: Mon Jul 14, 2003 11:35 pm Post subject: Message Flow Design |
 |
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
I have a question regarding message flow design... Currently I still have not found the best way to design a message flow...
Let's assume my broker caters for several different projects. Each of these projects consist of different input message types from different environments (boxes).
I know that a good way to design a message flow is to have only one input node for each message flow. If that is the case, should I categorise message flows according to the message type, or the environment type, or according to the project?
Example...
I have a message flow for XML messages only, a message flow for MRM-CWF messages only, ... (if I categorise according to message type)
or
I have a message flow to cater for requests from OS/390, a message flow to cater for requests from NT, ... (if I categorise according to environment type)
or
I have a message flow to cater for Call Centre requests, a message flow to cater for ABC project requests, ... (if I categorise according to projects)
And how does the concept of reusability come into play in this case?
Thanks!  |
|
| Back to top |
|
 |
| Yanghui |
| Posted: Tue Jul 15, 2003 12:25 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
It's a very interesting subject. Actually I have been very frustrated with similar thoughts. Later on, I got a conclution that msgflow is just glue between or among applications via MQ queues. It's really driven by MQ layer design and how application interface is designed. Probably this is the first principle before I start to design any msgflow. Above this, you can apply any more standards if more design space is left.
Regards
-Yanghui |
|
| Back to top |
|
|
| jfluitsm |
| Posted: Tue Jul 15, 2003 10:39 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
I have once used an approach, which worked quiet good.
In this approach a message type was defined at a functional level, say customer-information, the generic definition defined what information had to be transferred. Lets say for instance that customer-information had to flow from boxa to box1 and box2, and from boxb to box2 and box3.
For this we used 2 message flows (and 2 queue's), "cust-info from boxa" and "cust-info from boxb". These flows were implemented using sub-flows.
The flow from box a would look like:
mqinput --> xfrom from boxa to generic --> routing from boxa --> xform from generic to box1 --> mqoutput, parallel on the last 2 nodes: --> xform from generic to box2 --> mqoutput.
The flow from boxb would look similar where "xform from generic to box2" would be reused.
I don't regard using more input-nodes in one msgflow as bad desing, as long as the messages flowing through these flows have the same functionality, so the above example could have been build in 1 msgflow using 2 mqinput nodes.
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| lung |
| Posted: Tue Jul 15, 2003 5:16 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks for the replies.
I have another question, this one with more regards to the concept of subflows.
Let's say my main flow has two subflows, one for transaction A, another for transaction B. Let's say a message comes in, for transaction A. When the message arrives in the main flow, a process thread will be created by the broker, right? Now, my question is... When the process thread is created, does it include the two subflows, or will the subflow have their own process threads? (created only when invoked?)
Reason I ask is again with regards to design. I'm not sure whether I should design a message flow which includes subflows for each transaction type, or a message flow for each transaction type (no subflows)...  |
|
| Back to top |
|
|
| Craig B |
| Posted: Wed Jul 16, 2003 3:21 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
The concept of subflows only really exist at the message flow design level. They are there to assist the user in allowing them to re-use the same set of nodes in multiple message flows without having to wire them individually in each of the flows. When a message flow that contains subflows is deployed then the subflows are resolved at that point such that the run-time version of the message flow just sees them as another set of nodes that are wired into the flow. Therefore at execution time when the message flow is running it just sees these subflow nodes as another nodes to execute according to the wiring of the message flow. So in answer to your question, no new process threads are spawned for subflows, they execute under the message flow thread.
_________________
Regards
Craig |
|
| Back to top |
|
|
| jfluitsm |
| Posted: Wed Jul 16, 2003 9:29 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
I find it easiest to think of a sub-flow as a user-written node.
The number of threads depends on the number of additional instances for the flow and the number of input nodes (MQ, MQe, SCADA, etc.) in the flow. Every input node results in a thread, so the number of threads = number of input nodes * ( 1 + number of additional instances).
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| lung |
| Posted: Sun Jul 20, 2003 8:14 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
| lung wrote: |
| Let's say my main flow has two subflows, one for transaction A, another for transaction B. |
So r u guys saying that, even if the message coming in is for subflow transaction A, subflow transaction B will be loaded as well? |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Jul 20, 2003 8:58 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Yes.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| lung |
| Posted: Mon Jul 21, 2003 11:45 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks for the answer.
If that's the case, then having a main flow with subflows for each transaction is a bad design, I think. I won't want everything to load and hog the processing power of the CPU just because of one transaction all the time.
So, back to the main question... How to best design a message flow? Will it be feasible to use multiple output nodes in place of the subflows? For example, a message for transaction A comes into the main flow. In the main flow, the message is routed to output node A. The queue of output node A is actually the queue for an input node in another main flow, this main flow caters just for transaction A... Will this be a better design since this way, not everything will be loaded?  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 22, 2003 6:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| lung wrote: |
If that's the case, then having a main flow with subflows for each transaction is a bad design, I think. I won't want everything to load and hog the processing power of the CPU just because of one transaction all the time.
So, back to the main question... How to best design a message flow? Will it be feasible to use multiple output nodes in place of the subflows? For example, a message for transaction A comes into the main flow. In the main flow, the message is routed to output node A. The queue of output node A is actually the queue for an input node in another main flow, this main flow caters just for transaction A... Will this be a better design since this way, not everything will be loaded? |
Yes, it's completely feasible to replace your subflows with an output node and deploy the subflow to another message flow.
The way I would normally code a message flow that handles multiple transaction types is with a RouteToLabel design. Each Label node would then either do its own processing in the main flow, call a subflow, or write to an output queue for processing by another message flow.
The design is the same, the differences are reuseability, per-transaction scalability, and overall processing management. If you use multiple output nodes, you will be able to deploy multiple instances of each transaction individually to meet the performance needs. In addition, you will be able to call that transaction from any place, as opposed to only through your main flow. But you will incur the performance hits of having to convert your message back into a bitstream and reparse it plus the cost of the put and get.
You'll have to evaluate for yourself whether that's a gain in performance or not. |
|
| Back to top |
|
|
| lung |
| Posted: Tue Jul 22, 2003 5:33 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks for the reply. I guess I'll just have to think about this...  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
