B2B and Document-Literal SOAP
This article - XML: New Options, New Worries in eWeek last week makes the point that:
"the difference between a Web service and two applications exchanging data over EDI is largely semantic".
The article then goes on to talk about the problems associated with the fact that, even within the world of EDI , there are semantic differences which require document conversion. As those of us who've worked in that area know from bitter experience, this is an awkward process, which isn't helped by fact that EDI files generally mix syntax and semantics. With, let's say, an EDIFACT purchase order document, there is no DTD or Schema to help out with a line like this "DTM 137 19961015 102", which includes semantics ("DMT" means that the line refers to a "Date and Time", 137 refers to the specific format of the time and 102 is the action to which the date refers, all to be looked up in the EDIFACT documentation). "19961015" is the date itself.
With XML, syntax like angle brackets divides up the data and the semantics of the data. This reminds me of an insightful paragraph in XML Topic Maps (edited by Jack Park) which begins:
Excuse me for saying so, but there is no such thing as unstructured information.
Even the simplest kind of information has a sequence in which there is a beginning,a middle, and an end, some concept of unit, and, usually, several hierarchical levels of subunits.
With XML, the structure and hierarchies are just more obvious to the naked eye. With EDI, they are still there. So - it's not only EDI and Web Services data which may only differ on semantics (which is the same thing as saying they're "semantically the same" - funny thing, the English Language) it can be any kind of data.
The eWeek article then goes on to way that:
"While previous electronic data interchange-based B2B systems were essentially advanced document management systems, XML and Web services have made it possible to build B2B infrastructures that are truly integrated, removing lots of midlevel steps that either needed to be performed manually or required heavy API-based integration"
It's true that extended family of XML technologies certainly helps to ease data integration. However, one of the strengths of EDI is the fact that it is like an "advanced document management system". With EDI, two systems can agree on what documents they would exchange, but didn't have to go any further than that. They don't have to agree to make RPC calls to each other, or even to perform synchronous communication - they can use store-and-forward systems like X.400 mail. They don't have to share an object model, or even use the same platform. All of this points to Document/Literal SOAP, not RPC, as being the likeliest candidate for EDI over Web Services. Of course, you can do both.
[Mark O'Neill's Radio Weblog]
Since I had a 'phone discussion on this topic only last week (the UK Government is feverishly trying to 'web service' everything, and as far as I can determine, its not going well, lots of words but not a lot working) - just posting this for my own reference.