MQ is a good protocol for large-grained remote services, i.e. when you're calling outside your application to a partner system. It's particularly good for asynchronous messaging, perhaps if you're sending information to a partner system that might not be running right now. See Gregor Hohpe's Integration Patterns for lots of information on that.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Sep 28, 2004
We need to process the messages from upstream application. We will be able to process the message only if we have got all the data for a particular business, so till then we may need to store it in a place.
The messages needs to be sorted out based on a entity before it gets processed. Here is what we need to decide on using MQ or DB.
If the data is in the DB then sorting will be easier .. If the data is in MQ sorting might be a problem. On the other hand if we are using DB then we need a additional clean up process to clean the DB, since the data is not needed after it got processed. [ September 17, 2007: Message edited by: Srinivasa Raghavan ]
Joined: Jan 29, 2003
I wouldn't think of data "in" MQ, just arriving via MQ. Once it arrives you can put your bundle of messages together in the right order. Are you thinking something like this?