Re: Definition of Terms

Hi,

a remark on 'control' (or maybe a question). I assume that your definition of 
'message' is abstract, i.e. does not imply asynchronous transmission between 
sender and receiver. If this is so, then in context of synchronous 
invocations some control is applied from the invoking party since it controls 
when the receiving party has to respond, i.e., receives the 'message'. 

The definition of 'control' in general is difficult. Maybe a distinction has 
to be made between controlling the definition vs. controlling the execution 
(i.e., type vs. instance).

Thanks,

Christoph


In a message dated 3/17/03 4:55:50 PM Pacific Standard Time, 
david.burdett@commerceone.com writes:


> Subj:RE: Definition of Terms 
> Date:3/17/03 4:55:50 PM Pacific Standard Time
> From:<A HREF="mailto:david.burdett@commerceone.com">david.burdett@commerceone.com</A>
> To:<A HREF="mailto:sanjay.patil@iona.com">sanjay.patil@iona.com</A>, <A HREF="mailto:david.burdett@commerceone.com">david.burdett@commerceone.com</A>, <A HREF="mailto:public-ws-chor@w3.org">
> public-ws-chor@w3.org</A>
> Sent from the Internet 
> 
> 
> 
> 
> Sanjay
> 
> I've responded inline below, but first here's an attempt at clarifying the
> difference between the Choreographies and Orchestrations ...
> 
> Choreographies ...
> 1. Involve more than one "domain of control" (e.g. the exchange of messages
> between two businesses to place an order)
> 2. Have no single point of control. One "domain of control" has *no way* of
> controlling what any other "domain of control" does. For example a buyer
> cannot tell a supplier how to run their business
> 3. MUST be mutually agreed. If all the domains of control don't behave in
> precisely compatible ways, then, it won't work. For example if a buyer
> expects the supplier to send an Invoice when he sends an order, BUT the
> supplier sends a shipping note instead then the order placement will fail.
> 4. Can't be executed directly. Because there can never be a single point of
> control that governs the behavior of all the domains of control involved in
> the choreography.
> 5. *Can't* be described by languages like WSCI or BPEL4WS since they only
> describe what is going on in one "domain of control"
> 6. Should be content independent. Choreographies should be defined
> independently of the content of the messages. It should not matter whether
> UBL, EDI, fax or a letter is used to represent an order in an order
> placement choreography.
> 
> On the other hand, Orchestrations:
> 1. Involve a single "domain of control". They describe what is going on in
> one place, e.g. a within a Buyer
> 2. Have a single point of control. As they describe what is going on in 
> just
> one domain of control everything can be controlled and coordinated
> centrally. It also means that changes to the orchestration can be made at
> any time.
> 3. Don't require any pre-agreement. A Buyer can decide independently how
> they are going to run their business without consulting with anyone else.
> 4. Can be executed directly. As there is a single point of control, you can
> have a single piece of software that controls everything going on.
> 5. *Can* be described by languages like WSCI and BPEL4WS since they define
> executable logic that can be run in one "Domain of control" using a 
> Business
> Process Manager.
> 6. Are constrained by choreographies. Whenever an orchestration involves
> flows of information outside of its domain of control, then the
> Orchestration must follow precisely the constraints implied by the
> Choreography. See item 3 under choreographies.
> 7. Are implementation specific. Orchestrations should describe exactly what
> the flows of information are and how they relate to services and
> applications.
> 
> Also see comments inline ...
> 
> David
> 
> -----Original Message-----
> From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
> Sent: Monday, March 17, 2003 4:04 PM
> To: Burdett, David; WS Choreography (E-mail)
> Subject: RE: Definition of Terms
> 
> 
> 
> Frankly speaking, it's still not clear to me what the differences are (or
> how we want to define the differences for our convenience) between
> orchestration and choreography (and it seems we have to also deal with:
> process, conversation, interaction, interaction instance!).
> <DB>Maybe I covered a few too many nuances in one document but there are
> reasons for all the definitions. Would it help if I explained why these
> separate defintions are useful, for example between interaction and
> message?</DB>
> 
> David, this is what I am interpreting from your definitions. Please let me
> know if I am wrong ...
> Choreography provides the global view, where as the scope of orchestration
> is confined to any single entity participating in the choreography!
> Expanding the concept further, as per your definition, an orchestration is
> constrained by the roles it plays (that are defined by choreographies) and
> the other orchestrations it interacts with.
> <DB>That's a good summary.</DB>
> 
> I remember somebody distinguishing these two terms in another way during 
> the
> F2F, by associating liveliness with them, that is, choreography is a
> definition where as orchestration is an execution of the definition!
> <DB>We're just choosing words. The convention in other work, e.g. ebXML is
> to use the word Conversation as the execution of an orchestration which is
> why I used it. I don't really care as long as we have an agreed definition
> that is documented ... which is why I tried coming up with some definitions
> ;)</DB>
> 
> I also remember we simply abandoning the use of the term "orchestration" in
> order to move on!!
> <DB>IMO, the difference between the processes executed within a business
> (i.e. the Orchestration) and agreeing how businesses (domains of control)
> interact (i.e the Choreography) is *absolutely critical*. Unless and until
> there are widely published and agreed instances of choreography 
> definitions,
> e.g. on how to place an order, B2B will never get off the ground and you
> can't get instances of choreography definitions without having an agreed 
> way
> of defining them. BPSS is the closest to this that we have at the
> moment.</DB>
> 
> What I really carried with me on this topic in the F2F was somebody's
> comment that:- let us first nail down the concepts that we want to define
> and then we can associate any terms with those concepts. That is, let us
> first define the problems we want to deal with (I guess this is where we 
> got
> into the internal vs external debate!!).
> <DB>Totally agree. A Use case driven approach is the way to go. This is why
> I referenced in an earlier email the three party use case discussed in WS
> Architecture at ...
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0369.html
> </DB>
> 
> Sanjay Patil
> Distinguished Engineer
> sanjay.patil@iona.com
> -------------------------------------------------------
> IONA Technologies
> 2350 Mission College Blvd. Suite 650
> Santa Clara, CA 95054
> Tel: (408) 350 9619
> Fax: (408) 350 9501
> -------------------------------------------------------
> Making Software Work Together TM
> 
> 
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Monday, March 17, 2003 2:34 PM
> To: WS Choreography (E-mail)
> Subject: Definition of Terms
> 
> 
> 
> Folks
> There has been a lot of discussion about Choreographies, Orchestrations,
> Conversations, etc, so I thought it might help to make an attempt at some
> definitions of terms so that the distinction between them all was clear.
> The following is my attempt. It starts with some very basic definitions on
> which later definitions rely. I am also certain that there is still plenty
> of scope for improvement and revision, so comments are welcome.
> Hope this helps.
> David
> =========================================
> INFORMATION 
> Information is data of a specific type, for example, "Order Information",
> "Status Information". Information has a specific semantic meaning, e.g.
> "Order Information" is a  "request to purchase goods". The same piece of
> Information can take many different forms, for example an XML, PDF, email,
> paper letter, fax, voice, etc. 
> MESSAGE 
> A Message is a description of one or more pieces of Information combined
> with adressing information. A Message can have one or more different 
> Message
> Representations.
> MESSAGE REPRESENTATION 
> A Message Representation is a definition of the binding of a message to a
> particular form, for example each of the following are Message
> Representations: a UBL Order schema defintion within the Body of a SOAP
> Message, an EDI Order document within an ebXML Message or a spoken voice
> description of an Order. 
> MESSAGE INSTANCE 
> A Message Instance, is an instance of an actual Message Representation, 
> e.g.
> a real UBL order expressed in XML with real line items inside a SOAP
> message, etc. 
> LOCATION 
> A Location is a description of a person, place, software, application or
> service that can generate or accept Message Instances. A Location may 
> accept
> or generate Message Instances in one or more different Message
> Representations. (In WSDL this would be a Port). 
> ROLE 
> A Role is a description of a set of related Processes that serve a single
> purpose. For example a "buyer role" is the set of activities taken by a
> party, individual, business or software that are required to purchase 
> goods.
> A Role may be supported at multiple Locations. A Location may support
> multiple Roles. 
> INTERACTION 
> An Interaction is the definition of the sending of a Message from one Role
> to one other for a reason. For example: a) sending an "order message" from 
> a
> "buyer role" to a "supplier role" so that the "supplier role" can satisfy
> the order, or b) sending an order message from an "archive requesting role"
> to an "archive "archiving accepting role" so that the latter role can
> archive the order message. 
> INTERACTION INSTANCE 
> An Interaction Instance is the sending of one Message Instance from one
> Location acting in one Role to another Location acting in another Role. 
> PROCESS
> A Process is the description of a set of activities that do useful work 
> that
> occur as a result of an event such as the arrival of a Message Instance or
> the passage of time. The execution of a Process usually results in the
> generation of additional Message Instances. 
> SUB-PROCESS 
> A Sub-Process is a Process that is executed as part of and under the 
> control
> of another Process. 
> CONTROL DOMAIN 
> A Control Domain is a description of the set of Processes that are under 
> the
> management control of a single entity or organization. The Processes and 
> the
> Sub-Processes that are within a Control Domain can only be changed or
> altered by the entity that manages them. A Control Domain can support one 
> or
> more Roles. 
> COLLABORATIVE PROCESS 
> A Collaborative Process is a Process that is implemented through
> Interactions between two (or more) Roles within two (or more) Control
> Domains. 
> CHOREOGRAPHY
> A Choreography is the definition of the sequence and dependencies of the
> Interactions between Roles required to implement a Collaborative Process.
> For example the process by which a "buyer role" places an order with a
> "supplier role", or the process by which a procurement system comunicates
> order information with an ERP system. 
> ORCHESTRATION 
> An Orchestration is the definition of the sequence and dependencies of the
> Processes executed by a single Role. The Interactions that result from
> executing the Processes MUST comply with: a) any constraints implied by any
> Choreographies in which the Role takes part, and b) any constraints on
> Message Representations that Locations that receive Message Instances
> generated by the Orchestration require. 
> All the Processes and Sub-Processes within a single Orchestration 
> definition
> should be related to one another. An Orchestration definition may be used 
> to
> define the behavior of a Process that is executed by a single Role. 
> CONVERSATION 
> A Conversation is an instance of the execution of a Choreography or an
> Orchestration. 
> 
> Thoughts?
> 
> Director, Product Management, Web Services
> Commerce One
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
> 


------------------------------------------------------------------------------

---------------------------
Christoph Bussler
ChBussler@aol.com
hometown.aol.com/ChBussler/
www.google.com/search?q=bussler
www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
------------------------------------------------------------------------------

----------------------------