Re: [ws-caf] Use cases and context categories and questions

["Mark Little" <mark.little@arjuna.com>]

Dale, you raise some interesting points.

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

Transaction context doesn't really fall into this category. Although there
are implementations and specifications where the context may be augmented by
recipients and returned, the "typical" modus operandi is for the context to
be received and used to scope work by the recipient in the transaction
"domain". It tends to contain information on the coordinator (registration)
service for the recipient to use in the event it does some work that needs
to be coordinated by the transaction service when it ends.

However, I understand what you mean by the "cookie" model.

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

The un-augmented context service (where no ALS-es exist and no services
modify the context once it is created) matches this case, I believe. The
basic context is a URI that could be used by recipients to look-up other
data prior to them acting on the request.

>
> 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 schema allows arbitrary data to be encoded in the context. As we
discussed at the f2f, the current examples were all based on "system-level"
data, such as transaction context (where the coordination service endpoint
and other implementation specific data may be encoded in the context),
database sesssion id etc. However, the example from Systinet opened up the
possibility of us exposing the context to application data too, which is
interesting.

However, in no sense is the context just a URI or series of URIs. The
extensibility element (the ##other any in the context structure) allows
arbitrarily complex data items to be included.

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

I think what was meant in the f2f by not defining any URIs was that the uses
of context are many and varied and although we might define examples of how
a security service may use it, for example, we don't want to become a
registry of these context types. That's not to say that such a registry
isn't needed, only that I suspect a single TC like ours isn't the right
place. Once this TCs work is done, the TC may well cease to exist under
current OASIS rules, and in which case where does the registry go to, if we
had been hosting it?

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

I don't think 3 is just a cookie in terms of your original definition. Maybe
we should refine it?

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

Well I think the example is more in line with the general requirement for
context: being able to associate work items into a single unit or activity.
So for example, the user id may be sent on every request to a "stateless"
service (e.g., something written using an Entity Bean). So it's not that
different from a cookie.

> Maybe the same for 5, although special handling might be based
> on these values.

Wasn't this based on the Systinet example?

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

We definitely need a more precise definition of "cookie" then ;-) You're
original description above mentioned that it could be returned changed as
well.

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

I think it all comes down to what examples we had when the initial specs
were written (and updating context state dynamically with a list of
participants and their current status was one of them) and what we want to
continue to support. If the TC decides that we really want to have this
support in Context then we should (and I believe the necessary support is
there already).

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

Mark.

>
>
>
>
>
>
>
>
>
>
>
>
>
>