fair enough. I'll try to do a new model draft incorporating these
decisions tonight. I agree that forward progress is the highest
priority. I don't want to come to the next F2F without a new draft spec.
Mark Little wrote:
I agree with everything you say, but
my main concern is that we get context finished asap and try to move on
to CF. If there are things we need to revisit in Context subsequently
(and there may well be), then let's cross those bridges when/if we come
to them. I've never expected that closing off one spec. in this TC will
mean we can never revisit it when we move up the stack.
Mark.
-----
Original Message -----
Sent:
Monday, March 29, 2004 4:45 PM
Subject:
Re: [ws-caf-editors] als, context and compound protocols
well, my basic concern is that we make a decision that is appropriately
extensible. The most well defined usecases for context are:
coordination and coordinated transaction protocols. I think it's
natural to consider the implications for decisions we make at this
level for the next level up. We can punt on it to a certain extent, but
let's be prepared for the issue to arise.
My basic problem here is that if you think about it, two ALS's will
create a compound protocol that is necessarily different than the
natural structuring mechanism for coordination that comes with one ALS.
If that's not a big problem for anyone, than I guess we're ok.
Anyway, if I understand you correctly, I think we're closing in on a
definition for what it means for the ALS to augment a Context, which I
think is major progress. I'll fold that into the next round of model
comments. Hopefully we can send out for comment from the broader group
this week.
Greg
Mark Little wrote:
I think we can punt on this
until we start work on CF. I don't believe any decision we make would
affect Context.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
-----
Original Message -----
Sent:
Saturday, March 27, 2004 2:19 PM
Subject:
Re: [ws-caf-editors] als, context and compound protocols
Ah, I originally thought so as well, but just to further muddy the
waters (hopefully only for the moment) this won't work simply because
we must have the coordination context for all the known derived
protocols. And that is itself a derived type.
Unless, of course, the coordination aspects are added as well on a per
protocol basis. That makes it tough to encapsulated them vis a vis the
CF layer though.:
<ctx>
<security>
<coord/>
</security>
<transaction>
<coord/>
.... whatever this means
</transaction>
</ctx>
How does this strike you?
There is also the secondary issue of the SOAP processing model: the
headers being in the same namespace will ultimately all go to the same
handler set. I suppose this can in practice be a simple Chain of
Responsibility pattern. Perhaps Eric has some further comments on this
from a web services perspective? It's not sitting entirely well with
me, at least I can't think of anything else that works quite the same
way in the SOAP world (Anish Karmakar pointed this out to me
originally). On the other hand, WS-T does the same thing (all protocols
flow the base coordination context), so it may not be a big deal.
The derivation/mutation problem is more soluble with a single ALS, I
think. I have the sneaking suspicion that we could wipe out all these
issues if we were able to sit in front of a whiteboard for a single
afternoon.
Greg
Mark Little wrote:
I think the original intention was simply to model the context type through
XML "inheritence". However, it certainly wasn't fully thought out (like the
substitution group stuff). I think that we should do away with it and go the
a more uniform structure:
<ctx>
<security>
</security>
<transaction>
.... whatever this means
</transaction>
</ctx>
It's more in line with other useages of context out there, and the
derivation mechanism doesn't buy us much (apart from the fact that maybe
conceptually it's nicer to be able to differentiate a transaction context
this way, but I'm not convinced).
Mark.
----- Original Message -----
From: "Greg Pavlik" <greg.pavlik@oracle.com>
To: "ws-caf-editors" <ws-caf-editors@lists.oasis-open.org>
Sent: Friday, March 26, 2004 9:09 PM
Subject: [ws-caf-editors] 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.
|