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 & context poll


Alastair,
 
    Thanks for the thoughts. Yep, we are thinking in the same lines.
 
    We need a framework at a super-context level so that context is exchanges in a uniform manner across web services. As Mark and Sanjay pointed out, I think we could define our little world and move forward. The BT group might be the first to *require* a context.
 
cheers
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Monday, April 09, 2001 8:44 AM
To: Krishna Sankar
Cc: bt models
Subject: Re: activity context & context poll

Krishna,

I also agree with limiting the context to the needs of a cohesion (BT) protocol. The super-context is a) outside our scope/powers and b) arguable. I like the SOAP approach (or the GIOP approach) where many unrelated contexts can travel, and it is a matter of cooperation between different pairs of actors as to how they are interpreted, delegated/retransmitted etc. To take a concrete case in point: what if the rules for delegation are different for security and transactions? I may want to stop propagation in one case, and allow it (or enforce it) in the other.

Where I do strongly agree with your approach is that context information should be freely capable of being written by frameworks or application instances, as well as standardized services of the kind we're working on defining.

So I guess I would only want to see a framework for placing and identifying contexts (perhaps with an IANA like scheme for allocating unique ids for well-known standard contexts), rather than an attempt to tie them all into a super-context. Now, a framework where links are defined (or not defined), and elements may or may not be present may amount to the same thing ...

Alastair

Sanjay Dalal wrote:

<Mark>
.    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, ...
I think that the general context should be a series of specific context instances, one for transactions (which only talks about transaction related stuff), one for security, etc.
I agree, for us, context has the scope of business transaction only. Of course, it will be good if BT context can sit inside a larger context structure defined somewhere else (like W3C). I agree with Mark, we should concentrate on addressing only the transaction context.sanjay


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


Powered by eList eXpress LLC