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).