W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2006

Re: Latest primer

From: Greg Ritzinger <GRitzinger@novell.com>
Date: Thu, 09 Feb 2006 11:53:14 -0700
Message-Id: <43EB4931.3EE9.0048.0@novell.com>
To: "Gary Brown" <gary@pi4tech.com>, "Steve Ross-Talbot" <steve@pi4tech.com>, "Monica J Martin" <monica.martin@sun.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
All, 

I like the degenerate case, it provides a nice intro. 

-Greg 


Comments and editorial suggestions: 

section 2 
It is also important to understand that WS-CDL does not distinguish
between observable messages from applications, that might be considered
as application or business messages, or from the infrastructure upon
which an application is based, that might be considered as some form of
signal. 
It is also important to understand that WS-CDL does not distinguish
between observable messages from applications, that might be considered
as application or business messages, from the infrastructure upon which
an application is based, that might be considered as some form of
signal. 


section 3.1 
Isn't the bartering example really a bargaining example? (or haggling) 

section 3.3.1 
Each exchange names names the type of the thing to be exchanged and the
direction of the exchange (e.g. a request, a response, or a fault). 
Each exchange names the type of the thing to be exchanged and the
direction of the exchange (e.g. a request, a response, or a fault). 

In order to describe this more fully we shall have to define the
channelType for the channelVariable called Buyer2SellerC, in the
interaction, and then define the information types tns:QuoteRequestType,
tns:QuoteResponseType and tns:QuoteResponseFaultType for the variables ,
 and  respectively. 
In order to describe this more fully, we have to define the channelType
for the channelVariable in the interaction called Buyer2SellerC, and
then define the information types tns:QuoteRequestType,
tns:QuoteResponseType and tns:QuoteResponseFaultType. 


3.3.6 
The tokens we define will also be used to refer to a service reference,
that is a url, t for a web service. 
The tokens we define will also be used to refer to a service reference,
that is a url, for a web service. 

3.3.7 Channels 

Finally, having defined our roles, information types, tokens and
locatorswe are in a position to define our channel. 
Finally, having defined our roles, information types, tokens and
locators we are in a position to define our channels. 

To define a channel we need to name it, we need to, optionally, describe
it, we need to tell it which role realises it's behavioral interface
(the role we send things to and receive things from). 
To define a channel we need to name it, optionally describe it, and to
specify which role realises it's behavioral interface (the role we send
things to and receive things from). 

The abstract syntax of a channel definition is provided below, we shall
look at the other part of a channel type definition in later sections: 
The abstract syntax of a channel definition is provided below. We shall
look at the other part of a channel type definition in later sections: 

3.3.8 
Because this is a fault we also declare that the exchange has a
faultName, in this case we have called the faultName InvalidProduct to
denote that the product which is the subject of the quote request is
invalid in some way. 
Because this is a fault, we also declare that the exchange has a
faultName. In this case we have called the faultName InvalidProduct to
denote that the product which is the subject of the quote request is
invalid in some way. 

4.1 
But they very much variables in their own right and at their own roles. 
But they are very much variables in their own right in the roles they
are defined at. 

4.2 
These constructs are only performed is the workunits attributes enable
them to be performed. 
These constructs are only performed if the workunit's attributes enable
them to be performed. 

4.2.1 
It would be helpful if you showed where the varaibles used in the
workunit are declared. 

4.2.2 
domethink 
something 

4.3 
Credit Check returns a fault which implies credit failure and this is
dealt with in an exception block and you raise cause exception to
interrupt the flow of the choreo. The Exception handler returns a
message to the buyer to let them know that the order has been cancelled 
Credit Check returns a fault, which implies credit failure, and this is
dealt with in an exception block and you raise an exception to interrupt
the flow of the choreography. The Exception handler returns a message to
the buyer to let them know that the order has been cancelled. 
Received on Thursday, 9 February 2006 18:53:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:44 GMT