Re: XP->SOAP/1.1 requirement mappings for R8xx (Intermediaries)

On Wed, Feb 07, 2001 at 09:05:52AM -0800, Henrik Frystyk Nielsen wrote:
> >I missed those the first time around. I'm still a bit uncomfortable
> >that SOAP doesn't place explicit requirements on future protocol
> >bindings, though.
> 
> In fact it is interesting to see what these requirements are - the
> only one I can really think of is that the underlying protocol must
> be able to transfer a complete SOAP message from the SOAP sender to
> the SOAP receiver.

Perhaps framework would have been a better term than requirements,
although it will most likely place requirements on bindings.      

There is already talk about making it possible for messages to
influence and/or understand mechanisms in the transport protocol, for
things like -
  - QoS
  - Encryption
  - Authentication
  - Identification (e.g., IP address)   
  - Connection Control
  - Routing
If this happens, there will need to be a framework within which the
interface can be expressed, especially if we are to support chains
like:
  Sender --> (HTTP) --> Intermediary --> (BXXP) --> Receiver

Also, it will be very helpful to have a taxonomy with which the
message exchange pattern and other properties of the binding can be
expressed.

The tricky part here is to decide what bits need to be addressed by
the 'core', and what can be left for later.


> >I couldn't find a definition for something equivalent to 'processing
> >intermediary'.
> 
> Yes but although it doesn't distinguish between processing
> intermediaries and processing ultimate recipients it does define a
> single processing model that fits both in that the actor model is
> part of the processing model for any SOAP processor. Is there
> anything that is special in that regard to a processing
> intermediary?
 
Yes, there is little functional difference, but the requirement was
to 'define and accommodate' - SOAP doesn't formalize the definition,
that's all.


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Wednesday, 7 February 2001 14:44:20 UTC