Re: Issue 192 & R803

> Non-SOAP HTTP intermediaries have no business with the SOAP envelope
> in the entity body except as an opaque blob that happens to be
> of some media type. If they go beyond that, then IMO, they are
> SOAP intermediaries.

Absolutely!  That's why the HTTP envelope needs to be kept in synch
with what SOAP is doing.

> > I don't follow.  The processing model doesn't care whether the received
> > envelope contains a fault or not.  This is consistent with the
> > chameleon use.
> 
> 
> That's not how I read section 2.5. A SOAP intermediary isn't concerned
> with the SOAP Body EII and its contents, to be sure, but the
> SOAP node operating in the .../ultimateReceiver role MUST be capable
> of "correctly processing" the contents of the SOAP Body EII which I
> interpret as meaning, if the child of the SOAP Body EII is a SOAP
> Fault EII, it is a fault, and I process it as such unless there
> is some SOAP Header block telling me otherwise. That is the SOAP
> processing model as I understand it. The SOAP Processing model
> doesn't say anything about bells and whistles in the underlying
> protocol effecting the SOAP processing of the received SOAP message.

That's not how I interpret it, and your interpretation goes against the
chameleon view and R803.  We should probably fix the wording if it's
being interpreted in this manner, because surely you won't be the only
one to interpret it this way.

> You've lost me entirely.

In order to understand a message, you have to understand the context in
which the message is communicated.  In the chameleon view, the
underlying protocol provides the outermost context.  In the tunnel view,
the SOAP envelope does (i.e. it disregards the meaning of the
containment of the SOAP envelope within the HTTP envelope).

> > But an HTTP intermediary doesn't "process" the SOAP message; it knows
> > nothing of SOAP.  But it does know about success and failure.
> 
> 
> Now I am completely at a loss to understand what your issue is.
> 
> The resolution to issue #12 says that if a fault is generated,
> as a result of SOAP processing, you use a non 2xx HTTP status
> like 5xx or 4xx. That seems consistent with the chameleon view
> in my mind, so I'm at a loss to understand what issue you might
> have with that aspect.

I'm happy with the resolution of issue 12.  It's having a consistent
interpretation of the contra view that is what 192 is about.

> On the other hand, you say you have a use case where you want
> the equivalent of GET /errors/404 HTTP/1.1 which returns a SOAP
> message that is identical in all respects to a generated SOAP
> Fault message, tack it onto an HTTP/1.1 200 OK response and
> have it treated by the receiving SOAP node as <not><fault/></not>
> (as well as by any non-SOAP intermediaries).
> 
> What I'm saying is that you cannot do this consistently for
> *all* transport/transfer mechanisms because they are not all
> as perfect as HTTP. SOAP is intended to be independent of
> any underlying transport/transfer mechanism used to convey
> SOAP messages:

Yes, and with the chameleon view, these things only come out in the
binding.  SOAP and the binding framework would remain independant of
any underlying protocol.

> A SOAP message carries its own semantics.

Not in the chameleon view, it doesn't, as I explained above.  The
context provided by the underlying application protocol is required
in order to understand the entire message.

Sorry, I'm repeating myself, I know.  But I'm a bit confused.  Are you
trying to say that the chameleon view is invalid, or just that my
interpretation of it is incorrect?

I understand that this is difficult to communicate, because there's
several important things that have gone unsaid in the work we've done
here, not the least of which is that REST is a sufficient basis upon
which to implement Web services.  REST doesn't need the tunnel view of
SOAP, it just needs a protocol that implements the architecture it
defines.  That is HTTP.  The chameleon view exposes REST through
SOAP, by inheriting HTTP's application semantics.

> To a SOAP Processor, a
> SOAP message with a SOAP Fault EII as the child EII of the SOAP Body
> EII is a Fault, barring any SOAP Header extension that modifies these
> semantics. If you want to convey the equivalent of carrying a 404
> response entity body's HTML representation on an HTTP 200 OK, then
> you need to have some equivalent in SOAP. The SOAP Header extension
> example I gave in my previous posting would be an example of that.
> There's just no escaping this IMO or else you've broken SOAP for
> anyone not using HTTP protocol (exclusively) which defeats the
> whole point of SOAP (IMO).
> 
> To impose a requirement that all underlying transport/transfer
> mechanisms to which SOAP is bound be capable of (natively)
> conveying fault information the way HTTP does/can is unrealistic
> and violates R600 above.

Not just HTTP, but all application protocols.  Every application
protocol I know of has a notion of "failure" and "success".  I'm saying
that best practice for SOAP bindings to application protocols should be
to use those as authoritative.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 29 March 2002 14:18:50 UTC