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: Re: questions from today




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.


  


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