RE: updated service model

I find the word "comprises" in this sort of context very difficult to
understand.  I vote for another word, but I have no idea what it might
be -- indicating, of course, that I don't understand what you are
talking about.

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Champion, Mike
Sent: Wednesday, January 14, 2004 9:04 AM
To: www-ws-arch@w3.org
Subject: RE: updated service model



 

> -----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 11:15:23 UTC