RE: On the ordering of header entries

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 21 May 2001 04:24
> To: Noah_Mendelsohn@lotus.com; Glen Daniels; XML dist app
> Cc: David Fallside
> Subject: On the ordering of header entries
> 
> 
> 
> Please that the formulation with a grain of salt...
> 
> The current model is that from a SOAP/1.1 processing point of view, the
> order of header entries doesn't matter, neither between actors or within
> actors.

Lexical ordering within the message "doesn't matter" and/or header
evaluation ordering (the order in which the message visits actors combined
with the order a given actor evaluates the headers targetted at itself)
"doesn't matter"?

I certainly think that the SOAP/1.1 spec. does not express any concerns in
relation to the lexical or evaluation ordering of headers. However, I think
that this absense of concern in the SOAP 1.1 spec seriously undermines the
utility of both the intermediary and block/header/module extensibility
mechanisms.

> Either the whole message succeeds or the whole message fails. As
> long as we have a SOAP envelope as the "unit of communication" I think
> we have to enforce this holistic processing view. In this sense, any
> ordering mechanism that we might deploy can be seen as a performance
> optimization albeit an important optimization.
> 
> As the processing model doesn't allow for partial success, applications
> may always have to perform some form for compensation if the processing
> suddenly goes wrong in the middle.

I think that this will be hard!

Un-picking the effects (and side-effects) of a message when something goes
wrong demands that an intermediary whose state has changed as a consequence
of processing a message needs to learn of the success or failure at least of
the whole message. In needs to learn of failure in order to apply
compensation and it needs to learn of success in order to avoid building up
unbounded lists of 'compensations' that won't be applied in the absense of
failure. This requires there to be some means of determining where the
message has been.

Sounds like the antithesis of Simple!

<snip/>

> Because of intermediaries, I question that overall ordering of a message
> is useful. 

There seem to be several kinds of ordering in play:

	Lexical ordering of headers within the envelope.
	Dependendency ordering along the lines suggested by Noah.
	The ordering of visits to intermediaries.
	The order of processing of headers at an XML processor.

I'm curious about the kind of ordering whose utility you are questioning. 

Even if the headers within a message are entirely orthogonal wrt to the
'end-2-end' transformation of the message, the particular state of the
message seen by a given intermediary will depend upon which particular
actors the message has previously visited. This may be significant wrt to
the desired application functionality:

eg. while it may not make a difference to the end-2-end meaning of a message
whether it visits a signing or logging intermediary first, it does make a
difference with respect to the purpose of logging or signing the message.

> In order to support (potentially multiple) partial
> ordering(s) in a message, however, I think we need to provide a few
> simple rules for how such orderings can be expressed:
> 
> 0) Blocks are fundamentally unordered from a processing point of view.
> 
> 1) A SOAP intermediary MUST NOT reorder header entries. It may add
> header entries anywhere in the message

0 and 1 seem to be contradictory. 0 suggests that the lexical ordering of
blocks in the message is insignificant, so why the "MUST NOT" prohibition in
1?

> 2) Dependencies are indicated in one of two ways:
> 
> 	* Simple XML encapsulation in which the SOAP header is somewhat
> 	  out of the picture as the encapsulation happens with a
> 	  header entry
> 
> 	* By referring to other header entries using links. In this case
> 	  we can say that such links SHOULD point *forward* in the message

This again suggests that lexical ordering *is* important at least from a
pragmatics point-of-view.

> 3) It is allowed to introduce trailers after the body but only if a
> header points to them indicating that the trailer will follow and what
> it will contain (we don't define this). The SOAP/1.1 schema actually
> allows this but the description of how to deal with trailers is very
> vague.
> 
> Hope this makes at least a bit of sense...
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 

Regards

Stuart

Received on Thursday, 24 May 2001 11:07:29 UTC