>
> In OSI-speak (since somebody brought it up) IIOP, SOAP (as commonly
> used), etc.. are layer 5/6 protocols, while transfer protocols are
> layer 7. That's why I've always got a chuckle about those try to put
> SOAP over HTTP 8-)
Mark, as you know very well, the use of SOAP as IIOP was what was done
originally but is NOT what SOAP was meant to do and certainly not what
is being advocated and support now. SOAP is much better suited as an
envelope structure to send documents around rather than as an envelope
structure to send RPC requests over.
As such, SOAP is most certainly not in the space of IIOP. The only bits
of SOAP that was like that was Section 5 of of SOAP 1.1, which is now
gone in SOAP 1.2. Even the WS-I basic profile does not support that.
HTTP as a protocol transfers hypermedia application semantics.
Similarly, SOAP is used to transfer application semantics between one
app and another. So if I'm sending SOAP over HTTP *and* following the
semantics of HTTP, what is broken?? Do you know why all SOAP server side
faults result in HTTP 500? That's precisely to adhere to HTTP semantics.
Can you point to places where the SOAP over HTTP binding violates HTTP
semantics? If not, how is SOAP going over HTTP any more broken than
anyone putting together some random bit of XML and sending that over
HTTP? Or is that broken too in your book? Let's generalize, if the data
I'm sending over HTTP has ANY semantics for the apps sending/receiving
them, then is that usage a broken use of HTTP in your book? Where and
how do you draw the line?
Sanjiva.
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
