| Author |
Message
|
| Damien |
 Posted: Sun Jul 01, 2001 8:42 pm Post subject: |
 |
|
Newbie
Joined: 30 Jun 2001
Posts: 5
|
We are in the process of building an EAI solution using MQSI and we need some pointers on the design. The main question is how many incoming queues should we have to the broker. We have a whole load to different messages that we can send to the broker (most from one application at the moment) and the broker needs to identify each type message and handle them all differently. All the examples given in the documentation show how to handle a particular message and assume that only one type of message will arrive on a particular queue.
Is having one queue per message type the suggested approach? This could be a huge number of queues. The other approach would be to have one queue (or a set of queues) and let the message broker look at the message and decide how to handle it. Is there anyway of specifying in the MQInput node to only handle certain messages? If not, the only approach left appears to be using filter nodes to select and route the message to an appropriate set of nodes to handle the message. This seems pretty clumsy, is there a better way? Has anybody thought about using publish/subscribe to solve this problem and letting the broker subscribe to a paricular topics?
I've been looking at this for about a week and can't find anything documentation that suggests the appropriate approach. I guess it's either a hard problem or obvious....any help would be appreciated.
Cheers,
Damien |
|
| Back to top |
|
 |
| Ward |
| Posted: Mon Jul 02, 2001 3:48 am Post subject: |
|
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
Damien,
If at all possible I would use an RFH2 header to help you here. In the RFH2 header you can have a folder. This holds a message type. Within your node you'll find this type in the properties. I then used a route to label to split the flow into either sub-flow or other main flows. Other main flows will require queues to be set up but allow you to put them in different execution groups etc... for load balancing...
Hope this helps,
Ward. |
|
| Back to top |
|
|
| Ward |
| Posted: Mon Jul 02, 2001 3:50 am Post subject: |
|
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
doesn't seem to like the smaller than and greater than sign... the folder I was talking about is the 'mcd'-folder
cheers,
Ward |
|
| Back to top |
|
|
| Damien |
| Posted: Tue Jul 03, 2001 6:19 pm Post subject: |
|
|
Newbie
Joined: 30 Jun 2001
Posts: 5
|
Ward,
Thanks for you response. I also posted the message to the MQ List Serv and got the following response. Any thoughts on this approach? BTW: all messages that we receive will be XML.
A few comments.
We have one queue per message type. This means the application putting the
message to the queue needs to know which message goes on which queue. Since
we get transferred files, we own the putting application and do this in one
place. I believe it is a little more efficient in the message flow (see
below).
If you have all messages go to the same queue, then you need to sort them
within the message flow. This got quite tricky with our first sample of
seven different message flows because some of the differences were minor but
required different NEON or MRM message types. So, figuring out which type
of message you had (presuming the sending application did not tell you)
added some rather complex logic that had to be retested every time we added
a new type or changed any one of the message feed formats.
We did not see any real problem with the number of queues although we are in
the tens of message types (planning to go to about 200). |
|
| Back to top |
|
|
| Ward |
| Posted: Wed Jul 04, 2001 1:22 am Post subject: |
|
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
Damien,
If possible I prefer using one message type per queue. The only place where we could not do this we implemented a 'router' flow (using the RFH header) to route different messages to different queues. Therefore having a queue per message type anyway.
A couple of hundred queues is definitely next to nothing for MQSeries. As for MQSI I have no real experience with that many queues. Although I believe that if you would run into problems grouping them into separate execution groups would probably solve that. (We have around 50 in one execution group without a problem.)
Having different message formats (XML/MRM) in one queue does sound tricky although if all messages would use an RFH header then you could use that to split them without the need to look into the message. (ie. independent from the message format) Anyway, by the sounds of it you needn't worry about this...
Cheers,
Ward. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 04, 2001 2:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We have a small number of MQSI queues that the external applications are aware of.
Then we have small MQSI flows which split up the messages on to queues known only to the broker for other MQSI flows to process.
You don't want a whole load of queue names being referenced in your applications as this would be a maintainance nightmare. |
|
| Back to top |
|
|
| Mike Brady |
| Posted: Thu Jul 05, 2001 7:12 pm Post subject: |
|
|
Newbie
Joined: 04 Jul 2001
Posts: 8
|
| I agree with zpat. The approach I have alway s taken is to keep the application as simple as possible, i.e. the application should be aware of a minimal number of queues. Sorting of messages should be largely contained within the broker domain (or a broker pre-processor if you really need to). The routeToLabel node is generally preferable to having multiple filter nodes and makes for cleaner/simpler design. These can then feed subFlows rather than having a large number of separate Message flows as is the case when many queues are used |
|
| Back to top |
|
|
|
|
