RE: Slight mod to service model

Frank,
  Upon further reflection and you own explanation I agree that a message
in an SOA has here-to-fore has not been clearly defined.   I agree through
inference that a message is itself not described by a service description
as you state, "...The latter aspect involves defining the format of
messages, binding info etc...".   Therefore drawing a line of relationship
between the service description and a message would infer that the service
is responsible for defining the message (and that is not a good thing).

   Ultimately I believe the message itself is a distinct object defined
outside of the service.   Therefore the relationship the message has to
the service description is accurate as you have pictorially described it
in the diagram.  I am however reticent to use the word 'defines'.   I
believe the interface defines the operations that can be done on the
message by the service but the interface does not describe the message
itself.   The interface defines 'what' the service can do with the
message.
  
	I believe collaborations amongst services should be created based
upon coarse grained messages.   The battle I constantly wage in my own
company is trying to get folks to stop creating collaborations based on
the object semantics of a particular application (rpc) but on a higher
level abstraction of an object that may be a composite of multiple
services/applications.  This is where choreographic events may play an
important role in helping to distinguish the message from the service
description of a particular service.   

   I appreciate your time in clarifying the diagram as I am working on
defining an SOA for my own company based upon the fine work delivered by
the WS-Architecture group.   My questions were meant to enlighten myself
and my own endeavors and should not be construed as an attempt to alter
the course of the document.   

Thank you;
Richard D. Chennault

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of fgm@fla.fujitsu.com
Sent: Monday, January 12, 2004 1:51 PM
To: Richard Chennault
Cc: www-ws-arch@w3.org
Subject: Re: Slight mod to service model


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 18:14:32 UTC