Is it the message or the transport

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.

Phil Windley as usual makes good points in his post ? On the death of SOAP | Between the Lines | ZDNet.com but I think the issue is in the white space between the transport - HTTP and the message - XML

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?

I am not sure REST or SOAP address these issues. A well documented schema and a well written HTML page probably contribute more to message integration than any WSDL or REST URI

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.

Impedance Reduction

One of the usual starting points for me in a design is the flow of information. That usually leads me to creating a set of XML Schemas for the information flow. This works well until I need to start developing code. In the past this has been a little tiresome to create (and recreate as the design evolves) the bridge between xml and the application.

This problem seems to be rapidly going away both in the Java and .Net environments, in Java I am using XMLBeans which once you get it installed and working provides a slick and easy way to map between schema and Java. In the .Net world I have been using a tool called xsd that is part of Microsoft .Net toolkit.

On the two approaches XMLBeans seems to be the most polished and functional but it is great to have similar functionality in both environments to improve productivity and reduce the drudgery.

REST and SOAP: Fitting them into your toolbox

Two appropriately cautionary posts about SOAP and REST raise some good issues,
Jon Udell: Don't throw out the SOAP with the bathwater and
Steve Vinoski: SOAP vs REST: stop the madness.

I have always had the metaphor of a toolbox where I keep the set of tools I need to do my job. Taking it a little further I have seen the standards process (both informal and formal) as the series of events that shape and separate the tools in the toolbox. This shaping and separation ensures that the tools can work together and overlap enough to solve most problems. The struggle I am having is where do these tools fit in my toolbox?. Jon Udell asks the question:

Why must we make everything into a rivalry? Why can't we just enjoy the best of all worlds?

Today I use both for different purposes but do I want to support both for all customers - this becomes an economic issue that significantly reduces the enjoyment. If I support one over the other, what do I say to a CIO about why one versus the other should be in our mutual toolbox. Is it clear when to use SOAP and when to use REST - if it is clear then we have the best of both worlds - until then we need to keep working on shaping our tools.