RE: Slight mod to service model

Frank,
  Does not the service description describe the message whereas the
interface defines the operations that can be made on the message?  Would
this not then be represented in the service model as an interface performs
on a message as opposed to defines?   Furthermore a new relationship
between the service description and message would need to be drawn.  It
would be of type describes?  
  I am basing my supposition on my current interpretation of the
WS-Architecture specification.

Regards;

Richard D. Chennault

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of frankmccabe@mac.com
Sent: Thursday, January 08, 2004 9:45 PM
To: www-ws-arch@w3.org
Subject: 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 Monday, 12 January 2004 16:18:20 UTC