RE: Slight mod to service model

Perhaps it would also be relevant to mention that we are in the last
stages of cleaning up a document which is the result of many man years
of intense discussion and negotiation, and the time in which we have to
do this is now measured in days.  Insights that might be helpful in this
short term task are timely, discussions of overall organization or
fundamental issues are not.  There is, of course, the "issue mechanism"
if one really feels the need to record something of that sort for
posterity.

The working group also, of course, has an obligation to answer questions
from the public, which I believe is a fair characterization of this
discussion.  (Note that Kaiser Permanente is not a W3C member company).
However, since the lifetime of the working group itself is also measured
in days, one might wonder whether there could be a point in putting off
such answers for a few days, particularly if one is an editor who has
agreed to perform more tasks than one might expect a single person to be
able to do.  Or perhaps to delegate such answers to people like me who
are not as authoritative, but who probably have more time on their
hands.

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Francis McCabe
Sent: Monday, January 12, 2004 3:51 PM
To: Richard.Chennault@kp.org
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 17:47:50 UTC