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

Re: Slight mod to service model

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Mon, 12 Jan 2004 13:50:43 -0800
Message-Id: <5EF9B884-4549-11D8-9082-000A95DC494A@fla.fujitsu.com>
Cc: www-ws-arch@w3.org
To: Richard.Chennault@kp.org

Richard:
  First of all, the diagram is out of sync with the text, esp. in 
relation to the service model. The diagram is a kind of taster of how 
the text will look.
  Secondly, I am a little confused by your questions. I hope I have 
understood them properly:
1. The service description is fundamentally a semantic description of 
what the service does, and how to interact with it. The latter aspect 
involves defining the format of messages, binding info etc. This is a 
more general idea than service description a la WSDL, but should be 
reasonably consistent with it.
2. The concept of performing on a message does not really grok with me 
:) This view of service identifies messages as defining choreographic 
events in the use of a service. That is more abstract than RMI but RMI 
etc. fall out as special cases.
  The relationship of a message to a service is a key one for service 
oriented architectures.  To date we haven't managed to really nail it 
down very well; it is too easy to slip into modes of thought along the 
lines of "I send you this message and you perform the foo method on the 
bar object". But that line of thinking does not capture the essence of 
service; whereas the choreographic way point idea does a better job 
(IMO).
3. One could have a line between service description and messages; 
however, if we partition the service description into syntax and 
semantics (so to speak), then the how of the service is partially 
captured in the interface to the service, which includes the expected 
forms of messages. I.e., the form of the message is a proper aspect of 
the interface to the service.
Frank


On Jan 12, 2004, at 1:05 PM, Richard.Chennault@kp.org wrote:

>
> 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:50:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:24 GMT