glossary additions

Ok seems like some glossary definitions to me!
Not sure of the exact wording but something like:

A Choreography Instance is a set participants engaged in actual message
exchanges that follow a choreography (design).

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Steve Ross-Talbot
> Sent: Thursday, August 07, 2003 1:36 AM
> To: Burdett, David
> Cc: 'Cummins, Fred A'; Mark Little; Assaf Arkin; 
> jdart@tibco.com; public-ws-chor@w3.org
> Subject: Re: simultaneous execution
> 
> 
> 
> I like the term FOLLOWED. I don't like the term EXECUTED. I also like 
> the term PERFORMED but that is because it fits with the notion of 
> choreography. Choroegraphies in dance are performed but perhaps in 
> business FOLLOWED is better.
> 
> Cheers
> 
> Steve
> 
> On Wednesday, August 6, 2003, at 11:23  pm, Burdett, David wrote:
> 
> > Fred
> >
> > One minor comment in line.
> >
> > David
> >
> > -----Original Message-----
> > From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> > Sent: Wednesday, August 06, 2003 2:32 PM
> > To: Burdett, David; Mark Little; Assaf Arkin; Burdett, David
> > Cc: jdart@tibco.com; public-ws-chor@w3.org
> > Subject: RE: simultaneous execution
> >
> >
> > David,
> >
> > See comments below.
> >
> > Fred
> >
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Tuesday, August 05, 2003 5:13 PM
> > To: Cummins, Fred A; Mark Little; Assaf Arkin; Burdett, David
> > Cc: jdart@tibco.com; public-ws-chor@w3.org
> > Subject: RE: simultaneous execution
> >
> >
> >
> > Fred
> >
> > See comments inline.
> >
> > David
> >
> > -----Original Message-----
> > From: Cummins, Fred A [ mailto:fred.cummins@eds.com 
> > <mailto:fred.cummins@eds.com> ]
> > Sent: Tuesday, August 05, 2003 1:20 PM
> > To: Mark Little; Assaf Arkin; Burdett, David
> > Cc: jdart@tibco.com; public-ws-chor@w3.org
> > Subject: RE: simultaneous execution
> >
> >
> > I believe this thread has reached a
> > conclusion I don't agree with as a result
> > of some implicit assumptions:
> >
> > 1) that a choreography has instances.
> >
> > 2) that a choreography must express
> > how a message type is determined.
> >
> > 3) that the choreography must define
> > how one conversation/transaction is
> > distinguished from another when there are
> > two or more conversations involving the
> > same participants, roles and choreography.
> >
> > A choreography does not have instances
> > since it is not executed, it is observed
> > (i.e., complied with), just as a law does
> > not have instances, only instances of
> > people complying or breaking the law.
> > <DB>I think of a choreography *definition* as a design of *what* you
> > can do
> > just as an architect can provide a design for a building. 
> However the 
> > same
> > design can be followed multiple times resulting in, for the 
> architect,
> > multiple building. Identifying each of the buildings that 
> was built is
> > obviously useful for example in case there was a probelm with the 
> > design
> > that needed to be fixed. For exactly the same reason, it is 
> useful to
> > identify each time a choreography definition is followed. 
> Now whether 
> > the
> > term used to describe a choreography being followed should 
> be "used",
> > "followed", "complied with", "executed" or something else really 
> > requires
> > that the semantics of these words in the context of 
> choreographies is
> > properly defined. I don't think that "executed" is a good 
> term to uses 
> > for
> > the same reasons as you as it sounds like a program 
> execution which it
> > isn't. I have a marginal preference for "followed" what do others
> > think.</DB>
> > [FAC] Followed seems appropriate.  The issue is that it is 
> realized by 
> > the
> > participants, not by something that executes/performs it (the 
> > choreography).
> > Since it does not perform any actions, per se, it does not make any
> > decisions nor operate on any variables.  It only defines what the
> > participants can do.
> > [Burdett, David] +1
> >
> > A choreography defines what message types
> > are acceptable, but the participants define
> > what the message types are.
> > <DB>In my WS Choreography spec (aka BurdettML) I introduced 
> the idea 
> > of specifying choreographies using "message families" where 
> a message 
> > family is an abstract term for the set of messages that server the 
> > same purpose. For
> > example an EDI 850, a UBL Order and a RosettaNet Order are all 
> > different
> > messages but they are all in the "Order" message family.</DB>
> > [FAC] I think the choreography must identify the semantic 
> type of the
> > messages that are allowed, but these types may be realized 
> in different
> > ways, with different formats.  They may, in most cases, be XML, but 
> > even
> > there, there might be different specifications to achieve the same 
> > result.
> > In addition, there may be rather generic types, that are 
> specialized 
> > for
> > particular industries or situations.  This allows the 
> choreography to 
> > have
> > broad application and avoids unnecessary specialization of the 
> > choreography,
> > per se.
> > [Burdett, David] +1. This variability is something that the 
> Universal
> > Business Language (UBL) initiative has identified and, from an XML 
> > business
> > document perspective, is developing a solution. Meeting this 
> > requirement is
> > one of the main reasons why I like the idea of "message families".
> >
> > When a message
> > is received, the choreography defines what
> > the recipient should expect (one or more
> > possibilities).
> > <DB>Not sure about this. The choreography should define what a
> > recipient
> > should *send* when they receive a message of a particular type.</DB>
> > [FAC] When a recipient receives a message of a particular type, it 
> > often has
> > options on what to return.  In the order example, it may return a 
> > rejection
> > or a correction or a counter-offer under the right business 
> > circumstances.
> > The choreograpy only defines the options available by 
> agreement of the
> > subscribing parties.  Usually, there is an accept or reject option.
> > [Burdett, David] +1
> >
> > When a message is sent,
> > the choreography will define what messages
> > may be sent based on what the sender
> > determined it last received and its own
> > internal business logic to determine the next
> > step.
> > <DB>Agreed</DB>
> > The choreography does not determine which
> > type is actually sent.  Consequently, the
> > type of a message is what the sender or
> > receiver says it is.
> > <DB>Does this problem go away if you think of a choreography
> > definition as a
> > description of what should be done. Drawing on the architecture 
> > analogy.
> > What you really need to do is: a) design the building, b) build the
> > building, and c) check the building was built according to 
> the design 
> > and
> > fix the problem if it is not. The same goes for 
> choreographies as you: 
> > a)
> > Design the choreography, b) build implementations that follow the
> > choreography, and c) check the choreography is being 
> followed and fix 
> > the
> > problems if it is not.</DB>
> > [FAC] I think that's fair.
> >
> > This is
> > the basis for the sender to decide what
> > to expect in return according to the
> > choreography and for the receiver to
> > determine what it may send in order to
> > comply with the choreography.
> > <DB>Agreed</DB>
> >
> > Neither does the choreography determine
> > which messages are elements of the same
> > exchange.  The participants determine this
> > possibly with the assistance of the transport
> > protocol (e.g., session id).  A choreography
> > could specify that at some point, an exchange
> > could branch into multiple conversations/
> > transactions.  It does not, however, need
> > to determine which is which, the choreography
> > only defines the rules with which each must
> > comply.
> > <DB>Agreed, specifying the rules to follow is what choreography
> > definitions
> > are all about!</DB>
> >
> > Possibly, the choreography could also
> > specify that these (or some of these) should
> > or may join before some other action is allowed
> > to occur.  The choreography should not specify
> > which instance, only that instances complying
> > with certain choreography may or should join.
> > <DB>In practice I think that you may *have* to specify that the
> > instances
> > are related. For example before paying for goods it might 
> be necessary 
> > for
> > two choreographies to complete: a) one to check the goods are in 
> > stock, and
> > b) to know they have left the warehouse. However this only 
> makes sense 
> > if
> > the goods being order, the goods being checked for in stock 
> and also 
> > the
> > goods that left the warehous refer to the same goods!/DB>
> > [FAC] It may be necessary to reference some symbolic parameter that 
> > should
> > be the same for the instances to be joined.  I am wary of including 
> > any sort
> > of logic or reference to values in the messages.  I think these 
> > decisions
> > probably should be left to the participants and the 
> choreography remain
> > abstract.  If nothing else, it retains flexibility in the 
> > implementation.
> >
> > I want to see the choreography as light-weight
> > as possible so that it can be used independent
> > of the the message format employed by participants
> > or the technology employed, either the internal
> > technology (e.g., the business process language)
> > or the communication protocol (e.g., web
> > services or message broker).
> > <DB> +1 ... and this is *exactly* what I tried to do in the
> > WS-Choreography
> > spec. However since this is the WS Choreography group I think we 
> > *also* have
> > to define how the our Choreography spec binds to web services.</DB>
> > [FAC] I don't have any problem with the intent of binding.  I just 
> > want to
> > do it in a way that allows binding to other technologies as 
> well.  Even
> > explicit binding to WSDL might not be too bad if there are explicit 
> > mappings
> > from WSDL to other technologies.
> >
> > Fred
> >
> >> -----Original Message-----
> >> From: Mark Little [ mailto:mark.little@arjuna.com
> > <mailto:mark.little@arjuna.com> ]
> >> Sent: Monday, August 04, 2003 4:55 AM
> >> To: Assaf Arkin; Burdett, David
> >> Cc: jdart@tibco.com; public-ws-chor@w3.org
> >> Subject: Re: simultaneous execution
> >>
> >>
> >>
> >> +1. And if you look at the recent WS-CAF specifications
> >> you'll see that
> >> there is a separate context service definition precisely 
> because of 
> >> this.
> >>
> >> Mark.
> >>
> >> ----- Original Message -----
> >> From: "Assaf Arkin" <arkin@intalio.com>
> >> To: "Burdett, David" <david.burdett@commerceone.com>
> >> Cc: <jdart@tibco.com>; <public-ws-chor@w3.org>
> >> Sent: Thursday, July 31, 2003 10:58 PM
> >> Subject: Re: simultaneous execution
> >>
> >>
> >>>
> >>> I'll have to side with Jon on this. Correlation is a generic and 
> >>> flexible mechanism that can also be used for that. A more 
> specific 
> >>> mechanism would be too narrow in scope and would impose some 
> >>> limitations. Since we're dealing with WS in general, and not 
> >>> specifically PO scenarios, let's have the more generic mechanisms.
> >>>
> >>> arkin
> >>>
> >>> Burdett, David wrote:
> >>>
> >>>> If all you have is a request response over the same
> >> channel, then I agree
> >> it
> >>>> is not necessary unless that request response is part of a
> >> larger and
> >> longer
> >>>> interaction.
> >>>>
> >>>> But if you do need to do this, it is hardly rocket science
> >> and has also
> >> been
> >>>> done in other specs such as ebXML messaging.
> >>>>
> >>>> What we really want to do is have one *definitive* way of
> >> providing this
> >>>> functionality. Now identifying which choreography you are
> >> following is
> >>>> definitely, IMO, part of our scope. However identifying
> >> that a set of
> >>>> messages are related is broader as you could have some sort of
> >> "correlation
> >>>> identifier" without specifing the choreography which being
> >> followed.
> >>>>
> >>>> David
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> 
> 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, 7 August 2003 14:38:14 UTC