RE: Progressive Concreteness of Choreography binding

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.

Best Regards     Tony
A M Fletcher
 
Cohesions 1.0 (TM)
 
Business transaction management software for application coordination
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
Sent: 03 April 2003 03:24
To: Assaf Arkin
Cc: public-ws-chor@w3.org
Subject: Re: Progressive Concreteness of Choreography binding



Let me try to rewrite the code using your suggested model and then see
if 
there are values of indirection.  I'm assuming you are questioning the 
value of separating the implementation binding from abstract process.  I

assume you are OK with the "Protocol Binding" and "Address Binding".

PROCESS
=========
In this model (which WSCI and BPEL based on), the message exchange is
all 
expressed in terms of WSDL operations.
So there is no need to define named messages.  The process itself
directly 
point to the WSDL operation being invoked.
Message properties are defined as an XPATH extract from the message
type.

Orchestration POHandlingProcess {
         Partner declaration {
                 mySelf --> PortType POHandlingPT  // contains a one-way

"submitPO" operation
                 purchaser --> PortType POCallbackPT // contains 2
one-way 
"confirmPO", "rejectPO" operations
                 creditCheckProvider --> CreditCheckPT // contains a 
request/reply "check" operation
         }

         Message Property declaration {
                 float PO.dollarAmount = XPATH(//totalAmount/@amount) of

request of (PortType = "POHandlingPT", Operation = "submitPO",
Part="po");
                 Customer PO.cust = XPATH(//customer) of request of 
(PortType = "POHandlingPT", Operation = "submitPO", Part="po");
                 Customer CreditCheckRequest.cust = XPATH(//customer) of

request of (PortType = "CreditCheckPT", Operation = "check", 
Part="customerInfo");
                 int CreditCheckResponse.rating = XPATH("//rank") of 
response of (PortType = "CreditCheckPT", Operation = "check",
Part="Return");
         }

         Process {
                 receive request of (PortType = "POHandlingPT",
Operation = 
"submitPO", Part="po") from partner "purchaser"
                 if ("PO.dollarAmount" > 100K) {
                         assign "PO.cust" to "CreditCheckRequest.cust";
                         send request of (PortType = "CreditCheckPT", 
Operation = "check", Part="customerInfo") to partner
"creditCheckProvider";
                         receive response of (PortType =
"CreditCheckPT", 
Operation = "check", Part="customerInfo") from partner
"creditCheckProvider";
                         if ("CreditCheckResponse.rating" > 3) {
                                 send request of (PortType = 
"POCallbackPT", Operation = "confirmPO", Part="poConfirmation") to
partner 
"purchaser"
                         } else {
                                 send request of (PortType = 
"POCallbackPT", Operation = "rejectPO", Part="poRejection") to partner 
"purchaser"
                         }
                 }
                 send request of (PortType = "POCallbackPT", Operation =

"confirmPO", Part="poConfirmation") to partner "purchaser"
         }
}

Is this a correct representation of your suggestion ?

My other comments are embedded ...

At 02:21 PM 4/2/2003 -0800, Assaf Arkin wrote:
>I am in support of the use of properties, but I don't understand the 
>level
>of indirection or what it brings to the table.
>
>Some properties are interesting to express in the context of a
>choreography. Rules that affect the flow (as given in this example), 
>partners that are communicated, time-outs that are communicated (as 
>opposed to pre-decided), etc.
>
>Let's say that service seller X decides to extract the property in a 
>very
>specific way that is different from how service seller Y extracts it.
Any 
>buyer would have to understand the different ways in which it is
extracted 
>in order to put that value in the message to begin with. So there's 
>another level of complexity here that affects all the buyers.

For a particular buyer talk to a particular seller, he needs to know
1) The abstract process A1
2) The implementation binding B1
3) The protocol binding C1
4) The address binding D1

But I don't see how eliminating the layer 2 will help.  I think it is
even 
worse.  Lets say the seller want to talk to another buyer who use EDI 
rather than web services, then exchanging ...
1) The abstract process A1
2) The implementation binding B2
3) The protocol binding C2
4) The address binding D2

is better than exchanging
1) The process A2
2) The protocol binding C2
3) The address binding D2


>It's much easier if you write the choreography such that all seller
>services (X, Y, future ones) would extract that information in much the

>same way, e.g. by referencing the abstract (not concrete) message. That

>allows all buyers to build their side of the choreography in a generic
way 
>because they understand the abstract requirements regardless of which 
>specific service they end up talking to.
>
>In practice, that's how I would write choreographies. Write only the
>abstract parts that do not depend on the specific service you end up 
>using, so you can have one buyer that talks to any potential seller and

>vice versa. If I follow that best practice, I don't see any value for
this 
>level of indirection.

I completely agree with you that the extra indirection is unnecessary if

XML Schema and WSDL are *ABSTRACT ENOUGH*. I post some questions about
that 
in the following but haven't got any feedback 
yet.  http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0007.html

Since I'm not sure, so I propose this extra indirection layer that I
know 
for sure will work.

Rgds, Ricky


>Comments?
>
>arkin
>
>Ricky Ho wrote:
>
>>
>>Continuing our discussion of "abstract message".  I want to show an 
>>how
>>we can start with a very abstract definition at the choreography and 
>>progressively add concrete binding to that.
>>
>>Lets define a orchestration flow that is independent of message type 
>>and
>>only have the message properties concept.
>>
>>ABSTRACT PROCESS
>>===================
>>At the very beginning, the process declares the "NAMES" of all 
>>messages
>>that it may send or receive.  It also declares the "NAMES" and "TYPES"
of 
>>message properties, but it doesn't say how the message properties is 
>>extracted from the message.
>>
>>Within the process flow, it uses only the named "message" and "message
>>properties".
>>
>>
>>Orchestration POHandlingProcess {
>>     Partner declaration {
>>         purchaser;
>>         creditCheckProvider;
>>     }
>>
>>     Message declaration { // all are "typeless"
>>         PO;
>>         POConfirmation;
>>         PORejection;
>>         CreditCheckRequest;
>>         CreditCheckResponse;
>>     }
>>
>>     Message Property declaration { // all are "typed"
>>         float PO.dollarAmount
>>         Customer PO.cust
>>         Customer CreditCheckRequest.cust
>>         int CreditCheckResponse.rating
>>     }
>>
>>     Process {
>>         receive "PO" from partner "purchaser"
>>         if ("PO.dollarAmount" > 100K) {
>>             assign "PO.cust" to "CreditCheckRequest.cust";
>>             send "CreditCheckRequest" to partner
"creditCheckProvider";
>>             receive "CreditCheckResponse" from partner
>> "creditCheckProvider";
>>             if ("CreditCheckResponse.rating" > 3) {
>>                 send "POConfirmation" to partner "purchaser"
>>             } else {
>>                 send "PORejection" to partner "purchaser"
>>             }
>>         }
>>         send "POConfirmation" to partner "purchaser"
>>     }
>>}
>>
>>
>>IMPLEMENTATION BINDING
>>======================
>>The WSDL implementation binding basically map the partner into a
>>particular WSDL PortType.  Then it maps each named message (defined in

>>abstract process) into the WSDL PortType/Operation/Part (can be either

>>the request or the response).  Finally, it defines the message
properties 
>>in terms of XPATH which extract the data from the corresponding
message.
>>
>>
>>Implementation Binding for "POHandlingProcess" {
>>     Partner binding {
>>         mySelf --> PortType POHandlingPT  // contains a one-way
>> "submitPO" operation
>>         purchaser --> PortType POCallbackPT // contains 2 one-way 
>> "confirmPO", "rejectPO" operations
>>         creditCheckProvider --> CreditCheckPT // contains a 
>> request/reply "check" operation
>>     }
>>
>>     Message binding {
>>         PO --> From request of (PortType = "POHandlingPT", Operation 
>> =
>> "submitPO", Part="po")
>>         POConfirmation --> To request of (PortType = "POCallbackPT", 
>> Operation = "confirmPO", Part="poConfirmation");
>>         PORejection --> To request of (PortType = "POCallbackPT", 
>> Operation = "rejectPO", Part="poRejection");
>>         CreditCheckRequest --> To request of (PortType = 
>> "CreditCheckPT", Operation = "check", Part="customerInfo");
>>         CreditCheckResponse --> From response of (PortType = 
>> "CreditCheckPT", Operation = "check", Part="Return");
>>     }
>>
>>     Message Property binding {
>>         PO.dollarAmount = XPATH(//totalAmount/@amount);
>>         Customer PO.cust = XPATH(//customer);
>>         Customer CreditCheckRequest.cust = XPATH(//customer);
>>         int CreditCheckResponse.rating = XPATH("//rank");
>>     }
>>}
>>
>>
>>PROTOCOL (ON-THE-WIRE-MESSAGE) BINDING 
>>======================================
>>This binding defines how the abstract message defined in WSDL is
>>serialized on the wire, such as which parts goes to SOAP header and
which 
>>goes to SOAP body.
>>WSDL binding covers this.
>>
>>
>>ADDRESS BINDING
>>================
>>For dynamic address resolution, this defines the service provider
>>endpoint resolution mechanism.  For static address resolution, this 
>>defines the actual service endpoint location.
>>
>>
>>Rgds,
>>
>>Ricky
>
>
>
>--
>"Those who can, do; those who can't, make screenshots"
>
>----------------------------------------------------------------------
>Assaf Arkin                                          arkin@intalio.com
>Intalio Inc.                                           www.intalio.com
>The Business Process Management Company                 (650) 577 4700
>
>
>This message is intended only for the use of the Addressee and may 
>contain information that is PRIVILEGED and CONFIDENTIAL. If you are not

>the intended recipient, dissemination of this communication is 
>prohibited. If you have received this communication in error, please 
>erase all copies of the message and its attachments and notify us 
>immediately.
>
>

Received on Thursday, 3 April 2003 07:22:25 UTC