Re: Issue 742 - Proposal for discussion

WS-CDL is about the "globalised-view" of the collaborations (per our mission statement):

A Choreography defines re-usable patterns of collaborative behavior, agreed between two or more interacting peer-to-peer parties.
A Choreography defines the re-usable patterns of behavior, as the action(s) performing the actual work, such as globalised
exchange of messages (matched send and receive operations) , when the specified globalised ordering constraints are satisfied.

-An Interact is an example of a globalised action.
-A reaction guard in a Work Unit creates globalised ordering constraints.

Note that globalised view does not mean that global-coordination machinery is needed. What it portrais is a complete view of the
big picture. The WS-CDL projection to endpoint logic will create the localised view of the message exchanges and of the ordering constraints.

IMHO, a simple use-case from FIX (even without a Race Condition) requires a globalised guard. BTW, this feature existed
in WS-CDL from the very beginning but it was not crispy clear in the text as it is now with the function extension and the new
proposed explanation text in the workunit section.

Gary Brown wrote:

> Hi Nick
>
> What is the requirement for the globalizedTrigger function?
>
> Do you have a concrete use case where this is required?
>
> Regards
> Gary
>
> ----- Original Message -----
> From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> To: <public-ws-chor@w3.org>
> Sent: Wednesday, September 15, 2004 4:54 PM
> Subject: Issue 742 - Proposal for discussion
>
> >
> > For resolving issue 742
> (http://www.w3.org/Bugs/Public/show_bug.cgi?id=742) here is my
> > proposal:
> >
> >
> > Here are the proposed changes for section 2.4.5:
> >
> > The following rules apply for a Work Unit matching:
> >
> > · When a guard condition is not specified then the Work Unit always
> matches
> > · When a repetition condition is not specified then the Work Unit is not
> matched again
> > · When a guard condition or repetition condition is specified then:
> > o One or more variables can be specified in a guard condition or
> repetition condition, using XPATH and the WS-CDL functions, as described in
> Section 10.
> > o The WS-CDL function getVariable() is used in the guard or repetition
> condition to obtain or set the information of a variable
> > o When the WS-CDL function isVariableAvailable() is used in the guard or
> repetition condition, it means that the Work Unit that specifies the guard
> condition is checking if a variable is already available at a specific Role
> or is waiting for a variable to become available at a specific Role
> > o When the WS-CDL function variablesAligned() is used in the guard or
> repetition condition, it means that the Work Unit that specifies the guard
> or repetition condition is waiting for an appropriate alignment Interaction
> to happen between the two Roles. When the variablesAligned() WS-CDL function
> is used in a guard or repetition condition, then the Relationship Type
> within the variablesAligned() MUST be the subset of the Relationship Type
> that the immediate enclosing Choreography defines. In the example below, the
> guard condition specifies that the enclosed Work Unit is waiting for an
> alignment Interaction to happen between the customer Role and the retailer
> Role:
> >
> > guard="cdl:variablesAligned(
> >                "PurchaseOrderAtBuyer", "PurchaseOrderAtSeller",
> >                "customer-retailer-relationship")"
> > o If variables are defined at different Roles, then they can be combined
> together in a guard condition or repetition condition using only the
> globalizedTrigger() WS-CDL function
> > o If variables are defined at the same Role, then they can be combined
> together in a guard condition or repetition condition using all available
> XPATH operators and the WS-CDL functions except the globalizedTrigger()
> WS-CDL function
> > o When the block attribute is set to "false", then the guard condition or
> repetition condition assumes that the variable information is currently
> available.
> > o If either the variable information is not available or the guard
> condition evaluates to "false", then the Work Unit matching fails and the
> Activity-Notation enclosed within the Work Unit is skipped.
> > o If either the variable information is not available or the repetition
> condition evaluates to "false", then the Work Unit is not matched again.
> > o When the block attribute is set to "true" and one or more variable(s)
> are not available, then the Work Unit MUST block waiting for the variable
> information to become available.
> > o When the variable information specified by the guard condition become
> available then the guard condition is evaluated. If the guard condition
> evaluates to "true", then the Work Unit is matched. If the guard condition
> evaluates to "false", then the Work Unit matching fails and the
> Activity-Notation enclosed within the Work Unit is skipped.
> > o When the variable information specified by the repetition condition
> become available then the repetition condition is evaluated. If the
> repetition condition evaluates to "true", then the Work Unit is matched
> again. If the repetition condition evaluates to "false", then the Work Unit
> is not matched again.
> >
> >
> >
> > Here are the proposed changes for section 10:
> >
> > 10 WS-CDL Supplied Functions
> > There are several functions that the WS-CDL specification supplies as
> XPATH 1.0 extension functions. These functions can be used in any XPath
> expression as long as the types are compatible.
> >
> > ...
> > xsd:any getVariable(xsd:string varName, xsd:string documentPath?,
> xsd:QName  roleName?)
> > Returns the information of the variable with name varName as a node set
> containing a single node. The second parameter is optional. When the second
> parameter is not used, this function retrieves from the variable information
> the entire document. When the second parameter is used, this function
> retrieves from the variable information, the fragment of the document at the
> provided absolute location path. The third parameter is optional. When the
> third parameter is used that the variable information MUST be available at
> the Role specified by roleName. If this parameter is not used then the Role
> is inferred from the context that this function is used.
> >
> > xsd:boolean isVariableAvailable(xsd:string varName, xsd:QName  roleName)
> > Returns "true" if the information of the variable with name varName is
> available at the Role specified by roleName. Returns "false" otherwise.
> >
> > xsd:boolean variablesAligned(xsd:string varName, xsd:string withVarName,
> >                                                xsd:QName
> relationshipName)
> > Returns "true" if within a Relationship specified by relationshipName the
> variable with name varName residing at the first Role of the Relationship
> has aligned its information with the variable named withVarName residing at
> the second Role of the Relationship.
> >
> > xsd:boolean globalizedTrigger(xsd:string expression, xsd:string roleName,
> xsd:string expression2, xsd:string roleName2, .)
> > Combines expressions that include variables that are defined at different
> Roles.
> >
> >
> >
> > --
> > Nick
> >
> >
> >
> >
> >
> >

Received on Thursday, 16 September 2004 16:49:55 UTC