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 12:18:06 UTC