- From: Monica J. Martin <Monica.Martin@Sun.COM>
- Date: Wed, 03 Dec 2003 11:13:08 -0700
- To: Ugo Corda <UCorda@SeeBeyond.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, Jean-Jacques Dubray <jeanjadu@Attachmate.com>, Steve Ross-Talbot <steve@enigmatec.net>, public-ws-chor@w3.org, Haugen Robert <Robert.Haugen@choreology.com>, "Yunker, John" <yunker@amazon.com>, Jon Pyke <jpyke@dial.pipex.com>
Ugo Corda wrote: >Monica, >I share your concerns. > >It is very easy for a W3C WG to drag the resolution of some issues forever, since we strive for consensus. But let's keep in mind that it is that type of behavior that in the end can sink the WG. > > mm1: This is exactly my point as I believed this item of discussion re: business aspects had been decided. Has that changed? >Ugo > > > >>-----Original Message----- >>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] >>Sent: Wednesday, December 03, 2003 9:25 AM >>To: Burdett, David >>Cc: Ugo Corda; Jean-Jacques Dubray; Steve Ross-Talbot; >>public-ws-chor@w3.org; Haugen Robert; Yunker, John; Jon Pyke >>Subject: Re: choreography & orchestration must be defined in >>a context / >>s ematics and choreography >> >> >>Burdett, David wrote: >> >> >> >>>JJ >>> >>>I think that I don't completely understand what you're saying. >>> >>>You ***could*** say that any protocol is built on layers >>> >>> >>where at the >> >> >>>top, you have some kind of business interaction between the >>>participants involved and at the very bottom, you have bits >>> >>> >>going over >> >> >>>copper. In between you have layers of protocol which, through the >>>abstraction each layer provides, progressively make it easier to >>>describe what you want to do without having to define **all** the >>>detail as they have been abstracted down into a lower layer >>> >>> >>in the stack. >> >> >>> >>>That said, I do think that the understanding the layering >>> >>> >>is important >> >> >>>and would include: >>> >>>1. A "business interaction" layer that expresses the sequence and >>>condtion in which "business" interactions will occur, e.g. >>> >>> >>you have a >> >> >>>business "request for quote" function followed by the >>> >>> >>placement of an >> >> >>>order. Note that use of the term "business interaction" is pretty >>>arbitrary ... you could also have an even higher layer such as >>>"procure raw materials" >>>2. A "business choreography" layer where you carry out >>> >>> >>individual self >> >> >>>contained collaborations that are not easily divisible into smaller >>>components, e.g. place an order, or conduct an RFQ process >>>3. A "signals" layer, where you include various additional >>> >>> >>exchanges >> >> >>>of information where you are providing updates on the progress (or >>>not) of the higher layer, e.g order received, order checked >>> >>> >>OK, order >> >> >>>processing started >>>4. An "MEP layer", where you are working at various >>> >>> >>primitve message >> >> >>>sequences, e.g. one-way and request-response >>>5. A "Protocol layer" where you are providing additional >>> >>> >>functionality >> >> >>>to the delivery of individual message, e.g. sending each >>> >>> >>message in a >> >> >>>MEP reliably which will require the sending of additional messages >>>e.g. reliable messaging retries >>>6. The "Single message" layer where you are sending an individual >>>message, e.g. using HTTP or SMPT. >>>7. The "Networking" layer, where you are using protocols such as >>>TCP/IP to deliver a single piece or part of a piece of information >>>8. All the layers below networking down to bits over the wire! >>> >>>Having said that, I think the scope of choreography >>> >>> >>language includes >> >> >>>layers 1 and 2 but should also allow (but not necessarily require) >>>expression of layers 3 through 6. This means, for example that you >>>should be able to, but needn't, be able to express a Reliable >>>Messaging protocol using the CDL if you wanted to. >>> >>> >>> >>mm1: David, I believe the team had already discussed that the >>business >>aspects were outside of the scope of our effort. Are you >>indicating we >>are revisiting that issue? What is a 'self contained >>collaboration' and >>how does that map to a business collaboration? If we are >>interested in >>the control (or data flow, for Nick Kavantzas benefit) for the >>choreography definition to support is one thing. To infer we >>take on the >>business aspects of such an interchange is quite another. If you are >>basing the metamodel on these assumptions, I would request >>there be more >>discussion in the group prior to the development continuing any >>further. Thanks. >> >> >> >>>So where do MEPs fit into all this? >>> >>>I think that it is worth while: >>>1. Recognizing the MEPs that are widely deployed - one-way and >>>request-response >>>2. Allow additional MEPs to be added as and when they become popular >>>3. Allow more complex protocols to be built on top of MEPs >>>4. Allow the implementation of MEPs to utilize lower level >>> >>> >>protocols >> >> >>>such as reliable messaging, etc. >>> >>>Hope this helps. >>> >>>David >>> >>> >> >> >> > > >
Received on Wednesday, 3 December 2003 13:06:09 UTC