RE: Progressive Concreteness of Choreography binding

I'm thought I'd repond to several emails in this thread at the same time
rather than individually ...

David

************************************
Ricky's email at
http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0025.html

USE ROLE NOT PARTNER
Instead of:
	Partner declaration {
		purchaser;
		creditCheckProvider;
... use ...
	Role declaration {
		purchaser;
		creditCheckProvider;

The reason is that the entity you are talking to may be your own internal
system.

MESSAGE FAMILY VS MESSAGE TYPE vs MESSAGE
There are three separate concepts here which I don't think we should
confuse:
1. A Message. This is what physically gets sent over the wire
2. A Message Type. These are message that all have the same *physical*
structure, e.g. a UBL Order inside the a SOAP Body.
3. A Message Family or Abstract Message. A Message Family (or Abstract
Message) groups together Messages Types that server the same purpose. For
example:
  - a UBL Order inside a SOAP Body; 
  - an EDI Order inside ebXML; and 
  - a RosettaNet Order as the second MIME part in a SOAP with Attachments
style message; 

... would ALL be in the same Message Family. 

Choreographies MUST be based on Message Families if they are to be reusable.

ORCHESTRATION VS CHOREOGRAPHY
This example shows just one side so it's an orchestration rather than a
choreography that identifies all the roles ... but then this is covered in a
later email.

************************************
Ricky's email at
http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0031.html

DON'T TIE ROLES TO A SINGLE PORT
Tying a role to single port will not always work, as a role's implementation
of a process may involve multiple services where each service
accepts/generates a subset of the messages in the choreography.

************************************
Ricky's email at
http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0035.html

WHY WSDL IS PROBABLY NOT ENOUGH
In a conversation between Sanjay and Ricky they said ...
Going back to David Burdett's original message about reusing the "process"
definition across different message structure. I agree with that viewpoint
and don't see WSDL/XSDL is abstract enough. 
>However if the above was not precisely your motivation, then may I ask  Do
you have other scenarios in mind that would justify the additional layer as
necessary and not an unnecessary complexity. 
This come quite natural in my mind but I don't know enough to give you
another concrete example. But I'm sure David has a lot. 

I am absolutely certain that WS-CHOR will NOT be able to control anything to
do with the documents or message structures. There are two reasons for this:
1. We cannot seriously expect industry vertical groups like RosettaNet (to
mention one of very many) will agree to using an overall message structure
that we dictate. They will want to create their own.
2. Message/packaging standards are evolving, for example SOAP is evolving
from v1.1 to v1.2, additional extensions are being defined for Security and
Reliability by other groups.
We do not want to make our work dependent on any of this.

************************************
Tony Fletcher said at
http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0040.html

>>I was thinking along the lines of something as putting in what would be
effectively natural language comments (i.e. comments in English, Japanese,
Korean, whatever) that stated what the data was and what the nature of the
test was, and then these comments could later be replaced by the details of
the actual method of getting at the data and testing it.  However, I am
happy to follow Ricky's train of thought.<<

I prefer Tony's thinking. Expressing the *semantics* is vitally important.
This means you need to give everything (message & properties) an identifier,
e.g. "ShippingAddress" - probably expressed as a URI to make it unique, and
a description of its semantics "The address to which goods are delivered".
This way you can map the abstract to the concrete CORRECTLY!!




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

Received on Thursday, 3 April 2003 12:44:31 UTC