Use cases and context categories and questions

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

At some point Wednesday afternoon, Eric N. started an inventory of items
providing context for "activities" (WS-CAF technical term usage). Some
of these were provided by participants and some by Eric. Here is one
recollection of that list:

1.	Userid, address, email, phone
2.	Security context of requester  
3.	Transaction id  
4.	Database sessions, device session resource being used 
5.	Governing  technical, legal economic contract agreements 
6.	BusinessProcessState identifier, Choreography BP
7.	Replication 
8.	Tracking or Monitoring support

I have been considering what might be in common to the examples in the
inventory, either a simple definition or a disjunction of jointly
exhaustive features. 

My interest in doing so is to find some boundaries on what message
metadata is usefully regarded as "context". Otherwise I am a bit
concerned that context becomes essentially indistinguishable from
metadata-in-general (or, for those who like implementations, possible
header-block contents). If that happened "context" ceases to be an
interesting component or module because it ceases to have distinctive
semantic boundaries.

Two organizing categories for the cases seemed to be that the examples
tended to fall under the "cookie" model or under the "shared view
algnment" model.

By "cookie" model, I mean the situation where one participant provides
information to others expecting the others to return it (possibly with
some "additions") so that the original participant is able to continue
its computational processes locally. Transaction id, database connection
id, process or thread ids, application identifiers, and so forth are all
familiar examples of this kind of cookie context. Of course, a logical
cookie is also possible (where the participant then uses a hash table on
the logical id to retrieve the real ids with local application meaning).
ebXML's "ConversationId" was such a logical cookie at least, though it
also was to provide monitoring/tracking capability. However, ebXML left
most of the detail semantics for the ConversationID unspecified and so
left to implementations to work out their usage conventions.

I had some question whether WS-CAF intends to make room for application
specific cookie values (process/thread/dbconnection/etc. ids) or just
support logical cookies. The schema does not make this clear to me
either.

The variety of context values used for these cookie style purposes are
as varied as the computational tasks that need to be hooked up with
"responses." Is this why WS-CAF says it will not register URIs? Will it
define any URIs (say one that can serve as a logical "cookie")? 

Now I would put items  3 and 7 (and sometimes 2) squarely in the cookie
model. (BTW, SAML has entered into worrying about "session." See, for
example message at
http://lists.oasis-open.org/archives/security-services/200312/msg00038.h
tml )

Item 1 in the list is rarely used as a logical cookie. I would guess
that if this information is used by middleware it is more in connection
with "application routing" It however is not entirely good for that
purpose because once two participants engage in collaborations of more
than one type, the sender/receiver style information needs to be
supplemented by information about which specific activity this message
belongs to. So while I see item 1 as possibly having some computational
use it is more descriptive information that might help in
monitoring/search/retrieval. That is, just some general metadata type
indexing. Maybe the same for 5, although special handling might be based
on these values.

Items 6 and 8, however, seem to me to be different. A sender puts this
information on a message so that both the sender and the receiver can
know "where they are" in some possibly iterative, nested, multistage
kind of process that may involve a number of interactions, or repeated
interactions. This information allows some degree of state alignment and
it allows monitoring and tracking tools to know where with this message
fits in on a global map of message flows. This is something I would call
context, but it is quite definitely not something that is returned
unchanged. The values used by messages in some way responsive will label
the new state being entered (the label could be on an edge or node, and
I am not trying to be _that_ specific about how the state machine is
structured in those details). I am uncertain whether CTX was intended to
be used for this kind of message metainformation or not. I guess as an
XML container CTX container could be used. But that is just syntax, and
any old WS-GenericHeaderBlockSpecialization spec could be produced with
a special URI and do the same thing. I had hoped to be able to
understand the CTX intent for usage conventions after our face to face.
The fact that I am posting this is an admission that I still could
benefit from a little more information about what the CTX container.
After that I have some questions about how the context service works.