DB Vs Mq

[Srinivasa Raghavan]

I dont know if it's the right place to put this question. We have a situation to decide upon using MQ Vs Database. Can anyone let me know the pro's and cons of one versus other.

[todd runstein]

Any chance you can provide a bit more info?

Message queues are really good for exchanging messages. Databases are really good at storing and retrieving data. ;)

[Stan James]

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.

[Srinivasa Raghavan]

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 ]

[Stan James]

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?

onMessageArrive()
   receive message with Part of transaction
   get TxId from Part
   get Tx object from TempStore by TxId
   if Tx is null
      create new Tx
      put Tx in TempStore
   add Part to Tx
   if Tx is complete
      process Tx
      remove Tx from TempStore