JMS Message sequencing in JBESB

[skbiswas]

Hi All,

The requirement is to process a number of messages in a particular sequence. As JMS does not guarantee the sequence of the messages getting delivered, how can the messages be processed in the required sequence in JBOSS ESB?

[ryanhos]

The best solution would be to eliminate this requirement if at all possible.  I know that sounds like a cop-out, but that requirement will impose so many terrible restrictions on your business and exception handling code that you might spend more energy implementing it than designing it out.

That being said, there are instances when it is required.

Assuming you are on JBoss Messaging, you can utilize the Messaging Ordering Group.  I've never used it, and don't know how it works.  Questions should be directed at the JBoss Messaging Forum.

Failing that, your best bet is to implement your own Message Resequencer (Enterprise Integration Patterns, page 283).  Check out the stock ESB Aggregator for hints on how to implement this.  A number of concerns must be overcome.

1.)  For messages arriving on a gateway, caching them as the aggregator does and reordering them by delivery time: how will you ever know when the queue does not contain an earlier message?  It seems you'd have to stop delivery to the queue, drain the queue, reorder them, and send the ordered messages on their way (see point #4).

2.)  The best solution would be if the source could tag each with a value that imposes a total order on the messages.  That way, you'd know when you could send each message down the action pipeline, because the distance between the last delivered message and the earliest currently cached message would be zero.

3.)  The stock aggregator consumes the message and caches it in a non-persistent store (memory, IIRC), so in a failure scenario, the message will disappear, and never get processed.  Your Resequencer should use a persistent store.

4.)  It sounds as if your messages are not members of a batch.  You're just trying to impose a total order on them.  So, all of the message processing must be done inside a single ESB service, because otherwise, sending to another service will expose you to the ordering uncertainty that is inherent in JMS.  If they are members of a batch, compose them into a single message, ordered as appropriate, and send them wherever/however you like (unless batches need to be ordered...then ugh).

Designing this requirement out of the system seems a lot more attractive at this point, doesn't it?