OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: activity context

    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 :
    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.
-----Original Message-----
From: Mark Little [mailto:mcl@arjuna.com]
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;
(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.
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC