- From: Ricky Ho <riho@cisco.com>
- Date: Wed, 02 Apr 2003 18:24:02 -0800
- To: Assaf Arkin <arkin@intalio.com>
- Cc: public-ws-chor@w3.org
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 Wednesday, 2 April 2003 21:24:26 UTC