RE: [ws-caf] Context query

["Green, Alastair J." <Alastair.Green@choreology.com>]

Kevin,

After quite a bit of thought, I've come to the conclusion that the
ability to know that this is a "base context" is not a useful feature.

What can a processor do that understands it has received a context, but
does not know the type of the context? 

(Parenthetically: if the question arises: "how do I understand the type
of the context?", then surely it very simple for a header processor to
look for a header of type [namespace etc] X, rather than look for one of
type WSCTX, and then examine it to see whether it is X? It must be able
to discriminate X from Y to do anything useful, anyway.)

A receiver of a context can either process it (which requires
understanding its type and its nature and its specific content) or it
can forward the context to someone else who does understand it (which, I
will argue cannot meaningfully occur without processing it, with
understanding of its type, and nature, if not content). 

In order to forward it, the forwarder must understand to whom it must be
sent, and in the headers of which messages. 

If a message is sent out by an application then the forwarding entity
could, by interception, add the context silently to the application
message. In order to understand which application messages should be
"contexted" the forwarder would have to have an application-aware rules
processor. This rules processor would examine outbound messages in order
to establish type, instance and addressing information. The inbound
equivalent can be imagined (it's the start of this hypothetical
scenario).

However, at this point we have made a nonsense of the proposed approach.
The rules processor understands application messages: their schema, the
import of their instance values, the catalogue of all such messages and
of them which ones are contextable, which addresses are relevant, and,
from all of that application-specific information, which messages should
actually be contexted. Its attempt to deal with the context as something
opaque has turned out to be a sham. It has in fact, processed it: not
handed it off.

To ask such a processor to know the nature and type of a context
(recognize that a header is a context of a specific type) is to ask very
little extra or new of it: it is only a new facet of a multi-faceted
application awareness.

If a forwarder is completely dumb (gets context on an inbound message,
and outputs on all outbound messages) then it could, in principle, be
unaware of the nature of the contexts.

But it would be trivial to create a forwarder that had a small catalogue
of known context types, and which was therefore able to be not
completely dumb. It seems unlikely that there is any gain in having a
dumb forwarder. And one of even minimal intelligence ... requires type
information at the very least.

(The completely dumb forwarder is so primitive as to be of dubious value
under any circumstances, in any event)

Anyway you cut it: if you want to handle a context then you need to know
what it is, why it is and for whom it is.

Alastair

P.S. Supplementary to this: I believe that any attempt to state "must
propagate" is meaningless. Propagate to whom? On what successor
messages? How can I tell that the instruction has been received or
obeyed? How is it relevant to me and who am I to issue such
instructions?






-----Original Message-----
From: Kevin Conner [mailto:Kevin.Conner@arjuna.com] 
Sent: 15 June 2005 16:43
To: WS-CAF
Subject: Re: [ws-caf] Context query

> Yes, I think it's still a good idea to support opaque context passing
> through intermediaries.  

I think there is still a need for discussion on this topic.

The changes made recently to context remove the context element,
requiring the referencing specifications to define their own context
element.  This removes a mechanism for easy identification of context
headers (and therefore opaque treatment of such headers).

Is this something we want to restrict at this stage?

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.