- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Wed, 14 Jan 2004 10:14:39 -0600
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
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