Progressive Concreteness of Choreography binding

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

Received on Wednesday, 2 April 2003 16:07:26 UTC