W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2004

Slight mod to service model

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


(image/png attachment: ServiceModel.png)

Received on Friday, 9 January 2004 00:45:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC