Reliable Messaging Redux  

To respond to Doug Kaye - Confusion over Messaging and Phil Wainewright- Out of sync I do not thing we are far off in agreement. It is all a matter of approach. As Doug points out I am the CTO of Grand Central but for Grand Central to be successful we need to have standards be widely adopted. We cannot scale our business if every customer has a radically different implementation of reliable messaging. Currently our focus is to enable everyone to talk to one another in a cheap, simple and reliable fashion. As this becomes easier the focus of Grand Central moves more to providing the policy framework to allow businesses to interact in more sophisticated ways (long lived conversations with compensation transactions etc.).

To get to standards I am advocating a minimalist approach to standards by using the inherent structure of SOAP (header and body elements) and XML Namespaces to evolve standards. My issue with ebMS is that it tries to do everything, therefore if one part does not work it can cause problems with the whole standard. I believe working code and real business use cases move standards forward faster than any other factor. Adding complexity/features before you really need them slows down a standard. Web services are designed to be modular - lets create standards the same way.

JMS has a lot of real world experience and working code, but as Doug suggests it is Java centric and even though it is well designed it will not be able to get the support of all players. The other key factor is that it is not a protocol it is an interface specification - BEA's JMS cannot talk directly to IBMs, Tibco's or Sonic's. You can deploy gateways but the complexity becomes high.

In the end I am not sure a single standard will work for the complexity of reliable messaging. As I mentioned in my earlier post, reliable messaging is not one problem but several broad problems with different levels of reliability and delivery semantics. Tibco (a former employer) has spent 16 years working in this space solving real customer problems and they have not got it down to a single protocol and package. They have different flavors of the TIB for different solutions and have worked really hard over the last several years to keep everything in one product line (Rendezvous) but if you go through the product information and documentation you see that while it is a well design product it is very rich and complex. Therefore based on this real world experience I do not see a single uber standard being the right approach

posted by John McDowall | 7:59 AM