Re: Issue 742 - Proposal for discussion

Had a look at the example, and don't see that a "globalized trigger" would
be necessary to define this use case.

The main point in my previous response was how would you handle the issue of
the consistency between the expressions at the different roles? If the
expressions evaluated differently, then the roles would take different
paths. There would be no way to model check this for consistency, so it
would be down to the user to ensure this would not happen, which leads to a
high risk of errors being introduced.

Regards
Gary

----- Original Message ----- 
From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
To: "Gary Brown" <gary@enigmatec.net>
Cc: <public-ws-chor@w3.org>
Sent: Friday, September 17, 2004 5:12 PM
Subject: Re: Issue 742 - Proposal for discussion


> Have you looked into the FIX use-cases as I pointed out earlier?
>
> For example in FIX4.4, vol4 (march 25, 2003 draft) document, page 49:
> Take A.1.a - Filled Order as the use-case at hand (no races or other
"complicated stuff").
>
> Don't you think that the "globalized trigger" would be used to code this
use-case?
>
> --
> Nick
>
> Gary Brown wrote:
>
> > Hi
> >
> > So if I understand you correctly, each role (projected endpoint) would
apply
> > its own expression from the globalized trigger, to determine which path
it
> > takes?
> >
> > Then we may have an issue with consistency? How do we know if the list
of
> > expressions in the globalized trigger would cause the same path to be
taken
> > in all relevant roles?
> >
> > Still think a use case is required to justify this concept.
> >
> > Regards
> > Gary
> >
> > ----- Original Message -----
> > From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> > To: "Gary Brown" <gary@enigmatec.net>
> > Cc: <public-ws-chor@w3.org>
> > Sent: Thursday, September 16, 2004 5:49 PM
> > Subject: 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 Monday, 20 September 2004 08:32:34 UTC