ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » MQSI design question

Post new topic  Reply to topic
 MQSI design question « View previous topic :: View next topic » 
Author Message
Damien
PostPosted: Sun Jul 01, 2001 8:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ward
PostPosted: Mon Jul 02, 2001 3:48 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Ward
PostPosted: Mon Jul 02, 2001 3:50 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Damien
PostPosted: Tue Jul 03, 2001 6:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ward
PostPosted: Wed Jul 04, 2001 1:22 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
zpat
PostPosted: Wed Jul 04, 2001 2:39 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
Mike Brady
PostPosted: Thu Jul 05, 2001 7:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » MQSI design question
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.