RE: [R6xx, R7xx] Application of XP requirements to SOAP 1.1

Oisin,

Good start! Here are a few questions/comments...

> R700a - mechanism for carry application specific content
> 
> This requirement is partially addressed by SOAP 1.1, which provides a
> SOAP:Header extension element that may be used to add arbitrary XML to
> a SOAP:Envelope.
> 
> SOAP 1.1 does not include defined mechanisms to carry and reference
> payloads outside the SOAP:Envelope, nor does it address carrying
> non-XML formatted information.

I believe it specifies a mechanism for referring to data outside the
envelope using the href attrbitute. It is correct that it doesn't say
how to carry data outside the envelope but in fact SOAP itself doesn't
even say how to carry itself. This is where the protocol binding model
comes in.

> --
> 
> R700c - predictable failure model for extensions
> 
> Partially addressed by the simple semantics of SOAP:fault categories

I think it is as important if not even more so that SOAP supports a
decentralized fault mechanism with no requirement for central
registration of fault codes and each SOAP "block" to steal a term from
XML protocol can report faults in a manner that is orthogonal to any
other block.
 
> --
> 
> R701a - single schema-defined container for messages
> 
> The SOAP 1.1 Enveloping scheme satisfies this requirement if taken in
> isolation. Given the context of other XML Protocol requirements and
> the context of binary content discussions, the SOAP 1.1 scheme may
> only partially satisfy this requirement.

I don't follow you here?
 
> --
> 
> R701b - processing model
> 
> Is only slightly addressed by the concept and categorisation of faults
> and so is not satisfied by the SOAP 1.1 specification.

I don't understand what you mean by "slightly" - there are specific
fault codes for fault cases that directly are a result of the basic SOAP
processing? There are of course not fault codes for anything else.
 
> --
> 
> R703a - transport neutral XML protocol fault entity
> 
> SOAP 1.1 provides a fault entity, but also has an implicit dependence
> on HTTP for delivery, so it partially satisfies this
> requirement. Again, it is in a fairly unsophisticated manner as the
> faultcode semantics are limited.

I agree that SOAP needs a binding to a specific protocol in order to
deal with the actual transfer of a message but not that HTTP is
implicitly required nor that fault messages are bound to HTTP responses
in any way.

I am not sure I understand what it is that you find limiting in the
fault code?
 
> --
> 
> R703b - transfer of status information
> 
> Not satisfied in SOAP 1.1

That depends - SOAP leaves it up to the application to define what
status information os. For example, SOAP doesn't care if you send a
purchase order and get back a "thank you we are working on it" message.
The only thing that it does care about is whether it is a fault. So in
the sense that one can stick (in theory) any data into a SOAP message
then why wouldn't status information be part of that as well?
 
> --
> 
> R600 - transport protocol neutrality
> 
> SOAP 1.1 has an implicit dependency on a synchronous request/response
> transport protocol to achieve correlation. It has a further implicit
> dependency on SOAP processor endpoint information being transport
> protocol endpoint information.

SOAP is fundamentally a one-way message so it doesn't know about
correlation and therefore doesn't really have an implicit dependency on
a request/response protocol. Of course, what you get when you use a
request/response protocol is some kind of correlation but there is there
a reason why one couldn't do that as a SOAP header (XML protocol
module)?
 
> --
> 
> R604 - non-lossy transport protocol bindings
> 
> Not relevant to SOAP 1.1, so not addressed.
> 
> --
> 
> R608 - security specific bindings
> 
> Not specifically addressed by SOAP 1.1, although limited extension
> facilities may be used to help achieve this goal.

As there effectively is a binding for HTTP to SSL then wouldn't the SOAP
binding to HTTP be sufficient?
 
> --
> 
> R609 - possible mandatory character encoding
> Not specifically addressed.
> 
> --
> 
> R612
> A binding to a synchronous request/response protocol is implicit in
> the SOAP 1.1 specification, so a normative binding to HTTP is 
> not addressed.

I don't see where you read this out of the SOAP spec - to my knowledge
it doesn't say anything about sync messages or request/response other
than in the HTTP binding which of course is intended for this purpose.
 
Henrik

Received on Thursday, 25 January 2001 15:03:56 UTC