In writing one of my chapters on protocols and messaging for my next book, I wound up writing up this on the subject of MOM and interoperable wire protocol… I’m curious what people think….
When using a Message Oriented Middleware (MOM), a sender and receiver need to have a piece of client software that is supplied by the MOM vendor in order to participate in a messaging conversation. Granted its a small piece, often less than 1 meg, but the point is not about the size but the fact that there is a piece of software on both sides of the wire. JMS is the only adopted standard for MOM, yet it does not define an interoperable on-the-wire format and therefore does not alleviate that situation. The reason for this is the internals of the wire protocol are part of a MOM vendorís proprietary implementation for providing highly efficient reliable delivery of messages. I’m not talking about UDP vs. TCP/IP, vs something else. I’m talking about the next protocol level above that–the message transport layer–which has to do with what govern’s the behavior of things like message level acknowledgements and retries.
JMS does dictate that messages must be interoperable between vendors, meaning that a JMS message must be capable of being received from a Topic or Queue from one JMS vendor, and placed on a Topic or Queue of another JMS vendor implementation without modification. Most JMS vendors (and ESBs) provide bridge technology to do this.
WS-Reliability and WS-ReliableMessaging (collectively referred to as WS-Rel*) are industry efforts defining an open interoperable wire protocol for reliable messaging based on the SOAP protocol. It is conceivable, and also probable that a MOM implementation could be based entirely on one of these WS-Rel* specifications. However, that would still require a piece of MOM infrastructure be on both sides of the wire to handle behavior such as acknowledgement of receipt, message persistence, and recovery from failure. From that perspective, what you gain by having an open protocol is the ability to have the MOM piece of software on either side of the conversation provided by a different vendor. However this is at the expense of having less room to innovate on efficiencies of acks and nacks at the message transport layer.
Thereís a 80/20 rule to be considered here. For the most part, you arenít mixing MOM implementations on a regular basis, unless you are bridging together a new project with an old one, or if you are connecting together different departments, business units, or business partners who have their roots in one implementation or another. So for the 80% normal case, you are using one MOM vendor for a particular project, and for that it shouldnít matter what the internal protocol is between the pieces of the MOM software any more than it would matter whether there was an open standard for how a DBMS writes and manages storage on disk (just my luck, someone will chime in an tell me there is one for that). For the 20% or less case, you are mixing MOM vendors via bridging technology or WS-Rel* endpoint implementations together
I think Iím actually being generous with the 80/20 ratio. I believe its actually 90/10, or even higher. I mean, think about how many applications that you have spread out across your company that could benefit by being integrated together using messaging as the core of an integration strategy. Compare that with how many instances of integration you need to do with outside entities where you donít have any control over what software gets installed, and would therefore need to have an open reliable protocol like WS-Rel*. That would be your ratio. I would like to hear from folks what that is.
I am not trying to say anything negative about the need for WS-Rel*. I am a big proponent of both of the WS-Rel* specs, and have contributed to both. I am just trying to put it into the proper perspective. I’m not saying anything that’s contrary to the intent of WS-Rel* either. WS-Rel* provides much-needed interoperability between MOM implementations for the use cases where its applicable. And for that, we are all grateful (MOM vendors and users alike).