RE: Grounding Choreographies (the atoms) - WAS Simple Choreograph y composition suggestion

Frank,

Catching up from Friday:

I agree with your definition of agent.  It should be
distinguished from "role."  An agent may have many
roles.  When an agent participates in a choreography,
it may have one or more roles.  An agent may be
a buyer and also a shipment receiver (choreography
with a transport carrier).

So choreography defines the interactions between roles
of agents.  In general, I would not expect the 
choreography to be concerned with the agents, only the
roles.

Fred


> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> 
> This is simple.
> 
> An agent is the computational resource (yuk) that may be 
> considered to  
> represent a legal entity and which offers and/or requests 
> services; in  
> particular Web services.
> 
> The service itself is manifested by the messages between the agents;  
> those messages are the basic raw materials for 
> choreographies, not the  
> agents. Controlling the agents amounts (IMO) to orchestration;  
> observing the messages amounts to choreography.
> 
> Frank
> 
> 
> 
> On Friday, July 18, 2003, at 11:51  AM, Assaf Arkin wrote:
> 
> >
> > Then how should we use the term agent as suggested by the WSA?
> >
> > Also, how do we deal with the trivial case of a choreography that  
> > involves only one message (got to start somewhere). There's a Web  
> > service requester (agent 1) sending a message to Web 
> service provider  
> > (agent 2). The later is a Web service, but the former is 
> not. What are  
> > we choreographing in this case?
> >
> > arkin
> >
> > Frank McCabe wrote:
> >
> >>
> >> No, that would be orchestration! ;-)
> >>
> >> Frank
> >>
> >> On Thursday, July 17, 2003, at 11:32  AM, Assaf Arkin wrote:
> >>
> >>>
> >>> So a Web Service Choreography does not choreograph Web 
> services, it  
> >>> choreographs agents?
> >>>
> >>> arkin
> >>>
> >>> Francis McCabe wrote:
> >>>
> >>>>
> >>>> +1.
> >>>>
> >>>> Following the form of the WSA, we have agents that provide and  
> >>>> request Web services. This is based on the intuition 
> that a service  
> >>>> is fundamentally about the potential for action, and 
> that actors  
> >>>> (computational and otherwise) are the entities that do 
> the acting.
> >>>>
> >>>> Frank
> >>>>
> >>>> On Thursday, July 17, 2003, at 09:16  AM, Martin Chapman wrote:
> >>>>
> >>>>>
> >>>>> I think there is a fundamental terminology issue here 
> that needs  
> >>>>> to be
> >>>>> cleared up.
> >>>>> An entity (avoiding any overloaded word) that sends a 
> message to a  
> >>>>> web
> >>>>> service (and may expect a response depending on the 
> wsdl) doesn  
> >>>>> not iteslf
> >>>>> have to be a web service. This is the most fundamental 
> building  
> >>>>> block.
> >>>>> Furthermore this interaction supports an MEP (in soap 
> teminology)  
> >>>>> and
> >>>>> pattern (in wsd teminology).
> >>>>> Perosnllay if we can not describe these meps in a choreography  
> >>>>> language we
> >>>>> have failed, and hence I do not think that mep 
> choreogaprhy is any  
> >>>>> different
> >>>>> from web service choreography.
> >>>>>
> >>>>> Martin.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: public-ws-chor-request@w3.org
> >>>>>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Steve  
> >>>>>> Ross-Talbot
> >>>>>> Sent: Thursday, July 17, 2003 2:14 AM
> >>>>>> To: Champion, Mike
> >>>>>> Cc: public-ws-chor@w3.org
> >>>>>> Subject: Grounding Choreographies (the atoms) - WAS Simple  
> >>>>>> Choreography
> >>>>>> composition suggestion
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>    At the considerable risk of adding further confusion to the
> >>>>>> discussion I would like to attempt to clarify what I 
> said on the  
> >>>>>> call
> >>>>>> with respect to the grounding of a choroegraphy.
> >>>>>>
> >>>>>>
> >>>>>>    Here is how I see it:
> >>>>>>
> >>>>>>    A "web service" choreography, as distinct from any other
> >>>>>> choreography, is grounded to a minimum of two web services  
> >>>>>> instances.
> >>>>>> This may mean that the web services are the same web 
> services but
> >>>>>> different instance or it may mean that they are distinct  
> >>>>>> (personally I
> >>>>>> have a hard time seeing what they would be anything 
> other than the
> >>>>>> latter) such that I can observe a communication between them.
> >>>>>>
> >>>>>>    A communication is a minimum of a single message 
> sent from one  
> >>>>>> web
> >>>>>> service to another web service.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>    It may be the case that in receiving or indeed sending a  
> >>>>>> message the
> >>>>>> sending web service and/or the receiving web service can be  
> >>>>>> externally
> >>>>>> observed to change their behaviour.
> >>>>>>
> >>>>>>    A "web service" choreography, as distinct from any other
> >>>>>> choreography, is based on externally observable 
> behaviour where  
> >>>>>> this
> >>>>>> behaviour is defined in terms of communications between web  
> >>>>>> services
> >>>>>> and externally observed behavioral changes of a web service.
> >>>>>>
> >>>>>>    For the avoidance of doubt, a Message Exchange 
> Pattern (MEP)  
> >>>>>> or any
> >>>>>> mechanism that describes communication between two 
> parties can be  
> >>>>>> said
> >>>>>> to be a choreography. But it cannot be said to be a 
> "web service"
> >>>>>> choreography.
> >>>>>>
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>> Steve T
> >>>>>>
> >>>>>>
> >>>>>> On Wednesday, July 16, 2003, at 02:57  pm, Champion, 
> Mike wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
> >>>>>>>> Sent: Wednesday, July 16, 2003 9:12 AM
> >>>>>>>> To: public-ws-chor@w3.org
> >>>>>>>> Subject: FW: Simple Choreography composition suggestion
> >>>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The point I disagree with is the notion that 
> something is not a
> >>>>>>>> Choreography if somewhere, at some level it involves  
> >>>>>>>> 'orchestration'
> >>>>>>>> within a single system.  If we accept this notion /
> >>>>>>>> restriction it means
> >>>>>>>> that you can only have Choreographies involving exactly two  
> >>>>>>>> parties
> >>>>>>>> where each party only plays a single role - we will not be
> >>>>>>>> able to have
> >>>>>>>> Choreographies with more than two parties / roles at all.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> That wasn't my intent, FWIW.  All sorts of compositions and
> >>>>>>> decompositions
> >>>>>>> can occur within a "choreography," but IMHO only those that  
> >>>>>>> involve the
> >>>>>>> globally visible shared state are in scope for the 
> choreography
> >>>>>>> description
> >>>>>>> language we are developing.  The discussion yesterday got me
> >>>>>>> re-thinking all
> >>>>>>> sorts of things ... if the fundamental unit of a 
> "choreography"  
> >>>>>>> is a
> >>>>>>> Web
> >>>>>>> service invocation / MEP, then all sorts of implementation  
> >>>>>>> details of
> >>>>>>> the
> >>>>>>> service that involved "orchestrated" interactions behind the  
> >>>>>>> scenes are
> >>>>>>> abstracted away, but if the fundamental unit is a 
> message, then  
> >>>>>>> all
> >>>>>>> those
> >>>>>>> messages behind the scenes have to be accounted for 
> somehow.   
> >>>>>>> I'm as
> >>>>>>> confused as anyone at this point.
> >>>>>>>
> >>>>>>> By all means let's make sure that we don't box 
> ourselves into a  
> >>>>>>> corner
> >>>>>>> based
> >>>>>>> on some preliminary guesses about what terms mean!
> >>>>>>>
> >>>>>>>
> >>>>>>> This email is confidential and may be protected by legal  
> >>>>>>> privilege. If
> >>>>>>> you are not the intended recipient,  please do not copy or  
> >>>>>>> disclose
> >>>>>>> its content but  delete the email and contact the sender  
> >>>>>>> immediately.
> >>>>>>> Whilst we run antivirus software on all internet 
> emails we are  
> >>>>>>> not
> >>>>>>> liable for any loss or damage. The recipient is 
> advised to run  
> >>>>>>> their
> >>>>>>> own antivirus software.
> >>>>>>>
> >>>>>>
> >>>>>> This email is confidential and may be protected by legal
> >>>>>> privilege. If you are not the intended recipient,  
> please do not
> >>>>>> copy or disclose its content but  delete the email and contact
> >>>>>> the sender immediately. Whilst we run antivirus software on all
> >>>>>> internet emails we are not liable for any loss or damage. The
> >>>>>> recipient is advised to run their own antivirus software.
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>> -- "Those who can, do; those who can't, make screenshots"
> >>>
> >>> 
> --------------------------------------------------------------------- 
> >>> -
> >>> Assaf Arkin                                           
> >>> arkin@intalio.com
> >>> Intalio Inc.                                            
> >>> www.intalio.com
> >>> The Business Process Management Company                 
> (650) 577  
> >>> 4700
> >>>
> >>>
> >>> This message is intended only for the use of the Addressee and
> >>> may contain information that is PRIVILEGED and CONFIDENTIAL.
> >>> If you are not the intended recipient, dissemination of this
> >>> communication is prohibited. If you have received this 
> communication
> >>> in error, please erase all copies of the message and its 
> attachments
> >>> and notify us immediately.
> >>>
> >>>
> >>>
> >
> >
> >
>

Received on Tuesday, 22 July 2003 14:03:57 UTC