Re: Proposal: Module for checking mustUnderstand headers have been processed

I apologize for not having yet responded to Martin's early questions, so 
this note combines responses to the questions raised there and the 
specific proposal floated on the 7th.

General comments:  as I signal'd on our phone call, I think we can't get 
this right until we work out a bunch of details about how we want headers, 
paths and routes to work.  I'm not asking just what SOAP says, but what 
the right answers should be to questions such as:

Q1. In general, how philosophically symmetric are headers and bodies? SOAP 
signals quite symmetric.

Q2. To what degree is <BODY> identical in effect with other headers with 
no Actor.  SOAP says quite symmetric.   If so, then is there a defined 
order of processing BODY vs. other such headers?  Can we arrange to 
process a header that says "Close log", "Commit", or "Sign response" after 
the BODY itself? How?

Q3. Broader related question:  how do actors relate to whatever notion of 
path or routing that we eventually might invent?  I think that users 
want/need to be able to specify a partial order to help SOAP routers (for 
the case where headers are processed at different physical locations) and 
dispatchers (processed at the same physical location) to do processing in 
the right order.   Maybe that's a cleanly layered module, maybe not, but 
either way I think we have to figure out what's needed.

So, here's a quick speculation on where such considerations might land us:

A1. Yes, symmetric.
A2.. Yes, symmetric, and order can be controlled (see A3).  Headers can be 
processed after BODY.
A3. Rough invention by Noah:  a means is provided whereby senders can 
optionally indicate a partial order of dependencies among headers.   This 
is the sense in which we specify a path.  No anonymous (no actor) header 
can depend on any header but another anonymous header (generalization of 
the notion that anonymous headers are at the end of the path.

With that framework in place, I think A1 (symmetry of all headers and 
bodies) and A3 (we have paths embodied as partial orders on the headers) 
suggests that what you really want to do is to make sure that no header is 
processed if a mustHaveHappened header earlier in the path did not happen. 
 In orther words, checking whether something happens must be sensitive to 
the partial order.  If I have a header "Begin Transaction" and indicate 
that it must have been understood and must happen before some other 
header, then I want that checked as soon as some dependent header is to be 
processed.

A consequence of this, I think, is that the extension to handle 
"mustHappen" isn't easily syntatically modeled as a single additional 
header as Martin proposes.  The most natural model, I think, would be have 
a "mustHappen" attribute that can appear on each header where it is 
required.  We also need some kind of "dependsOn" syntax (not sure quite 
what" to encode the partial order.

Anyway, the above may not be right, but I do think we need to allow for 
discussion of these issues before attempting to resolve mustUnderstand.

I'm off to jury duty in two minutes.   Will try to stay in touch as best I 
can.  Cheers.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Wednesday, 9 May 2001 14:01:05 UTC