RE: TBTF: In-context Framework Intro.

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 20 November 2001 15:43
> To: Williams, Stuart
> Cc: Noah_Mendelsohn@lotus.com; Mountain, Highland M;
> Chris.Ferris@sun.com; fallside@us.ibm.com; gdaniels@macromedia.com;
> hugo@w3.org; jones@research.att.com; marc.hadley@sun.com;
> ohurley@iona.com; ylafon@w3.org; www-archive@w3.org
> Subject: RE: TBTF: In-context Framework Intro.
> 
> 
> 
> PS: Feel free to move this to the public list - I have cc'ed
> www-archives in the mean time.
> 
> >Thanks for taking a crack at this. I've attached a diff 
> >version (html and
> >.doc) that I've generated by doing a document compare on 
> >Noah's and Henrik's versions. I think it highlights the 
> >differences in the first couple of pages more clearly.
> 
> Good idea...
> 
> >I have a couple of concerns:
> >
> >1) I am concerned that we have removed all distinction between 
> >"transport/underlying protocol message exchange patterns" and 
> >end-2-end SOAP provided message exchange patterns. 
> >Transport/underlying protocol MEPs are scoped for a single 
> >hop. SOAP provided MEPs are the patterns that the SOAP layer 
> >provides to the things that use SOAP. I think the 
> >undistinguished use of plain MEP will lead to confusion. I 
> >think that there is a difference between what a binding 
> >provides to SOAP and what SOAP provides to SOAP applications 
> >which we need to be clear about.
> 
> I am actually not sure I can see the benefit of talking about underlying
> protocol MEPs - after all we are interested in carrying SOAP messages
> around and not of modeling underlying protocols in general. 
> It seems to me that just as we expose features to SOAP, we expose MEPs to
SOAP -
> whether they are "native" or not doesn't really matter. Also, it doesn't
> seem consistent that we talk about one particular property of the
> underlying protocol but not others like intermediaries, say. What
> benefit does this distinction bring to the table?

Ok... two responses... firstly a degree of agreement that transport provided
MEPs are just like other features exposed by the transport protocol/binding
combination, so in that sense I'd agree that the distinction between
transport MEPs and other transport/binding provided features is unimportant.
It is also not the distinction I was trying to make.

The distinction I was trying to make was between features and MEPs exposed
to a SOAP processor by a binding and the features (Modules?) and MEPs
exposed by a SOAP processor to a SOAP application (or the thing that uses
SOAP rather than the thing that provides SOAP).

With respect to a SOAP message path, the scope of transport protocol/binding
provided features and meps is between immediately adjacent SOAP Nodes,
whereas the scope of features(modules)/meps exposed to SOAP applications by
a SOAP processor is end-2-end (modulo the behaviour of intermediaries). It
may be the case that these end-2-end features/meps are defined simply by
defining (in the relevant mep/feature spec) how a transport provided
mep/feature is relayed.

However, I'm not sure that all features/meps that we would wish to have
operate end-2-end can be defined this way. Clearly, SOAP Modules gives us
one mechanism with end-2-end scope... even SOAP provided meps...

> >2) I am concerned about the removal of all the stuff that Noah 
> >signalled he had not touched. This probably bears on what it 
> >was we thought we'd agreed as a compromise. 
> 
> I may have missed something but after having read Noah's discussion and
> moved a few things up in the introduction, I could not find anything
> that wasn't addressed already with respect to features and MEPs.
> 
> >I think that my take away was that we agreed that the property 
> >based style of describing features and MEPs would be a none 
> >normative convention that we do use within our own work (HTTP 
> >binding, MEP and feature descriptions) and encourage others to 
> >adopt. The diagram and the narrative that accompanies the 
> >diagram effectively provide the setup for that non-normative 
> >convention... which needs to be explained somewhere if it is 
> >not part of Part 1.
> 
> That is fine - I was assuming that the part being edited was intended
> for part 1. It may make sense to move the description of properties to
> the HTTP binding in section 2 - I haven't touched that at all.

That's ok... I think its material that we need somewhere if we are going
with the HTTP binding and single-request-response exchange pattern that we
currently have.

> 
> Henrik
> 

Stuart

Received on Tuesday, 20 November 2001 11:30:18 UTC