Slight mod to service model

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

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