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. 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.

Note that processing faults can be due to unhandled mandatory blocks or
because the 34th parameter 7 levels down in a specific block was out of
bounds.

Also note that even though the processing can start, it is not clear
that any follow-up message can be generated because we can't change a
success to a failure in the middle in a clean way. The only mechanism is
to effectively break the transmission so that the whole message becomes
invalid but then the recipient doesn't know whether it was a processing
failure or a communications failure.

Btw, an additional consequence of this model is that boxcarring
implicitly is deprecated because it severely complicated the protocol
and introduces unknown fault cases.

The problem of enforcing ordering in SOAP itself is exactly the problem
that Jean-Jacques brings up: where should intermediaries insert blocks?
In general it is desirable that an intermediary does not have to know
anything about the blocks provided by other parties in the message path
before it can insert its own blocks into the message. That would
constrain the extensibility model in SOAP.

A similar discussion on soapbuilders discuss the use of references in
the SOAP section 5 encoding and what happens if one finds links that
refer to previous entries.

It is also related to the discussion of trailers - is it possible to
stick trailers in after the body so that one can compute a signature
over the body and stick the result in at the end without having to
buffer the contents? 

Noah also brings up the very good point that actors may be addressed in
a variety of ways using "next" and the specific URI as the obvious
example.

Because of intermediaries, I question that overall ordering of a message
is useful. 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

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

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

Received on Sunday, 20 May 2001 23:39:24 UTC