- From: Oisín Hurley <ohurley_no@spam_iona.com>
- Date: Sat, 8 Jul 2000 14:14:18 +0100
- 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 UTC