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

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

That is possible for XML data that uses the id/href mechanisms for
reference. But this is not _explicit_ in the text of the SOAP 1.1
document, it is up to the reader to _assume_ that this is the case.
So it doesn't really address it IMHO :)

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

I don't think these points are actually related, Henrik! :)

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

Standard semantics for certain failure modes that are relevant within
the standard SOAP processor architectural artifacts are necessary for
definite. Mapping of these failure modes to transport protocol failure
modes, should they be supported is necessary in the transport protocol
bindings. Extension is required for application specific and proprietary
extra information or finer grained failure semantics. Er, I'm agreeing
with you here...

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

An assumption on my part that schema-defined means XML Schema defined
that means XML container (rather than say manifested multi-slot container).
I'm not a schema expert so this may be incorrect.

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

XML Protocol will have a richer processing model and it appears that we
will also generate at least a notional processing architecture. SOAP 1.1
has faultcodes 'Server' 'Client' 'VersionMismatch' and 'mustUnderstand'.
This reflects a simple processing model that will not be rich enough for
XML Procotol, IMHO.

> > 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 shouldn't have said HTTP here, sorry! What I meant was SOAP 1.1 has an
implicit dependence on synchronous request reply transport protocol to
achieve request/reply/fault correlation.

> I am not sure I understand what it is that you find limiting in the
> fault code?

It's fine for SOAP! I think sticking to the scheme of SOAP 1.1 will be
limiting for XML Protocol, which will have a more explicit and richer
processing model.

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

Ah yes, if you have an extensible protocol you can make anything of it :)
BUT what I was addressing was an _explicit_ conventional approach to
transferring status information, which is the thrust of R703b.

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

If SOAP is one-way, then it should not have an RPC convention, or it should
at least say this and explain the semantics. This is why I argue that
SOAP1.1
has a dependency on certain transport protocol features. I think the problem
here is because the SOAP 1.1 note does have a number of interpretations in
the details - purely because it hasn't suffered the slings and arrows of
a large committee based standardization process ;) Rather than bash my
assumptions off yours, we will need to get this fixed in the XML Protocol
definition!

As for SOAP header, that can certainly be used for correlation info!

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

Ummf - I don't know without further thought and analysis as I have a very
basic SSL operation knowledge. Anyone else for this one?

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

Ok, it's an assumption :)

thanks for the comments!
  --oh

Received on Wednesday, 31 January 2001 17:46:07 UTC