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

Martin,

While I agree that it should be possible to define a MEP with
the choreography langauge, I would not like a reliable messaging
choreography to be merged with a purchasing choreography.  
I want the purchasing choreography to be expressed with the
reliable messaging protocol implied, i.e., abstracted out.

The MEP will have implications to the design of the business
choreography.  Consequently, it may be necessary to incorporate
a reference so that the assumptions are clear, but I don't
see a single choreography incorporating both levels of 
abstraction in any more complex way.

Fred

> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Thursday, July 17, 2003 12:17 PM
> To: Steve Ross-Talbot; Champion, Mike
> Cc: public-ws-chor@w3.org
> Subject: RE: Grounding Choreographies (the atoms) - WAS Simple
> Choreography composition suggestion
> 
> 
> 
> 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.
> >
> >
>

Received on Thursday, 17 July 2003 13:59:07 UTC