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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

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


Subject: als, context and compound protocols


Guys,

I have spent some time trying to figure out how we can have both derived 
context types and multiple ALSes. Let me see if I can explain the 
problem clearly without writing a dissertation. Let me first layout my 
understanding/assumptions as to what happens according to the spec:

1) There is a ContextService that only knows about contexts of the 
namespace [context namespace]
2) The context service creates a generic activity and represents it by a 
context of ContextType defined in [context namespace] when an Begin 
operation occurs
3) following the creating of the "generic context", the ContextService 
implemenation invokes ALSBegin with the generic Context included as a 
SOAP header.
4) the ALS, as it stands, produces a new "augmented" context, of a 
derived type. I put augmented in quotes because this is a mutation 
occurence. For example, if this is the ACID protocol, the ALS is 
interested in producing a context of the type defined in the [acid 
namespace]. Have I got this right? (As an aside, what is one to make of 
the sync context, the 2pc context and the acid context? Do we really 
need more than one context type here?) I've always found this to be a 
little strange and it's unclear to me how this works well for the 
creation of nested activities. But let's assume for the moment it's 
correct and we nail down the specifics of how generic contexts 
communicate to the ALS they are a part of derived type parent context 
later. Then...
5) The ALS responds to the ContextService with the new augmented context 
of the derived type. This is the context that the ContextService now 
maintains on behalf of the activity.
6) The ContextService returns the new augmented context of the derived 
type to the caller with the Begun operation on the UserContextService.

This may work, however, I'm unclear as to what exactly happens when 
there are two ALSes. How does this "mutation" mechanism work? Which ALS 
does the mutating? Does the first ALS do the mutating?

In my implementation, I cheated and restricted the registration of an 
ALS to one per protocol. Is there a way around this? Do we really care 
about accounting for the set of all possible scenarios we can dream up, 
or can we as a first version try to make something that works well with 
this restriction?

We're keen to move things along rapidly, so let's strive to come to a 
convincing conclusion on this matter.



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