RE: XML.COM: How I Learned to Love daBomb

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Al Snell [mailto:alaric@alaric-snell.com]

<snip/>

> People do order processing and stuff over RPC, too. The focus 
> on business
> stuff now is because the network extends between businesses 
> when it didn't
> before... we can do more stuff with RPCs now, but there's nothing
> really different about the protocol.

RPC could never displace EDI technologies. It's too rigid and inflexible. If
you want to adapt to a particular format over the wire, you have to write
the source for your business services to match that format. Every new format
requires the coding of a new interface.

XML-based technologies can displace EDI, because they can easily support an
adaptive layer that can map different XML structures into the same core
business services.

SOAP can support both RPC and more flexible approaches to messaging like
EDI. In so doing, it offers a common foundation that minimizes reinventing
the wheel. It provides a standard mechanism for recognizing a SOAP messages,
for clearly differentiating error responses from successful responses, and
for disambiguating elements that carry generic information relevant to the
execution context (e.g. authentication info) from elements carrying business
processing info.

This debate seems reminiscient of the recurring debate about "what is XML
good for?". We've seen these challenges on xml-dev before from those who
argue that XML is a retrograde step from binary formats like ASN.1. XML had
explicit design goals that were not met with these other formats. The broad
success of XML seems to me to indicate that those design goals hit a sweet
spot with most developers. For my part, I find it refreshing to be able to
look at the messages I'm sending between applications in an ordinary text
editor when I'm debugging an integration (and be able to easily read the
message). I'd be quite happy if I could consign my hex editor to the dustbin
forever.