Mark,
I am a fan of context and by having one for *all*
interactions, we can promote more of the stateless services. Here are some
of my thoughts on context:
1. Context could be viewed as a set of
attribute assertions, some of them signed and even
encrypted.
2. Context is information other than the
actual transaction data and can include the user credentials, any previous
state, time of day, geographic location of the calling entity,
...
3. The context of course would be an XML
document. I was thinking of something like :
<context>
<actionType>xxxx</actionType>
..
</context>
4. Yes, context need not be that
elaborate, but we do need to divide context into related graphs so that
later the systems can use XPath/XPointer to get specific set of information they
need.
5. FYI, I think context is much more
important from a web services point-of-view and if W3C ever standardized the
context, we could use it at that time. For now we should be able to define a
simple context graph which is relevant to our work.
6. If we start defining context
now, i.e. what pieces of data do we need , we could "normalize" the
structure after we have identified say 70% of the
information.
cheers
-----Original Message-----
From: Mark Little
[mailto:]
Sent: Saturday, April 07, 2001 12:35
PM
To: bt models
Subject: activity
context
Something we haven't yet got round to discussing in
much detail is the notion of (business activity) context (c.f. transaction
context). This is the context information that flows from the initiator and
between high-level participants (i.e., business objects). We can encode this
information within the XML, for example. The actual format of the context is
obviously important for interoperability. If you've had a chance to read my
previous emails you'll see that it should be possible to support a range of
different extended transaction models with a single infrastructure, and each
of these may have a slightly different requirement on the context. So, is it
possible to have a single context structure that can map to these models? I
believe so. Using CORBA IDL as an example:
struct Context
{
unsigned
long actionType;
long timeout;
Coordinator theCoordinator;
sequence <octet>
actionId;
any
activity_specific_data;
};
where:
(i) actionType defines the type of model being used
(so that the rest of the context may be interpreted
appropriately)
(ii)
timeout is the timeout period associated with the business activity, such that
if it hasn't completed within this period it will automatically be completed
with a "failed" semantic (whatever "failed" means will be application
dependant).
(iii)
theCoordinator is a reference to the coordinator (this may be the root
coordinator or a subordinate coordinator, depending upon who sent the
context).
(iv)
actionId is a unique identifier for this business activity.
(v)
activity_specific_data is arbitrary data that is encoded in the context and
may be interpreted on a per invocation/per model basis.
Obviously
there are other ways in which the context information may be specified and
encoded. This is just an example. What do people think?
What
I'm hoping to show from this is that the context doesn't have to be complex in
order to be powerful.
Mark.
----------------------------------------------
Dr. Mark Little ()
Transactions Architect,
HP Arjuna Labs
Phone +44 191 2064538
Fax +44 191
2064203
