Re: updated service model

Mike:
1. goal state/goal/state whatever is of the essence I believe. Noone is 
talking about goals at the level of war in Iraq; but they *are* talking 
about things like ensuring that a database entry is updated. Without 
the concept it is not possible to have sensible discussions about 
things like idempotency, transaction success, transaction failure, etc. 
Also, at least based on my slightly out of date reading of ws-chor, the 
concept of a target for a choreography is also very much in their 
thinking.

2. Property is a deliberately vague term. However, it might mean 
something like 'all messages pertaining to a given task', or it might 
mean 'all messages that have a WS-CAF header in them'.

3. I believe that our use of the chor term is consistent with ws-chor's 
use; although we have not elaborated. There is an `inner' aspect to 
this: in pi-calculus there is a notion of event, (also in event 
calculus and many other calculi). These events are a generic for 
something significant occurring; in our case all events take the form 
of messages either sent or received. The message is not, however, the 
same thing as the internal action denoted by the event. I.e., me 
telling you that I have sent you the book is not the same thing as 
actually sending you the book. (There is a corner case here, but we 
needn't explore it.) The service model has to establish the 
relationship between the messages and the real-world actions that the 
service performs.

4. There are cardinality issues: I deliberately did not nail this down. 
There does not need to be a single choreography for each task. I agree 
that the MEP issue seems to loom large, but I think that that is 
*merely* legacy stuff :)

5. The interface comprising tasks is not well worded. The intention is 
to lay the foundation for an interface being able to refer to any 
number of related tasks that can be performed using a service.

Frank


On Jan 14, 2004, at 7:04 AM, Champion, Mike wrote:

>
>
>
>> -----Original Message-----
>> From: Francis McCabe [mailto:frankmccabe@mac.com]
>> Sent: Wednesday, January 14, 2004 1:38 AM
>> To: www-ws-arch@w3.org
>> Subject: updated service model
>>
>> I have checked in a revised arch document with updated service model.
>>
>> The diagram, included here for convenience, is slightly
>> modified from before. The text in the arch should now reflect
>> the diagram.
>
> Overall, we're definitely getting there. A few comments, that probably
> reopen old wounds (sorry!).
>
> - I really don't think "goal state" adds much here.  It's perfectly 
> true
> that tasks are presumably taken to achieve goals, but this gets into 
> deep
> philosophy (at least I had a professor in Political Science grad 
> school who
> was violently opposed to the idea, mainly because it's not at all 
> obvious
> what if any "goal" is really being pursued, e.g. by the US in Iraq.) 
> Can we
> just say that tasks execute actions, and policies apply to services?
>
> - I'm a bit unclear on how messages have a property defined by the 
> service
> role.  Concretely, what are we talking about here?  It seems to make 
> sense,
> but what would be lost by dropping it?
>
> - I think we're getting close on the interface - task - action - 
> message -
> choreography corner, but I still have concerns:
>
> * I have a hard time reconciling this use of the term "choreography" 
> with
> WS-CHOR's.  In their world, it refers specifically to a set of 
> messages that
> carries out some task and is carried out by multiple actors without a
> central authority, right?  "Orchestration" is the same thing, but with 
> a
> central business process manager, right?  [I might be wrong here; I 
> haven't
> followed WS-CHOR for a month or so very well]
>
> * What about the simple case where there is only one set of messages
> implementing a task, but different MEP's (e.g., a request-response 
> version
> and a pub-sub version) are possible.  Is that also a "choreography"?  
> I know
> we toyed with this idea earlier in the WS-CHOR group but I thought it 
> turned
> into a swamp.
>
> * Isn't this basically a matter of how to describe the cardinality of 
> the
> relationships among Interface, Task, and Message?  "Choreography" might
> capture that, but isn't really a property "Task" that may (in the case 
> of a
> Choreography as I understand it) or may not (e.g. in the case of an
> Orchestration as I understand it) be exposed to the Interface?  Maybe 
> we
> should be honest and draw a fuzzy cloud around this and say that our
> understanding is nebulous!  I think this *is* one of our "unresolved
> meta-architectural issues" -- there's no consensus on how MEP, 
> choreography,
> orchestration, and business process management relate to one another, 
> other
> than that they do, sortof, somehow.
>
> * I don't know about the "interface comprises task" link.  What is that
> really saying?  What breaks if we drop it?  Or maybe we need a better 
> term
> than "comprises"?
>

Received on Wednesday, 14 January 2004 12:15:36 UTC