RE: [ws-caf] Context query

[nknrc1 <Kevin.Conner@arjuna.com>]

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

Then I hope I can convince you otherwise :-). I will attempt to answer your 
points before giving a scenario that I hope will explain my position.

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

It can simply pass it through.

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

It is not always a requirement to understand nor identify the type of a 
context in order for a processor to choose to pass it through, it may be 
sufficient to identify it as a context.

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

Whereas I believe that forwarding of the context can meaningfully occur 
without processing it.

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

The forwarder would have to have knowledge but this need not be application 
specific.  A forwarder could decide to pass all contexts, it could base the 
decision on the originator/receiver or it could be based on other, non 
application specific, criteria.

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

In your scenario yes, but not in mine.

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

I agree but to change this, even if it is a small change, may be an expensive 
operation for other reasons.

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

One with minimal intelligence need have no knowledge of the context type, in 
fact this may be desirable to reduce coupling in the system.

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

Unfortunately those who design systems do not always agree with this :-)

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

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

So do I and I have never argued for that.  My point is that neither you nor I 
are in a position to understand the specific requirements placed on a system, 
this is a question for the Architect.  The decision to pass a context through 
their system without understanding the type is one that only they can make.  
It is an option that, IMHO, we do not have the right to prevent.

By way of an example consider the following.

There are three systems within an organization, X, Y and Z.  X and Z share 
knowledge of a context type, C1, whereas Y has no reason to process it.  X 
creates context C1 and makes a call(s) on Y (including C1), which in turn 
makes a call(s) on Z (passing C1).

In your argument it is necessary for Y to identify C1 as such before passing 
it through.  This creates a dependency which, IMHO, need not exist.

Now suppose that X and Z decide to use context C2 instead of C1.  This would 
necessitate a change to Y, a system that does nothing with C2 except pass it 
through.  There are a number of reasons I can think of why this may be 
undesirable

 - Y may be controlled by a different team within the organization and,
   therefore, change may not be possible (or easy).
 - Y may serve more systems than X and Z and therefore cannot easily be taken
   down to make the change.
 - The organization may have a policy whereby any changes to Y, however
   insignificant, must go through a lengthy QA process before being released.

These are all barriers to a simple change.

The Architect may have decided that, in order to mitigate the impact of 
changes in X and Z (or any other systems that it may support), it is safe and 
desirable for Y to pass contextual information through without having 
knowledge of the type.  This would break the dependency Y currently has on the 
context and reduce the coupling in the system.

This is an option that only the Architect of the system can make and is one 
that we currently rule out.  I do not believe we have the right to make such a 
decision.

    Kev

--
Kevin Conner
Arjuna Technologies Ltd.

Kevin Conner
Arjuna Technologies Ltd.