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 10:04:02 UTC