RE: choreography & orchestration must be defined in a context / s ematics and choreography

Monica

Answers/questions below ...

>>>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?<<<
No I'm not if it is actually the same iussue. However I don't understand
what you mean by "business aspects" and I don't recall the thread on the
list where this was discussed, description of "business aspects" defined, or
a resolution/vote made. Can you point me to the relevant documentation?

>>>What is a 'self contained collaboration' and how does that map to a
business collaboration?<<<
What I meant by a "self contained collaboration" was one that was not easily
divisible into smaller parts. For example a collaboration that described how
to place an order either works or it does not, you can't easily split it up.

>>>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.<<<
The **only** business aspects we are including in the model are
annotations/description elements in the model that **allows** (but does not
require) the designer of the choreography to explain what the different
parts of the model mean. Steve RT has also said he would like to see these
things in a more structured format as well. I hope you think that
documenting what you design, which is all we are taling about, is a good
idea ;)

>>>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.<<<
I need to better understand what you mean by "business aspects" before I can
respond to your point - you will also be getting the model definition very
soon.
As far as continuing development is concerned, please remember that the
model we are working on is a development by Oracle and Commerce One that we
are contributing to the group. It has no formal status within the group
until it is accepted. It is really an attempt to synthesize the many ideas
and requirements that have been raised in the group in to a form that,
subject to agreement of the group, can be the basis for the spec.

Regards

David

-----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