Re: Progressive Concreteness of Choreography binding

Burdett, David wrote:

>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.
>
+1

>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. 
>  
>
What about the possibility of having an abstract message type, 
independent of particular protocol or encoding, and then a message 
family as a set of message types that are specific to given 
protocol/encoding and are all expressions of the abstract message type?


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

>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.
>  
>
I think it's useful to have partial definitions in example because it's 
easier to focus on the point we want to discuss.

So in this case Ricky ommitted the message definition, the operation 
definition and also the definition of the other partners. We can guess 
what they look like, but writing them down is not helpful to discuss the 
point he was raising. I don't see it as an orchestration, I see it as 
part of the full choreography specification, but only the part that is 
important to write down for this specific discussion.


>************************************
>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.
>
Absolutely true, but helpful for making a simple example.

However, there is indeed an issue here. When you communicate 
participants you need to communicate more than just one end-point since 
a participant (role) may elect to use multiple services. My preference 
is for sending WSDL service definitions (not the abstract part) around 
since they can define multiple services, but something that constrains 
WSDL to just service definitions and even extends them would be even 
better. (For example, WS-Addressing and WS-Callback would be a good 
place to start)


arkin

Received on Thursday, 3 April 2003 13:35:50 UTC