Re: [RPCTF] RPC as an application or an extension of SOAP?

The RPC-as-a-module discussion is related to the Abstract Model discussion 
about whether we could model SOAP using just the XMLP_UnitData 
operation[1].  Since an RPC request and an RPC response are really just 
SOAP messages, it was determined that XMLP_UnitData would be simpler than 
to have both XMLP_UnitData and XMLP_Data (which appeared in earlier drafts).

The fact that RPC Requests are sent in HTTP Requests, and RPC Responses are 
sent in HTTP Replies is hidden from the view of an upper layer.

The tricky part was correlation of request with response over transport 
bindings (unlike HTTP) that do not tightly couple request and 
response.  Here is where the SOAP Block can be used to carry a correlation 
identifier, modeled abstractly as a Correlation parameter [3].

The term Module was removed from the SOAP 1.2 spec, so "RPC as a Module" 
needs to be discussed further.

The Binding Context [2] needs further discussion.
How does a "handler" pass a correlation identifier through the XMLP Layer 
down to a protocol binding (see Fig 5.1 [4])?
Even if a handler inserts a SOAP Header Block to include Operational 
Parameters (correlation identifier, From and To URIs), is the binding 
supposed to look inside the Block, or look inside a Binding Context?  Does 
the handler just place parameters in the Binding Context and let the 
binding create a SOAP Header Block if needed?

I like the words added to the SOAP 1.2 spec (section 2.5) that state
"Unless otherwise stated, processing must be semantically equivalent to 
performing the following steps separately, and in the order given. Note 
however that nothing in this specification should be taken to prevent the 
use of optimistic concurrency, roll back, or other techniques that might 
provide increased flexibility in processing order as long as all SOAP 
messages, SOAP faults and application-level side effects are equivalent to 
those that would be obtained by direct implementation of the following rules."

With a phrase like this, we don't need to be as concerned that we are 
dictating implementation.  If an implementation appends the binding context 
as a SOAP header block that gets removed before transmission by the 
binding, thats okay.  We should be able to say that an extension may reads 
things from the binding context, add things to the binding context, the 
binding looks at them, and when the message is on the wire it looks like 
....  We need a way to describe how information is carried vertically 
between the layers or sublayers (what OSI used to call Protocol Control 
Information or PCI).

When we get to mapping usage scenarios to the spec, I think the Binding 
Context will be important.  For example, QoS is clearly not part of SOAP 
1.2, but SOAP 1.2 must support extensions that enable the usage scenarios 
(e.g., S810 [5]).  Some bindings may be able to handle lower layer QoS, 
while other are not.  An Intermediary node receiving a SOAP header block 
for a QoS extension with mustUnderstand="1" should be able to ask the 
binding if it can support the specified QoS for the next hop (else return a 
SOAP fault).  Since we are not specifying APIs, we can "declare" such 
things in a Binding Context.  We can allow handlers to query the binding 
context (e.g., to see if it contains appropriate QoS capabilities), then 
act accordingly.  For example, can the binding use an HTTP TCP connection 
where the IP packets contain a differentiated services codepoint for 
assured forwarding per-hop-behavior (AF PHB)?  Is that PHB provisioned 
within the network (i.e., if I send it, will the network treat it 
differently than other best-effort traffic)?  The specification for the 
"extension" could include a description of what information items it 
depends upon within the Binding Context.

Perhaps we need an Infoset description of the Binding Context within the 
SOAP 1.2 spec.

[1] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3.1
[2] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec5.2
[3] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3.2
[4] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec5.1
[5] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2690

Paul

At 01:35 PM 2001-07-20, Jacek Kopecky wrote:
>  Hi, on the RPC task force telecon I recalled that during the
>February face-to-face meeting the following issue arose and I
>don't remember it ever being resolved:
>  Is RPC an extension of SOAP or is it an application of SOAP?
>  Let me show what I see as the meaning by this difference:
>  1) if RPC is an extension of SOAP it should be able to live
>happily in SOAP headers (which it doesn't in SOAP/1.1), and we
>should be able to create messages that use RPC but whose main
>purpose would be something different.
>  2) if RPC is an application of SOAP (in other words RPC is a
>description of how to use SOAP in certain situations), we have
>"RPC messages" - messages whose main purpose is to invoke a
>method or communicate its result. There would be no messages that
>use RPC and are not "RPC messages".
>
>  Personally, I can't understand RPC as a module. RPC uses SOAP to
>do some semantics. I can't see how RPC could _extend_ the
>semantics of something else.
>
>  Please the proponents of the RPC-as-a-module view write what
>your thinking is.
>
>                             Jacek Kopecky
>
>                             Idoox
>                             http://www.idoox.com/

Received on Monday, 23 July 2001 15:47:52 UTC