Reliable Messaging and Loosely Coupled  

I think this is a measured response to some popular misconceptions about enabling reliable messaging in a loosely coupled framework ( I use the word framework as I am not sure what else to use, I could use environment, space, etc). One of the key misconception is that this is a transport protocol issue - it is a mediation issue among application protocols. The applications can be anywhere in the seven layer stack and still enable reliability.

In Reliable Messaging Doug Kaye gets it partially right in that the three alternatives presented in the article Sending an unmistakable message will probably not be the solution. I would have thought that Doug would have recognized this a problem that requires a loosely coupled solution. Or at least a minimalist approach, otherwise the degree of agreement required by every end of the reliable conversation becomes too complex just considering several point-to-point conversations. When the problem is extended to multi-party conversations the problem forces a loosely coupled approach.

For this discussion I would like to define reliability a little more precisely into three categories

Messaging Categories

• Reliable If there is no network failure great than or equal to the timeout period of the transport protocol (TCP or UDP), i.e., you unplug and replug in the network cable without any data loss.
• Guaranteed: No matter what happens to the physical network connections or the destination service the message will be delivered within a time period defined by the sender. If the message is not delivered the sender will receive a message showing non-delivery. Here a message is guaranteed to be delivered regardless of physical network conditions or reliability of the destination
• Transactional: This expands on the previous case by adding the complexity of transactional compensation to the picture. If any party in the transaction fails all parties are guaranteed to be informed about the state of the message within a specified time period.

To achieve any level of reliability, there are a few assumptions that must be made that are consistently overlooked about to the environment the solution is to be deployed in.

• The environment is homogeneous, this is a common problem for JMS solutions. JMS is not a protocol it is a set of interface specifications. It is a well designed set of interfaces, as it covers all the cases considered above, but if two different providers are used unless a gateway is deployed there is no interoperability.



• Producers and consumers of services are at the same level of technology. As technologists we sometimes forget that most organizations go through a natural technology adoption cycle. This cycle is 2-3 years for most companies at a minimum. This is the time required to evaluate, deploy and capture value before moving onto the next technology wave. Therefore most companies are not synchronized in terms of technology adoption and never will be given the current pace of technologies.



• Adoption levels: not every company has the same degree of sophistication, and more significantly not every company needs the same degree of sophistication in all areas. Therefore matching up levels of technology is problematic

The final factor is that all these parameters are moving independently driven by widely different business requirements at different times and on a different time scale. Therefore to presume a homogeneous environment is a false assumption except in the rarest of cases. Traditional techniques have attempted to force homogeneity by deploying the same software at every node. This solution works when one partner has power over the others and/or deep pockets. This then puts the responsibility for change management and the definition of all interactions onto the partner with the "power". If the business world is considered to be more of a mesh or grid of relationships than a set of independent hub and spokes it becomes obvious that forcing homogeneity does not scale.

The objective of standards in this area should be to create framework standards to enable loose coupling of systems rather than imposing a rigid standard that forces tight coupling on all participants. This is where there is a need for frameworks/platforms based on a Services Orientated Architecture (SOA) to enable reliable conversations among all parties and enabling change at everyone's own pace. The solution is a flexible mesh capable of supporting heterogeneous nodes and change.

Framework standards such as WS-Coordination allow multiple parties to interact with the minimal amount of shared information - i.e., an unique coordination-id. This minimalist approach to protocol standards specification is much more aligned with a loosely coupled world than over specified standards such as ebMS. Over specification before there are substantial working implementations and real world experience rarely results in a broadly accepted standard.

Focusing on solving real business problems through a loosely coupled SOA and a minimalist approach to standards will accelerate adoption faster than complex standards trying to solve complex technical problems in a complex problem space. We need to focus on the intent not on the technology.The intent should be to create the flexibly and adaptable mesh not hard wired connections

posted by John McDowall | 7:54 PM