RE: SOAP Binding Framework, HTTP Binding, MEP documents

Hi Paul,

Thanks for the feedback and apologies that i've taken a while to get round
to replying.

> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: 12 October 2001 22:35
> To: xml-dist-app@w3.org
> Subject: Re: SOAP Binding Framework, HTTP Binding, MEP documents
> 
> 
> At 02:53 PM 2001-10-11, David Fallside wrote:
> >The request-response MEP is intended as a description that can
> >be referenced by different bindings; the WG may consider 
> describing other
> >MEPs.
> 
> It should be noted that there is a relationship to applications in that 
> different bindings may be swapped (e.g., replace HTTP with something else)

> as long as the other binding supports the same MEP.

Yes, I think that is very much the intent... that features and meps are the
component from which the contract between SOAP Nodes and their local
bindings are formed, and that SOAP Nodes select between bindings on the
basis of the 'contract' (mep and feature sets) they support as well as their
ability to support the required message path (explicit or emergent).

> Applications will need 
> to specify which MEPs are expected from the underlying protocol 
> binding.  Perhaps applications can define "properties" for the MEPs they 
> expect, and the SOAP processor can check whether there is a match between 
> the applications MEP needs and the MEPs offered by the binding(s).

I'm hoping that as we get the framework text written we will explain this
more clearly. The MEP and binding descriptions both assume the existence of
a separate piece of narrative that introduces the framework. I think this is
a piece that we (the TBTF) still need to do some more work on.

>  Or the 
> SOAP processor can use the application MEP-needs property to select the 
> appropriate underlying binding (assuming a SOAP processor may have
multiple 
> bindings simultaneously).  This gets a little into routing, which is
beyond 
> the scope of the WG, but defining an MEP-needs property would put the
hooks 
> in place for it.

Agreed.

> 
> As suggested above, we need to say something about the transparency of the

> binding to applications and the role of registered MEPs.

Again... I would hope this becomes clearer as the framework narrative
develops.

> We also need to talk more about the rationale for defining transport MEP 
> rather than application MEPs.  I imagine WSFL or something similar would
be 
> more appropriate for application MEPs.  However, I'm wondering how usage 
> scenario S7 [2] relates to these MEPs.

In the material I contributed to the TBTF I've tried to be very clear about
a focus on transport message exchange patterns, which by-and-large I think
of as being the natural patterns of the underlying protocol. This has been
deliberate, partly because the concept of independent application message
exchange patterns has also been mentioned previously and also to simply
speak of message exchange patterns leaves things a little vague and
ambiguous.

In the abstract model, we present only one primitive application message
exchange pattern (one-way with corelation) and in earlier incarnations we
presented both simple one-way and request-response (as application meps) as
being the patterns provided by SOAP. 

> I'd like to see some more treatment on timeouts between the request and
the 
> response.  Do we need a property?

That would be a way to handle it.

> What about HTTP 1.1 [1] persistent connections and pipelining 
> (section 8.1)?

Yes... interesting question. This is a place that the SOAP 1.1 binding
doesn't go AFAIK ie. it says very little about management of the underlying
TCP/IP connection.

The request/response pattern described is a single isolated request/response
exchange, ie. nothing is said about its relationship to any other message
exchanges going on at the same time. This seems to me to be the most
primitive of rr meps. Once you kick in persistent connections other
characteristics begin to emerge, like ordering of request/response sharing
the same connection, which don't matter if you don't depend on them, be
clearly do matter if you come to rely on them.

Do we kind of regard that as QoS like differences on a given mep, or do we
regard it as a distinct mep. If an ordering relationship becomes important,
overwhat temporal scope is ordering maintained and how do we manage that?

> 
> "In order to remain persistent, all messages on the connection MUST have a

> self-defined message length (i.e., one not defined by closure of the 
> connection), as described in section 4.4."
> 
> We should make it explicit in the SOAP HTTP binding that self-defined 
> message length MUST be used.  Do we want to say that it is the job of the 
> binding to determine this length, or must SOAP tell the binding what value

> to use (via a property)?  Perhaps we also need a property that can be used

> to explicitly close a connection rather than keep it open.  
> Is there a time limit to how long a persistent connection remains open?

I'd like to abstract these things away from directly thinking of
manipulating HTTP like things. Where you may have ended up is at a
'conversational' mep, where the conversation has a beginning that sets up a
context for the exchange, it has a data phases where ordering, loss and
delivery characteristics apply, and then the conversation ends.

> "Servers will usually have some time-out value beyond which they will no 
> longer maintain an inactive connection. Proxy servers might make this a 
> higher value since it is likely that the client will be making more 
> connections through the same server. The use of persistent connections 
> places no requirements on the length (or existence) of this time-out for 
> either the client or the server."
> 
> "Clients that use persistent connections SHOULD limit the number of 
> simultaneous connections that they maintain to a given server. A 
> single-user client SHOULD NOT maintain more than 2 connections with any 
> server or proxy."
> 
> Since SOAP HTTP clients, in many case, will not be a "single-user" client,

> we should define a SOAP binding property to specify a maximum  number of 
> simultaneous connections.
> 
> 
> [1] http://www.rfc-editor.org/rfc/rfc2616.txt
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0116.html
> 
> Paul

Regards,

Stuart

Received on Friday, 19 October 2001 05:23:13 UTC