Mark Little wrote:
-----
Original Message -----
Sent:
Tuesday, March 23, 2004 2:18 PM
Subject:
Re: questions from today
See below; if we have broad agreement, I'll augment the text once I
hear from Eric.
Mark Little wrote:
Alastair asked me to send out the questions I got from today; I assume
this will be our charter for the next revision, so to speak. Could you
validate that this is accurate against your understanding as well before
I send them out?
I'll take a pass at the model text tomorrow and send it to you both;
prior to, I'd like to get your takes on the questions -- I'm not certain
you will both agree with my intial opinions. I guess Mark should update
the diagram?
Thanks.
Greg
1) There is some confusion over the last paragraph in the first
section (Activities and Contexts): specifically how does the begin
operation relate to nesting? The last sentence of said paragraph implies
contexts can be used to supply ALS configuration information, whereas
other parts of the spec suggest that a begin in a context generates a
parent-child (nested) relationship.
What text does this refer to? I can't find it in the Context spec. or the
text accompanying the UML diagram.
Specifically, you added text about the ALS configuration
identifier. The question was something like "if a context is used to
send the ALS configuration identifier for begin with no activity, how
can we distinguish this useage from a begin that is intended to created
a parent-child relationship".
There's a difference: in a
nesting relationship begin is accompanied by a context. Simple enough.
Right, but the point is that the text I pointed out is ambiguous and
seems to imply otherwise.
2) Are the protocol identifier, ALS configuration identifier, etc. all
the same thing?
Yes, he's right (damn ;) The ALS-configuration identifier is the type
attribute in the context.
This also relates to question one. My take on things is that
we should have one precise name for "protocol,", "type", whatever, and
use it consistently. Second, since the begin is paramterized with a
type, there should be no need to use any context mechanism on a begin
with no activity. Third, the ALS configuration should be opaque to
applications.
I've been calling it
protocol-type for a while until I realised it's just called type in the
context. I think the rule for begin (assuming we keep the
ALS-configuration id - but renamed) is:
(i) if this is a new top-level
activity (no parent), then begin is parameterized with the
protocol-type.
(ii) if this is a nested activity,
then begin is parameterized with the protocol-type and a context
accompanies the begin message.
3) Should "web service operations performed" be changed to "web
services operation invocations" in the first sentence.
Which text?
First sentence of model text; I take this to be
non-controversial.
If it'll make him go away,
then no ;)
4) If the ALS is an optional implementation technique, does it make
sense to expose it in the application interoperability layer (ie, what's
in the context should be independent of how the ALS is configured).
It's an option for the "context service", but that really exists as two
logical entities: the context manager (the thing that returns the context
either via getContext or for begin operations), and the context augmentation
manager (!), which provides a way for services to plug into the "context
service" and augment the context (!) 99% of users will use the context
manager, and that doesn't expose ALS information.
We should augment the text in the specification to make this distinction
clearer if necessary.
Right, but this implies -- please tell me if you disagree --
that the ALS configuration identifier should not be exposed to
applications.
I think if we call it
protocol-type and then wrap that with appropriate words in the
specification that relate it to different services (that may or may not
be implemented using ALSs) then we're fine.
5) the diagram appears to have a mistake: should the context and the
activity identifier be related in a bi-directional one to one
relationship?
Maybe there's confusion as to what Context is in the diagram. It's meant to
be an element in a context structure (hence the nesting relationship it has
with itself). So, with that in mind, a context element has exactly one
activity identifier associated with it. An activity identifier is associated
with exactly one activity (and hence one context element). So the diagram
seems right to me.
Martin has promised to send a more detailed critique of the
diagram.. I think half the problem is that we have to use UML.
Tell me about it!
Mark.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
|