When I first read the SOAP
specification I could not decide whether it was meant to be a replacement
for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the
ligua franca of SOAP was XML. But at the same time, Section 5 supported
the RPC view of SOAP. Unfortunately this section seemed to just confuse the
issue between the RPC world and the document/literal world.
In a great MSDN
Article, Tim Ewald argues against support for Section 5 support. I guess I
haven't been keeping up, but I am excited to hear that Section 5 support is now
optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever
die?
As I started playing with .NET's Web Services Framework some years back, I
was excited and dishearted at the same time. It supported doc/literal by
default, but it seemed to want to hide the fact we were using XML in any
fashion. How unfortunate.
Tim recently gave a great talk at the Web Services DevCon about this
very issue. Now Tim seems to want to go farther than I would (wanting to deal
with all SOAP messages as XML Streams), but I think he is on the right track.
Instead of creating .NET types (or Java Types for that matter) when defining Web
Services interfaces, I think we should be defining XML Schemas that define the
interface. This would allow us to remember we are dealing with XML without
having to intercept the XML streams directly. It seems to me that the more we
use XML as our Web Service Type System, interoperability between differnet
technologies (e.g. .NET on one end and Apache Axis on the other) becomes less
and less an issue. All the better if the XML documents are well known formats
(e.g. XBRL).
