Re: Slight mod to service model

I am responding to this because it helps my thinking ... :)

I am pretty uncomfortable with some of the assertions you make in here; 
I am not yet completely sure why though.

1. There is a certain duality to messages and service. I don't feel 
comfortable with either the position that the service is merely 
operates on a message, and nor do I feel comfortable with the message 
being defined in some isolation apart from the service.

  Perhaps this is blue sky, but certainly in human conversations we do 
not feel operated on by our conversational elements, and yet nor are we 
completely free of the message either.

  99% of computer systems today are thought of in terms of command and 
response. Yet, human conversation is not like that. I have strong 
suspicions that one reason for the fragility of computer systems is 
from trying to express everything in terms of command/response (even 
though it can be hard to find good counterexamples).

Frank



On Jan 12, 2004, at 2:56 PM, Richard.Chennault@kp.org wrote:

>
> 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 Tuesday, 13 January 2004 12:48:40 UTC