The last JMS specification was written 8 years ago! Since then the world has seen multi-core 64 bit systems, Hadoop, compute grids, data grids, AMQP, ZeroMQ, NoSql, Twitter, Facebook ..... and still JMS 1.1 is the backbone of enterprise systems.
There are a few things however, that are missing sorely from the spec and consequently from any implementation in a "standard" way. Each provider no doubt has an answer to some of its limitations but the emphasis is on the lack of a standard way.
8 years ago, running a whole swarm of machines as a single cluster was rare. But in today's world it is not. It is exactly here that the spec is lacking. I have listed some features below that I would find useful.
- Out of order Acks: Acknowledging messages individually and in an order that is different from how they were received. The spec is vague about this. In some systems acknowledging a message will automatically ack all messages that have been received so far in that session! TIBCO EMS has Explicit Client Acknowledgement that is non-standard but is certainly very useful
- Negative Acks: In some systems, if a message causes an exception at the receiving end, that message will not be redelivered by the server until the original client session disconnects. It would've been nice if the spec allowed some kind of a Negative Ack to force the server to redeliver the message to the same or a different session
- Batch Acks: Since JMS is used in many setups to correlate multiple messages coming from different queues and considering that Ack'ing is expensive at high message rates; JMS should have a facility to accept a batch acknowledgment of many JMSMessageIds. Similar to JDBC batch statements
- Disconnected & Federated Acks: In complex systems where messages can flow through multiple tiers of application servers either as the original JMS message or as an enriched DTO/VO, allowing the final tier in the flow to acknowledge the message purely by JMSMessageId would be very useful. Currently, only the client that received the message from the server can acknowledge it. Also the message has to be held in memory for the duration. In SEDA systems this does not work well and forces the developers to jump through unnecessary design hoops
- Smart selectors: JMS Selectors are very static and expensive to apply at high message rates. They were meant to work as a rudimentary form of Content based routing. What is really needed is a way to let the client run custom logic (like RMI) through the queue and pick what it needs. This way clients should be able to use a modified form of QueueBrowser and consume anything it finds interesting
- Context aware routing: ActiveMQ has a non-standard feature called Message Group that can be used to perform smart message routing using a custom header. This would be a welcome feature where data aware routing would provide a huge performance improvement by exploiting data locality to deliver related messages to the same application server and thereby avoiding data/cache thrashing
Until next time, cheers!