OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: APIs, messaging

"Simon St.Laurent" wrote:
> XML offers computing the opportunity to behave much more like the "real
> world", where communications is inexact and messy and the
> standardization costs are only borne if there's a real benefit to
> standardization.  (ISO standardizes shipping container construction, not
> which contents are appropriate to containers.)
I agree with your analogy but not, I suspect, your conclusion.

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

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.

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

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.