Raise Exception activity (Re: Preface to Coordinated Choreography proposals)

In the NYC F2F I've promised a solution that addresses "Proposal 2: Add
<throw/> or <raise/> activity to trigger exception block"
as requested by Choreology.

Here it is:


***Oracle's proposal for providing a Raise Exception activity***

We suggest using assign to raise an exception. This is consistent with the
syntax
for throwing an exception in a record element in an interaction.


Proposal

In section 2.5.4 Assign Variables perform the following changes. (We assume
the
changes are based on Nov 11, 2004 version of the spec.)
Changes are enclosed by **.


1.1.1. Assigning Variables
Assign activity is used to create or change and then make available within
one Role, the value of one Variable using the value of another Variable or
expression. **The assign activity MAY also be used to cause an exception at
a Role.**

The syntax of the assign construct is:

<assign  role="qname">
   <copy  name="ncname" **causeException="true|false"?**>
      <source  variable="XPath-expression"?|expression="Xpath-expression"?
/>
      <target  variable="XPath-expression" />
   </copy>+
</assign>

A copy element within the assign element creates or changes at a Role the
Variable defined by the target element using the Variable or expression
defined
by the source element at the same Role. Within the copy element, the
attribute
name is used for specifying a name for each copy element declared within
this
assign activity.

The following rules apply to assignment:
  The source MUST define either a variable attribute or an expression
attribute:
o When the source defines an expression attribute this MUST contain
expressions, as defined in Section 2.4.3. The resulting type of the
defined expression MUST be compatible with the target Variable
type
o When the source defines a Variable, then the source and the target
Variable MUST be of compatible type
o When the source defines a Variable, then the source and the target
Variable MUST be defined at the same Role
  When the attribute variable is defined it MUST use only the WS-CDL
function getVariable
  The target Variable MUST NOT be defined with the attribute silent set to
"true"
  When two or more copy elements belong to the same assign element, then
they are performed in the order in which they are defined.
  If there are two or more copy elements specified within an assign, then
all
copy operations MUST complete successfully for the assign to complete
successfully. Otherwise, none of the Variables specified in the target
attribute will be affected

  **The attribute causeException MAY be set to "true" in a copy element if
the
target Variable is an Exception Variable
  At most one copy element MAY have the attribute causeException set to
"true"
  When the attribute causeException is set to "true" in a copy element, the
Role
gets into Exception state after the assign activity has completed**



--
Nick


----- Original Message ----- 
From: "Haugen Robert" <Robert.Haugen@choreology.com>
To: <public-ws-chor@w3.org>
Sent: Saturday, October 30, 2004 3:40 AM
Subject: Preface to Coordinated Choreography proposals


> At the last face-to-face meeting, Choreology presented six proposals for
> coordination of choreographies:
>
> Coordinating a single-level choreography:
>
> * Proposal 1: Add "coordination" attribute to choreography.
>
> * Proposal 2: Add <throw/> or <raise/> activity to trigger exception
> block.
>
> Coordinating inner choreographies:
>
> * Proposal 3: Allow multiple finalizers, distinguished by attribute
> "case".
>
> * Proposal 4: Add <finalize /> activity to identify when to fire which
> finalizer.
>
> * Proposal 5: Add attribute to <perform /> to label inner choreography
> instance.
>
> Composing or "overlaying" coordination:
>
> * Proposal 6: Add to the composition mechanism (perform) the ability to
> "overlay" choreographies.  (This proposal has been changed, in
> collaboration with Gary Brown, from perform "overlay" to a kind of
> choreography inheritance.)
>
> We promised WS-CDL spec language for each of the proposals.
>
> Separate messages will be coming up shortly for proposals 1, 3, 4, and
> 6.
>
> Nick has already proposed a mechanism for proposal 2.
>
> We do not have spec language for proposal 5, because the sense of the
> F2F meeting was for a choreography-instance-capturing variable, the use
> cases for which raised some complications. Next week we'll initiate a
> discussion of those complications.
>
>
> Choreology Anti virus scan completed

Received on Monday, 15 November 2004 22:00:28 UTC