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



Francis Norton wrote:

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

I agree with this and believe that it is the inevitable consequence of the
greater diversity and node-to-node differences which are possible in the
internetwork topology.

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

I believe that, given my understanding of node-to-node diversity and autonomy
in the internetwork topology, these 'close-coupled' premises are SOAP's chief
design flaw.

> There's nothing to stop you sending single literal XML documents, there is
> just no explanation of how literal XML
> content should be signalled

A weakness.

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

A strength.

> We already use XML Schema structured messages to interface between major
> components, internal and external, of our retail finance systems.

I believe that this is too fine-grained for communication with arbitrary
counterparties across the Internet. The business strategy question, of course,
is whether that is what you want to do.

> My view is that [a] single document style is far more productive than RPC
> style,

Agreed.

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

IMHO this presumes that the application knows more of the schema, or that the
schema designer knows more of the application, than I believe is a healthy or
reasonable assumption in an internetwork topology.

> and [c] that XML Schemas will be the units of selection by which industry
> standard common message structures will evolve.

I believe that selection by structure, or schematic, is too brittle and
fine-grained for the limited knowledge of one node by another in the
internetwork topology. I specifically believe that, over a large population of
diverse nodes, there will be only a small percentage whose interaction is
standardized by the structure of the message exchanged.

Respectfully,

Walter Perry