- From: Francis McCabe <frankmccabe@mac.com>
- Date: Thu, 8 Jan 2004 21:45:00 -0800
- To: www-ws-arch@w3.org
- Message-Id: <F6E565D4-4266-11D8-9082-000A95DC494A@mac.com>
This diagram is slightly modified: 1. The relationship between a message and task is one of choreography. The idea is that messages denote significant events in the choreography of tasks. Anyone with a better suggestion would be welcomed. 2. Service roles have a relationship to the tasks performed by a service. Again, abstracts is a horrible word, but the idea here is that the role defines the tasks that the service represents for the owning organization. 3. To defend the aspect/processing link: We might short circuit aspect out of the diagram. However, SOAP 1.2 clearly identifies that a message processor (intermediary and final recipient) is not expected to leave messages untouched. In fact, any processor of a message is, by default, expected to *remove* the processed element; possibly replacing it with a modified element. The proper generalization of this is that messages have aspects, or views, or projections, that fit the role adopted by a given service. 4. I realize that the diagram does not mention intermediaries directly. I *could* have added it, it just felt superfluous at the time. I am not going to lay down as roadkill for that though, as I also subscribe to the redundancy is not necessarily bad POV. 5. I understand that the task/action/goal triangle caused confusion. However, services are there to perform tasks; and that is fundamentally a combination of an action (or set of actions) and the goal associated with the task. However, it might be clearer to identify a desired state rather than goal (they are the same IMO but the wording may be less contentious) 6. I added a link from policy to state - to denote that policies apply to the states achieved as well as the actions performed. Its redundant, but WTH. Frank
Attachments
- image/png attachment: ServiceModel.png
Received on Friday, 9 January 2004 00:45:11 UTC