RE: issue 78

> BTW, in your example, why couldn't "id1" be a header?
>
> Frank DeRose wrote:
>
> > <SOAP-ENV:Body
> > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
> >   <SOAP-ENC:int id="i1" SOAP-ENC:root='0'>34.5</SOAP-ENC:int>
> >   <m:GetLastTradePriceResponse xmlns:m="Some-URI">
> >     <PriceAndVolume>
> >       <LastTradePrice href="#i1"/>
> >       <DayVolume>10000</DayVolume>
> >     </PriceAndVolume>
> >   </m:GetLastTradePriceResponse>
> > </SOAP-ENV:Body>
>
> Jean-Jacques.


Jean-Jacques,

I think the main motivation of Section 7.2 of SOAP 1.1 is to prevent people
from referencing a Header item from the request/response element in the
Body. Section 7.2 reads:

"Additional information relevant to the encoding of a method request but not
part of the formal method signature MAY be expressed in the RPC encoding. If
so, it MUST be expressed as a subelement of the SOAP Header element.

An example of the use of the header element is the passing of a transaction
ID along with a message. Since the transaction ID is not part of the
signature and is typically held in an infrastructure component rather than
application code, there is no direct way to pass the necessary information
with the call. By adding an entry to the headers and giving it a fixed name,
the transaction manager on the receiving side can extract the transaction ID
and use it without affecting the coding of remote procedure calls."

This section makes a clear distinction between 1.) the signature of the call
and 2.) infrastructure information contained in the Header. It says that the
infrastructure information is "not part of the signature." I would argue
that this implies that the infrastructure information also cannot be reached
through the signature. Why else would the spec insist so strongly that the
infrastructure information "MUST be expressed as a subelement of the SOAP
Header element?"

Look, there's really nothing the SOAP spec can say that will prevent someone
from referencing a Header item from the request/reply element in the Body,
even if it's something as simple as a string that says: "Dude, look at
Header item xyz." If you want to do that, you can. But, doing so is the
equivalent of having data in a DCOM PDU body point to data in the PDU
header. I think that's wrong. A clean separation should be maintained
between the RPC parameters and infrastructure information in the header.
These are essentially 2 different protocol layers. In most cases, data in a
header will not even be available to the processor of data in the body.

Consider the "transaction id" example given in Section 7.2. Suppose that the
signature of the RPC is:

HRESULT Method1([in] int p1, [out,retval] int* p2);

The source of the data in p1 (the "application code") is quite different
from the source of the transaction id (the "transaction manager," an
"infrastructure component"). When the user thinks of the signature of
Method1, he doesn't include the transaction id in that signature, as in:

HRESULT Method1([in] int txid, [in] int p1, [out,retval] int* p2);

in which case the user WOULD be required to be conscious of the transaction
id.

Maybe Section 7.2 is not as clear as it could be and needs to be rewritten.
But, IMHO, it's intention is to prevent people from referencing Header items
from inside the Body.

F

Received on Friday, 15 June 2001 21:26:50 UTC