W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2000

Re: announce: WorldOS 0.2

From: Oisín Hurley <ohurley_no@spam_iona.com>
Date: Sat, 8 Jul 2000 14:14:18 +0100
Message-ID: <00b601bfe8de$7149a9e0$e09578d4@ohurley>
To: "Lucas Gonze" <lucas@gonze.com>, <xml-dist-app@w3.org>
Hi Lucas,
I the opportunity to browse through your worldOS page and got a bit
interested when I came to
this in the 'future directions' section:

>XML-RPC and SOAP support in the HTTP transport are probably inevitable.
FWIW I object to the design >of those specifications, as they start with
datatyping instead of semantics, which seems to me exactly backward;

SOAP is intended to represent data - message types, invocation frames,
context information, etc. It not intended to describe connection semantics,
fragmentation, channel management and the like. This area is the prerogative
of the protocol that carries the SOAP envelope. Hence the datatyping rather
than the semantics issue - it's there by design.

>and locate elements by fixed position, as an array would do, instead of by
name, which has the damaging effect >of making cross-version compatibility
difficult;

 [I assume you are talking about XML elements and that you find the SOAP
syntax too constricting]

Cross version compatibility I think is catered for -- the syntax is
extensible, provided it fits within the framework of the envelope, header
and body elements. I think this is acceptable - if interoperability is a
goal, which it is for sure with SOAP, then it is important to preserve some
kind of basic structure.

>and as they assume sychronous request/response pairs.

One first look at SOAP that appears to be the case, as there is no explicit
request/response correlation key within the message. Keeping in mind that
the current versions of SOAP all run over HTTP, it's easy to make the
assumption that SOAP will depend wholly upon some underlying protocol for
ordering of request-response pairs. This need not actually be the case. If a
SOAP-carrying network protocol provides correlation, then that's all to the
good. If it does not, it is possible to extend the SOAP headers to do the
correlation in your own way.  In fact there is a distinct advantage to this
approach as its flexibility means that you can have correlation schemes or
arbitrary complexity, like state machine rules or multiple data
contributers. So there is no assumption on the part of SOAP about
synchronous request/response pairs. In fact, SOAP has been designed to be
more aligned with the asynchronous/messaging style of communication.

 cheers!
    --oh

-----
Oisin Hurley
IONA.
Received on Saturday, 8 July 2000 09:27:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT