RE: updated service model

 

> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
> Sent: Wednesday, January 14, 2004 12:15 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: updated service model
> 

> 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. 

I'm suggesting that it is the *task* that succeeds rather than "the task has
a goal that is achieved".  It seems more concise, and equally meaningful as
far as the rest of the model is concerned.  You're right in some general
semantic sense, but I have a bias toward keeping the WSA models as focused
as possible on WS concepts, and hence I'm willing to sacrifice a bit of
precision for comprehensibility.  

That said, I don't want to lay down in the road, just question whether this
concept adds enough to the overall architecture to justify its cost in
complexity.


> 
> 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'.

I'm currently in the mindset of wanting to remove anything that doesn't have
a very compelling definition, and thost concepts that don't have any
*compelling* need to be there.  Again, I'd rather leave them in than argue,
but am waiting for others to give their opinion.

> 
> The service model has to establish the 
> relationship between the messages and the real-world actions 
> that the service performs.

Sure, but what is the real "thing" that establishes it?  In a service simple
enough to be described with WSDL, it's the MEP.  In a multi-party task
performed by peers, it's a choreography description language document.  In
orchestration/workflow/business process that decomposes a task into
coordinated actions, it's the BPEL/BPML/etc description.  I wouldn't have a
problem using the word "choreography" to describe the abstraction here if
it's clear to the typical reader.

Received on Wednesday, 14 January 2004 12:38:48 UTC