Re: APIs, messaging

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> We are watching a transition from "close-coupled" comms to
> "loosely-coupled" comms. I'm using "coupling" here to refer to how much
> the send and receive code has to know about the fine structure of the
> data being sent, from an RPC-style list of individually-typed parameters
> at one extreme to a single XML document at the other. This is
> crystalised in the web-services technology stack, and not always in the
> ways you might expect.
>
> SOAP, the exciting XML contender, has a spec which is focussed on
> close-coupled calls. The SOAP EncodingStyle allows you to serialise an
> RPC-style parameter set. There's nothing to stop you sending single
> literal XML documents, there is just no explanation of how literal XML
> content should be signalled, just a statement that the "section 5" SOAP
> EncodingStyle is the only one defined in the spec, and "There is no
> default encoding defined for a SOAP message."
> (http://www.w3.org/TR/SOAP/#_Toc478383495)

Wow.  In the above 2 paras, you essentially read my mind and spilled the
contents forth to the list.

In my latest Thinking XML column installment I tossed the cryptic barb
that ebXML's adoption of SOAP could actually prove a defeat for its
principles of loose-coupling.  The tyranny of the SOAP serialization is
one of the factors behind this observation.

While I left this unsaid in my column, I have vented about it at length in
discussions about Python/Web services efforts.  I had an argument with
Rich Salz because I chose not to use the SOAP serialization when
implementing the "native" SOAP API for 4Suite Server.  I chose not to do
so because section 5 is such a horrid mess and besides, my intentions were
not to create yet another RPC mechanism for 4SS but rather to provide a
message-oriented request system.  Someone with a stronger stomach than I
do might still implement section 5 for 4SS so that the RPC folks can do
their thing, but this wasn't the point of the argument with Rich.

He as much as said that any SOAP implementation that didn't use section 5
was wilfully flouting interoperability goals.  I pointed out that if Web
services were to offer anything more than CORBA or DCOM they would have to
provide true loose coupling in the face of the normally opaque boundaries
between information systems.  Registries and the technology to mine them
for the requisite data models are the key to Web services success, not
forcing conformity of core message payload format.  Egads, this is XML,
isn't it?  Remember the "X"?

I'm not saying that registries are a magic bullet for successful
interoperability in the face of loose coupling.  There is still a lot of
work to be done, and some of it may require fundamental comp sci
developments, but if Web services are really a valulable new development,
and not just a slower, less secure, fatter network form of RPC, we'll have
to find a way to make it as flexible as the pundits claim it can be.


> WSDL makes explicit provision for both RPC-style and document-style
> messages - in fact for the SOAP binding, the default values for the
> soap:operation/@use and soap:body/@style attributes appear to make
> unadorned literal XML content the default.

I'd like to think this isn't a sop to folks who argue as I do, but every
example and piece of advocacy I've seen invariably involves SOAP
serialization in the "message/parts" and XML schemas in the "types"
descriptors.


> The UDDI Programmer's API 1.0, I notice, specifies that "In version 1 of
> the UDDI specification, the SOAP encoding feature (section 5) is not
> supported. Operator Sites will reject any request that arrives with a
> SOAP encoding attribute."

Whoa!  I missed this, and I'm quite surprised, I must say.  Maybe there is
hope...  Gotta go research.


> We already use XML Schema structured messages to interface between major
> components, internal and external, of our retail finance systems. My
> view is that [a] single document style is far more productive than RPC
> style, [b] that XML Schema means that the message can use declarative
> validation in the comms layer rather than procedural validation in the
> application (and no, DTDs don't cut it for us) and [c] that XML Schemas
> will be the units of selection by which industry standard common message
> structures will evolve.

I can buy most of this, but parts of it requires my sprinkling on a lot of
hot Nigerian pepper to mask the bad taste.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python