- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Mon, 12 Nov 2001 11:17:19 -0000
- To: "'Mark Jones'" <jones@research.att.com>, Chris.Ferris@sun.com, Noah_Mendelsohn@lotus.com, henrikn@microsoft.com, highland.m.mountain@intel.com, hugo@w3.org, marc.hadley@sun.com, mnot@akamai.com, ohurley@iona.com, "Williams, Stuart" <skw@hplb.hpl.hp.com>, www-archive@w3.org, ylafon@w3.org, "David Fallside (E-mail)" <fallside@us.ibm.com>
Hi Mark Another ramble... inspired by your note. Bottom line is that I think there is a lot that we (you and I) would agree about. I think there are probable some forms of expression that we disagree on, but there may be more substance there than just presentation. I think the key difference is in where (concepually) we imagine the partitioning of an outbound message infoset into SOAP message envelope with in envelope expression of some features (as SOAP blocks) and wrappings (carring feature expressions outside the envelope). I think I see the SOAP layer being responsible for making the partitioning decision, forming the SOAP envelope and delegating some feature expression to a suitably capable binding. I think that you would push all this work into the binding and maintain an abstract message infoset as low in the system (description) as possible. I think the difficult I have with that is not so much about the outbound message formation, but about the inbound message processing and faithfully honoring the SOAP message processing model in section 2. Processing features expressed as SOAP headers within the message envelope calls into play the SOAP processing rules. I don't see the binding as a separately 'addressable' entity. Processing and removing elements from the envelope ahead of subjecting the message to SOAP processing seems to me a violation of the SOAP processing model. Of course, you may not see that as an implication of what you suggest, in which case there is probably something that I'm not getting. Anyway... more discussion (ramblings) below for those with the time to read it. Best regards Stuart > -----Original Message----- > From: Mark Jones [mailto:jones@research.att.com] > Sent: 07 November 2001 21:43 > To: Chris.Ferris@sun.com; > David_Fallside/Santa_Teresa/IBM%LOTUS@lotus.com; > Noah_Mendelsohn@lotus.com; henrikn@microsoft.com; > highland.m.mountain@intel.com; hugo@w3.org; jones@research.att.com; > marc.hadley@sun.com; mnot@akamai.com; ohurley@iona.com; > skw@hplb.hpl.hp.com; www-archive@w3.org; ylafon@w3.org > Subject: RE: notes from yesterday's telecom > > > Stuart, > > For me, the main issue has to do with getting the separation of > concerns right in the model. This doesn't mean that someone can't > create an implementation that blurs everything together, but you > want a decomposition that encourages the particular kinds of > abstractions that you want to make. Ok... so I think that we're on the same page there. > For example, we have often talked about "pluggable" bindings. To me, > that strongly suggests that SOAP processors wouldn't be required to > know too much about bindings. The magic SOAP middleware would know > about binding capabilities (what features they agree to handle), but > certainly not their algorithms/strategy -- whether they use the > envelope or their own facilities or some combination, whether they use > encoding layers (DIME/MIME) or base64 encoding into the envelope, etc. > Again, processors would be free to hardwire an understanding of > binding internals for the purpose of optimizing the selection or > invocation of a binding, but that would be viewed as exceptional from > a separation-of-concerns perspective. Again I think we're in the same place here... I think that there are two forms of "pluggable" at work here. One is from the point-of-view of a document collection... 'spec. pluggable' if you like where the concepts/abstractions we put in place in our documentation enable new features and bindings to specified in a way that they 'hook' in to that conceptual framework and that the intended aggregate behaviour of some specific collection of features and bindings is in some sense decernable from the appropriate collection of specifications. The other "pluggable" is more operational/technology centric where you would like to be able to deliver features and bindings as (technology) components that you can 'drop-in' to an implementation/deployment framework, and again such that the aggregate behaviour of the collection is as would be expected from the corresponding collection of specifications. I think that there are some hard problems in this... Just taking message exchange patterns for example. I think that we have three types of message exchange patterns to talk about and if we don't keep them separated in our dicussion, folks will get very confused: 1) Binding/Underlying protocol provided message exchange patterns: I have been calling these transport message exchange patterns. 2) SOAP provided message exchange patterns: These are the message exchange patterns that the SOAP layer provides to the entities that use SOAP, ie. the primitive message exchange patterns from which applications build more complex patterns. Recently I have been referring to these SOAP provided MEP's as "application meps", but I now think that that is a confusing term (to be confused with the 3rd category of MEPs). I don't really have a good term for these MEPs other than to think of them as SOAP primitives cf. XMLP_UNITDATA from the abstract model. 3) Application generated message exchange patterns: ie. the exchange patterns synthesised by application through use of the primitive exchange patterns provided by the SOAP layer. I think that term "application mep" is a more natural fit for this type of mep. Something that I think our spec should then describe is how to map SOAP provided meps, 2 above, onto transport meps, 1 above. Of course if 1 and 2 are both open ended sets this becomes a big problem, and at present our spec. really touch on this at all. My hope would be that 1) and 2) are a relatively small in number. I might even venture that the one-way message with corellation/casuality called out in the AM is *the* single SOAP provided mep. In [1] I made some attempt to show how you could recast request/response in terms of one-way with corellation/causality. From one-way plus cauality, I think that you can derive request/response, request-(N)response. I also think that you can develop threaded conversations and possibly deal with message order (in those cases where it is important). *IF* we have a small number of transport meps (1), say single-request-response, single-one-way and single-one-way with casuality then the we only have three mappings to describe. Of course each expansion to the set of transport meps potentially adds a row/column to our matrix. I think we'd really like to avoid this becoming an NxM problem! Of course, so far I've ducked on features like reliablity, security or the formation of contexts such as sessions/conversations and transactional contexts... > Someone who wants to reimplement a given binding on other platform > will need to know the algorithmic/strategic details of that binding, > but the soap processor middleware (on the sender or receiver) needn't. > Furthermore, we want interoperability. A reasonable interoperability > condition would be that the other site is running the same (or > compatible) binding and has the proper application-level software > running. It would be much tougher on interoperability if you also had > to take into account arbitrary transformations performed by unnamed, > magic SOAP processor middleware. Yep... > > Maybe it would help to enumerate what we think represent are > appropriate separations of concern. Here is my list: > > (1) A sending application should be able to abstractly > specify features, message exchange patterns, and blocks > (the message infoset or message exchange context) in a > fashion that is binding-independent. Agreed. > > (2) A binding accepts this message context (from (1)) and > implements some strategy for delivery to the next node > which is faithful to the requested features, etc. in > the message infoset. Ok... but this pushes *all* the work into the binding. I think Henrik's thesis is that much of the functionality can be provided as SOAP Modules with header blocks that are generated and processed above the binding according to the section 2 SOAP message processing model. I think his concern also is that there is a danger of processing SOAP blocks down inside the binding and that that would 'break' the SOAP message processing model. I think this is probably where much of the debate lies. For some, almost anything goes down in the binding subject to the sole provision that the XML infoset of the message envelope submitted to a binding is faithfully reproduced and delivered to the receiving end of that binding. If we were to allow bindings to add/remove SOAP blocks from the envelope's XML infoset, I think I would share the practical concern of how to we distinguish those inserted by the binding from those originally submitted to the binding. I would also share the perhaps more philosophical concern of how can we process any such binding introducted headers at all AND argue that the message is processed according to SOAP message processing rules... to do that you must do the targetted mU checks which surely happen above the binding. At least logically, I think that the binding has no-business changing the content of the SOAP envelope... and probably the safest way to accomplish that is practically for a binding implementation not to insert and remove things from the envelope. The way I envisage things of that the SOAP layer does to more work, in that it constructs the SOAP envelope based on the message infoset (your term) and its knowledge (possibly hardwired) of the features and patterns supported by the bindings available to it... ie. it is the SOAP layer, rather than the binding, that makes a choice about whether a feature becomes expressed within the SOAP envelope itself or whether responsiblity for providing the functionality of a feature is delgated to the binding. > > (3) The principal job of the magic SOAP middleware is then > cleanly reduced to that of matchmaker between (1) and (2). > Given a message infoset, it finds an appropriate binding to > handle it. Hmmm.... I can see where you're going here... and I could be happy with it... (we perhaps needs some pictures, like where the SOAP processor lives in this model). I think it lives in the world where the message infoset becomes serialised into XML SOAP envelope, its contents and wrappings as low down in the 'system' and as later as possible... which is probably ok on the outbound message. But on the inbound message, I think that we have this position that SOAP blocks MUST be processed according to the section 2 processing model... which means that the distinction between what is and is not inside the envelope (rather than merely part of the message infoset) is important. So... i think that I think the 'magic SOAP middleware' does more than merely matchmaker... I think it needs to make the decisions about what functionality gets provided by (available) SOAP modules and what gets delegated to the binding. I think that there are others still that would take the view that the SOAP application itself forms the the SOAP envelope, and that it is the SOAP layers job to deliver that envelope intact at least to an immediate neighbour down a message path. I think that this view merely bundles together the application and the SOAP layer and obviates making a distinction between SOAP and the things that use SOAP, and possibly takes us to a position that "SOAP is the SOAP message processing model and a set of bindings (with their intrinsic behaviour)." > Sure, a given implementation could let a sending application designate > the binding to be used. A given implementation could use its detailed > knowledge of a binding's algorithm to optimize how it invokes a > binding or munges the data before doing so. Implementations are > always free to selectively disregard conceptual separations for their own > purposes. I think I see two conceptual separations being discussed: 1) where effectively, all work (partitioning the message infoset into envelope and non envelope expression of features, envelope formation, and envelope wrapping (feature expression outside of the envelope)). 2) where the SOAP layer takes on more of the work of partitioning the message infoset, envelope formation and delegates the expression of some features (outside the envelope) to the binding. > But note that even in these optimized cases, the receiver > still cleanly needs only to know whether it implements the binding > [discretely identified] being used by the sender. It doesn't have > to know about magic in the sending processor. I think these is true for either of the two conceptual viewpoint expressed above. > > So... I like the model you present at the end of your note, I also find > > myself in broad agreement with Glen and what I have some difficulty with is > > identifying quite where the two of you part company... I think it lies > > somewhere between the abstract and the pragmatic... ie in the abtract we can > > pull together the package of serialising envelope, binding and underlying > > protocol in zero time as late as possible... but that's not how it happens > > in practice. > > Perhaps this is somewhat analogous to the view that we have adopted > toward the SOAP envelope processing model. It has to act as though it > processed all of the headers and checked for mustUnderstand faults, > whether it in fact does so. As long as an implementation (externally) > appears to adhere to a clean conceptual model, it can optimize in any > way it cares to. Yes... Apologies for being long winded (again). > > --mark > > Mark A. Jones > AT&T Labs - Research > Shannon Laboratory > Room A201 > 180 Park Ave. > Florham Park, NJ 07932-0971 > > email: jones@research.att.com > phone: (973) 360-8326 > fax: (973) 360-8970 Best regards Stuart Williams
Received on Monday, 12 November 2001 06:20:41 UTC