Re: Reqs/AM - Comments/Questions

Doug Davis wrote:

> There is a M-1 relationship between targeted blocks and XMLP processors
> not handlers.  It is possible that within a single XMLP processor
> the work of processing a single header might be split across multiple
> handlers, in which case it become an M-N relationship between targeted
> blocks and handlers.

I think the intent of the latest definition of Module:

     "An XMLP module is a basic unit for the definition of extensions to
     XMLP. An XMLP module encapsulates the definition of zero or more
     related XMLP/SOAP blocks and the associated processing rules. These
     processing rules are realized by an XMLP/SOAP handler."

was that a Block would be targeted at a Module, and the Module would
"implemented" by a single Hanlder.

> >Correlation was brought out so we could deal with 2-way messages. We need
> >2-way messaging (at least) for RPC.
>
> So does this mean that we're changing the definition of SOAP from
> one-way messaging to possibly two-way?  And if so, how does this
> relate to our goal compliance with existing SOAP implementations.

I believe RPC is inherently two way (request-response), and I think this is
illustrated in the spec in at least the following places:

   * "an RPC invocation maps naturally to an HTTP request and an RPC response
     maps to an HTTP response"
   * "RPC invocations and responses are both carried in the XMLP/SOAP Body
     element"
   * "An RPC invocation is modelled as a struct."
   * "An RPC response is modelled as a struct."
   * "it is an error for an RPC response to contain both a result and a
     fault."

> There have been discussions in some soap forums about allowing the
> processing to continue in order to get as many error messages as
> possible returned to the user.

As has been said recently, only one fault can currently be returned by a
message:

     "If present, the XMLP/SOAP fault MUST appear as an XMLP/SOAP body
     block and MUST NOT appear more than once within an XMLP/SOAP Body."

but I agree this seems like an unnecessary restriction.

Notice also that the definition for Ultimate Receiver mentions that a message
may not reach the ultimate recipient:

     "The XMLP/SOAP receiver that the initial sender specifies as the
     final destination of the XMLP/SOAP message within an XMLP/SOAP
     message path. An XMLP/SOAP message may not reach the ultimate
     recipient because of an XMLP/SOAP fault generated by an XMLP/SOAP
     processor or an XMLP/SOAP Handler along the XMLP/SOAP message path."

Jean-Jacques.

Received on Friday, 11 May 2001 05:35:38 UTC