Why JMS is Cool

What makes JMS programming much cooler than programming TCP communications, Morse code, or messages in bottles is that all the responsibilities are heaped onto the JMS service provider, whether it's housed inside or outside your own system. Say you want to pass a message—some arbitrary byte array or text—from process A to process B. You simply create the message and hand it to the JMS service provider through its standard interface.

Here's what the JMS provider guarantees it will do with that message:

• Cache it in persistent storage. The message will be retained, even if your process experiences catastrophic failure. (Persistent storage is optional; for efficiency purposes, you can specify messages are stored only in memory.)
• Distribute it to all subscribed outside-user processes. Anyone interested in the message will receive it. Messages are sent either to multiple recipients, known as the publish/subscribe model, or to at most a single recipient, which is the point-to-point model.
• Distribute it, at most, once. This ensures there is no chance for accidental multiple deliveries. Actually, you have two delivery options: durable or non-durable. Durable messages are delivered to recipients exactly once, guaranteed. Non-durable messages at delivered at most once, but may not get delivered if the recipient is offline.
• Distribute messages in the order they were sent. According to your chosen delivery options messages may have a 1 to 10 priority; JMS delivers higher priorities first, while messages of equal priority arrive in order—FIFO, that is.
• Distribute the message under a JTS transaction. Messages are distributed to remote JMS agents in each consumer process, but not handed over to consuming code until the JTS transaction is committed. (Messages are said to be staged until actually delivered.)

So a JMS implementation provides a ton of superstructure on top of plain message delivery. Of course, you could implement all these features yourself. There's nothing stopping you from designing a protocol with enough ACK and RESEND tokens to get all these features. But with JMS this is not necessary. You just get a JMS implementation from a provider and save yourself all the work. Furthermore, because JMS is a standardized interface, it means you can swap out implementations. If one JMS provider is too slow or too buggy, you can get a different implementation from someone else.

Next: Justifying JMS through Science