[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: 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".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. 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.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. First sentence of model text; I take this to be non-controversial.3) Should "web service operations performed" be changed to "web services operation invocations" in the first sentence.Which text? Right, but this implies -- please tell me if you disagree -- that the ALS configuration identifier should not be exposed to applications.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. Martin has promised to send a more detailed critique of the diagram.. I think half the problem is that we have to use UML.5) the diagram appears to have a mistake: should the context and the activity identifier be related in a bi-directional one to onerelationship? 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. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]