Re: SOAP concerns

Roger,

SOAP doesn't mandate what can go in the SOAP Body at all. It leaves
that to the imagination of the developer of the service. SOAP *does*
describe an RPC mechanism, but that is not the exclusive use of
the SOAP:Body, just one approach.

The observation you make regarding the onionesque aspect of
SOAP over some protocol such as HTTP is quite accurate. However,
just as HTTP provides an extension capability (you can add your
own custom HTTP headers) SOAP allows you to define your own
SOAP headers which are namespace qualified and it provides
a processing model that defines how these (and the SOAP Body
which is really just a special type of header... syntactic
sugar is the term that has been used to describe the distinction
between a SOAP header block and the SOAP Body).

Your example of an XSLT application of SOAP is perfectly valid
even though it doesn't follow the RPC convention because the RPC
convention is NOT the ONLY valid use of SOAP.

Cheers,

Chris

Roger L. Costello wrote:

> Hi Folks,
> 
> I have a couple of questions/concerns:
> 
> 1. My observation is that SOAP is following the same model as HTTP
> messages, that is, a header followed by a payload:
> 
> The general form of an HTTP message is:
> 
>    HTTP Headers
>    HTTP Payload 
> 
> The general form of a SOAP message is:
> 
>    SOAP Headers
>    SOAP Body (Payload)
> 
> When SOAP is nested within an HTTP message we have:
> 
>    HTTP Headers
>    <soap:Envelope>
>       SOAP Headers
>       SOAP Body
>    </soap:Envelope>
> 
> However, unlike HTTP, which clearly defines what can go in an HTTP
> Header and the semantics of the headers, SOAP leaves its header section
> undefined.  Right?
> 
> I like to imagine a SOAP message nested within an HTTP message to be
> like an onion: an application which understands the HTTP protocol (such
> as a Web server) examines the HTTP headers to determine where the
> message should be routed, the size of the payload, the MIME type of the
> message, etc.  The HTTP-protocol-aware application then strips off the
> HTTP header and routes the payload to the appropriate program. [The
> outermost layer of the onion has been stripped off.]  Let's suppose that
> the HTTP Header specifies that the payload should be routed to a SOAP
> server (i.e., a SOAP-protocol-aware application).  Continuing in an
> analogous fashion, I would imagine the SOAP server would examine the
> SOAP header to glean information, such as what application should be
> used to process the SOAP payload, the size of the SOAP payload, etc. 
> But no, this is not the case.  In fact, the SOAP spec doesn't define
> anything for the SOAP header.  Rather, SOAP mandates the contents of the
> <Body> element be in a particular form:
> 
>    <Body>
>        <methodName>
>            <param>value</param>
>            <param>value</param>
>        </methodName>
>    </Body>
> 
> The SOAP server uses the name of the Body element's first child as the
> name of a method to be invoked.  I fail to see how this would work if
> the Body were to contain an XML document, rather than a "subroutine
> call" [i.e., document-centric rather than API-centric].
> 
> Comments:
> 
> - to be consistent with the HTTP model it seems sensible to clearly
> define what elements can go in the SOAP header section.  Then, an
> HTTP-protocol-aware application can "peal off" the HTTP header, followed
> by a SOAP-protocol-aware application which can "peal off the SOAP
> header.
> - Can you please explain why SOAP leaves the header section open and
> undefined?
> 
> 2. I would like to now get out of the "weeds" and try to get the "big
> picture" of SOAP.  Based upon Marwan's comments it appears that the idea
> of SOAP is this:
> 
> Suppose that I have an application which understands a namespace (let's
> call it namespace X).  SOAP provides a vehicle by which a message
> (containing elements from namespace X) can be transported to the
> namespace-X-aware application.
> 
>   -------------------
>   |                 |
>   |  SOAP Envelope  |          ---------------------
>   | --------------- |          |                   |
>   | |             | |          | namespace-X-aware |
>   | |  X-message  | | -------> |    application    |
>   | |             | |          |                   |
>   | --------------- |          ---------------------
>   |                 |
>   -------------------  
> 
> Does this describe correctly the intent of SOAP - to transport a message
> in a namespace to an application which can process elements from that
> namespace?
> 
> Let's consider an example. Suppose that my namespace is:
> 
>   http://www.w3.org/1999/XSL/Transform
> 
> That is, my namespace is XSLT.  Suppose that my application is an XSLT
> Processor. [I wish to set up an XML-transformation Web service.] 
> Suppose that the message that I want transported (via SOAP) to the XSLT
> Processor is an XSLT stylesheet.  I contend that it cannot be done.
> Why?  Look at the SOAP document:
> 
> <soap:Envelope>
>    <soap:Body>
>       <xsl:stylesheet> 
>           ...
>       </xsl:stylesheet>
>    </soap:Body>
> </soap:Envelope>
> 
> It does not conform to the "method name followed by params" mandate. 
> So, how would a SOAP server know what application it should dispatch the
> stylesheet to?  Again, it seems to me that the information about what
> application to send the stylesheet to would be in the SOAP header
> section.  But, alas, the SOAP header section is void of anything.
> 
> Any clarification on these points would be much appreciated.  Thanks! 
> /Roger
> 
>

Received on Friday, 12 October 2001 10:02:07 UTC