To make integration work the discussion seems to focus on the transport rather than the message. We are trying to convey meaning the transport is largely irrelevant providing both sides speak it and HTTP is the lowest common denominator.

If I may make a bold statement - between disparate systems (even similar systems ) the transport protocol is HTTP and the message format is XML, end of story. There are other use cases and approaches but they are edge cases and very domain specific and have propriety end points such as AS/2. For the foreseeable future the common transport is HTTP(S), protocol independence is a futile exercise and (IMHO) should be abandoned.

The real issue for most applications is which end is going to do the transformation into the format necessary to process the message. Whether the message is formatted as a SOAP or REST message is largely irrelevant to the end point that needs to do the transformation, the issues that need to be addressed are:

• Is the message understandable?
• Is there sufficient fidelity for understanding?
• Can the message be converted into the receiving format?
• Can the response be returned in an understandable format to the sender?

This is because any standard needs to both exist for at least five years and be actively deployed for five years before it makes any impact on the industry as a whole. In my current environment we are integrating systems from Windows 3.1 to the present day. This is real life, and it will always be this way, legacy systems will always be in the majority. Interesting however the information flows are pretty constant, how they are described and formatted has not changed much - they have become formal and faster but the core information is the same.

The point is therefore the transport of the information needs to be the lowest common denominator while the ability to convey meaning must the focus not the protocol.