This file last updated 0:50 6 Jan 2005 (UTC)
This is the issues list for the OASIS Web Services Business Process Execution Language Technical Committee. The issues list is posted as a TC document to the OASIS WSBPEL TC pages on a regular basis (if it has changed). The current edition, as a TC document, is the most recent version of the document wsbpel_issues_list.html in the "Issues" folder of the WSBPEL TC document list - the uri for this document includes the document number generated by the upload process. The list editor's working copy, which will always at least as recent as the formal upload and will usually include later updates, is available at this constant URI.
Procedures for handling of issues are defined in the issues process document, and the procedure for issues submitted after 15 August 2004. Potential new issues should be submitted as an email to the issue list editor (peter.furniss@choreology.com), with a subject line of "New issue - <proposed title>. If this email follows the pattern described in the issues process document, appendices 5 and 6, it will be helpful. The new issue will be announced on the main wsbpel TC list with a status of "received". In accordance with procedure for issues submitted after 15 August 2004 the TC will decide whether to accept the issue for consideration (when the status will become "open") or not. If messages discussing an issue (including whether the issue should be accepted) have subject lines that begin Issue - <issue-id> - , or are replies to such, the archived copy of that message on the wsbpel list should be picked up by the software that revises this list and added to the Links section of the issue.
IssueID | Title | Status | Proposed resolution | Vote announcement |
---|---|---|---|---|
Issue 2 | Sub-Functions | resolution proposed | Ivana Trickovic, 24 Nov 2004 | |
Issue 9 | Static analysis | resolution proposed | Yaron Y. Goland, 17 Sep 2004 | |
Issue 11.1 | Making <assign> truly extensible | resolution proposed | ||
Issue 12 | XML types and WS Interactions | resolution proposed | Yaron Y. Goland, 10 Dec 2004 | |
Issue 81 | Are start activities that aren't createInstance activities legal? | resolution proposed | Yaron Y. Goland, 1 Dec 2004 | |
Issue 82 | description of abstract processes in spec | resolution proposed | Peter Furniss, 14 Dec 2004 | |
Issue 91 | Nested Activities in Abstract Processes | resolution proposed | Dieter Koenig1, 19 Feb 2004 | waiting on issue 107 |
Issue 92 | Mandatory & Optional BPEL Extensibility | resolution proposed | Dieter Koenig1, 21 Dec 2004 | |
Issue 97 | Optional Variable References in Abstract Processes | resolution proposed | Dieter Koenig1, 19 Feb 2004 | waiting on issue 107 |
Issue 99 | Triggering activities for abstract processes | resolution proposed | Ivana Trickovic, 10 Mar 2004 | waiting on issue 107 |
Issue 103 | Standardizing $varName syntax for XPath to refer to a BPEL variable | resolution proposed | Yaron Y. Goland, 17 Sep 2004 | |
Issue 107 | Opacity and the meaning of nothingness in abstract processes | resolution proposed | Peter Furniss, 14 Dec 2004 | |
Issue 125 | Literal and Expression Assignment Semantics | resolution proposed | Yuzo Fujishima, 6 Dec 2004 | |
Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | resolution proposed | Yaron Y. Goland, 30 Jun 2004 | |
Issue 160 | facilities to define XML schema validation boundary | resolution proposed | Alex Yiu, 15 Dec 2004 | |
Issue 169 | transition condition error handling clarification | resolution proposed | Yuzo Fujishima, 7 Dec 2004 |
IssueID | Title | Status | In spec | Date added | Last changed |
---|---|---|---|---|---|
Issue 11 | Query in <to> close should allow assigning to new locations | open | 25 Jun 2003 | 5 Jan 2005 | |
Issue 11.1 | Making <assign> truly extensible | resolution proposed | 5 Jan 2005 | 5 Jan 2005 | |
Issue 92 | Mandatory & Optional BPEL Extensibility | resolution proposed | 22 Jan 2004 | 3 Jan 2005 | |
Issue 124 | PartnerLink/URI setter/getter function | resolved | no change | 18 May 2004 | 28 Dec 2004 |
Issue 130 | Remove Partner Element | resolved | no change | 6 Jul 2004 | 6 Jan 2005 |
Category | IssueID | Title | Champion |
---|---|---|---|
Abstract processes | Issue 82 | description of abstract processes in spec | |
Abstract processes | Issue 91 | Nested Activities in Abstract Processes | |
Abstract processes | Issue 97 | Optional Variable References in Abstract Processes | |
Abstract processes | Issue 99 | Triggering activities for abstract processes | |
Abstract processes | Issue 107 | Opacity and the meaning of nothingness in abstract processes | |
Abstract processes | Issue 109 | Compatibility between Abstract and Executable Processes | |
Asynchronous operations | Issue 4 | Dynamic parallel processing | Ivana Trickovic |
Asynchronous operations | Issue 63 | Support of Array | |
Asynchronous operations | Issue 147 | Serial and Parallel For-Each | |
Correlation | Issue 11 | Query in <to> close should allow assigning to new locations | Danny van der Rijn |
Correlation | Issue 11.1 | Making <assign> truly extensible | Alex Yiu |
Correlation | Issue 26 | Correlating use with receive/reply | Assaf Arkin |
Correlation | Issue 96 | Engine-managed correlation sets | |
Correlation | Issue 120 | What are the semantics when an initial <receive> has no correlation set? | |
Correlation | Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | |
Data Handling | Issue 156 | Cleaning Up XPATH in BPEL | |
Data Handling | Issue 157 | Cleaning up copy | |
Data handling | Issue 11 | Query in <to> close should allow assigning to new locations | Danny van der Rijn |
Data handling | Issue 11.1 | Making <assign> truly extensible | Alex Yiu |
Data handling | Issue 12 | XML types and WS Interactions | |
Data handling | Issue 51 | Section 9.3.1 & Schema Validation | |
Data handling | Issue 63 | Support of Array | |
Data handling | Issue 102 | Fixing Typos in getVariable*() in BPEL examples | |
Data handling | Issue 103 | Standardizing $varName syntax for XPath to refer to a BPEL variable | |
Data handling | Issue 112 | Input/Output Elements on Messaging Activities | |
Data handling | Issue 153 | getVariableData xpath function should return node sets of any size | |
Event handling | Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | |
Expressions | Issue 6 | Completion Condition | |
Expressions | Issue 28 | Simplification of join condition | Assaf Arkin |
Expressions | Issue 29 | Simplification of XPath expressions | Assaf Arkin |
Expressions | Issue 51 | Section 9.3.1 & Schema Validation | |
Expressions | Issue 125 | Literal and Expression Assignment Semantics | |
Fault handling | Issue 133 | Access to unnamed fault bodies | |
Fault handling | Issue 141 | Standard Fault Format | |
Fault handling | Issue 180 | Clarification of WSDL fault declarations and Reply in BPEL | |
Partner links | Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | |
Partner links | Issue 139 | PartnerLink Semantics | |
Process lifecycle | Issue 81 | Are start activities that aren't createInstance activities legal? | |
Related Standards | Issue 180 | Clarification of WSDL fault declarations and Reply in BPEL | |
Related standards | Issue 86 | Addressing Interoperability / Portability - SOAP 1.2 | |
Related standards | Issue 154 | doc/lit & multiple body parts | |
Related standards | Issue 174 | Are multiple imports with the same namespace allowed? | |
Scopes | Issue 119 | Transition Conditions and Invoke Fault Handlers | |
Specification editing | Issue 144 | Defining Undefined Behaviors | |
Specification editing | Issue 148 | Explicitly state that solicit/response & notification aren't supported by BPEL | |
Specification editing | Issue 158 | Changing Spec Structure from 3 part to 2 part | |
Specification editing | Issue 159 | Ordering specification sections by dependency | |
State management | Issue 2 | Sub-Functions | Ivana Trickovic |
State management | Issue 6 | Completion Condition | |
State management | Issue 28 | Simplification of join condition | Assaf Arkin |
State management | Issue 81 | Are start activities that aren't createInstance activities legal? | |
State management | Issue 119 | Transition Conditions and Invoke Fault Handlers | |
State management | Issue 142 | Break & Continue | |
State management | Issue 147 | Serial and Parallel For-Each | |
Subprocesses | Issue 2 | Sub-Functions | Ivana Trickovic |
Syntax & semantics | Issue 177 | Inconsistent optional/required nature of @Variable on onMessage, onEvent and Receive | |
Syntax and validation | Issue 9 | Static analysis | |
Syntax and validation | Issue 88 | Import Errata | |
Syntax and validation | Issue 92 | Mandatory & Optional BPEL Extensibility | |
Syntax and validation | Issue 110 | Issues with the Pattern Attribute | |
Syntax and validation | Issue 111 | Extension Activities | |
Syntax and validation | Issue 125 | Literal and Expression Assignment Semantics | |
Syntax and validation | Issue 132 | In-line Variable Initialization | |
Syntax and validation | Issue 136 | If-Then-Else Activity | |
Syntax and validation | Issue 138 | Properties of type element | |
Syntax and validation | Issue 140 | Until Activity | |
Syntax and validation | Issue 142 | Break & Continue | |
Syntax and validation | Issue 143 | StaticSwitch Activity | |
Syntax and validation | Issue 147 | Serial and Parallel For-Each | |
Syntax and validation | Issue 150 | Message variables on invoke and reply | |
Syntax and validation | Issue 160 | facilities to define XML schema validation boundary | |
Syntax and validation | Issue 163 | languageExecutionFault | |
Syntax and validation | Issue 181 | uninitializedVariable cleanup | |
syntax & semantics | Issue 169 | transition condition error handling clarification | Yuzo Fujishima |
IssueID | Title | Date added | Last changed | Champion |
---|---|---|---|---|
Issue 4 | Dynamic parallel processing | 25 Jun 2003 | 2 Jun 2004 | Ivana Trickovic |
Issue 9 | Static analysis | 25 Jun 2003 | 17 Sep 2004 | |
Issue 26 | Correlating use with receive/reply | 26 Jun 2003 | 15 Jan 2004 | Assaf Arkin |
Issue 28 | Simplification of join condition | 26 Jun 2003 | 20 Oct 2003 | Assaf Arkin |
Issue 29 | Simplification of XPath expressions | 26 Jun 2003 | 21 Oct 2003 | Assaf Arkin |
Issue 63 | Support of Array | 15 Sep 2003 | 22 Apr 2004 | |
Issue 86 | Addressing Interoperability / Portability - SOAP 1.2 | 25 Nov 2003 | 27 Nov 2003 | |
Issue 88 | Import Errata | 3 Dec 2003 | 23 Jun 2004 | |
Issue 91 | Nested Activities in Abstract Processes | 22 Jan 2004 | 29 Apr 2004 | |
Issue 96 | Engine-managed correlation sets | 3 Feb 2004 | 22 Jun 2004 | |
Issue 97 | Optional Variable References in Abstract Processes | 10 Feb 2004 | 29 Apr 2004 | |
Issue 99 | Triggering activities for abstract processes | 3 Mar 2004 | 23 Jun 2004 | |
Issue 102 | Fixing Typos in getVariable*() in BPEL examples | 9 Mar 2004 | 22 Apr 2004 | |
Issue 109 | Compatibility between Abstract and Executable Processes | 24 Mar 2004 | 17 Aug 2004 | |
Issue 111 | Extension Activities | 25 Mar 2004 | 25 Mar 2004 | |
Issue 112 | Input/Output Elements on Messaging Activities | 25 Mar 2004 | 24 Jun 2004 | |
Issue 120 | What are the semantics when an initial <receive> has no correlation set? | 19 Apr 2004 | 27 Aug 2004 | |
Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | 10 Jun 2004 | 15 Jul 2004 | |
Issue 132 | In-line Variable Initialization | 15 Jul 2004 | 16 Jul 2004 | |
Issue 133 | Access to unnamed fault bodies | 15 Jul 2004 | 16 Jul 2004 | |
Issue 136 | If-Then-Else Activity | 15 Jul 2004 | 16 Jul 2004 | |
Issue 138 | Properties of type element | 15 Jul 2004 | 15 Sep 2004 | |
Issue 139 | PartnerLink Semantics | 15 Jul 2004 | 4 Aug 2004 | |
Issue 140 | Until Activity | 15 Jul 2004 | 16 Jul 2004 | |
Issue 141 | Standard Fault Format | 15 Jul 2004 | 16 Jul 2004 | |
Issue 143 | StaticSwitch Activity | 15 Jul 2004 | 16 Jul 2004 | |
Issue 144 | Defining Undefined Behaviors | 15 Jul 2004 | 16 Jul 2004 | |
Issue 147 | Serial and Parallel For-Each | 16 Jul 2004 | 20 Sep 2004 | |
Issue 148 | Explicitly state that solicit/response & notification aren't supported by BPEL | 17 Jul 2004 | 17 Jul 2004 | |
Issue 150 | Message variables on invoke and reply | 20 Jul 2004 | 21 Jul 2004 | |
Issue 153 | getVariableData xpath function should return node sets of any size | 27 Jul 2004 | 27 Jul 2004 | |
Issue 154 | doc/lit & multiple body parts | 28 Jul 2004 | 30 Jul 2004 | |
Issue 156 | Cleaning Up XPATH in BPEL | 31 Jul 2004 | 31 Jul 2004 | |
Issue 157 | Cleaning up copy | 31 Jul 2004 | 31 Jul 2004 | |
Issue 158 | Changing Spec Structure from 3 part to 2 part | 4 Aug 2004 | 7 Aug 2004 | |
Issue 159 | Ordering specification sections by dependency | 4 Aug 2004 | 6 Aug 2004 |
IssueID | Title | Last changed |
---|---|---|
Issue 84 | Require Static Analysis Description & List | 23 Jun 2004 |
Issue 93 | Use of XML types in faults | 14 Dec 2004 |
Issue 105 | XML namespaces used in spec and examples need to be defined | 24 Jun 2004 |
Issue 145 | Properties on Non-Message Variables | 16 Dec 2004 |
Issue 155 | complexType Variables | 9 Dec 2004 |
Issue 162 | Unique Activity Names for Compensate | 15 Dec 2004 |
Issue 167 | Rethrow semantics clarification | 27 Oct 2004 |
Issue 170 | How to handle faultcode, faultstring, and faultactor | 3 Dec 2004 |
Issue 171 | faultName should be optional for invoke fault handlers | 15 Dec 2004 |
IssueID | Title | Status | In spec | Date added | Last changed | Revisitable |
---|---|---|---|---|---|---|
Issue 1 | Permeability of scopes | resolved | 5 Oct 2004 | 25 Jun 2003 | 6 Oct 2004 | |
Issue 2 | Sub-Functions | resolution proposed | 25 Jun 2003 | 10 Dec 2004 | ||
Issue 3 | Current state influence in compensation handlers | resolved | 4 June 2004 | 25 Jun 2003 | 9 Jun 2004 | |
Issue 4 | Dynamic parallel processing | open | 25 Jun 2003 | 2 Jun 2004 | ||
Issue 5 | Suspend/resume | resolved | no change | 25 Jun 2003 | 11 Feb 2004 | |
Issue 6 | Completion Condition | open | 25 Jun 2003 | 20 Dec 2004 | ||
Issue 7 | Import | resolved | 4 June 2004 | 25 Jun 2003 | 9 Jun 2004 | |
Issue 8 | Non-mutability of correlation sets | resolved | No change | 25 Jun 2003 | 22 Jun 2004 | |
Issue 9 | Static analysis | resolution proposed | 25 Jun 2003 | 17 Sep 2004 | ||
Issue 10 | Serialization of compensation | resolved | 19 Nov 2004 | 25 Jun 2003 | 19 Nov 2004 | |
Issue 11 | Query in <to> close should allow assigning to new locations | open | 25 Jun 2003 | 5 Jan 2005 | ||
Issue 11.1 | Making <assign> truly extensible | resolution proposed | 5 Jan 2005 | 5 Jan 2005 | ||
Issue 12 | XML types and WS Interactions | resolution proposed | 25 Jun 2003 | 14 Dec 2004 | ||
Issue 13 | Future Usage of XPATH 2.0 and XQuery 1.0 | resolved | 4 June 2004 | 25 Jun 2003 | 26 Jul 2004 | |
Issue 14 | Restriction on join conditions | resolved | no change | 25 Jun 2003 | 4 Feb 2004 | |
Issue 15 | WSDL MEPs | resolved | No change | 25 Jun 2003 | 6 Oct 2004 | |
Issue 16 | Ensuring exactly once | resolved | no change | 25 Jun 2003 | 10 Dec 2003 | |
Issue 17 | Asynchronous operations | resolved | no change | 25 Jun 2003 | 27 Jan 2004 | |
Issue 18 | BPEL Visual Binding | resolved | no change | 25 Jun 2003 | 11 Feb 2004 | |
Issue 19 | Multiple properties associated to a single property alias | resolved | no change | 25 Jun 2003 | 11 Feb 2004 | |
Issue 20 | installing compensation handlers for faulted scopes | resolved | no change | 25 Jun 2003 | 1 Oct 2003 | |
Issue 21 | faultHandlers to be renamed cancellationHandlers | resolved | no change | 25 Jun 2003 | 3 Mar 2004 | |
Issue 22 | Implicit <sequence> macro | resolved | no change | 25 Jun 2003 | 4 Feb 2004 | |
Issue 23 | Rationale for sequence vs. flow | resolved | 4 June 2004 | 25 Jun 2003 | 9 Jun 2004 | |
Issue 24 | Separate schemas for executable vs abstract BPEL | resolved | no change | 25 Jun 2003 | 11 May 2004 | |
Issue 25 | Consistent enablement of compensation handlers | resolved | 1.34, 19 June 2004 | 26 Jun 2003 | 20 Jun 2004 | |
Issue 26 | Correlating use with receive/reply | open | 26 Jun 2003 | 15 Jan 2004 | ||
Issue 27 | Setting link status in case of transition condition | resolved | 4 June 2004 | 26 Jun 2003 | 9 Jun 2004 | |
Issue 28 | Simplification of join condition | open | 26 Jun 2003 | 20 Oct 2003 | ||
Issue 29 | Simplification of XPath expressions | open | 26 Jun 2003 | 21 Oct 2003 | ||
Issue 30 | Support for coordination protocol | resolved | 1.34, 19 June 2004 | 26 Jun 2003 | 20 Jun 2004 | Yes |
Issue 31 | Unique identifier for establishing new correlation | resolved | No change | 26 Jun 2003 | 22 Jun 2004 | Yes |
Issue 32 | Link Semantics in Event Handlers | resolved | 4 June 2004 | 3 Jul 2003 | 9 Jun 2004 | |
Issue 33 | Race condition before correlation set is established | resolved | 1.34, 19 June 2004 | 9 Jul 2003 | 20 Jun 2004 | |
Issue 34 | Dependency on Proprietary Specifications | resolved | 16 Aug 2004 | 9 Jul 2003 | 17 Aug 2004 | |
Issue 35 | Support for modeling | resolved | no change | 9 Jul 2003 | 11 Feb 2004 | |
Issue 36 | Multiple instances of event handler | resolved | 4 June 2004 | 9 Jul 2003 | 9 Jun 2004 | |
Issue 37 | Initiating Correlation Set More Than Once | resolved | 1.35, 30 June 2004 | 11 Jul 2003 | 15 Jul 2004 | |
Issue 38 | Directed Activity Graph and block structured | resolved | no change | 13 Jul 2003 | 4 Feb 2004 | |
Issue 39 | Inconsistent syntax for query attribute values in spec examples | resolved | 4 June 2004 | 16 Jul 2003 | 9 Jun 2004 | |
Issue 40 | attribute name "variable" or "message" | resolved | no change | 24 Jul 2003 | 9 Jun 2004 | |
Issue 41 | onMessage handler definition | resolved | 4 June 2004 | 31 Jul 2003 | 9 Jun 2004 | |
Issue 42 | Need for Formalism | resolved | no change | 31 Jul 2003 | 3 Mar 2004 | yes |
Issue 43 | Setting up Periodic Alarms | resolved | 16 Aug 2004 | 31 Jul 2003 | 17 Aug 2004 | |
Issue 44 | portType is duplicated on Invoke activity and partnerLinkType | resolved | 16 Aug 2004 | 5 Aug 2003 | 17 Aug 2004 | |
Issue 45 | Wording of "while" activity | resolved | 4 June 2004 | 7 Aug 2003 | 9 Jun 2004 | |
Issue 46 | Namespace for the document fragment representing a part | resolved | 4 June 2004 | 7 Aug 2003 | 9 Jun 2004 | |
Issue 47 | Which Version of WSDL should we use? | resolved | no change | 8 Aug 2003 | 15 Oct 2003 | |
Issue 48 | XML Transform Support | resolved | no change | 12 Aug 2003 | 29 Apr 2004 | |
Issue 49 | Disambiguating <receive>s to <reply> to | resolved | no change | 12 Aug 2003 | 27 Jan 2004 | |
Issue 50 | Semantics for "dangling receive" | resolved | 4 June 2004 | 12 Aug 2003 | 9 Jun 2004 | |
Issue 51 | Section 9.3.1 & Schema Validation | open | 18 Aug 2003 | 25 Nov 2004 | ||
Issue 52 | Specify how flows in the same process send messages to each other | resolved | No change | 18 Aug 2003 | 23 Sep 2004 | |
Issue 53 | Include Business Transaction Management (BTM) constructs | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 54 | Construct to hold Business transaction contexts | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 55 | Business transaction propagation | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 56 | Business transaction creation | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 57 | Business transaction termination | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 58 | Selective termination of business transaction participants | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 59 | BPEL process as business transaction participant | resolved | 1.34, 19 June 2004 | 26 Aug 2003 | 20 Jun 2004 | Yes |
Issue 60 | process category | resolved | no change | 8 Sep 2003 | 11 Feb 2004 | |
Issue 61 | process priority | resolved | no change | 8 Sep 2003 | 11 Feb 2004 | |
Issue 62 | Event handlers and Serializable Scopes | resolved | 4 June 2004 | 12 Sep 2003 | 9 Jun 2004 | |
Issue 63 | Support of Array | open | 15 Sep 2003 | 22 Apr 2004 | ||
Issue 64 | Explicit declaration of process instantiation | resolved | No change | 15 Sep 2003 | 14 Oct 2004 | |
Issue 65 | Multiple partners of a partner type | resolved | No change | 15 Sep 2003 | 22 Jun 2004 | |
Issue 66 | Zero or multiple matches of correlation set | resolved | No change | 19 Sep 2003 | 22 Jun 2004 | |
Issue 67 | Clarify semantics of serializable scopes | resolved | 4 June 2004 | 24 Sep 2003 | 9 Jun 2004 | |
Issue 68 | catch syntax broken | resolved | 4 June 2004 | 26 Sep 2003 | 9 Jun 2004 | |
Issue 69 | When to clear link status | resolved | 4 June 2004 | 27 Sep 2003 | 9 Jun 2004 | |
Issue 70 | suppressJoinFailure default value | resolved | 4 June 2004 | 30 Sep 2003 | 9 Jun 2004 | |
Issue 71 | Removal of wsdl:message | resolved | No change | 1 Oct 2003 | 14 Oct 2004 | |
Issue 72 | What to do with WS-I BP1.0? | resolved | 4 June 2004 | 1 Oct 2003 | 9 Jun 2004 | |
Issue 73 | "wsdl:fault" element not allowed with one-way operation | resolved | 4 June 2004 | 6 Oct 2003 | 9 Jun 2004 | |
Issue 74 | Ambiguity in join condition definition | resolved | 4 June 2004 | 9 Oct 2003 | 9 Jun 2004 | |
Issue 75 | Locally Scoped partnerLink declarations | resolved | 1.35, 30 June 2004 | 21 Oct 2003 | 15 Jul 2004 | |
Issue 76 | Mandating either Pessimistic or Optimistic Static Analysis | resolved | no change | 21 Oct 2003 | 12 Nov 2003 | |
Issue 77 | BPEL cannot handle some SOAP header bindings | resolved | no change | 21 Oct 2003 | 10 Dec 2003 | |
Issue 78 | New value for initiate on multi-starts | resolved | No change | 22 Oct 2003 | 22 Jun 2004 | |
Issue 79 | Serializable scopes do not need to be leaf scopes | resolved | 4 June 2004 | 22 Oct 2003 | 9 Jun 2004 | |
Issue 80 | Clarify Fault Handler Selection When Fault Data is Absent | resolved | 4 June 2004 | 31 Oct 2003 | 9 Jun 2004 | |
Issue 81 | Are start activities that aren't createInstance activities legal? | resolution proposed | 3 Nov 2003 | 7 Dec 2004 | ||
Issue 82 | description of abstract processes in spec | resolution proposed | 3 Nov 2003 | 16 Dec 2004 | ||
Issue 83 | Garbage Collecting Compensation Handlers | resolved | no change | 3 Nov 2003 | 20 May 2004 | Yes |
Issue 84 | Require Static Analysis Description & List | resolved | 5 Nov 2003 | 23 Jun 2004 | ||
Issue 85 | Multiple links with the same source and target | resolved | 4 June 2004 | 17 Nov 2003 | 9 Jun 2004 | |
Issue 86 | Addressing Interoperability / Portability - SOAP 1.2 | open | 25 Nov 2003 | 27 Nov 2003 | ||
Issue 87 | Optional SOAP Headers | resolved | No change | 27 Nov 2003 | 8 Dec 2004 | Yes |
Issue 87.1 | Optional SOAP Headers (subissue: generic mechanism) | resolved | No change | 8 Dec 2004 | ||
Issue 88 | Import Errata | open | 3 Dec 2003 | 23 Jun 2004 | ||
Issue 89 | Handling Unrecognized Query/Expression Languages | resolved | 16 Nov 2004 | 7 Jan 2004 | 17 Nov 2004 | |
Issue 90 | Assignment of external data into a variable | resolved | no change | 9 Jan 2004 | 29 Apr 2004 | Yes |
Issue 91 | Nested Activities in Abstract Processes | resolution proposed | 22 Jan 2004 | 29 Apr 2004 | ||
Issue 92 | Mandatory & Optional BPEL Extensibility | resolution proposed | 22 Jan 2004 | 3 Jan 2005 | ||
Issue 93 | Use of XML types in faults | resolved | 22 Jan 2004 | 14 Dec 2004 | ||
Issue 94 | Allow both "compensate" and other activities in compensation or fault handler | resolved | 1.35, 30 June 2004 | 2 Feb 2004 | 15 Jul 2004 | |
Issue 95 | Rethrow a Fault | resolved | 4 June 2004 | 3 Feb 2004 | 9 Jun 2004 | |
Issue 96 | Engine-managed correlation sets | open | 3 Feb 2004 | 22 Jun 2004 | ||
Issue 97 | Optional Variable References in Abstract Processes | resolution proposed | 10 Feb 2004 | 29 Apr 2004 | ||
Issue 98 | What version number are we working towards | resolved | 19 Nov 2004 | 20 Feb 2004 | 19 Nov 2004 | |
Issue 99 | Triggering activities for abstract processes | resolution proposed | 3 Mar 2004 | 23 Jun 2004 | ||
Issue 100 | When should XML be validated? | resolved | No change | 4 Mar 2004 | 23 Jun 2004 | |
Issue 101 | Local variables overriding enclosing scope | resolved | 4 June 2004 | 5 Mar 2004 | 9 Jun 2004 | |
Issue 102 | Fixing Typos in getVariable*() in BPEL examples | open | 9 Mar 2004 | 22 Apr 2004 | ||
Issue 103 | Standardizing $varName syntax for XPath to refer to a BPEL variable | resolution proposed | 9 Mar 2004 | 30 Sep 2004 | ||
Issue 104 | incorrect target link names in 12.5.3. Flow Graph | resolved | 4 June 2004 | 10 Mar 2004 | 9 Jun 2004 | |
Issue 105 | XML namespaces used in spec and examples need to be defined | resolved | 17 Mar 2004 | 24 Jun 2004 | ||
Issue 106 | ASSERT activity. | resolved | No change | 18 Mar 2004 | 23 Jun 2004 | |
Issue 107 | Opacity and the meaning of nothingness in abstract processes | resolution proposed | 18 Mar 2004 | 14 Dec 2004 | ||
Issue 108 | Parallel Compensation | resolved | 19 Nov 04 | 20 Mar 2004 | 24 Nov 2004 | |
Issue 109 | Compatibility between Abstract and Executable Processes | open | 24 Mar 2004 | 17 Aug 2004 | ||
Issue 110 | Issues with the Pattern Attribute | open | 24 Mar 2004 | 14 Oct 2004 | ||
Issue 111 | Extension Activities | open | 25 Mar 2004 | 25 Mar 2004 | ||
Issue 112 | Input/Output Elements on Messaging Activities | open | 25 Mar 2004 | 24 Jun 2004 | ||
Issue 113 | Optional Port Types | resolved | No change | 25 Mar 2004 | 23 Jun 2004 | |
Issue 114 | Multiple Correlation Sets | resolved | 1.35, 30 June 2004 | 31 Mar 2004 | 15 Jul 2004 | |
Issue 115 | Revise content of Appendix C | resolved | No change | 1 Apr 2004 | 23 Sep 2004 | |
Issue 116 | <process> element should be optional | resolved | No change | 1 Apr 2004 | 27 Oct 2004 | |
Issue 117 | Link Name Scoping | resolved | 4 June 2004 | 14 Apr 2004 | 9 Jun 2004 | |
Issue 118 | When are Correlation Sets Mandatory? | resolved | no change | 15 Apr 2004 | 7 Jul 2004 | |
Issue 119 | Transition Conditions and Invoke Fault Handlers | open | 19 Apr 2004 | 12 Oct 2004 | ||
Issue 120 | What are the semantics when an initial <receive> has no correlation set? | open | 19 Apr 2004 | 27 Aug 2004 | ||
Issue 121 | <finally> construct | resolved | No change | 20 Apr 2004 | 14 Dec 2004 | Yes |
Issue 122 | Clarify wording for Message Exchange Patterns | resolved | No change | 20 Apr 2004 | 23 Jun 2004 | |
Issue 123 | Matching <reply> with <receive> | resolved | 21 Oct 2004 | 18 May 2004 | 23 Oct 2004 | |
Issue 124 | PartnerLink/URI setter/getter function | resolved | no change | 18 May 2004 | 28 Dec 2004 | Yes |
Issue 125 | Literal and Expression Assignment Semantics | resolution proposed | 25 May 2004 | 8 Dec 2004 | ||
Issue 126 | Event Handlers with local partnerLinks & Correlation Sets | resolution proposed | 10 Jun 2004 | 15 Jul 2004 | ||
Issue 127 | Locally Scoped Partners | resolved | no change | 11 Jun 2004 | 12 Jun 2004 | |
Issue 128 | WS-I BP Incompatible WSDL Import | resolved | 16 Aug 2004 | 14 Jun 2004 | 17 Aug 2004 | |
Issue 129 | Inconsistent Name Attribute Usage in PartnerLinkType | resolved | 16 Nov 2004 | 14 Jun 2004 | 17 Nov 2004 | |
Issue 130 | Remove Partner Element | resolved | no change | 6 Jul 2004 | 6 Jan 2005 | |
Issue 131 | revisiting section 9.3.1 "Type Compatibility in Assignment" | resolved | No change | 13 Jul 2004 | 16 Jul 2004 | |
Issue 132 | In-line Variable Initialization | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 133 | Access to unnamed fault bodies | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 134 | Non-Integer XPATHS | resolved | 21 Oct 2004 | 15 Jul 2004 | 23 Oct 2004 | |
Issue 135 | Clarifying forcedTermination Handler | resolved | 19 Nov 2004 | 15 Jul 2004 | 19 Nov 2004 | |
Issue 136 | If-Then-Else Activity | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 137 | Making properties consistent with variable values | resolved | 25 Nov 04 | 15 Jul 2004 | 25 Nov 2004 | |
Issue 138 | Properties of type element | open | 15 Jul 2004 | 15 Sep 2004 | ||
Issue 139 | PartnerLink Semantics | open | 15 Jul 2004 | 4 Aug 2004 | ||
Issue 140 | Until Activity | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 141 | Standard Fault Format | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 142 | Break & Continue | open | 15 Jul 2004 | 8 Dec 2004 | ||
Issue 143 | StaticSwitch Activity | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 144 | Defining Undefined Behaviors | open | 15 Jul 2004 | 16 Jul 2004 | ||
Issue 145 | Properties on Non-Message Variables | resolved | 15 Jul 2004 | 16 Dec 2004 | ||
Issue 146 | Making tVariable Extensible | resolved | 8 Sept 2004 | 15 Jul 2004 | 15 Sep 2004 | |
Issue 147 | Serial and Parallel For-Each | open | 16 Jul 2004 | 20 Sep 2004 | ||
Issue 148 | Explicitly state that solicit/response & notification aren't supported by BPEL | open | 17 Jul 2004 | 17 Jul 2004 | ||
Issue 149 | adding formal <documentation> support to BPEL | resolved | 8 Sept 2004 | 20 Jul 2004 | 15 Sep 2004 | |
Issue 150 | Message variables on invoke and reply | open | 20 Jul 2004 | 21 Jul 2004 | ||
Issue 151 | Allow a new process instance to be created by "pick onAlarm until" | resolved | no change | 26 Jul 2004 | 15 Sep 2004 | yes |
Issue 152 | Clarification of usage of "reference-scheme" attribute of "service-ref" element | resolved | 3 Dec 2004 | 27 Jul 2004 | 4 Dec 2004 | |
Issue 153 | getVariableData xpath function should return node sets of any size | open | 27 Jul 2004 | 27 Jul 2004 | ||
Issue 154 | doc/lit & multiple body parts | open | 28 Jul 2004 | 30 Jul 2004 | ||
Issue 155 | complexType Variables | resolved | 28 Jul 2004 | 9 Dec 2004 | ||
Issue 156 | Cleaning Up XPATH in BPEL | open | 31 Jul 2004 | 31 Jul 2004 | ||
Issue 157 | Cleaning up copy | open | 31 Jul 2004 | 31 Jul 2004 | ||
Issue 158 | Changing Spec Structure from 3 part to 2 part | open | 4 Aug 2004 | 7 Aug 2004 | ||
Issue 159 | Ordering specification sections by dependency | open | 4 Aug 2004 | 6 Aug 2004 | ||
Issue 160 | facilities to define XML schema validation boundary | resolution proposed | 10 Aug 2004 | 16 Dec 2004 | ||
Issue 161 | Explicit conformance statements | resolved | No change | 8 Sep 2004 | 29 Sep 2004 | Yes |
Issue 162 | Unique Activity Names for Compensate | resolved | 8 Sep 2004 | 15 Dec 2004 | ||
Issue 163 | languageExecutionFault | open | 22 Sep 2004 | 14 Oct 2004 | ||
Issue 164 | Variable Types for Throw and Catch | resolved | Duplicate | 23 Sep 2004 | 14 Oct 2004 | |
Issue 165 | clarification of the default NS URI for expression and query language | resolved | 3 Dec 2004 | 23 Sep 2004 | 4 Dec 2004 | |
Issue 166 | Does atomicity in assign imply variable locking? | resolved | 25 Nov 04 | 29 Sep 2004 | 25 Nov 2004 | |
Issue 167 | Rethrow semantics clarification | resolved | 4 Oct 2004 | 27 Oct 2004 | ||
Issue 168 | Semantics of instance creation | resolved | No change | 4 Oct 2004 | 8 Dec 2004 | |
Issue 169 | transition condition error handling clarification | resolution proposed | 18 Oct 2004 | 10 Dec 2004 | ||
Issue 170 | How to handle faultcode, faultstring, and faultactor | resolved | 18 Oct 2004 | 3 Dec 2004 | ||
Issue 171 | faultName should be optional for invoke fault handlers | resolved | 18 Oct 2004 | 15 Dec 2004 | ||
Issue 172 | Clarification/correction of correlation sets example in sec. 10.2 | resolved | 25 Nov 04 | 18 Oct 2004 | 25 Nov 2004 | |
Issue 173 | Value of initiate attributes in Multiple Start Activities example | resolved | 25 Nov 04 | 20 Oct 2004 | 25 Nov 2004 | |
Issue 174 | Are multiple imports with the same namespace allowed? | open | 23 Oct 2004 | 11 Nov 2004 | ||
Issue 175 | Supporting WSDL Overloading in BPEL | resolved | 25 Nov 04 | 27 Oct 2004 | 25 Nov 2004 | |
Issue 176 | Removing Section 4 | resolved | 19 Nov 2004 | 27 Oct 2004 | 19 Nov 2004 | |
Issue 177 | Inconsistent optional/required nature of @Variable on onMessage, onEvent and Receive | open | 28 Oct 2004 | 11 Nov 2004 | ||
Issue 178 | Correlation sets visible to an event handler | resolved | 25 Nov 04 | 2 Nov 2004 | 25 Nov 2004 | |
Issue 179 | Type Compatibility in Assignment of EPRs | resolved | No change | 12 Nov 2004 | 24 Nov 2004 | |
Issue 180 | Clarification of WSDL fault declarations and Reply in BPEL | open | 4 Dec 2004 | 8 Dec 2004 | ||
Issue 181 | uninitializedVariable cleanup | open | 10 Dec 2004 | 14 Dec 2004 |
The colour of the issue title is determined by the status: red=open (42 issues), maroon=resolution proposed (16 issues), green=resolved (125 issues). According to the TC issue procedures (issues process document), the formal status values are "open" and "resolved". The procedure revision for issues submitted after 15 August 2004 implies a provisional status before an issue is open. The other status values are just informational variations on those.
The "revisitable" entry applies to resolved issues where it has been suggested that it may be worth returning to the question
in future work, after the completion of the first OASIS TC edition of the WS BPEL specification.
This is the same proposal that was posted earlier (reproduced below for convenience) with one slight necessary clarification (pointed out by Alex).
Clarification:
The restriction that links cannot cross serializable scope boundaries is now no longer needed. Since serializable scopes are now impermeable, such links cannot cause deadlock. The proposal therefore is to eliminate this restriction. This was already implied in the previous proposal implicitly.
Original proposal restated: The core problem in Issue 1 is that we have no way to control the firing of links in cases where the source activity may be compensated after the link has fired and thus "revoke the promise" of prerequisite fulfillment that the link may represent.
The proposal is to strengthen the meaning of "variableAccessSerializable" to also control the visibility of link status, by attaching the meaning of isolation to the attribute. In order to reflect this we propose that the name of the attribute be changed to "isolated". Thus we would have
<scope isolated="yes"> <!-- serializable, non-permeable --> <faultHandlers ...> ... </faultHandlers> <compensationHandler ...> ... </compensationHandler> ... </scope>Where a scope is said to be permeable if link status can travel freely across its boundaries as in the present specification. The status of links leaving (source inside target outside) a non-permeable scope will not be visible at the target until the scope completes, whether successfully or unsuccessfully. If the scope completes unsuccessfully, the status of links leaving the scope is false regardless of what it was at the time the source activity completed. There is no change for links entering (source outside target inside) the non-permeable scope.<scope isolated="no"> <!-- non-serializable, permeable --> <faultHandlers ...> ... </faultHandlers> <compensationHandler ...> ... </compensationHandler> ... </scope>
Note that this gives the BPEL process designer the discretion to use
isolated="no" when s/he cares to protect the target from revocable
promises. The downside of the protection is potential loss of
concurrency.
Links: Announcement, 25 Jun 2003
Satish Thatte, 15 Sep 2003
Discussed at Redmond face-to-face - Dieter's presentation (document details)
Ricky Ho, 25 Sep 2003
Satish Thatte, 17 Mar 2004
Reversible and Permeable Scopes v2.ppt (document details)
Satish Thatte, 16 Mar 2004
Danny van der Rijn, 16 Mar 2004
Yaron Y. Goland, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Frank Leymann, 19 Mar 2004
Discussed at Walldorf f-t-f (document details)
GORAN.OLSSON@ORACLE.COM, 28 Apr 2004
Satish Thatte, 29 Apr 2004
Nickolas Kavantzas, 7 May 2004
Proposed resolution (Satish Thatte, 7 Jun 2004)
Proposed resolution (Satish Thatte, 18 Jun 2004)
Issues 1 and 10.ppt (document details)
Changes: 4 Jul 2003 - fields: Document;
11 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
26 Sep 2003 - fields: Links;
17 Mar 2004 - fields: Links;
19 Mar 2004 - fields: Links;
22 Apr 2004 - fields: Links;
29 Apr 2004 - fields: Links;
8 May 2004 - fields: Links;
9 Jun 2004 - fields: Links, Status, Proposed resolution;
16 Jun 2004 - fields: Categories;
18 Jun 2004 - fields: Links, Status, Proposed resolution;
23 Jun 2004 - fields: Links, Status, Proposed resolution, Resolution;
6 Oct 2004 - fields: In spec
Following is extracted from proposal message.
The relevant text in Section 13.3.1 will be replaced with the following, with appropriate editing (the picture (see attachment to proposal message) would also be included in the specification):
Compensation handlers always interact with the current state of the process, specifically the state of variables declared in their associated scope and all enclosing scopes. The variables include partnerLinks at the process scope. Compensation handlers are able to both get and set the values of all such variables. Other parts of the process will see the changes made to shared variables by compensation handlers, and conversely, compensation handlers will see changes made to shared variables by other parts of the process, including situations where a compensation handler runs concurrently with other parts of the process. Compensation handlers will need to use serializable scopes when they touch state in enclosing scopes to avoid interference.The current state of the process consists of the current local state of all scopes that have been started. This includes scopes that have completed but for which the associated compensation handler has not been invoked. For completed uncompensated scopes their current local state is the state as it was at the time of completion. Such scopes are in suspended animation because their compensation handlers are still available and therefore their execution may continue in compensation mode. Note that a scope may have been executed several times in a loop, and the current state of the process includes the state of each completed (and uncompensated) iteration through the scope.
The behavior of a compensation handler can be thought of as an optional continuation of the behavior of the associated scope and as such its usage of variables is similar to the usage that occurred in the body of the scope itself, including update actions. This includes variables in both the local scope and all enclosing scopes. Note that the compensation handler may itself have been called from an enclosing compensation handler. It will then share the continuation of the state of the enclosing scope that its caller is using. In the attached picture showing three nested scopes S1, S2 and S3, and their compensation handlers C1, C2, C3, and failure handlers F1 and F2, we may have an error handling call stack F1->C2->C3. In that case C3 will share the state of S2 as it is being seen and used by C2.
Close with no change to the specification.
Rationale: Suspend/resume appears to be out of scope for a first release.
Furthermore, it seems that suspend/resume might as well be handled by the
infrastructure and therefore outside of the process model.
Links: Announcement, 25 Jun 2003
Peter Furniss, 22 Oct 2003
Tony Fletcher, 23 Oct 2003
Proposed resolution (Dieter Koenig1, 19 Jan 2004)
Peter Furniss, 26 Jan 2004
Changes: 4 Jul 2003 - fields: Document;
22 Oct 2003 - fields: Links;
23 Oct 2003 - fields: Links;
20 Jan 2004 - fields: Links;
26 Jan 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
Introduce a single <bpel:import> element used to import XSD, WSDL definitions. Zero or more <bpel:import> elements may appear as first children of the <bpel:process> element. Three required attributes must be:
For example:
<bpel:import namespace="..." location="document-location" importType="XYZ-namespace-uri"/>A <bpel:import> location element will be interpreted as a hint for BPEL processors. In particular, processors are not required to retrieve the imported document from the specified location.
Close with no change to the spec.
Rationale: The ambiguity originally perceived is no longer felt to be there. Any clarification needed
will be treated as an editorial matter.
Links: Announcement, 25 Jun 2003
Discussed at meeting, 6 August (document details)
Discussed at Redmond face-to-face
Changes: 4 Jul 2003 - fields: Document;
7 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
18 Sep 2003 - fields: Links;
22 Jun 2004 - fields: Status, Proposed resolution, Resolution, Rationale, In spec
Question: Is it possible to define a conservative set of restrictions that
will ensure portability?
Proposed resolution: Yaron Y. Goland, 17 Sep 2004
Links: Announcement, 25 Jun 2003
Chris Keller, 7 Oct 2003
Eckenfels. Bernd, 7 Oct 2003
Chris Keller, 7 Oct 2003
Yaron Goland, 7 Oct 2003 (links previous 3 msgs to this issue)
Yaron Y. Goland, 9 Apr 2004
Yaron Y. Goland, 12 Aug 2004
John Evdemon, 13 Aug 2004
Yaron Y. Goland, 13 Aug 2004
John Evdemon, 16 Aug 2004
Alex Yiu, 17 Aug 2004
Yaron Y. Goland, 18 Aug 2004
Satish Thatte, 24 Aug 2004
Yaron Y. Goland, 24 Aug 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Assaf Arkin, 16 Sep 2004
Proposed resolution (Yaron Y. Goland, 17 Sep 2004)
Changes: 4 Jul 2003 - fields: Document;
8 Oct 2003 - fields: Links;
10 Apr 2004 - fields: Links;
13 Aug 2004 - fields: Links;
14 Aug 2004 - fields: Links;
17 Aug 2004 - fields: Links;
18 Aug 2004 - fields: Links;
24 Aug 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
17 Sep 2004 - fields: Links, Status, Proposed resolution
Informally, we propose that default compensation order need only respect the control dependencies that are explicitly modeled. With the resolution of issue 1, it is far from easy to emulate strict reverse order of completion with explicit fault and compensation handlers. But with the proposed resolution of Issue 10 here, that does not matter since strict reverse order is permitted but not mandated for the default behavior. This does require an additional restriction on links to ban reentrant control paths, as described below more formally.
Definition: Control Dependency. If an activity A must complete before activity B begins, as a result of the existence of a control path from A to B in the process definition, then we say that B has a control dependency on A. Note that control dependencies may occur due to control links in <flow> as well as due to constructs like <sequence>. Control flow due to explicit "throw" is not considered a control dependency.
Part I: Consider scopes A and B such that B has a control dependency on A. Assuming both A and B completed successfully and both must be compensated as part of default compensation behavior, the compensation handler of B must run to completion before the compensation handler of A is started. This permits scopes that executed concurrently on the forward path to also be compensated concurrently in the reverse path. Of course, if one follows the strict reverse order of completion, then that necessarily respects control dependencies and is also consistent with this rule. The rule imposes a constraint on the order in which compensation handlers run during default compensation, and is not meant to be fully prescriptive about the exact order and concurrency.
Definition: Reentrant control path. Consider activities A and B enclosed in a scope S, such that B has a control dependency on A. The control path from A to B is said to be reentrant if it includes an activity C that is outside scope S, i.e., there is an activity C outside scope S such that C has a control dependency on A and B has a control dependency on C. Informally, such a reentrant path starts at A, "leaves scope S" to reach activity C and then "reenters scope S" to reach activity B. Note that reentrant control paths always involve links, at the least, one to leave the scope and one to reenter the scope.
Part II (this was NOT part of the original resolution of this issue, but was kept here for documentary completeness. It is the subject of the second resolution proposal in Satish Thatte, 8 Sep 2004): It is necessary to be able to define the default compensation behavior of a given scope independent of its peer and enclosing scopes. One reason is that such a default compensation handler may be invoked explicitly by the fault and compensation handlers of its enclosing scope. However, there are currently legal cases where the proposed resolution in Part I makes this impossible. One such example is attached. We propose to resolve this by banning reentrant control paths. This restriction would be added to the list of restrictions on links at the end of section 12.5. Clarifying note: all reentrant control paths are banned according to this proposal, whether or not they involve scope activities.
Part III: Given that compensation handlers may run concurrently with other activities including other compensation handlers, it is necessary to allow compensation handlers to use isolation scope semantics. Compensation handlers do not run within the isolation domain of their associated scopes, but fault handlers do. This creates difficulties in the isolation semantics of compensation handlers for scopes nested inside a serializable scope. Such handlers cannot use serializable scopes themselves because serializable scopes cannot be nested. However, their isolation environment is uncertain because they may be invoked from either a fault handler within the isolation domain of their enclosing scope or within the compensation handler of the same enclosing scope which is not in that isolation domain. In order to improve consistency of behavior, we propose that the compensation handler of a serializable scope will itself have serializable behavior implicitly, although it will create a separate isolation domain from that of its associated scope.
Two new issues will be raised
Replacing part II of original resolution
I begin with a formal restatement for Part II of the resolution of Issue 10. I will then add some explanation.
Definition: Peer-Scopes. Two scopes S1 and S2 are said to be peer scopes if they are both directly nested within the same parent scope (including process scope).
Definition: Scope-controlled set. An activity A is within the scope-controlled set of activities of scope S if either A is S itself, or A is nested within S, at any depth.
Definition: Peer-Scope Dependency. If S1 and S2 are peer scopes then we say that S2 has a direct peer-scope dependency on S1 if there is an activity B within the scope-controlled set of S2 and an activity A within the scope-controlled set of S1 such that B has a control dependency on A. The peer-scope dependency relation is the transitive closure of the direct peer-scope dependency relation.
Part II: The peer-scope dependency relation MUST NOT include cycles. In other words, BPEL forbids a process in which there are peer scopes S1 and S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope dependency on S1.
Explanation:
The basic motivation for Part II is to make the "respect for control dependency" rule of Part I consistent with a depth-first traversal of the scope tree for default compensation. If we can guarantee that there is a depth-first (post-order variant) traversal consistent with Part I, we no longer have any difficulty in defining default compensation of any scope, since depth-first order implies that such compensation is only dependent on the compensation of its nested scopes. The question then reduces to constraining control paths so we can make this guarantee. I claim that we need only concern ourselves about control dependencies between peer scopes in the sense defined above. An example illustrates the point. Consider the following example (taken from an earlier exchange with Alex)
<scope name="s0"> <scope name="s1"> <flow> <anActivity> <source linkName="lnk1" /> </anActivity> <!-- Assume that the above anActitity does not contain a scope activity --> <scope name="s2"> <target linkName="lnk1" /> </scope> </flow> </scope> </scope>
Does the link create a dependency between s1 and s2 that has any relevance to compensation order? If this example is changed to
<scope name="s0"> <scope name="s1"> <flow> <scope name="s7"> <source linkName="lnk1" /> </scope> <scope name="s2"> <target linkName="lnk1" /> </scope> </flow> </scope> </scope>
Does the situation change? The only difference between the examples is that, whereas s1 was theoretically responsible for the compensation of the previous generic anActivity (since we assumed it does not contain a scope), it's replacement scope is an activity that is responsible for its own compensation. But let us look further. If we think about default compensation behavior for s1 it is going to do absolutely nothing about compensating any non-scope activities nested inside it. Thus the fact that fact that s1 was theoretically responsible for the compensation of the generic anActivity has no consequence regarding a required ordering of compensation between s1 and s2. Part II exploits this point and its generalization to control chains and multiply nested scopes.
Links: Announcement, 25 Jun 2003
Satish Thatte, 15 Sep 2003
Sid Askary, 9 Dec 2003
Yaron Goland, 11 Dec 2003
Satish Thatte, 12 Dec 2003
Yaron Goland, 12 Dec 2003
Assaf Arkin, 12 Dec 2003
Satish Thatte, 12 Dec 2003
Satish Thatte, 12 Dec 2003
Assaf Arkin, 12 Dec 2003
Yaron Goland, 23 Dec 2003
Ugo Corda, 23 Dec 2003
Yaron Goland, 24 Dec 2003
Ugo Corda, 24 Dec 2003
Satish Thatte, 30 Dec 2003
Ron Ten-Hove, 31 Dec 2003
Yaron Goland, 5 Jan 2004
Assaf Arkin, 7 Jan 2004
Danny van der Rijn, 7 Jan 2004
Peter Furniss, 7 Jan 2004
Satish Thatte, 7 Jan 2004
Satish Thatte, 17 Mar 2004
Reversible and Permeable Scopes v2.ppt (document details)
Satish Thatte, 16 Mar 2004
Danny van der Rijn, 16 Mar 2004
Yaron Y. Goland, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Frank Leymann, 19 Mar 2004
Discussed at Walldorf f-t-f (document details)
Satish Thatte, 18 Jun 2004
Proposed resolution (Satish Thatte, 18 Jun 2004)
Proposed resolution (Satish Thatte, 20 Jun 2004)
Issues 1 and 10.ppt (document details)
Yaron Y. Goland, 19 Aug 2004
Satish Thatte, 19 Aug 2004
Alex Yiu, 19 Aug 2004
Alex Yiu, 19 Aug 2004
Danny van der Rijn, 20 Aug 2004
Satish Thatte, 20 Aug 2004
Yaron Y. Goland, 24 Aug 2004
Satish Thatte, 24 Aug 2004
Yaron Y. Goland, 26 Aug 2004
Satish Thatte, 30 Aug 2004
Satish Thatte, 8 Sep 2004
Proposed resolution (Satish Thatte, 8 Sep 2004)
Peter Furniss, 9 Sep 2004
Dieter Koenig1, 13 Sep 2004
Changes: 4 Jul 2003 - fields: Document;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
10 Dec 2003 - fields: Links;
23 Dec 2003 - fields: Links;
7 Jan 2004 - fields: Links;
17 Mar 2004 - fields: Links;
19 Mar 2004 - fields: Links;
22 Apr 2004 - fields: Links;
18 Jun 2004 - fields: Links, Proposed resolution, Status;
20 Jun 2004 - fields: Links, Status, Proposed resolution;
23 Jun 2004 - fields: Links, Status, Proposed resolution, Resolution;
19 Aug 2004 - fields: Links;
22 Aug 2004 - fields: Links;
24 Aug 2004 - fields: Links;
26 Aug 2004 - fields: Links;
30 Aug 2004 - fields: Links;
8 Sep 2004 - fields: Links, Status, Proposed resolution;
9 Sep 2004 - fields: Links;
13 Sep 2004 - fields: Links;
15 Sep 2004 - fields: Status, Proposed resolution, Revised resolution;
19 Nov 2004 - fields: In spec
After have a discussion and straw-poll at the Hawthorne NY F2F, I believe that the timing is now appropriate for me to formally to open a new issue (sub issue) 11.1 to make <assign> truely extensible.
Background:
Currently, <assign> is an BPEL extensible activity element. That means people can potentially add some other construct under <assign> to denote some of operations that the spec do not define. (So, the other operations can be still under the same atomic assignment unit.)
However, the BPEL syntax grammar (including its XMLSchema) requires at least one <copy> under <assign>. That is:
<assign standard-attributes> standard-elements <copy>+ from-spec to-spec </copy> </assign>That implies we cannot have just one extended operation under the <assign> syntax. E.g.:
<assign> <foo:barOperation ... /> </assign>
Due to the current usage of XML Schema definition, it also forces the extension element must appear before the <copy> element. E.g.: the following usage is disallowed by the current schema design:
<assign> <copy> ... </copy> <foo:barOperation ... /> </assign>
In order to have the true spirit of extensibility of <assign> syntax, we would like to suggest the following syntax changes:
The <assign> construct contains one or more elementary data manipulation operations, which are <copy> or operations defined as extension under other namespaces.
<assign standard-attributes> standard-elements ( <copy> from-spec to-spec </copy> | any-element-of-other-namespace )+ </assign>
The <copy> operation copies a type-compatible value from the source ("from-spec") to the destination ("to-spec").
[Note: the above changes go into section 9.4, starting from second paragraph]
Related Schema Change: From:
------------------------------------- <complexType name="tAssign"> <complexContent> <extension base="bpws:tActivity"> <sequence> <element name="copy" type="bpws:tCopy" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> ------------------------------------- To: ------------------------------------- <complexType name="tAssign"> <complexContent> <extension base="bpws:tActivity"> <sequence minOccurs="0"> <element name="copy" type="bpws:tCopy" /> <choice minOccurs="0" maxOccurs="unbounded"> <element name="copy" type="bpws:tCopy" /> <any namespace="##other" processContents="lax"/> </choice> </sequence> </extension> </complexContent> </complexType> -------------------------------------
[Note: the XSD changes is not that straightforward because we want to avoid the non-deterministic choice content model problem due to XSD semantics and our current usage of its extension mechansim (tActivity). Also, due to similar restrictions from XSD, the constraint of at least one data manipulation operation cannot be enforced directly by the XSD itself. BPEL implementation needs to do its own validation post XSD validation, similar to the case of enforcing that only one of multiple optional attributes at <variable> declaration is used.]
Changes: 5 Jan 2005 - new issue
A. Should we adjust the BPEL syntax (element rather than attribute content for XQuery) to prepare for the use of XQuery in future?
B. Should we change the mandatory dependency for query and expression support
from XPATH 1.0 to XPATH 2.0? Keeping in mind that XPATH 1.0 is very widely
deployed whereas XPATH 2.0 is not yet a recommendation, although it is likely
to become one in roughly the same timeframe as the final release of the specification
produced by the WSBPEL TC.
Resolution: Proposed in rkhalaf, 10 Dec 2003, decided at conf call, 21 January 2004
The proposal is to replace things with expressions and queries from being an attribute to being an element. This would affect <from>, <to> , <propertyAlias>, and conditions. This would gear up for using other languages for querying that may have a structured syntax. An example is the upcoming XQueryX, a proposal for XQuery using XML syntax. The case for string queries is also shown below.
With elements instead of attributes, we can allow one to override the default query/expression languages locally. The proposal allows for optional query/expressionLanguage attributes on queries and conditions that can locally override the global default.
Current syntax:
<wsbp:from variable="ncname" part="ncname"? query="queryString"?/><wsbp:link ... transitionCondition="..." /> <wsbp:targets joinCondition="..."> .. the same for switch's case, and the whileCondition
Proposed syntax
<wsbp:from variable="ncname" part="ncname"?> <wsbp:query queryLanguage=".."?> ? query goes here </wsbp:query> </wsbp:from>For example, an XPath 1.0 query would be encoded:
<wsbp:from variable="ncname" part="ncname"?> <wsbp:query> /shipNotice/ShipNoticeHeader/shipOrderID </wsbp:query> </wsbp:from>Conditions:
<wsbp:source ... > <wsbp:transitionCondition expressionLanguage=".."?>...</transitionCondition>? </wsbp:source>and
<wsbp:targets> <wsbp:joinCondition expressionLanguage="..."?>...</joinCondition> ? <wsbp:link.... /> </wsbp:targets>.. the same for switch's case, and the whileCondition
Close with no change to the specification.
Rationale: The referenced paper discusses different behavior (called side
effects) for processes run with or without DPE. From looking at the paper,
it seems that running processes without DPE introduces new situations where
the process just stops and never reaches the end.
Links: Announcement, 25 Jun 2003
Proposed resolution (Dieter Koenig1, 19 Jan 2004)
Peter Furniss, 26 Jan 2004
Changes: 4 Jul 2003 - fields: Document;
20 Jan 2004 - fields: Links;
26 Jan 2004 - fields: Links, Status, Proposed resolution;
4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
Whatever action we were going to take with respect to WSDL 2.0 has been taken and
therefore this issue can be closed with 'no change'.
Links: Announcement, 25 Jun 2003
Kevin Liu, 22 Sep 2003
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 4 Jul 2003 - fields: Document;
10 Sep 2003 - fields: Champion;
23 Sep 2003 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
6 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec
On step 6, how can we prevent process A from executing the invoke a
second time, creating another instance of process B, and debiting the
account a second time?
Resolution: proposed in Mike Marin, 10 Dec 2003, agreed at Melbourne face-to-face, 10 December 2003
Closed without change to the specification
Vote 18 for, 6 against, 5 abstain
Links: Mike Marin, 22 May 2003
Fred A Cummins, 22 May 2003
Mike Marin, 22 May 2003
Mark Little, 23 May 2003
Mike Marin, 23 May 2003
David RR Webber, 24 May 2003
Satish Thatte, 24 May 2003
Mark Little, 24 May 2003
Maciej Szefler, 26 May 2003
Mark Little, 27 May 2003
Maciej Szefler, 27 May 2003
Announcement, 25 Jun 2003
proposed resolution (Mike Marin, 10 Dec 2003)
Changes: 4 Jul 2003 - fields: Document, Links;
10 Dec 2003 - fields: Status, Resolution, Links
Close with no change to the specification.
Links: Mike Marin, 22 May 2003
Assaf Arkin, 27 May 2003
Maciej Szefler, 27 May 2003
Mark Little, 27 May 2003
Edwin Khodabakchian, 27 May 2003
Maciej Szefler, 27 May 2003
Edwin Khodabakchian, 27 May 2003
Maciej Szefler, 28 May 2003
Assaf Arkin, 30 May 2003
Maciej Szefler, 30 May 2003
Satish Thatte, 2 Jun 2003
Assaf Arkin, 2 Jun 2003
Announcement, 25 Jun 2003
Proposed resolution (Yaron Goland, 20 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;
21 Jan 2004 - fields: Links, Status, Proposed resolution;
27 Jan 2004 - fields: Status, Proposed resolution, Resolution
The problem is that this means that exporting a BPEL definition from one BPEL Design Time for input into another will result in a BPEL definition that will not be easily editable as all the graphical information would be lost.
In the extreme, for a complex design, it could mean that designer of business processes using BPEL is effectively locked into the BPEL Design Time software provider that they initially choose. This I don't think is a good idea.
THE SOLUTION ?
To solve this problem I would like to suggest the setting up of a sub-committe
of the TC that has responsibilty for developing a "BPEL Visual Binding" specification
which would contain the relevant visual information from the BPEL Design Time.
The idea would be that the Visual Binding specification is a separate document
to the main BPEL specification. Also BPEL Design Time Implementations could
export either:
1. The BPEL XML Definition alone, or
2. The BPEL XML Definition PLUS the BPEL Visual Binding
The former could be used for input to a BPEL Run Time and the latter could be input into some other BPEL Design Time.
By creating a separate, but related, specification, it should be possible to
carry out the work on the BPEL Visual Binding specifcation in parallel, without
hindering any work on the main BPEL specification.
Resolution: Proposed in Satish Thatte, 23 Jan 2004, decided 4 February 2004 con call
Close with no change to the
specification.
Rationale: Visual notation is a separable dimension and arguably out
of scope for this TC.
David Burdett originally opened the issue.
Discussion:
David wrote that he was agreeable to closing this, but added the suggestion that the TC make a non-binding recommendation to implementers of BPEL to provide an export file and related specification that provided information about any graphical representations of a BPEL definition. So that others could provide import facilities if they wanted to.
My response to that suggestion was that making such a recommendation will start the whole discussion about whether BPEL is meant to be directly used for design or compiled out of some higher level design metaphor. I would much prefer to avoid a discussion that would be tool specific anyway.
I suggested to David that he open a separate issue for the non-binding
recommendation if he felt that was important to have.
Links: David Burdett, 22 May 2003
Tony Andrews, 22 May 2003
David Burdett, 22 May 2003
Rajesh Pradhan, 22 May 2003
David Burdett, 23 May 2003
David RR Webber, 23 May 2003
Jim Webber, 23 May 2003
Stephen White, 23 May 2003
Edwin Khodabakchian, 23 May 2003
Waqar Sadiq, 23 May 2003
David Burdett, 23 May 2003
Waqar Sadiq, 23 May 2003
Edwin Khodabakchian, 23 May 2003
Stephen White, 23 May 2003
Maciej Szefler, 26 May 2003
David RR Webber, 27 May 2003
Rajesh Pradhan, 27 May 2003
David Burdett, 27 May 2003
Jim Webber, 27 May 2003
Waqar Sadiq, 27 May 2003
David RR Webber, 27 May 2003
Maciej Szefler, 27 May 2003
Fred A Cummins, 27 May 2003
Assaf Arkin, 27 May 2003
David RR Webber, 27 May 2003
David Burdett, 28 May 2003
David Burdett, 28 May 2003
J. Matthew Pryor, 28 May 2003
David RR Webber, 28 May 2003
David RR Webber, 29 May 2003
Assaf Arkin, 30 May 2003
Announcement, 25 Jun 2003
Satish Thatte, 23 Jan 2004
Proposed resolution (Satish Thatte, 23 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;
23 Jan 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
In practice, it is likely that some number of processes will refer to the same properties, but that these BPEL files may not be aware of one another. Thus, it would be good to explore the ability to associate multiple properties with a single property alias.
Part of this work may involve determining how to map different type specifications (which may be (probably must be) structurally "similar", but named differently) that are associated with the property definition.
This is probably a lower-level issue, not required to be addressed early
on. However, we should consider it for usability purposes.
Resolution: Proposed in Satish Thatte, 21 Jan 2004, decided 4 February 2004 con call
Close with no change to the specification.
Rationale: While generalization of type systems may be useful in some circumstances, we have stayed with XML types in BPEL for a good reason -interoperability. On the issue of property sharing, the existing mechanisms already allow the same alias to be used for many properties, so no change seems to be required there. Fred Carter originally opened the issue and he agreed with me in e-mail that the issue should be closed with no changes to the spec.
Links: Announcement, 25 Jun 2003
Proposed resolution (Satish Thatte, 21 Jan 2004)
Changes: 4 Jul 2003 - fields: Document;
21 Jan 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
currently, i beleive, a compensation handler is not installed for a faulted scope, irrespective of whether the fault is propagated-up or not.
i realize, as Satish pointed to, there are issues with allowing the fault handler to attempt alternative normal completion.
however, i would like to discuss this further to help convince ourselves that we are embarked on the right model for fault/compensation handling.
(a) Normally, if a fault handler were to be able to handle the fault itself, that is, do corrective actions (both undo and redo), then the fault is not rethrown, and the forward action can proceed as normally intended.
(b) On the other hand, if the fault handler is not able to handle the fault, perhaps it failed somewhere in its attempt to undo/redo, it rethrows the fault, and the normal execution is short-circuited.
in the case of (a), it seems reasonable to install a compensation handler, since the fault was successfully handled, and forward progress can be made. If this is not the case, the problem is that every forward action has to check if the previous action(s) had successfully completed, which is non-trivial. In such a case, the developer is most-likely going to almost *always* rethrow* a fault in order to avoid having to check for every action if the previous one(s) had successfully completed.
in the case of (b), it seems reasonable to *not* install a compensation handler, since the fault was not successfully handled, or rather the action did not completed successfully.
summary: the fact whether a fault was rethrown by a fault handler may be used
to decide whether to install a compensation handler or not. thanks.
Resolution: Proposed in message Ram Jeyaraman, 29 Sep 2003, decided in TC conf call, 1 October 2003
Closed with no further action
Links: Ram Jeyaraman, 28 May 2003
Assaf Arkin, 30 May 2003
Ram Jeyaraman, 31 May 2003
Assaf Arkin, 31 May 2003
Ram Jeyaraman, 31 May 2003
Assaf Arkin, 2 Jun 2003
David RR Webber, 2 Jun 2003
Assaf Arkin, 3 Jun 2003
David RR Webber, 3 Jun 2003
Announcement, 25 Jun 2003
Satish Thatte, 15 Sep 2003
Discussed at Redmond face-to-face
Ram Jeyaraman, 22 Sep 2003
Satish Thatte, 23 Sep 2003
Ram Jeyaraman, 24 Sep 2003
Proposed resolution (Ram Jeyaraman, 29 Sep 2003)
Ram Jeyaraman, 30 Sep 2003
Monica Martin, 30 Sep 2003
Changes: 4 Jul 2003 - fields: Document, Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
22 Sep 2003 - fields: Links;
23 Sep 2003 - fields: Links;
24 Sep 2003 - fields: Links;
30 Sep 2003 - fields: Links, Proposed resolution, Status;
1 Oct 2003 - fields: Vote announcement, Links, Status, Resolution, Proposed resolution
Closed with no further action.
Rationale:
The existing text below is considered clear enough:
The completion of the activity of a fault handler, even when it does not rethrow the fault handled, is never considered successful completion of the attached scope and compensation is never enabled for a scope that has had an associated fault handler invoked.
<scope> <receive/> <invoke/> <reply/> </scope>as
<scope> <sequence> <!-- implicit sequence --> <receive/> <invoke/> <reply/> </sequence> </scope>
Close with no change to the specification.
Rationale: The issue was originally opened by Yuzo Fujishima. There was a
discussion thread on the proposal and it was agreed that the potential
complexity of the optimization outweighted its benefit. The thread concluded
with a general agreement to close the issue but no actual proposal was made.
I (Yaron) exchanged e-mail with Yuzo in which he confirmed that he agreed that the
issue should be closed with no change to the spec.
Links: Yuzo Fujishima, 11 Jun 2003
Satish Thatte, 12 Jun 2003
Edwin Khodabakchian, 12 Jun 2003
Frank Leymann, 12 Jun 2003
Satish Thatte, 12 Jun 2003
Assaf Arkin, 12 Jun 2003
Greg Ritzinger, 12 Jun 2003
Waqar Sadiq, 12 Jun 2003
David RR Webber, 12 Jun 2003
Prasad Yendluri, 12 Jun 2003
Ugo Corda, 12 Jun 2003
Satish Thatte, 12 Jun 2003
Neelakantan Kartha, 12 Jun 2003
Assaf Arkin, 12 Jun 2003
Ugo Corda, 12 Jun 2003
Assaf Arkin, 12 Jun 2003
Ugo Corda, 12 Jun 2003
Prasad Yendluri, 12 Jun 2003
Ron Ten-Hove, 12 Jun 2003
Glenn Mi, 13 Jun 2003
Assaf Arkin, 13 Jun 2003
Announcement, 25 Jun 2003
Proposed resolution (Yaron Goland, 19 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;
31 Jul 2003 - fields: Champion;
20 Jan 2004 - fields: Links, Status, Proposed resolution;
4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
This may be possibly confusing for the readers (wondering if they missed anything).
So the redundancy needs to be either removed or explained.
Submitter's Proposal:
Either
- remove <sequence> construct
Or
- add rationale to explain it is syntactical sugar
Resolution: Proposed in message Neelakantan Kartha, 29 Aug 2003, approved at conf call 15 October 2003. (Previous approving Web ballot (ended 08 Oct 2003) was inquorate)
Add the following text in Section 12.
12 Structured Activities
... * Nondeterministic choice based on external events is provided by pick.
The set of structured activities in BPEL4WS is not intended to be the minimal required set. There are cases where one activity can replace another. For example, the sequence activity used to structure sequential processing may be emulated by a flow with additional links, to ensure sequential processing.
Structured activities can be used recursively.....
To create 2 separate schemas for validating abstract and
executable processes. Each schema would have its own URI. I will leave the
question of if/how they extend a common base schema to whoever writes the
things.
Links: Danny van der Rijn, 12 Jun 2003
John Evdemon, 12 Jun 2003
Announcement, 25 Jun 2003
Danny van der Rijn, 12 Dec 2003
Yaron Goland, 12 Dec 2003
John Evdemon, 12 Dec 2003
Danny van der Rijn, 13 Dec 2003
John Evdemon, 13 Dec 2003
Danny van der Rijn, 13 Dec 2003
Jim Clune, 15 Dec 2003
Satish Thatte, 16 Dec 2003
John Evdemon, 16 Dec 2003
Danny van der Rijn, 16 Dec 2003
Jim Clune, 16 Dec 2003
Satish Thatte, 18 Dec 2003
Eckenfels. Bernd, 18 Dec 2003
Proposed resolution (Danny van der Rijn, 7 Jan 2004)
David RR Webber, 7 Jan 2004
Discussed at 21 January 2004, deferred pending schema development
Philip Rossomando, 26 Jan 2004
Philip Rossomando, 2 Feb 2004
Philip Rossomando, 2 Feb 2004
Alex Yiu, 2 Feb 2004
Philip Rossomando, 6 Feb 2004
Diane Jordan, 6 Feb 2004
John Evdemon, 6 Feb 2004
Ben Bloch, 6 Feb 2004
John Evdemon, 6 Feb 2004
Alex Yiu, 6 May 2004
Alex Yiu, 11 May 2004
Alex Yiu, 11 May 2004
Changes: 4 Jul 2003 - fields: Document, Links;
31 Jul 2003 - fields: Champion;
13 Dec 2003 - fields: Links;
16 Dec 2003 - fields: Links;
23 Dec 2003 - fields: Links;
7 Jan 2004 - fields: Links, Status, Proposed resolution;
27 Jan 2004 - fields: Links;
2 Feb 2004 - fields: Links;
3 Feb 2004 - fields: Links;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Links;
6 May 2004 - fields: Links;
11 May 2004 - fields: Links
<compensationHandler> <compensate/> </compensationHandler>Although this require more XML elements to be defined, it allows the compensation handling behavior to be turned on and off for the process and a scope by simply electing not to define a compensation handler. At any rate, the ability to disable compensation for a scope is also required if a process attempts to invoke compensation handlers for invoked services from compensation handlers associated with the invoke activity's scope.
Remove instance (process) compensation handlers
Remove the enableInstanceCompensation attribute
Rationale: See minutes of Melbourne and Walldorf meetings, and discussion under issue 53 : Include Business Transaction Management (BTM) constructs especially Process Coordination in BPEL Final.ppt (document details)
Links: Announcement, 26 Jun 2003
Satish Thatte, 11 Aug 2003
Assaf Arkin, 11 Aug 2003
Satish Thatte, 11 Aug 2003
Assaf Arkin, 11 Aug 2003
Satish Thatte, 11 Aug 2003
Assaf Arkin, 20 Aug 2003
Satish Thatte, 20 Aug 2003
Monica Martin, 26 Aug 2003
Satish Thatte, 15 Sep 2003
Assaf Arkin, 16 Sep 2003
Discussed at Redmond face-to-face
Proposed resolution (Yaron Y. Goland, 31 Mar 2004)
Discussed at Walldorf f-t-f (document details)
Discussed at 14 April con call (document details)
Web ballot (ended 28 Apr 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;
31 Jul 2003 - fields: Champion;
12 Aug 2003 - fields: Links;
20 Aug 2003 - fields: Links;
26 Aug 2003 - fields: Links;
15 Sep 2003 - fields: Links;
16 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
25 Mar 2004 - fields: Categories;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Rationale, Vote announcement, Links;
20 Jun 2004 - fields: In spec
<scope name="X"> <source link="A" transition=".."/> <source link="B"/> <compensationHandler/> .. do something </scope>
The scope activity executes to completion. Some activities were performed that have side-effects and so a compensation handler was defined and got installed. The activity can now be compensated. The status of link B would be set to true, the status of link A would be set based on the value of the transition condition. The transition condition happens to generate a fault. What happens next?
A fault handler would be invoked in the enclosing scope and would compensate
for the work done by the scope activity. If the targets of link A and link B
are enclosed in the same scope then neither one would execute. But what if the
target of link A and link B is in some other scope. What would be the status
of the links? If the status of link A is true that may conflict with the intent
of the transition condition that may set it to false realizing that some pre-condition
has not been met. If the status of link A is false that would consist with the
activity being compensated immediately after completion. But the case must be
made that the status of link B should also be set to false for consistency.
Qualifier: clarification
Resolution: Proposed in Assaf Arkin, 1 Oct 2003, repeated in Assaf Arkin, 11 Oct 2003, decided at 15 October 2003, with the addition at the end
Add the following paragraph to the specification in the description of how links are handled (pages 64/65):
Note that the transition condition is evaluated after the activity has completed. If an error occurs while evaluating the transition condition, that error does not affect the completion status of the activity and is handled by the activity's enclosing scope. In the case of scopes, completion does not necessarily imply successful completion. A scope may suffer an internal fault and yet complete (unsuccessfully) if there is a corresponding fault handler associated with the scope and that fault handler completes without throwing a fault.
Yaron Goland and Assaf Arkin will ensure that appropriate text to note the
implementation implications is included in the spec.
Links: Announcement, 26 Jun 2003
Satish Thatte, 15 Sep 2003
Discussed at Redmond face-to-face - see last slide of Satish's presentation (document details)
Assaf Arkin, 18 Sep 2003
Satish Thatte, 18 Sep 2003
Assaf Arkin, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Satish Thatte, 30 Sep 2003
Assaf Arkin, 30 Sep 2003
Satish Thatte, 30 Sep 2003
Proposed resolution (Assaf Arkin, 1 Oct 2003)
Repeat of proposed resolution (Assaf Arkin, 11 Oct 2003)
Ashwini Surpur, 16 Oct 2003
Prasad Yendluri, 16 Oct 2003
Satish Thatte, 17 Oct 2003
Ron Ten-Hove, 17 Oct 2003
Satish Thatte, 17 Oct 2003
Assaf Arkin, 20 Oct 2003
Satish Thatte, 20 Oct 2003
Assaf Arkin, 21 Oct 2003
Satish Thatte, 23 Oct 2003
Maciej Szefler, 27 Oct 2003
Harvey Reed, 27 Oct 2003
Satish Thatte, 27 Oct 2003
Maciej Szefler, 27 Oct 2003
Maciej Szefler, 27 Oct 2003
Satish Thatte, 27 Oct 2003
Assaf Arkin, 27 Oct 2003
Assaf Arkin, 27 Oct 2003
Changes: 4 Jul 2003 - fields: Origin, Links;
31 Jul 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links, Proposed resolution;
26 Sep 2003 - fields: Links;
30 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Links, Status, Proposed resolution;
8 Oct 2003 - fields: Vote announcement;
11 Oct 2003 - fields: Proposed resolution, Links;
15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution;
17 Oct 2003 - fields: Links;
20 Oct 2003 - fields: Links;
21 Oct 2003 - fields: Links;
23 Oct 2003 - fields: Links;
27 Oct 2003 - fields: Links;
9 Jun 2004 - fields: In spec
getVariable( getVariable( 'name' ) )
An expression of this form is supported by the current specification, but hinders
the ability to perform static analysis on the use of variables within the activity.
This could be mitigated by clarifying the use of BPEL functions such that their
input arguments must be literals. However, this goes against the XPath specification
that makes no such restriction. An alternative would be to use XPath variables
which are precluded from this dynamic behavior as per the XPath specification.
(Assuming this restriction is still part of XPath 2.0 and XQuery).
Qualifier: enhancement
Links: Announcement, 26 Jun 2003
Satish Thatte, 15 Sep 2003
Next messages are in Issue 3 discussion
Yaron Goland, 8 Oct 2003
Edwin Khodabakchian, 8 Oct 2003
Satish Thatte, 8 Oct 2003
Danny van der Rijn, 8 Oct 2003
Assaf Arkin, 9 Oct 2003
Assaf Arkin, 20 Oct 2003
Yaron Goland, 21 Oct 2003
Changes: 4 Jul 2003 - fields: Origin, Links;
31 Jul 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
9 Oct 2003 - fields: Links;
20 Oct 2003 - fields: Links;
21 Oct 2003 - fields: Links
Clarify use of coordination protocol to:
Clarify how a compensation handler in the process is used to invoke compensation handler of a service such coordinated. Clarify how the compensation handler of the process is invoked by such a service. Clarify how parameters are passed to and from compensation handler when invoked in such a manner.
Clarify the relationship between the scope in which an invocation is performed and the context that governs the coordination, where to wait for the completion of work by the participant, when to cancel such work, and how to be notified of general failure.
Also, investigate means to determine whether service supports
coordination as part of the process definition (where only its interface
is known), and how a process advertises this capability as part of its
interface definition, e.g. using WSDL 1.2 F&P.
Revisitable: Yes
Qualifier: enhancement
Resolution: Proposed in Peter Furniss, 31 Mar 2004, decided by Web ballot (ended 28 Apr 2004) , after straw poll at Walldorf ftf
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Jun 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;
31 Jul 2003 - fields: Champion;
25 Mar 2004 - fields: Categories;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
A generic solution would introduce a new function that would generate a unique value, e.g. a UUID. A more specific solution would grant the process a single unique value that could be, e.g. the process instance identifier, accessible from a function or contained in a well defined variable/property.
Another solution would have the process use a property from the input message
that is equivalent to the message identifier as specified by WS-Addressing.
However, a complication may occur if the process is instantiated by two concurrent
receive activities, either of which can decide on the correlation set value
to use.
Revisitable: Yes
Qualifier: enhancement
Resolution: Proposed verbally by Yaron Goland and decided at San Francisco f-t-f
Close with no change to spec.
Rationale: It can be assumed that platform-specific mechanisms are available to generate
a unique identifier.
Links: Announcement, 26 Jun 2003
Changes: 4 Jul 2003 - fields: Origin, Links;
31 Jul 2003 - fields: Champion;
22 Jun 2004 - fields: In spec, Resolution, Rationale, Status, Revisitable
Each thread maintains its own copy of link status.
Specification to be aligned with this resolution.
Links: Yuzo Fujishima, 26 May 2003
Satish Thatte, 26 May 2003
Yuzo Fujishima, 2 Jul 2003
Edwin Khodabakchian, 2 Jul 2003
Yuzo Fujishima, 3 Jul 2003
Chunbo Huang, 3 Jul 2003
Edwin Khodabakchian, 3 Jul 2003
Announcement, 4 Jul 2003
Yuzo Fujishima, 5 Jul 2003
Dieter Roller, 5 Jul 2003
Frank Leymann, 5 Jul 2003
Francisco Curbera, 7 Jul 2003
Yuzo Fujishima, 7 Jul 2003
Yuzo Fujishima, 7 Jul 2003
Dieter Roller, 7 Jul 2003
Francisco Curbera, 7 Jul 2003
Assaf Arkin, 7 Jul 2003
Dieter Roller, 8 Jul 2003
Dieter Roller, 15 Sep 2003
Discussed at Redmond face-to-face - resolution to be proposed
Proposed resolution (Yuzo Fujishima, 27 Sep 2003)
Changes: 3 Jul 2003 - new issue;
4 Jul 2003 - fields: Links;
7 Jul 2003 - fields: Links;
9 Jul 2003 - fields: Links;
31 Jul 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
27 Sep 2003 - fields: Links;
30 Sep 2003 - fields: Proposed resolution, Status;
1 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Resolution;
9 Jun 2004 - fields: In spec
Handling Callbacks in a Business Process (especially if it is done as suggested in the Initial Example of the 1.1 Spec) is depending on unspecified runtime engine behavior.
If we assume, that a new entry for a correlation set is entered on activation of the receive, and we also assume, that incoming web service requests on ports which have no matching correlation are rejected, we have a small window in the system, where a particular information was requested, but the related receive activity was not yet activated. This could be, because the requested party will answer, before the SOAP communication was finished, it could also be, because the runtime engine is loaded, to not enable the receive fast enough. It could also be because the runtime engine was putting the process to sleep because or priority issues.
The specification should either enforce a semantic which will allow <sequence><invoke><receive></sequence> process, and force implementers to keep that case in mind, or the specification should endorse (and then actually use in its own samples) an alternative way.
Please keep in mind, that it might not be enough to assure, that implementations can handle the response to an invoke of the directly following activity. Flows and sub process could be involved, too. In the case of flows, the current spec does not assume any implementations, which is good for implementing conforming engines, but it is also bad for specific modeling techniques which may be unsafe to use. A good sample would be a <flow><receive /><invoke /></flow> which also has the same (maybe even bigger) race condition window to allow callbacks.
A process which creates a correlation id, waits for the response and then invokes the service is a typical use case. Issue 31 is a feature request which would depend on this, and will suffers from the same unspecified behavior.
Alternative solution (which is a bit overhead, unfortunately): allow a new link
type "ready to receive" from receive components to invoke components, which
will be enabled, as soon as the corresponding correlation entry is made, and
the system is listening for the callback. Brainstorming welcome.
Resolution: Proposed in Eckenfels. Bernd, 14 Apr 2004, decided by Web ballot (ended 28 Apr 2004)
Include an explanation (final wording from the editing team), that it is accepted that messages with legal outstanding correlations may arrive after the correlation set is instantiated but before the actual receive is activated and that such messages should be processed. Modellers can assume that it is safe to rely on this (since there is no bpel construct to implement it otherwise).
There is no need for a precise definition of when it is legal/required for the engine to to look ahead and what timeouts to assume. Therefore it is not possible to include samples like "receive or a callback in a sequnece directly after the invoke". The text should address the modeller's expectations and not to explicitly define requirements to the engine, since we are not yet down that conformance definition road in other places.
There are other places where the bpel spec does not require a specific timing (e.g. invoke and receive in parallel
in a flow), where the same expectations of the modeller should be acknolwledged.
Vote announcement: Web ballot (ends 28 Apr 2004)
Links: issue 31 : Unique identifier for establishing new correlation
Announcement, 9 Jul 2003
Eckenfels. Bernd, 10 Jul 2003
Eckenfels. Bernd, 12 Aug 2003
Proposed resolution (Eckenfels. Bernd, 29 Mar 2004)
Revised proposal (Eckenfels. Bernd, 14 Apr 2004)
Eckenfels. Bernd, 14 Apr 2004
Kevin Liu, 27 Apr 2004
Eckenfels. Bernd, 28 Apr 2004
Changes: 9 Jul 2003 - new issue;
10 Jul 2003 - fields: Links;
31 Jul 2003 - fields: Champion;
12 Aug 2003 - fields: Links;
29 Mar 2004 - fields: Links, Status, Proposed resolution;
15 Apr 2004 - fields: Proposed resolution, Links;
22 Apr 2004 - fields: Vote announcement;
29 Apr 2004 - fields: Links, Status, Proposed resolution, Resolution;
20 Jun 2004 - fields: In spec
A "service-ref" wrapper will be defined:
<xs:element name="service-ref" type= tns:ServiceRefType /> <xs:complexType name="ServiceRefType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attribute name="reference-scheme" type="xs:anyURI" use="required"/> </xs:complexType>
The partnerlink should contain this "service-ref" element for the endpoint references of partnerRole or myRole.
e.g.:
<service-ref reference-scheme="http://foo.org"> <foo:barEPR xmlns:foo="http://foo.org"> ... </foo:barEPR> </service-ref>
When including this in the spec., the editing team will include explanations of error handling and the motivation for this construct. The solution will include a clarification to the reference-scheme attribute.
Rationale: It may take more than few months for the industry to converge on ONE single addressing or EPR scheme.
Instead of keep delaying BPEL TC itself, we should leave it open. And let the industry take its own
course to find out its convergence point. BPEL spec should be as flexible as possible to allow the convergence happen.
Even after the industry has converged into one addressing or EPR scheme in future, we may still need to face the versioning issue.
For WSA alone, we already have two versions floating around:
http://schemas.xmlsoap.org/ws/2003/03/addressing
http://schemas.xmlsoap.org/ws/2004/03/addressing
WSA by itself already presents us the version conversion problem. The solution of this problem would require the semantics listed above.
Links: Ron Ten-Hove, 16 May 2003
Announcement, 9 Jul 2003
Monica J. Martin, 31 Mar 2004
Monica J. Martin, 1 Apr 2004
Ron Ten-Hove, 6 May 2004
Proposed resolution (Ron Ten-Hove, 7 May 2004)
Yaron Y. Goland, 14 May 2004
Ron Ten-Hove, 17 May 2004
Yaron Y. Goland, 18 May 2004
Proposed resolution (Yaron Y. Goland, 18 May 2004)
Ron Ten-Hove, 18 May 2004
Francisco Curbera, 19 May 2004
Frank Ryan, 19 May 2004
Ron Ten-Hove, 19 May 2004
John Evdemon, 19 May 2004
Ron Ten-Hove, 19 May 2004
Ron Ten-Hove, 19 May 2004
Steve Ross-Talbot, 19 May 2004
John Evdemon, 19 May 2004
Assaf Arkin, 19 May 2004
Francisco Curbera, 25 May 2004
Ron Ten-Hove, 25 May 2004
Yaron Y. Goland, 26 May 2004
Satish Thatte, 26 May 2004
Martin Chapman, 26 May 2004
Satish Thatte, 26 May 2004
Ugo Corda, 26 May 2004
Monica J. Martin, 26 May 2004
Satish Thatte, 26 May 2004
Jeff Mischkinsky, 28 May 2004
Jeff Mischkinsky, 28 May 2004
Monica J. Martin, 28 May 2004
Francisco Curbera, 29 May 2004
Peter Furniss, 30 May 2004
Alex Yiu, 21 Jun 2004
Ron Ten-Hove, 22 Jun 2004
Alex Yiu, 30 Jun 2004
Ron Ten-Hove, 30 Jun 2004
John Evdemon, 1 Jul 2004
Prasad Yendluri, 2 Jul 2004
Alex Yiu, 3 Jul 2004
Prasad Yendluri, 3 Jul 2004
Alex Yiu, 14 Jul 2004
Prasad Yendluri, 14 Jul 2004
Ron Ten-Hove, 14 Jul 2004
Alex Yiu, 15 Jul 2004
Prasad Yendluri, 15 Jul 2004
Changes: 9 Jul 2003 - new issue;
10 Jul 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
31 Mar 2004 - fields: Links;
1 Apr 2004 - fields: Links;
6 May 2004 - fields: Links, Status, Proposed resolution;
8 May 2004 - fields: Links, Status, Proposed resolution;
15 May 2004 - fields: Links;
18 May 2004 - fields: Links, Status, Proposed resolution;
19 May 2004 - fields: Links;
20 May 2004 - fields: Links;
25 May 2004 - fields: Links;
26 May 2004 - fields: Links;
27 May 2004 - fields: Links;
30 May 2004 - fields: Links;
2 Jun 2004 - fields: Links, Proposed resolution;
16 Jun 2004 - fields: Categories;
22 Jun 2004 - fields: Links;
23 Jun 2004 - fields: Status, Vote, Resolution, Rationale;
30 Jun 2004 - fields: Links;
1 Jul 2004 - fields: Links;
3 Jul 2004 - fields: Links;
16 Jul 2004 - fields: Links;
17 Aug 2004 - fields: In spec
A more detailed explanation is provided by Frank Leymann at the end of Frank Leymann, 6 Jul 2003
Qualifier: enhancement
Resolution: Proposed in Satish Thatte, 22 Jan 2004, decided 4 February 2004 con call
Close with no change to the specification.
Rationale: while modeling is a very important requirement it is a
big and non-trivial requirement that goes well beyond what we have set
ourselves as goals. Assaf Arkin originally opened the issue and he
agreed with me in e-mail that the issue should be closed with no changes
to the spec since the issue has been dormant anyway. There was no
additional discussion.
Links: Announcement, 9 Jul 2003
Proposed resolution (Satish Thatte, 22 Jan 2004)
Changes: 9 Jul 2003 - new issue;
10 Jul 2003 - fields: Links;
31 Jul 2003 - fields: Champion;
22 Jan 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
An input message targeting that event handler is received by the process (M1). A new instance of the event handler is started, the message is assigned to the specified variable and work begins based on the value of that variable.
At which point another input message targeting the same event handler is recieved by that process (M2). A new instance of the event handler is started, the message is assigned to the specified variable and work begins based on the value of that variable.
Except that the first instance has not completed all work yet. While it started performing some work using the variable value from M1, it suprisingly finds that the new value of the variable is coming from M2.
Currently the spec does not indicate that these two instances will be serialized with respect to each other, nor that these two variables are distinct and not the same (variable instances are per process or some enclosing scope). Scoping does not alleviate the race condition since a new scope must be created and the values assigned to its variables, giving enough overlap between the two instances for a race condition to exist.
There seems to be no measure in the spec that allows for multiple
instances of an event handler to occur concurrently, yet the spec
suggests that this is possible.
Qualifier: enhancement, clarification
Related issue: issue 79 : Serializable scopes do not need to be leaf scopes
Resolution: Proposed in Assaf Arkin, 11 Oct 2003, decided at 15 October 2003
The semantics of event handler would be changed to allow the variable used to capture the input message to be treated local to the event handler instance:
The above is a statement of the intent, the editing group will review the text with
the issue champion, Assaf Arkin
Links: Announcement, 9 Jul 2003
Dieter Roller, 18 Jul 2003
Edwin Khodabakchian, 18 Jul 2003
Monica J. Martin, 18 Jul 2003
Edwin Khodabakchian, 1 Aug 2003
Dieter Roller, 15 Sep 2003
Discussed at Redmond face-to-face
Maciej Szefler, 19 Sep 2003
Edwin Khodabakchian, 19 Sep 2003
Francisco Curbera, 21 Sep 2003
Edwin Khodabakchian, 21 Sep 2003
Maciej Szefler, 22 Sep 2003
Steve Brown, 22 Sep 2003
Edwin Khodabakchian, 22 Sep 2003
Satish Thatte, 22 Sep 2003
Francisco Curbera, 24 Sep 2003
Maciej Szefler, 25 Sep 2003
Maciej Szefler, 25 Sep 2003
Yaron Goland, 25 Sep 2003
Satish Thatte, 25 Sep 2003
Maciej Szefler, 25 Sep 2003
Satish Thatte, 25 Sep 2003
Monica Martin, 26 Sep 2003
Assaf Arkin, 26 Sep 2003
Assaf Arkin, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Edwin Khodabakchian, 26 Sep 2003
Assaf Arkin, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Edwin Khodabakchian, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Edwin Khodabakchian, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Assaf Arkin, 26 Sep 2003
Satish Thatte, 26 Sep 2003
Assaf Arkin, 30 Sep 2003
Edwin Khodabakchian, 30 Sep 2003
Assaf Arkin, 30 Sep 2003
Satish Thatte, 30 Sep 2003
Edwin Khodabakchian, 30 Sep 2003
Assaf Arkin, 30 Sep 2003
Satish Thatte, 30 Sep 2003
Proposed resolution (Assaf Arkin, 1 Oct 2003)
Satish Thatte, 1 Oct 2003
Yaron Goland, 1 Oct 2003
Assaf Arkin, 2 Oct 2003
Harvey Reed, 2 Oct 2003
Assaf Arkin, 2 Oct 2003
Harvey Reed, 2 Oct 2003
Danny van der Rijn, 2 Oct 2003
Francisco Curbera, 3 Oct 2003
Assaf Arkin, 3 Oct 2003
Edwin Khodabakchian, 3 Oct 2003
Satish Thatte, 3 Oct 2003
Revised proposed resolution (Assaf Arkin, 11 Oct 2003)
Prasad Yendluri, 17 Oct 2003
Satish Thatte, 17 Oct 2003
Assaf Arkin, 17 Oct 2003
Changes: 9 Jul 2003 - new issue;
10 Jul 2003 - fields: Links;
20 Jul 2003 - fields: Links;
31 Jul 2003 - fields: Champion;
1 Aug 2003 - fields: Links;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
20 Sep 2003 - fields: Links;
22 Sep 2003 - fields: Links;
23 Sep 2003 - fields: Links;
25 Sep 2003 - fields: Links;
26 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Links, Status, First proposed resolution;
2 Oct 2003 - fields: Links;
3 Oct 2003 - fields: Links;
6 Oct 2003 - fields: Links;
8 Oct 2003 - fields: Vote announcement;
11 Oct 2003 - fields: Links, Proposed resolution;
15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution;
17 Oct 2003 - fields: Links;
12 Nov 2003 - fields: Related issue;
9 Jun 2004 - fields: In spec
What will happen if a correlation set is initiated more than once during the lifetime of the corresponding scope?
Quote from 10.2 Defining and Using Correlation Sets:
After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until its completion.
Candidates are:
A. bpws:correlationViolation fault is always thrown.
B. bpws:correlationViolation fault is thrown only if the new property values are different from the old ones.
C. The old property values remain valid and no fault is thrown.
The new property values are ignored.
Resolution: Proposed in Alex Yiu, 23 Jun 2004, decided at San Francisco f-t-f
The "initiate" attribute becomes a tri-value switch instead of a boolean switch. The legal values of the "initiate" attribute are: "yes", "rendezvous", "no". The default value of the attribute remains "no".
After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until the completion of the scope. This correlation consistency constraint must be observed in all cases of "initiate" values.
Affected Sections:
There may be good rationale for supporting such constructs. However, no
good rationale has been given in the spec. An explicit description of the
rationale for including such redundancy, or the purpose it serves would
be helpful in weighing up other changes to the specification.
Qualifier: clarification
Resolution: Proposed in Yaron Goland, 19 Jan 2004, decided 4 February 2004 con call
Close with no change to the specification.
Rationale: I (Yaron) talked with Assaf Arkin, who opened the issue and he agreed
that the resolution to issue 23 : Rationale for sequence vs. flow also resolved this issue. Therefore he
agrees to having this issue closed without change to the specification.
Links: Announcement, 13 Jul 2003
Proposed resolution (Yaron Goland, 19 Jan 2004)
Changes: 13 Jul 2003 - new issue;
13 Jul 2003 - fields: Links;
31 Jul 2003 - fields: Champion;
20 Jan 2004 - fields: Links, Status, Proposed resolution;
4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
On page 38:
<bpws:propertyAlias propertyName="tns:taxpayerNumber" messageType="txmsg:taxpayerInfo" part="identification" query="/socialsecnumber"/>instead of query="/identification/socialsecnumber"
On page 49:
<bpws:propertyAlias propertyName="cor:customerID" messageType="tns:POMessage" part="PO" query="/PO/CID"/>(and similarly the three following propertyAlias elements in the same example)
On page 92:
<bpws:propertyAlias propertyName="tns:shipOrderID" messageType="sns:shippingNoticeMsg" part="shipNotice" query="/ShipNoticeHeader/shipOrderID"/>instead of query="/shipNotice/ShipNoticeHeader/shipOrderID" (and similarly the four following propertyAlias elements in the same example)
It seems that the example on page 49 is correct and the other ones are wrong.
In fact, sec. 14.3, Assignment, says:
"For XPath 1.0, the value of the query attribute MUST be an absolute locationPath (with '/' meaning the root of the document fragment representing the entire part). It is used to identify the root of a subtree within the document fragment representing the part."and sec. 8.2, Defining Properties, says:
"The interpretation of the message, part, and query attributes is the same as in the corresponding from-spec in copy assignments (see Assignment).
See text in message Ugo Corda, 18 Aug 2003
Close with no change to the specification.
Rationale: The issue was originally opened by Peter Furniss based on a
complaint by Alastair Green. I (Yaron) talked with Peter and he agreed that he has
gotten used to the naming and so has no objections to the issue being closed
with no action.
Links: Announcement, 24 Jul 2003
Proposed resolution (Yaron Goland, 19 Jan 2004)
Peter Furniss, 22 Jan 2004
Satish Thatte, 26 Jan 2004
Changes: 24 Jul 2003 - new issue;
25 Jul 2003 - fields: Links;
20 Jan 2004 - fields: Links, Status, Proposed resolution;
23 Jan 2004 - fields: Links;
26 Jan 2004 - fields: Links;
4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale;
9 Jun 2004 - fields: In spec
The editorial error on page 25 will be corrected to align with the definition on page 80
Links: Announcement, 31 Jul 2003
Discussed at Redmond face-to-face - resolution to be proposed
Ram Jeyaraman, 21 Sep 2003
Satish Thatte, 23 Sep 2003
John Evdemon, 23 Sep 2003
Changes: 31 Jul 2003 - new issue;
31 Jul 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
18 Sep 2003 - fields: Links;
22 Sep 2003 - fields: Links;
23 Sep 2003 - fields: Links;
24 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Status, Resolution;
9 Jun 2004 - fields: In spec
Close without change to the specification.
Rationale: Although the use and definitions of formalisms can be useful in understanding and defining a specification, including such in a formal description as normative in a specification that is also in natural language and less formal expressions has the drawbacks:
Separate formal descriptions of bpel, not included in the specification and without normative authority are encouraged. The TC will establish a publically-accessible space in the website for supplementary information on formalism with appropriate links.
Links: Sid Askary, 28 Jul 2003
Steve Ross-Talbot, 28 Jul 2003
Ron Ten-Hove, 28 Jul 2003
Announcement, 31 Jul 2003
Proposed resolution (Peter Furniss, 20 Feb 2004)
Peter Furniss, 20 Feb 2004
Satish Thatte, 22 Feb 2004
Frank Leymann, 22 Feb 2004
Ron Ten-Hove, 23 Feb 2004
Changes: 31 Jul 2003 - new issue;
31 Jul 2003 - fields: Links;
23 Feb 2004 - fields: Links, Status, Proposed resolution;
25 Feb 2004 - fields: Links;
3 Mar 2004 - fields: Status, Proposed resolution, Resolution, Rationale, Revisitable
<onAlarm for="duration-expr"? until="deadline-expr"? repeat="duration-expr"? frequency="cardinal-expr"?>* alarmActivity </onAlarm>
The text as proposed (and copied here) will be modified in line with the resolution of issue 13 : Future Usage of XPATH 2.0 and XQuery 1.0 , changing the attributes to elements.
The syntax for onAlarm element be changed to:
<onAlarm for="duration-expr"? until="deadline-expr"? repeatEvery="duration-expr"?> activity </onAlarm>repeatEvery can appear on its own, or with one of the other two attributes. If on its own, the semantics of repeatEvery are that from the time that the event handler is instantiated until it is un-instantiated an event handler will be created every duration-expr period. Like onEvent handlers each onAlarm handler created as a consequence of a repeatEvery exists independently of all other instances.
If one of "for" or "until" attributes and "repeatEvery" are present, the event
handler is not created until the "for" or "until" attribute time; thereafter
it is recreated at the interval defined by "repeatEvery".
Links: Ram Jeyaraman, 29 Jul 2003
Dieter Roller, 29 Jul 2003
Ram Jeyaraman, 29 Jul 2003
Announcement, 31 Jul 2003
Discussed at Redmond face-to-face
Ram Jeyaraman, 21 Sep 2003
Satish Thatte, 23 Sep 2003
Ben Bloch, 23 Sep 2003
Satish Thatte, 23 Sep 2003
Ben Bloch, 24 Sep 2003
Satish Thatte, 24 Sep 2003
Ram Jeyaraman, 24 Sep 2003
Proposed resolution (Yaron Y. Goland, 16 Jun 2004)
Satish Thatte, 18 Jun 2004
Yaron Y. Goland, 21 Jun 2004
Edwin Khodabakchian, 21 Jun 2004
Frank Leymann, 22 Jun 2004
Changes: 31 Jul 2003 - new issue;
31 Jul 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
18 Sep 2003 - fields: Links;
22 Sep 2003 - fields: Links;
23 Sep 2003 - fields: Links;
24 Sep 2003 - fields: Links;
17 Jun 2004 - fields: Links, Status, Proposed resolution;
19 Jun 2004 - fields: Links;
22 Jun 2004 - fields: Links;
24 Jun 2004 - fields: Status, Proposed resolution, Resolution;
17 Aug 2004 - fields: In spec
A partnerLinkType do refer to a maximum of two portTypes. Assuming that a process
does not invokes itself, then the Invoke refers to the partnerRole, not myRole, so
there is only one possible portType, for that Invoke. In the other hand, if we assume
the process can invoke itself, then it will be better to specify the role in the
Invoke activity instead of the portType, because role has process semantics instead
of the portType.
Submitter's Proposal: I propose that portType on the Invoke activity be removed and
instead an optional role be included instead. When the role is specified, it must
correspond to one of the two roles defined in the partnerLink. If the role is not
specified the partnerRole in the partnerLink should be assumed.
First resolution: proposed in message Mike Marin, 19 Aug 2003, decided in TC conf call, 20 August 2003
Remove the portType from the invoke activity and use the portType that corresponds to the partnerRole in the partnerLink.This covers most if not all the use cases. With the only exception of a process that wants to call itself, which is discussed by issue 52
It is moved that the portType attribute be made optional.
If the portType attribute is included in a message activity then the
value of the portType attribute MUST match the portType value implied by
the combination of explicitly specified partnerLink and the role
implicitly specified by the message activity. A failure to match as
previously described MUST result in a static checking error.
Links: Announcement, 5 Aug 2003
Satish Thatte, 11 Aug 2003
Satish Thatte, 11 Aug 2003
Mike Marin, 11 Aug 2003
Satish Thatte, 11 Aug 2003
Yaron Goland, 12 Aug 2003
Satish Thatte, 12 Aug 2003
Eckenfels. Bernd, 12 Aug 2003
Danny van der Rijn, 12 Aug 2003
Yaron Goland, 13 Aug 2003
Satish Thatte, 14 Aug 2003
Monica Martin, 17 Aug 2003
Mike Marin, 19 Aug 2003
see also issue 52
Yaron Goland, 19 Aug 2003
Mike Marin, 19 Aug 2003
Yaron Goland, 19 Aug 2003
Kevin Liu, 16 Oct 2003
Satish Thatte, 16 Oct 2003
Chris Keller, 16 Oct 2003
Kevin Liu, 16 Oct 2003
Satish Thatte, 16 Oct 2003
Yaron Goland, 20 Oct 2003
Proposed resolution (Yaron Y. Goland, 4 Jun 2004)
Changes: 5 Aug 2003 - new issue;
5 Aug 2003 - fields: Links;
12 Aug 2003 - fields: Links;
14 Aug 2003 - fields: Links;
18 Aug 2003 - fields: Links;
19 Aug 2003 - fields: Links;
20 Aug 2003 - fields: Status, Resolution;
16 Oct 2003 - fields: Links;
17 Oct 2003 - fields: Links;
20 Oct 2003 - fields: Links;
4 Nov 2003 - fields: Status, First resolution (renamed from Resolution), Reopened;
9 Jun 2004 - fields: Links, Status, Proposed resolution;
22 Jun 2004 - fields: Status, Proposed resolution, Resolution;
17 Aug 2004 - fields: In spec
"The while activity supports repeated performance of a specified iterative activity. The iterative activity is performed until the given Boolean while condition no longer holds true."
The use of the word "until" in the description can cause the reader to conflate the semantics of the
"while" activity with a (currently) non-existent "repeat-until" activity that evaluates the condition
after the loop has executed, and therefore always executes at least once.
Submitter's proposal: Change the wording to read:
"The while activity supports repeated performance of a specified iterative activity. The iterative activity is performed as long as the given Boolean while condition holds true."
To be referred to the editorial committee.
In XPath 1.0 there is no default namespace for evaluation meaning that all names need to be qualified with a prefix. In XPath 2.0 there is the use of a default namespace, but this specification is referencing 1.0. Putting that aside for a moment in both 1.0 and 2.0 no namespace is not equal to default namespace. Let's take an example:
<message name="poMessage"> <part name="PO" type="tns:purchaseOrder"/> </message><bpws:property name="poNumber" type="xsd:positiveInteger"/>
<bpws:propertyAlias propertyName="tns:poNumber" messageType="tns:poMessage" part="PO" query="/PO/Header/PONumber"/>
</bpws:propertyAlias>
If as suggested in issue 39 we assume that the Part PO is included in the query and has no namespace (namespace URI is null) association. This query in order to be correct in XPath should be formulated as:
/PO/tns:Header/tns:PONumber
Note the section Node Tests from XPath 1.0 – section 2.3 Node Tests)
"A node test that is a QName is true if and only if the type of the node (see [5 Data Model]) is the principal node type and has an expanded-name equal to the expanded-name specified by the QName. For example, child::para selects the para element children of the context node; if the context node has no para children, it will select an empty set of nodes. attribute::href selects the href attribute of the context node; if the context node has no href attribute, it will select an empty set of nodes.A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration n the expression context."
Note the statement "except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null"
Now in XPath 2.0 it is slightly different (XPath 2.0 section 3.2.1.2 Node Tests)
"A node test that consists of a QName is called a name test. A name test is true if and only if the kind of the node is the principal node kind and the expanded-QName of the node is equal to the expanded-QName specified by the name test. For example, child::para selects the para element children of the context node; if the context node has no para children, it selects an empty set of nodes. attribute::abc:href selects the attribute of the context node with the QName abc:href; if the context node has no such attribute, it selects an empty set of nodes.
A QName in a name test is expanded into an expanded-QName using the in-scope namespaces in the expression context. It is a static error if the QName has a prefix that does not correspond to any in-scope namespace. An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespaceURI of the default element namespace in the expression context; otherwise, it has no namespaceURI."
Note the statement: "An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespaceURI of the default element namespace in the expression context; otherwise, it has no namespaceURI."
So in either case we need to qualify the namespace for your message
part declared as a type example. And if we are following the XPath 1.0
specification we should qualify all elements that have a namespace
since no default namespace is applied. In this case basically every
query in the bpel specification is incorrect and should contain prefixes
for all element names associated with namespaces in the XPath expressions.
Resolution: Proposed in Francisco Curbera, 24 Sep 2003, decided at 15 October 2003
The document fragment for a message part declared as a type is represented in XPath expressions (inside a "query" attribute) as an element with local name equal to the part name (this is according to the resolution of issue 39.) In addition, the namespace URI of that element is considered to be a null URI.
WSDL1.2 is still under construction, but it's already obvious that some key changes will be made to the core WSDL language. For example, portType will be called "interface", support for interface inheritance (sort of) will be added, and most importantly for BPEL, the message construct will most likely be removed (the W3C web services description WG has just reached consensus in its F2F last week that). Hopefully the public will have access to a relatively stable draft by November as the W3C group is targeting to produce a last call draft by then.
We are facing a timing issue here. Our charter gives us 9 months to produce a TC draft. Let's assume that we will get the job done on time J , and we will have a new version of BPEL delivered in February 2004. Though nobody can tell for sure at this point of time, but it's likely that WSDL1.2 (at least part 1 for the core language) may be released in about the same time frame, if not earlier. If we will not be able to meet our deadline in February, WSDL1.2 may already been there for a little while when we do our release.
I would like suggest that the TC consider to:
1. Assess the necessity for establishing a form liaison with the W3C WSD working group to coordinate schedules and get updates on key feature changes
2. Assess the impact of relevant WSDL changes on BPEL
Resolution: Proposed in Kevin Liu, 4 Oct 2003, decided at 15 October 2003
This issue was created to have a general discussion about what to do with WSDL1.2 (or whatever version number W3C WSD WG may call it eventually, same below)
As discussed in the Redmond F2F (Kevin Liu, 22 Sep 2003) and the Oct.1 con call, we agreed not to use WSDL1.2 for WSBPEL since it is still under construction and its availability is still uncertain.
We will try to align with WSDL1.2 work via identifying and addressing particular relevant feature changes. issue 71 : Removal of wsdl:message and issue 15 : WSDL MEPs will be used to clarify potential impacts of removal of message construct and WSDL1.2 patterns
Issue 47 closed without specific change to the specification.
Links: Announcement, 8 Aug 2003
Kevin Liu, 15 Sep 2003
Discussed at Redmond face-to-face
First proposed resolution (Kevin Liu, 22 Sep 2003)
Discussed at TC conf call, 1 October 2003
see also issue 15
see also issue 71
see also issue 72
Much of the discussion on issue 72 has a subject line identifying this issue
Revised proposed resolution (Kevin Liu, 4 Oct 2003)
Eckenfels. Bernd, 6 Oct 2003
Changes: 8 Aug 2003 - new issue;
8 Aug 2003 - fields: Links;
15 Sep 2003 - fields: Links;
18 Sep 2003 - fields: Links;
23 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Links;
2 Oct 2003 - fields: Links;
3 Oct 2003 - fields: Links;
6 Oct 2003 - fields: Links;
8 Oct 2003 - fields: Vote announcement;
15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution
Closed with no change to the spec.
Vote announcement: Web ballot (ends 28 Apr 2004)
Rationale: With the agreed resolution of issue 13 : Future Usage of XPATH 2.0 and XQuery 1.0 it is now possible to add in support
for languages such as XQUERY. (See also discussion in Yaron Y. Goland, 25 Mar 2004 and messages referenced
from that)
Links: Announcement, 12 Aug 2003
issue 11 : Query in <to> close should allow assigning to new locations
Yaron Goland, 11 Aug 2003
Yaron Goland, 13 Aug 2003
Proposed resolution (Yaron Y. Goland, 25 Mar 2004)
Danny van der Rijn, 25 Mar 2004
Yaron Y. Goland, 25 Mar 2004
Discussed at Walldorf f-t-f (document details)
Changes: 12 Aug 2003 - new issue;
12 Aug 2003 - fields: Links;
14 Aug 2003 - fields: Links;
25 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Rationale
Closed as a duplicate of 26.
Links: Announcement, 12 Aug 2003
Dieter Roller, 14 Aug 2003
Danny van der Rijn, 14 Aug 2003
Dieter Roller, 17 Aug 2003
Monica Martin, 17 Aug 2003
Danny van der Rijn, 18 Aug 2003
Danny van der Rijn, 4 Sep 2003
Danny van der Rijn, 5 Sep 2003
Dieter Roller, 7 Sep 2003
Danny van der Rijn, 8 Sep 2003
Monica Martin, 25 Sep 2003
Danny van der Rijn, 25 Sep 2003
Edit group action (Satish Thatte, 14 Jan 2004)
Proposed resolution (Danny van der Rijn, 14 Jan 2004)
Changes: 12 Aug 2003 - new issue;
12 Aug 2003 - fields: Links;
14 Aug 2003 - fields: Links;
18 Aug 2003 - fields: Links;
19 Aug 2003 - fields: Links;
8 Sep 2003 - fields: Links;
26 Sep 2003 - fields: Links;
14 Jan 2004 - fields: Links, Status, Proposed resolution;
15 Jan 2004 - fields: Links;
27 Jan 2004 - fields: Status, Proposed resolution, Resolution
A receive activity for an inbound request/response operation is said to be *open* if that activity has been executed and no corresponding reply activity has been executed. A fault bpel:missingReply is thrown if the process instance reaches the end of its execution, and one or more receive activities remain open. This fault indicates a modeling error that was not detected by static analysis.
Close with no change to spec.
Links: Announcement, 18 Aug 2003
Yaron Goland, 18 Aug 2003
split from issue 44
Maciej Szefler, 20 Aug 2003
Satish Thatte, 20 Aug 2003
Danny van der Rijn, 20 Aug 2003
Tony Andrews, 20 Aug 2003
Yaron Goland, 20 Aug 2003
Edwin Khodabakchian, 20 Aug 2003
Yaron Goland, 20 Aug 2003
Edwin Khodabakchian, 20 Aug 2003
Yaron Goland, 20 Aug 2003
Ugo Corda, 20 Aug 2003
Danny van der Rijn, 20 Aug 2003
Eckenfels. Bernd, 21 Aug 2003
Satish Thatte, 23 Aug 2003
Yaron Goland, 26 Aug 2003
Satish Thatte, 26 Aug 2003
Assaf Arkin, 26 Aug 2003
Ron Ten-Hove, 27 Aug 2003
Satish Thatte, 27 Aug 2003
Ron Ten-Hove, 27 Aug 2003
Sazi Temel, 28 Aug 2003
Satish Thatte, 28 Aug 2003
David RR Webber, 30 Aug 2003
Yaron Goland, 2 Sep 2003
David RR Webber, 3 Sep 2003
Frank Leymann, 3 Sep 2003
Monica Martin, 3 Sep 2003
David RR Webber, 3 Sep 2003
Yaron Goland, 3 Sep 2003
Assaf Arkin, 3 Sep 2003
Yaron Goland, 29 Sep 2003
Satish Thatte, 30 Sep 2003
Yaron Goland, 30 Sep 2003
Satish Thatte, 30 Sep 2003
Edwin Khodabakchian, 30 Sep 2003
Yaron Y. Goland, 27 Aug 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Francisco Curbera, 17 Sep 2004
Proposed resolution (Dieter Koenig1, 17 Sep 2004)
Yaron Y. Goland, 17 Sep 2004
Yaron Y. Goland, 17 Sep 2004
Assaf Arkin, 18 Sep 2004
Dieter Koenig1, 19 Sep 2004
Satish Thatte, 21 Sep 2004
Changes: 18 Aug 2003 - new issue;
19 Aug 2003 - fields: Links;
20 Aug 2003 - fields: Links;
21 Aug 2003 - fields: Links;
23 Aug 2003 - fields: Links;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
28 Aug 2003 - fields: Links;
30 Aug 2003 - fields: Links;
3 Sep 2003 - fields: Links;
4 Sep 2003 - fields: Links;
8 Sep 2003 - fields: Links;
29 Sep 2003 - fields: Links;
30 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Links;
25 Mar 2004 - fields: Title, Original title;
27 Aug 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
17 Sep 2004 - fields: Links;
18 Sep 2004 - fields: Links, Status, Proposed resolution;
20 Sep 2004 - fields: Links;
21 Sep 2004 - fields: Links;
23 Sep 2004 - fields: Status, Proposed resolution, Resolution, In spec
In our view BTP Cohesions, WS-T Business Activity, and WS-TXM Long-Running Actions are the most relevant aspects of these specifications for WS-BPEL. These aspects overlap to a very high degree, each effectively utilizing a two-phase (promise/decide) outcome protocol. (We should emphasize that there has been little time to analyze or assimilate WS-TXM, so this is a provisional conclusion with respect to that specification).
WS-BPEL should be equipped with the ability to create and terminate business transactions, and to define process participation in such transactions, in a way which is compatible with the intersection of these three capabilities. This will minimize dependence on future standardization efforts in the BTM area.
Original title: Should include Business Transaction Management (BTM) programming constructs compatible with WS-T, BTP and WS-TXM
Revisitable: Yes
Submitter's proposal: Syntax should be added to WS-BPEL to permit
The WS-Coordination specification (proprietary consortium, August 2002) is able to support context passing for multiple coordination protocols, and its use will support the goal of compatibility with WS-T, BTP and WS-TXM.
Resolution: Proposed in Peter Furniss, 31 Mar 2004, decided by Web ballot (ended 28 Apr 2004) , after straw poll at Walldorf ftf
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Monica Martin, 27 Aug 2003
Alastair Green, 27 Aug 2003
Issue A in Choreology BTM submission (document details)
David RR Webber, 27 Aug 2003
Monica Martin, 27 Aug 2003
Peter Furniss, 28 Aug 2003
David RR Webber, 28 Aug 2003
Mark Little, 1 Sep 2003
Mark Little, 1 Sep 2003
Mark Little, 1 Sep 2003
David RR Webber, 1 Sep 2003
David RR Webber, 1 Sep 2003
David RR Webber, 1 Sep 2003
Mark Little, 1 Sep 2003
Mark Little, 1 Sep 2003
David RR Webber, 2 Sep 2003
Monica Martin, 1 Sep 2003
Revised submission (document details)
Monica Martin, 14 Sep 2003
Peter Furniss, 13 Oct 2003
Harvey Reed, 13 Oct 2003
Satish Thatte, 13 Oct 2003
Harvey Reed, 13 Oct 2003
Yaron Goland, 20 Oct 2003
Haugen Robert, 24 Oct 2003
Post-Melbourne discussion on coordination questions is under issue 30 issue 30
Alastair J. Green, 7 Jan 2004
Satish Thatte, 7 Jan 2004
Haugen Robert, 8 Jan 2004
Yaron Goland, 8 Jan 2004
Haugen Robert, 9 Jan 2004
Dieter Roller, 9 Jan 2004
Peter Furniss, 9 Jan 2004
Satish Thatte, 9 Jan 2004
Satish Thatte, 9 Jan 2004
Haugen Robert, 9 Jan 2004
Satish Thatte, 10 Jan 2004
Diane Jordan, 12 Jan 2004
Haugen Robert, 12 Jan 2004
Yaron Goland, 12 Jan 2004
Haugen Robert, 12 Jan 2004
Yaron Goland, 13 Jan 2004
Haugen Robert, 13 Jan 2004
Yaron Goland, 20 Jan 2004
Tony Fletcher, 20 Jan 2004
Danny van der Rijn, 20 Jan 2004
LI Yanming / FTR&D / US, 20 Jan 2004
Alastair J. Green, 20 Jan 2004
Tony Fletcher, 23 Jan 2004
Satish's presentation at Melbourne, FL (document details)
Bob Haugen's presentation at Melbourne, FL (document details)
Peter Furniss, 29 Mar 2004
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
28 Aug 2003 - fields: Links;
3 Sep 2003 - fields: Links;
9 Sep 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
13 Oct 2003 - fields: Links;
20 Oct 2003 - fields: Links;
24 Oct 2003 - fields: Links;
9 Dec 2003 - fields: Links;
7 Jan 2004 - fields: Links;
8 Jan 2004 - fields: Links;
9 Jan 2004 - fields: Links;
12 Jan 2004 - fields: Links;
13 Jan 2004 - fields: Links;
14 Jan 2004 - fields: Links;
20 Jan 2004 - fields: Links;
21 Jan 2004 - fields: Links;
23 Jan 2004 - fields: Links;
15 Mar 2004 - fields: Links;
25 Mar 2004 - fields: Title, Original title;
29 Mar 2004 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue B in Choreology BTM submission (document details)
Mark Little, 1 Sep 2003
David RR Webber, 1 Sep 2003
Tony Fletcher, 1 Sep 2003
Mark Little, 1 Sep 2003
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
3 Sep 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue C in Choreology BTM submission (document details)
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue D in Choreology BTM submission (document details)
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue E in Choreology BTM submission (document details)
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue F in Choreology BTM submission (document details)
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003
Issue G in Choreology BTM submission (document details)
Monica Martin, 14 Sep 2003
Proposed resolution (Peter Furniss, 31 Mar 2004)
Peter Furniss, 31 Mar 2004
Discussed at Walldorf f-t-f (with issue 53) (document details)
Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;
26 Aug 2003 - fields: Links;
27 Aug 2003 - fields: Links;
10 Sep 2003 - fields: Champion;
15 Sep 2003 - fields: Links;
31 Mar 2004 - fields: Links, Status, Proposed resolution;
22 Apr 2004 - fields: Vote announcement, Links;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;
20 Jun 2004 - fields: In spec
<process name="ncname" targetNamespace="uri" queryLanguage="anyURI"? . . category="ncname"/>
Close with no change to the specification.
Rationale: The process category (and the process priority) belong to a set
of attributes that are independent of the process model and rather subject
of the process deployment. Having both covered by WS-Policy (from my point
of view a reasonable direction) would also increase the reusability of a
process model, as it could be deployed multiple times with different
category (and priority, see also the proposed resolution of issue 61)
attributes.
Links: Sid Askary, 4 Sep 2003
Ron Ten-Hove, 4 Sep 2003
Satish Thatte, 4 Sep 2003
Ron Ten-Hove, 4 Sep 2003
Edwin Khodabakchian, 4 Sep 2003
Satish Thatte, 4 Sep 2003
Satish Thatte, 4 Sep 2003
Sid Askary, 4 Sep 2003
Ron Ten-Hove, 4 Sep 2003
Ron Ten-Hove, 4 Sep 2003
Edwin Khodabakchian, 4 Sep 2003
Ron Ten-Hove, 5 Sep 2003
Assaf Arkin, 5 Sep 2003
Edwin Khodabakchian, 5 Sep 2003
Ron Ten-Hove, 5 Sep 2003
Announcement, 8 Sep 2003
Proposed resolution (Dieter Koenig1, 3 Feb 2004)
Changes: 8 Sep 2003 - new issue;
8 Sep 2003 - fields: Links;
9 Sep 2003 - fields: Links;
3 Feb 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
a)
<process name="ncname" targetNamespace="uri" queryLanguage="anyURI"? . . prioritize="yes|no"?/>b)
<priority name="ncname" priorityNumber="anynumber" PriorityNumberBase="anynumber"/>
NOTE: PriorityNumberBase reflects the devisor for PriorityNumber.
Alternatively, one could replace the two by a single floating-point
fraction.
Submitter: Sid Askary
Resolution: Proposed in Dieter Koenig1, 3 Feb 2004, decided 4 February 2004 con call
Close with no change to the specification.
Rationale: The process priority (and the process category) belong to a set
of attributes that are independent of the process model and rather subject
of the process deployment. Having both covered by WS-Policy (from my point
of view a reasonable direction) would also increase the reusability of a
process model, as it could be deployed multiple times with different
priority (and category, see also the proposed resolution of issue 60)
attributes.
Links: Sid Askary, 4 Sep 2003
Danny van der Rijn, 4 Sep 2003
Edwin Khodabakchian, 4 Sep 2003
Harvey Reed, 4 Sep 2003
Rajesh Pradhan, 4 Sep 2003
Sid Askary, 4 Sep 2003
Satish Thatte, 4 Sep 2003
Monica Martin, 4 Sep 2003
Ron Ten-Hove, 4 Sep 2003
Sid Askary, 4 Sep 2003
Ron Ten-Hove, 5 Sep 2003
Assaf Arkin, 5 Sep 2003
Monica Martin, 5 Sep 2003
Announcement, 8 Sep 2003
Proposed resolution (Dieter Koenig1, 3 Feb 2004)
Changes: 8 Sep 2003 - new issue;
8 Sep 2003 - fields: Links;
9 Sep 2003 - fields: Links;
3 Feb 2004 - fields: Links, Status, Proposed resolution;
11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale
Let's assume a scope S, an event handler E associated with S, a scope S-S that is part of S, and a scope S-E that is part of E. Then the following rules apply
If a serializable scope has an event handler associated with it, no enclosed scope nor a scope in the body of the event handler can be serializable. If a non-serializable scope has an event handler associated with it, an enclosed scope as well as a scope in the body of the event handler can be serializable.Equivalently: Let's assume a scope S, an event handler E associated with S, a scope S-S that is part of S, and a scope S-E that is part of E. Then the following rules apply
- If S is marked variableAccessSerializable="yes", then neither scope S-S nor scope S-E can be marked with variableAccessSerializable ="yes".
- If scope S is marked variableAccessSerializable="no", scope S-E and scope S-S can be marked variableAccessSerializable="yes"
I'm not proposing to define a new data type system for BPEL. We should leverage what is already in XML schema. Although in the XML schema there is a construct to declare repetitive occurrence of element structure, it is designed for describing the XML document being exchanged ? There is a difference between "there are some repetitive elements within a document" and "there are multiple documents".
Therefore, I propose that we need to support "Array"
For example, if a seller is receiving multiple POMessage from multiple buyers, (assuming the complex type of POMessage is already defined), the BPEL will look like this ..
<process> <variables> <array name="poArray" type="POMessage"/> </variables><sequence> <iterate array="poArray" count="10"> <receive partner="buyer" ... array="poArray"/> </iterate> .... </sequence> </process>
However, since the spec requires the first basic activity in the process must be a <receive createInstance="yes"/>, the actual intention may try to make the process instance distinct rather than homogeneous.
The current mechanism has the following challenges ...
To treat every process instance distinct, I'm suggesting to use a more explicit way to capture the initialization of process instances, which includes
<process> .... <sequence> .... <receive partner="buyer" portType="p1" operation="submitOrder" variable="var1" createInstance="yes"/> .... <receive ..../> <sequence> </process>I suggest to use this ...
<process> ... <triggeredBy> <receive partner="buyer" portType="p1" variable="var1" operation="submitOrder"/> </triggeredBy> ... <sequence> .... <receive ..../> <sequence> </process>
Please note the following difference ...
Closed with no change
Links: Ricky Ho, 13 Sep 2003
Dieter Roller, 13 Sep 2003
Ricky Ho, 13 Sep 2003
Ricky Ho, 13 Sep 2003
Ron Ten-Hove, 15 Sep 2003
Announcement, 15 Sep 2003
Ricky Ho, 15 Sep 2003
Eckenfels. Bernd, 16 Sep 2003
Ricky Ho, 16 Sep 2003
Dieter Roller, 17 Sep 2003
David RR Webber, 17 Sep 2003
Ricky Ho, 17 Sep 2003
Proposed resolution (Yaron Y. Goland, 9 Oct 2004)
Changes: 15 Sep 2003 - new issue;
15 Sep 2003 - fields: Links;
16 Sep 2003 - fields: Links;
17 Sep 2003 - fields: Links;
11 Oct 2004 - fields: Links, Status, Proposed resolution;
14 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec
Lets look at an auction scenario ...
There are three roles. "Seller", "Bidder" and "Buyer". How many <partner>
do I have in my BPEL ?
Resolution: Proposed verbally by Satish Thatte and decided at San Francisco f-t-f
Close with no change to spec.
Rationale: Partly a misunderstanding notion of partner, partly covered by other issues, including issue 4.
Links: Announcement, 15 Sep 2003
Changes: 15 Sep 2003 - new issue;
15 Sep 2003 - fields: Links;
22 Jun 2004 - fields: In spec, Resolution, Rationale, Status
1) When an incoming message matches multiple process instances, which one will get the message ?
e.g. ProcessA is executing
<receive portType="PT1" operation="oper" ... createInstance="yes"/>
ProcessB is executing
<receive portType="PT1" operation="oper" ... createInstance="yes"/>An instance of processC is executing
<receive portType="PT1" operation="oper" ... createInstance="no"/>
Lets say someone invoke "PT1/oper" and it matches the correlation set of the processC instance. Who gets the message ?
2) When an incoming message matches zero process instances, does the sender get a fault ? or the message will be queued until a matching process instances gets it later
e.g. A sender invoke "PT2/oper2" but no process is listening in that.
Resolution: Proposed verbally by Paco Cabrera and decided at San Francisco f-t-f
No normative change, but the editors' group will add a note for implementors pointing out that there
are possible implementation alternatives and that users may need to be aware of these.
Links: Announcement, 20 Sep 2003
Yaron Goland, 23 Sep 2003
Ricky Ho, 23 Sep 2003
Danny van der Rijn, 23 Sep 2003
Prasad Yendluri, 24 Sep 2003
Satish Thatte, 24 Sep 2003
Danny van der Rijn, 24 Sep 2003
Satish Thatte, 24 Sep 2003
Ron Ten-Hove, 24 Sep 2003
Ron Ten-Hove, 24 Sep 2003
Francisco Curbera, 24 Sep 2003
Ugo Corda, 24 Sep 2003
Satish Thatte, 24 Sep 2003
Satish Thatte, 24 Sep 2003
Danny van der Rijn, 24 Sep 2003
Ron Ten-Hove, 24 Sep 2003
Assaf Arkin, 25 Sep 2003
Francisco Curbera, 25 Sep 2003
Satish Thatte, 26 Sep 2003
Ron Ten-Hove, 26 Sep 2003
Ron Ten-Hove, 26 Sep 2003
Tony Fletcher, 29 Sep 2003
Assaf Arkin, 1 Oct 2003
Discussed at San Francisco ftf
Changes: 19 Sep 2003 - new issue;
22 Sep 2003 - fields: Links;
24 Sep 2003 - fields: Links;
25 Sep 2003 - fields: Links;
26 Sep 2003 - fields: Links;
29 Sep 2003 - fields: Links;
1 Oct 2003 - fields: Links;
22 Jun 2004 - fields: Links, In spec, Resolution, Status
Add the following sentences to section to Section 13.6 following paragraph 2.
Note that serialization of variable access cannot lead to internal deadlock in a BPEL process instance. The reason being that, conceptually, a serializable scope is not started until it can gain sufficiently exclusive access to all the non-local variables it needs.
This is because we make
Change the syntax of faultHandlers to the following
<faultHandlers>? <!-- there must be at least one fault handler or default --> <catch faultName="qname"? faultVariable="ncname"? faultMessageType="qname"?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers>
And in addition, add the following sentences immediately following the syntax.
Note that the faultName, faultVariable and faultMessageType attributes are all optional. However, the faultVariable and faultMessageType declarations go together, i.e., they must either both be present or both absent. This is to ensure that the type of the faultVariable is well specified even when the faultName is omitted. Moreover, the faultName and faultVariable attributes cannot both be absent.
Link target and/or source activities can be run more than once if the process contains a loop (i.e. while acitivity).
When to clear the link status in such cases is not defined in the current specification.
Submitter's Proposal: Possible resolutions are to specify that the link status is cleared:
I would propose C. In the following example, A1 and A2 are cleared every time flow A is started and B1 and B2 are cleared every time flow B is started.
<while ...> <flow name="base"> <flow name="A"> <links> <link name="A1"/> <link name="A2"/> </links>... activities ... </flow> <while ...> <flow name="B"> <links> <link name="B1"/> <link name="B2"/> </links>
... activities ... </flow> </while> </flow> </while>
Updated proposal for 69: - new subject for script magic - added Satish's clarification of def in 12.5 - replaced "defined" with "declared" (i.e. links are declared)
New text shown in italics, old text as strikeout
Section 12.5: Flow
Change the following text:
Section 12.5.1: Link SemanticsIn general, a link is said to cross the boundary of a syntactic construct if the source activity for the link is nested within the construct but the target activity is not, or vice versa, if the target activity for the link is nested within the construct but the source activity is not.A link is said to cross the boundary of a syntactic construct if the source or target activity for the link is nested within the construct while the link is declared outside the construct. Note that it is possible for a link to cross the boundary of a syntactic construct even in those cases where both the source and the target activities are nested within the same construct: so long as the link is /declared/ outside that construct.
Insert the following text:
The precise semantics of link status evaluation are as follows: The link status is a tri-state flag associated with each declared link. This flag may be in the following three states: "positive", "negative", or "unset". Each time a certain flow activity is activated, the link status of all the links declared in that activity is "unset", that is the lifetime of the status of a link is exactly the lifetime of the flow activity within which it is declared. When activity A completes, the following steps are performed to determine the effect of the synchronization links on other activities:
The above changes imply option C (if you all remember the options). The second part is essentially Satish's earlier proposal in the context of the current language, while the first part addresses the problem brought up by Yaron in the conference call relating to while loops that use links declared outside the while loop. The major consequence of the above changes is that the following is no longer permitted:
<flow name="f1"> <link name="l1"> <while> <flow name="f2"> <empty> <source linkName="l1"/> </empty> <empty> <target linkName="l1"/> </empty> </flow> </while> </flow>
The link "l1" will now need to be declared in "f2".
The issue of whether links are belong in scopes as opposed to flows will be
made a separate issue.
Links: Announcement, 27 Sep 2003
Edit group action (Satish Thatte, 14 Jan 2004)
Proposed resolution (Satish Thatte, 15 Jan 2004)
Maciej Szefler, 22 Jan 2004
Satish Thatte, 26 Jan 2004
Yaron Goland, 26 Jan 2004
Satish Thatte, 26 Jan 2004
Maciej Szefler, 27 Jan 2004
Discussed at 21 January 2004, deferred for further discussion
Satish Thatte, 28 Jan 2004
Maciej Szefler, 28 Jan 2004
Satish Thatte, 28 Jan 2004
Maciej Szefler, 11 Feb 2004
Satish Thatte, 13 Feb 2004
Proposed resolution (Maciej Szefler, 13 Feb 2004)
Eckenfels. Bernd, 13 Feb 2004
Maciej Szefler, 13 Feb 2004
Changes: 27 Sep 2003 - new issue;
27 Sep 2003 - fields: Links;
15 Jan 2004 - fields: Links, Status, Proposed resolution;
22 Jan 2004 - fields: Links;
26 Jan 2004 - fields: Links;
27 Jan 2004 - fields: Links;
28 Jan 2004 - fields: Links;
29 Jan 2004 - fields: Links;
13 Feb 2004 - fields: Links;
16 Feb 2004 - fields: Links, Status, Proposed resolution;
18 Feb 2004 - fields: Links, Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
A value of "yes" for [suppressJoinFailure] has the effect of suppressing the bpws:joinFailure fault for the activity and all nested activities, except where the effect is overridden by using the suppressJoinFailure attribute with a value of "no" in a nested activity.
By having the schema specify a default value for suppressJoinFailure for each activity element, nested activities always reset the value of suppressJoinFailure instead of inheriting it.
Submitter's proposal: If I am reading this wrong, perhaps someone can clarify. Otherwise, I propose, in the schema's tActivity declaration, replacing this:
<attribute name="suppressJoinFailure" type="bpws:tBoolean" default="no"/>with this:
<attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional"/>
Make the following changes to the spec:
Existing Text:
where the default values are as follows:
- name. No default value (that is, unnamed)
- joinCondition. The logical OR of the liveness status of all links that are targeted at this activity
- suppressJoinFailure. No
New Text:
where the default values are as follows:
- name. No default value (that is, unnamed)
- joinCondition. The logical OR of the liveness status of all links that are targeted at this activity
- suppressJoinFailure. In case the suppressJoinFailure attribute is omitted for an activity, it is inherited from its closest enclosing activity.
New description:"The default value of suppressJoinFailure is no."
"In case the suppressJoinFailure attribute is omitted for an activity, it is inherited from its closest enclosing activity"
"no for process element. This attribute is optional for activities other than process. When not present for such an activity, it inherits its value from its closest enclosing activity."
Existing description:
New description:"The default value of the suppressJoinFailure attribute is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.
"The default value of the suppressJoinFailure attribute of process element is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.
<attribute name="suppressJoinFailure" type="bpws:tBoolean" default="no"/>
with this:
<attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional">
In addition, give the editors action to double check the spec and make editorial changes as they see appropriate to reflect resolution for this issue.
Links: Jim Clune, 26 Sep 2003
Francisco Curbera, 26 Sep 2003
Announcement, 30 Sep 2003
Edit group action (Satish Thatte, 14 Jan 2004)
Proposed resolution (Kevin Liu, 27 Jan 2004)
Alex Yiu, 4 Feb 2004
Kevin Liu, 4 Feb 2004
Satish Thatte, 4 Feb 2004
Proposed resolution (Kevin Liu, 4 Feb 2004)
Changes: 30 Sep 2003 - new issue;
30 Sep 2003 - fields: Links;
15 Jan 2004 - fields: Links;
27 Jan 2004 - fields: Links, Status, Proposed resolution;
4 Feb 2004 - fields: Links, Status, Proposed resolution;
18 Feb 2004 - fields: Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
Closed with no change (c.f resolution of issue 15 : WSDL MEPs )
Links: split from issue 47
Announcement, 1 Oct 2003
Proposed resolution (Yaron Y. Goland, 5 Oct 2004)
Satish Thatte, 6 Oct 2004
Kevin Liu, 9 Oct 2004
Changes: 1 Oct 2003 - new issue;
1 Oct 2003 - fields: Links;
6 Oct 2004 - fields: Links, Status, Proposed resolution;
11 Oct 2004 - fields: Links;
14 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec
Given that the scope of BP is confined to the specifications it references, and that BPEL is of wider application:
<portType name="BuyerPT"> <operation name="AsyncPurchaseResponse"> <input message="smsg:POResponse"/> <fault name="tns:RejectPO" message="smsg:POReject"/> </operation> <operation name="AsyncPurchaseReject"> <input message="smsg:POReject"/> </operation> </portType>
<portType name="BuyerPT"> <operation name="AsyncPurchaseResponse"> <input message="smsg:POResponse"/> </operation> <operation name="AsyncPurchaseReject"> <input message="smsg:POReject"/> </operation> </portType>
Accept the "submitter's proposal".
Links: Announcement, 6 Oct 2003
Proposed resolution (Ugo Corda, 8 Jan 2004)
Changes: 6 Oct 2003 - new issue;
6 Oct 2003 - fields: Links;
8 Jan 2004 - fields: Links, Status, Proposed resolution;
27 Jan 2004 - fields: Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
Every activity that is the target of a link has an implicit or explicit joinCondition attribute associated with it; an activity that is not target of a link has no joinCondition attribute associated with it.Furthermore it may be helpful to have a similar sentence earlier in the document.
A) remove "joinCondition" from the set of Standard attributes for each activity
- change formal syntax definition:
FROM <source .../>* <target .../>* TO <sources> <source linkName="ncname" transitionCondition="bool-expr"?/>+ </sources>? <targets joinCondition="bool-expr"? > <target linkName="ncname"/>+ </targets>?
- add description of "joinCondition" attribute right below (above 11.3) (removed default value, replaced with default semantic):
The value of the joinCondition attribute is a Boolean-valued expression in the expression language indicated for this document (see Expressions). If this attribute is not present, the join condition is the logical OR of the link status of all incoming links of this activity (see 12.5.1 Link semantics).(this also aligns the semantic definition with 12.5.1 without using the "default value")
- change text of 11.2: FROM
Each BPEL4WS activity has optional nested standard elements <source> and <target>. The use...TO
Each BPEL4WS activity has nested standard elements <source> and <target> within the optional containers <sources> and <targets>. The use...C) update all samples and schema
It is proposed that the BPEL specification be modified to allow for the
declaration of partnerLinks within scopes. Such a declaration would be
accomplished by allowing for the use of the partnerLinks element as a
child of the scope element. partnerLinks will be treated
similarly to BPEL variable in terms of life cycle management, name
collision resolution, etc.
Links: Announcement, 21 Oct 2003
Yaron Goland, 21 Oct 2003
Harvey Reed, 21 Oct 2003
Yaron Goland, 22 Oct 2003
Edwin Khodabakchian, 22 Oct 2003
Assaf Arkin, 23 Oct 2003
Frank Leymann, 23 Oct 2003
Assaf Arkin, 13 Nov 2003
Satish Thatte, 14 Nov 2003
Frank Leymann, 14 Nov 2003
Assaf Arkin, 14 Nov 2003
Assaf Arkin, 14 Nov 2003
Satish Thatte, 16 Nov 2003
Assaf Arkin, 17 Nov 2003
Satish Thatte, 17 Nov 2003
Yaron Goland, 27 Nov 2003
Assaf Arkin, 30 Nov 2003
Assaf Arkin, 2 Dec 2003
Discussed at Walldorf f-t-f (document details)
Yaron Y. Goland, 28 Apr 2004
Proposed resolution (Yaron Y. Goland, 19 May 2004)
Yaron Y. Goland, 20 May 2004
Changes: 21 Oct 2003 - new issue;
21 Oct 2003 - fields: Links;
22 Oct 2003 - fields: Links;
23 Oct 2003 - fields: Links;
13 Nov 2003 - fields: Links;
14 Nov 2003 - fields: Links;
16 Nov 2003 - fields: Links;
17 Nov 2003 - fields: Links;
27 Nov 2003 - fields: Links;
30 Nov 2003 - fields: Links;
2 Dec 2003 - fields: Links;
22 Apr 2004 - fields: Links;
29 Apr 2004 - fields: Links;
19 May 2004 - fields: Links, Status, Proposed resolution;
20 May 2004 - fields: Links;
9 Jun 2004 - fields: Status, Proposed resolution, Resolution;
15 Jul 2004 - fields: In spec
This issue is a duplicate of issue 9 : Static analysis
Links: Announcement, 21 Oct 2003
Yaron Goland, 21 Oct 2003
Eckenfels. Bernd, 21 Oct 2003
Harvey Reed, 22 Oct 2003
Proposed resolution (Yaron Goland, 8 Nov 2003)
Changes: 21 Oct 2003 - new issue;
21 Oct 2003 - fields: Links;
22 Oct 2003 - fields: Links;
8 Nov 2003 - fields: Links, Status, Proposed resolution;
12 Nov 2003 - fields: Status, Proposed resolution, Resolution
<message name="In"> <part name="InPart" element="InElement"/> </message>In this example, the abstract operation "op1" refers to message "In", but the binding brings in an additional second message, "Header", for the concrete operation.<message name="Header"> <part name="HeaderPart" element="HeaderElement"/> </message>
<portType name="myPortType"> <operation name="op1"> <input message="In"/> </operation> </portType>
<binding type="myPortType" ... > <soap:binding ..../> <operation name="op1"> <input> <soap:body parts="InPart" ...> <soap:header message="Header" part="HeaderPart" .../> </input> </operation> </binding>
It seems that BPEL would not be able to process the "Header" information in any way. For instance, a "receive" operation would only be able to specify one inputVariable, which would be associated with the "In" message and not the "Header" message. In other words, the "Header" message would carry information to the "receive" operation that BPEL would have no access to.
If this is the case, new Web services defined with BPEL in mind could
easily modify this scenario by defining both body and header as being
part of a single message, but legacy Web services might be out of reach for BPEL.
Resolution: agreed to close with no change in Web ballot (ended 08 Dec 2003)
Vote announcement: Web ballot (ends 08 Dec 2003)
Links: Ugo Corda, 20 Oct 2003
Frank Leymann, 21 Oct 2003
Ugo Corda, 21 Oct 2003
Satish Thatte, 21 Oct 2003
Peter Furniss, 21 Oct 2003
Ugo Corda, 21 Oct 2003
Satish Thatte, 21 Oct 2003
Ugo Corda, 21 Oct 2003
Satish Thatte, 21 Oct 2003
Ugo Corda, 21 Oct 2003
Announcement (erroneously stating as issue 78)
Rajesh Pradhan, 21 Oct 2003
Francisco Curbera, 21 Oct 2003
Ugo Corda, 21 Oct 2003
Reannouncement as issue 77
Peter Furniss, 22 Oct 2003
Peter Furniss, 22 Oct 2003
Ugo Corda, 22 Oct 2003
Yaron Goland, 22 Oct 2003
Satish Thatte, 23 Oct 2003
Satish Thatte, 23 Oct 2003
Frank Leymann, 23 Oct 2003
Peter Furniss, 23 Oct 2003
Ugo Corda, 23 Oct 2003
Ugo Corda, 23 Oct 2003
Frank Leymann, 24 Oct 2003
Maciej Szefler, 27 Oct 2003
jim@parasoft.com, 27 Oct 2003
Yaron Goland, 27 Oct 2003
Frank Leymann, 31 Oct 2003
Ugo Corda, 31 Oct 2003
Ron Ten-Hove, 31 Oct 2003
Ugo Corda, 31 Oct 2003
Ron Ten-Hove, 1 Nov 2003
Ugo Corda, 1 Nov 2003
Satish Thatte, 2 Nov 2003
Ugo Corda, 2 Nov 2003
Ugo Corda, 2 Nov 2003
Satish Thatte, 2 Nov 2003
Ugo Corda, 2 Nov 2003
Satish Thatte, 3 Nov 2003
Satish Thatte, 3 Nov 2003
Frank Leymann, 3 Nov 2003
Ugo Corda, 3 Nov 2003
Satish Thatte, 4 Nov 2003
Ugo Corda, 4 Nov 2003
Satish Thatte, 4 Nov 2003
Ugo Corda, 4 Nov 2003
Satish Thatte, 4 Nov 2003
Ugo Corda, 4 Nov 2003
Satish Thatte, 4 Nov 2003
Harvey Reed, 4 Nov 2003
Satish Thatte, 4 Nov 2003
Ugo Corda, 4 Nov 2003
John Yunker, 4 Nov 2003
Yaron Goland, 19 Nov 2003
Yaron Goland, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ron Ten-Hove, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Rajesh Pradhan, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Harvey Reed, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Ron Ten-Hove, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Satish Thatte, 19 Nov 2003
Ugo Corda, 19 Nov 2003
Francisco Curbera, 19 Nov 2003
Ugo Corda, 20 Nov 2003
Sanjiva Weerawarana, 20 Nov 2003
Ugo Corda, 20 Nov 2003
Sanjiva Weerawarana, 20 Nov 2003
Ugo Corda, 20 Nov 2003
Ron Ten-Hove, 20 Nov 2003
Ugo Corda, 20 Nov 2003
Ron Ten-Hove, 21 Nov 2003
Ron Ten-Hove, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Sanjiva Weerawarana, 21 Nov 2003
Sanjiva Weerawarana, 21 Nov 2003
Sanjiva Weerawarana, 21 Nov 2003
Francisco Curbera, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Satish Thatte, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Sanjiva Weerawarana, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Satish Thatte, 21 Nov 2003
Ugo Corda, 21 Nov 2003
Sanjiva Weerawarana, 24 Nov 2003
Ugo Corda, 24 Nov 2003
Proposed resolution (Ugo Corda, 24 Nov 2003)
Sanjiva Weerawarana, 24 Nov 2003
Ugo Corda, 24 Nov 2003
Ron Ten-Hove, 25 Nov 2003
Sanjiva Weerawarana, 25 Nov 2003
Edwin Khodabakchian, 25 Nov 2003
Ugo Corda, 25 Nov 2003
Ugo Corda, 25 Nov 2003
Ron Ten-Hove, 25 Nov 2003
Ugo Corda, 25 Nov 2003
Ron Ten-Hove, 26 Nov 2003
Ugo Corda, 26 Nov 2003
Sanjiva Weerawarana, 27 Nov 2003
Ugo Corda, 27 Nov 2003
Sanjiva Weerawarana, 30 Nov 2003
Ugo Corda, 1 Dec 2003
Ron Ten-Hove, 1 Dec 2003
Ugo Corda, 1 Dec 2003
Ron Ten-Hove, 1 Dec 2003
Ugo Corda, 1 Dec 2003
Ron Ten-Hove, 1 Dec 2003
Ugo Corda, 2 Dec 2003
Yaron Goland, 2 Dec 2003
Ron Ten-Hove, 3 Dec 2003
Peter Furniss, 3 Dec 2003
Changes: 21 Oct 2003 - new issue;
22 Oct 2003 - fields: Links;
23 Oct 2003 - fields: Links;
24 Oct 2003 - fields: Links;
27 Oct 2003 - fields: Links;
31 Oct 2003 - fields: Links;
1 Nov 2003 - fields: Links;
2 Nov 2003 - fields: Links;
3 Nov 2003 - fields: Links;
4 Nov 2003 - fields: Links;
19 Nov 2003 - fields: Links;
20 Nov 2003 - fields: Links;
21 Nov 2003 - fields: Links;
24 Nov 2003 - fields: Links, Status, Proposed resolution;
25 Nov 2003 - fields: Links;
26 Nov 2003 - fields: Links;
27 Nov 2003 - fields: Status, Vote announcement, Links;
30 Nov 2003 - fields: Links;
1 Dec 2003 - fields: Links;
2 Dec 2003 - fields: Links;
3 Dec 2003 - fields: Links;
10 Dec 2003 - fields: Status, Proposed resolution, Resolution
Closed as a subset of issue 37 : Initiating Correlation Set More Than Once
Links: Announcement, 22 Oct 2003
Edit group action (Satish Thatte, 14 Jan 2004)
Yaron Y. Goland, 26 Mar 2004
Changes: 22 Oct 2003 - new issue;
22 Oct 2003 - fields: Links;
15 Jan 2004 - fields: Links;
26 Mar 2004 - fields: Links;
22 Jun 2004 - fields: In spec, Resolution, Status
The latter requirement is too restrictive. Sub-scopes can be included in a
serializable scope, and will be treated as logically part of the serializable scope.
What should be banned are nested serializable scopes.
Proposed resolution: Ron Ten-Hove, 11 Nov 2003
Resolution: Proposed in Ron Ten-Hove, 11 Nov 2003, accepted at 12 November meeting
Section 13.6, first paragraph, in the input text reads:
When the variableAccessSerializable attribute is set to "yes", the scope provides concurrency control in governing access to shared variables. Such a scope is called a serializable scope. Serializable scopes must not be nested. A scope marked with variableAccessSerializable="yes" must be a leaf scope.
The final sentence should be modified such that the paragraph should read a follows:
When the variableAccessSerializable attribute is set to "yes", the scope provides concurrency control in governing access to shared variables. Such a scope is called a serializable scope. Serializable scopes must not be nested. A scope marked with variableAccessSerializable="yes" must not contain other serializable scopes, but may contain scopes that are not marked as serializable. In the latter case, access to shared variables from within such enclosed scopes is controlled by the enclosing serializable scope.
Note that this should be borne in mind in considering and applying issue 36 : Multiple instances of event handler and issue 62 : Event handlers and Serializable Scopes
Links: Satish Thatte, 22 Oct 2003
Dieter Roller, 22 Oct 2003
Announcement, 22 Oct 2003
Proposed resolution (Ron Ten-Hove, 11 Nov 2003)
Eckenfels. Bernd, 11 Nov 2003
Changes: 22 Oct 2003 - new issue;
22 Oct 2003 - fields: Links;
11 Nov 2003 - fields: Status, Proposed resolution, Links;
12 Nov 2003 - fields: Links, Status, Resolution;
9 Jun 2004 - fields: In spec
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value will be selected if present.
This is misleading because it suggests that such a catch activity will be selected even if it specifies a faultVariable.
For instance:
<scope> <faulthandlers> <catch faultName="x:foo" faultVariable="bar"> <empty/> </catch> <catchAll> <empty/> </catchAll> </faulthandlers> <throw faultName="x:foo"/> </scope>
The wording suggests that the first fault handler will be invoked rather than the catchAll.
Change the sentence to:
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value, and no faultVariable attribute, will be selected if present. Otherwise, the default catchAll handler is selected if present.
Change the line in Section 13.4 of the BPEL 1.1 spec
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value will be selected if present.To:
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value, and no faultVariable attribute, will be selected if present. Otherwise, the default catchAll handler is selected if present.
In other words is the following legal?
<process> ... <flow> <receive createInstance="yes".../> <receive createInstance="no".../> </flow> </process>
Yaron
Links: Yaron Goland, 30 Oct 2003
Assaf Arkin, 31 Oct 2003
Frank Leymann, 31 Oct 2003
Announcement, 3 Nov 2003
Discussed at Walldorf f-t-f (document details)
Proposed resolution (Yaron Y. Goland, 19 May 2004)
Yaron Y. Goland, 20 May 2004
Changes: 3 Nov 2003 - new issue;
3 Nov 2003 - fields: Links;
22 Apr 2004 - fields: Links;
19 May 2004 - fields: Links, Status, Proposed resolution;
20 May 2004 - fields: Links
Add an appendix, much like the existing fault summary
appendix, that will provide a single checklist of all static analysis
requirements with a brief description of their function.
Resolution: Proposed in Yaron Y. Goland, 4 Jun 2004, decided at San Francisco f-t-f
It is moved that the BPEL spec be required to provide an explicit list
in a single location of all static analysis checks mandated by the spec.
It is recommended that the editors produce a list similar to the one
provided in Appendix A for standard faults.
Links: Announcement, 5 Nov 2003
Proposed resolution (Yaron Y. Goland, 4 Jun 2004)
Changes: 5 Nov 2003 - new issue;
5 Nov 2003 - fields: Links;
9 Jun 2004 - fields: Links, Status, Proposed resolution;
23 Jun 2004 - fields: Status, Proposed resolution, Resolution
<flow ...> <links> <link name="AtoB-1"/> <link name="AtoB-2"/> </links> <invoke name="A" ...> <source linkName="AtoB-1" transitionCondition="P1"/> <source linkName="AtoB-2" transitionCondition="P2"/> ... </invoke> <invoke name="B" ...> <target linkName="AtoB-1"/> <target linkName="AtoB-2"/> ... </invoke> </flow>
In section 12.5, "Flow", add an explicit constraint to the specification text that disallows multiple links to have the same source and the same target.
Vote 11 for, 8 against, plus abstentions (meeting was quorate)
Links: Announcement, 17 Nov 2003
Proposed resolution (Dieter Koenig1, 20 Nov 2003)
Changes: 17 Nov 2003 - new issue;
17 Nov 2003 - fields: Links;
20 Nov 2003 - fields: Links, Status, Proposed resolution;
10 Dec 2003 - fields: Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
In addition, recommend we discuss how this affects interoperability and
portability, and whether implementation guidelines would be in order
(coordination with implementation subgroup is recommended).
Qualifier: clarification
Links: Announcement, 25 Nov 2003
Ugo Corda, 25 Nov 2003
Monica J. Martin, 26 Nov 2003
Changes: 25 Nov 2003 - new issue;
26 Nov 2003 - fields: Links;
27 Nov 2003 - fields: Links
Unfortunately WSDL does not define how one should specify an optional message part in an
abstract definition. To resolve this ambiguity and to fully support SOAP it is necessary
for BPEL to introduce a mechanism that allows the BPEL process to specify that a particular
message part in an abstract message definition is optional.
Revisitable: Yes
Resolution: Proposed in Yaron Y. Goland, 29 Nov 2004, decided conf call 8 Dec 2004
Given the outcome of the vote on issue 87.1 I propose that we close
issue 87 with no change to the spec and mark it as revistable.
Links: Announcement, 27 Nov 2003
Ugo Corda, 27 Nov 2003
Yaron Y. Goland, 27 Aug 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Ugo Corda, 16 Sep 2004
Yaron Y. Goland, 17 Sep 2004
Ugo Corda, 17 Sep 2004
Yaron Y. Goland, 17 Sep 2004
Yaron Y. Goland, 17 Sep 2004
Satish Thatte, 17 Sep 2004
Ugo Corda, 18 Sep 2004
Frank Leymann, 19 Sep 2004
Yaron Y. Goland, 27 Sep 2004
Yaron Y. Goland, 27 Sep 2004
Ugo Corda, 27 Sep 2004
Eckenfels. Bernd, 4 Oct 2004
Yaron Y. Goland, 5 Oct 2004
Satish Thatte, 6 Oct 2004
Kristofer Agren, 6 Oct 2004
Francisco Curbera, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Danny van der Rijn, 6 Oct 2004
Satish Thatte, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Eckenfels. Bernd, 6 Oct 2004
Satish Thatte, 7 Oct 2004
Proposed resolution (Yaron Y. Goland, 29 Nov 2004)
Changes: 27 Nov 2003 - new issue;
27 Nov 2003 - fields: Links;
28 Nov 2003 - fields: Links;
27 Aug 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
17 Sep 2004 - fields: Links;
18 Sep 2004 - fields: Links;
20 Sep 2004 - fields: Links;
27 Sep 2004 - fields: Links;
29 Sep 2004 - fields: Links, Status, Proposed resolution;
7 Oct 2004 - fields: Split by hand;
11 Oct 2004 - fields: Links;
30 Nov 2004 - fields: Links, Status, Proposed resolution;
8 Dec 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, In spec
Close with no change to the spec. The WS-BPEL TC should not standardize a way to use
WSDL 1.1 web services in BPEL with the WSDL 2.0 extension for application data
Links: Proposed resolution (Yaron Y. Goland, 28 Sep 2004)
Eckenfels. Bernd, 4 Oct 2004
Yaron Y. Goland, 5 Oct 2004
Satish Thatte, 6 Oct 2004
Kristofer Agren, 6 Oct 2004
Francisco Curbera, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Danny van der Rijn, 6 Oct 2004
Satish Thatte, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Eckenfels. Bernd, 6 Oct 2004
Satish Thatte, 7 Oct 2004
Eckenfels. Bernd, 4 Oct 2004
Yaron Y. Goland, 5 Oct 2004
Satish Thatte, 6 Oct 2004
Kristofer Agren, 6 Oct 2004
Francisco Curbera, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Danny van der Rijn, 6 Oct 2004
Satish Thatte, 6 Oct 2004
Yaron Y. Goland, 6 Oct 2004
Eckenfels. Bernd, 6 Oct 2004
Satish Thatte, 7 Oct 2004
Peter Furniss, 7 Oct 2004
Yaron Y. Goland, 11 Oct 2004
Yaron Y. Goland, 11 Oct 2004
Satish Thatte, 12 Oct 2004
Web ballot (ends 09 Nov 2004)
Web ballot (ends 24 Nov 2004)
Diane Jordan, 7 Dec 2004
Changes: 7 Oct 2004 - fields: Split, Links;
12 Oct 2004 - fields: Links;
3 Nov 2004 - fields: Links;
23 Nov 2004 - fields: Status, Links;
2 Dec 2004 - fields: Status, Resolution, In spec, Proposed resolution;
8 Dec 2004 - fields: Links
Should we use the XML element name 'import'?
Import implies that the files that are being pointed to are included in the BPEL definition. But
strictly speaking that isn't the case since BPEL does not support in-line WSDL or XML Schema definitions.
Shouldn't the name be more descriptive, such as 'associate'?
How do we handle relative URIs in import's attributes?
What is the base URI against which the relative URIs are resolved? Should we refer to something like
XML Base (http://www.w3.org/TR/xmlbase/)? Should we specify that if xmlbase isn't used then the definition
of the base URI is engine specific?
What happens if an engine chooses not to honor the import?
The current text of the BPEL spec states that the BPEL engine is not required to import the files
it is pointed at. But if it fails to import the files then the BPEL definition will not be complete
and at some point an error is likely to happen if the imported files contained definitions necessary
for the BPEL. Shouldn't a static error be thrown if an engine decides not to honor an import?
What happens if two different files import the same definition?
Is there any sort of ordering? Does the first or last definition hold? Should this always
be a static error? What about collisions from implicit imports versus explicit imports? An
implicit import is an import that occurs through a mechanism not specified in the BPEL file
itself (e.g. how import worked before we introduced the import XML element). An explicit
import is an import specified via an import XML element.
Links: Announcement, 3 Dec 2003
Ugo Corda, 4 Dec 2003
Francisco Curbera, 5 Dec 2003
Ugo Corda, 5 Dec 2003
Ugo Corda, 5 Dec 2003
Discussed at San Francisco f-t-f
Changes: 3 Dec 2003 - new issue;
4 Dec 2003 - fields: Links;
5 Dec 2003 - fields: Links;
23 Jun 2004 - fields: Links
A static analysis requirement will be defined to ensure that a
process will be rejected if query or execution language expressions are not supported.
(Yaron to provide text)
Links: Announcement, 7 Jan 2004
Yaron Y. Goland, 13 Aug 2004
Alex Yiu, 17 Aug 2004
Yaron Y. Goland, 18 Aug 2004
Alex Yiu, 18 Aug 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 7 Jan 2004 - new issue;
8 Jan 2004 - fields: Links;
13 Aug 2004 - fields: Links;
18 Aug 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
23 Sep 2004 - fields: Status, Proposed resolution, Resolution;
17 Nov 2004 - fields: In spec
<assign> <copy> <from location="uri" query="queryString"?/> <to.../> </copy> </assign>
Close with no change, but mark as revisitable
Links: Announcement, 9 Jan 2004
Ugo Corda, 9 Jan 2004
Kristofer Agren, 9 Jan 2004
Ugo Corda, 9 Jan 2004
Ron Ten-Hove, 9 Jan 2004
Kristofer Agren, 9 Jan 2004
Edwin Khodabakchian, 9 Jan 2004
Kristofer Agren, 9 Jan 2004
David RR Webber, 9 Jan 2004
Eckenfels. Bernd, 12 Jan 2004
Kristofer Agren, 12 Jan 2004
Yaron Goland, 13 Jan 2004
Ugo Corda, 13 Jan 2004
Discussed at Walldorf f-t-f (document details)
Proposed resolution (Kristofer Agren, 23 Apr 2004)
Dieter Koenig1, 26 Apr 2004
Martin Chapman, 26 Apr 2004
Edwin Khodabakchian, 26 Apr 2004
Kristofer Agren, 26 Apr 2004
Kristofer Agren, 26 Apr 2004
Alex Yiu, 26 Apr 2004
Kristofer Agren, 27 Apr 2004
David RR Webber, 27 Apr 2004
Dieter Koenig1, 27 Apr 2004
Kristofer Agren, 28 Apr 2004
Satish Thatte, 28 Apr 2004
Satish Thatte, 28 Apr 2004
David RR Webber, 28 Apr 2004
Changes: 9 Jan 2004 - new issue;
9 Jan 2004 - fields: Links;
12 Jan 2004 - fields: Links;
13 Jan 2004 - fields: Links;
22 Apr 2004 - fields: Links;
23 Apr 2004 - fields: Links, Status, Proposed resolution;
26 Apr 2004 - fields: Links;
27 Apr 2004 - fields: Links;
29 Apr 2004 - fields: Links, Status, Proposed resolution, Resolution, Revisitable
Example:
<pick> <onMessage partnerLink="pl1" portType="mypt" operation="myop"> <flow>...</flow> </onMessage> <onAlarm for="P1M"> <sequence>...</sequence> </onAlarm> </pick>
Currently, the nested activities must be replaced by an explicit <empty> because the schema requires a nested activity.
Example:
<pick> <onMessage partnerLink="pl1" portType="mypt" operation="myop"> <empty/> </onMessage> <onAlarm for="P1M"> <empty/> </onAlarm> </pick>Submitter's proposal: Allow to omit the nested activity of pick/onMessage, eventHandlers/onEvent, and onAlarm in abstract processes. New syntax - added '?' after "activity" (4 times):
<pick createInstance="yes|no"? standard-attributes> standard-elements <onMessage partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?>+ <correlations>? <correlation set="ncname" initiate="yes|no"?/>+ </correlations> activity? </onMessage> <onAlarm (for="duration-expr" | until="deadline-expr")>* activity? </onAlarm> </pick><eventHandlers>? <!-- there must be at least one onEvent or onAlarm handler --> <onEvent partnerLink="ncname" portType="qname" operation="ncname" messageType="qname" variable="ncname">* <correlations>? <correlation set="ncname" initiate="yes|no"/>+ </correlations> activity? </onEvent> <onAlarm for="duration-expr"? until="deadline-expr"?>* activity? </onAlarm> </eventHandlers>
BPEL provides for extension points but does not provide guidance on how they should be used. This brings up a number of issues:
Changes Required: Add a faultElement attribute for use with catch.
Change Since Previous Proposal: Removed the faultType attribute. Throwing complex types as faults is vaguely odd and WS-I requires that all SOAP faults be defined using elements so in general Web Services faults are typically elements anyway.
Sections 6.2, 11.3 and 13.4
Change schema from:
<faultHandlers>? <!-- there must be at least one fault handler or default --> <catch faultName="qname"? faultVariable="ncname"? faultMessageType="qname"?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers>to:
<faultHandlers>? <!-- there must be at least one fault handler or default --> <catch faultName="qname"? faultVariable="ncname"? faultMessageType="qname"? faultElement="qname"?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers>
Section 13.4
From: The faultMessageType is technically redundant when the faultName used is derived from a WSDL 1.1 fault message defined as a fault response to a synchronous operation, since the WSDL fault response has a defined message type. The faultMessageType is technically redundant when the faultName used is derived from a WSDL 1.1 fault message defined as a fault response to a synchronous operation, since the WSDL fault response has a defined message type. However, the faultName may reflect a purely internal custom fault in a process, or the faultName may be missing. In such cases, the faultVariable, which is local to the fault handler and declared by its occurrence in the catch element, will not have a defined type. To avoid this possibility, although the faultName, faultVariable and faultMessageType attributes are all optional, the faultVariable and faultMessageType declarations go together, i.e., they must either both be present or both absent. Moreover, the faultName and faultVariable attributes cannot both be absent.
To: Data thrown with a fault can be a WSDL message type or a XML schema element. Each catch which specifies a faultName can only catch a fault of a single type. This one-to-one relationship is necessary in order to guarantee proper typing. If the data to be caught is a WSDL message type then the faultMessageType attribute MUST be used to specify the message type’s qname. If the data to be caught is a XML element definition then the faultElement attribute MUST be used to specify the element definition’s qname.
The faultName may reflect a purely internal custom fault in a process, or the faultName may be missing. In such cases, the faultVariable, which is local to the fault handler and declared by its occurrence in the catch element, will not have a defined type. To avoid this possibility faultVariable MUST only be used if either the faultMessageType or faultElement attributes, but not both, accompany it. faultMessageType and faultElement MUST NOT be used unless accompanied by faultVariable.
From: If the fault has associated fault data, a catch activity specifying a matching faultName value and a faultVariable whose type (WSDL message type) matches the type of the fault’s data will be selected if present.
To: If the fault has associated fault data, a catch activity specifying a matching faultName value and a faultVariable whose type matches the type of the fault’s data will be selected if present.
Section C
From:
<complexType name="tCatch"> <complexContent> <extension base="bpws:tActivityOrCompensateContainer"> <attribute name="faultName" type="QName"/> <attribute name="faultVariable" type="NCName"/> <attribute name="faultMessageType" type="QName"/> </extension> </complexContent> </complexType>To:
<complexType name="tCatch"> <complexContent> <extension base="bpws:tActivityOrCompensateContainer"> <attribute name="faultName" type="QName"/> <attribute name="faultVariable" type="NCName"/> <attribute name="faultMessageType" type="QName"/> <attribute name="faultElement" type="QName"/> </extension> </complexContent> </complexType>
Specific fault handlers that catch a particular fault can rethrow the fault because they have the fault name and variable. However, a catchAll cannot because it does not know about the details of the fault.
A similar consideration applies to <catch> fault handlers that are able to accept different
faults because they do not specify faultName AND faultVariable.
Submitter's proposal: Allow all fault handlers to rethrow the original fault. For example,
this could be done by invoking <throw/> without attributes which would then mean that the
original fault is rethrown.
Example:
<catchAll> <sequence> ... <throw/> <!-- this is a rethrow of the original fault --> </sequence> <catchAll>
Allow all custom fault handlers to rethrow the original fault with the syntax
<rethrow/>
rethrow has no attributes.
Rationale: Default fault handlers, in addition to other steps, rethrow the
original fault. Custom fault handlers must be able to express the default
behavior as well.
Example:
<catchAll> <sequence> ... <rethrow/> <!-- this is a rethrow of the original fault --> </sequence> <catchAll>
<catch faultVariable="xxx" faultMessageType="yyy"> also needs this construct.
Since rethrow only appears within the scope of a fault handler, it will always be unambiguous at runtime which fault is to be rethrown.
Links: Announcement, 3 Feb 2004
Proposed resolution (Dieter Koenig1, 19 Feb 2004)
Alex Yiu, 2 Mar 2004
Yaron Y. Goland, 2 Mar 2004
Dieter Koenig1, 3 Mar 2004
Alex Yiu, 3 Mar 2004
confirmation of change (Dieter Koenig1, 3 Mar 2004)
Changes: 3 Feb 2004 - new issue;
3 Feb 2004 - fields: Links;
19 Feb 2004 - fields: Links, Status, Proposed resolution;
3 Mar 2004 - fields: Links, Status, Proposed resolution, Resolution, Rationale;
4 Mar 2004 - fields: Links;
9 Jun 2004 - fields: In spec
Consequently, for abstract processes, these references must also be optional in the
<onMessage> and <onEvent> elements.
Submitter's proposal: For abstract processes, make variable references optional
in the <onMessage> and <onEvent> elements.
Proposed resolution: Dieter Koenig1, 19 Feb 2004
Vote announcement: waiting on issue 107
Links: Announcement, 10 Feb 2004
Ivana Trickovic, 10 Feb 2004
Proposed resolution (Dieter Koenig1, 19 Feb 2004)
Alex Yiu, 19 Feb 2004
Dieter Koenig1, 19 Feb 2004
Alex Yiu, 19 Feb 2004
Monica J. Martin, 26 Feb 2004
Changes: 10 Feb 2004 - new issue;
11 Feb 2004 - fields: Links;
19 Feb 2004 - fields: Links, Status, Proposed resolution;
20 Feb 2004 - fields: Links;
26 Feb 2004 - fields: Links;
29 Apr 2004 - fields: Vote announcement
Version 1.0 was the August 2002 text; our input document is 1.1. "OASIS TC 1.0" has been used, but a
simpler monotonic numbering would seem easier to follow.
Resolution: Agreed by multiple choice web ballot first (ended 14 Sep 2004) , second (ended 14 Sep 2004) , third (ended 14 Sep 2004) , announced result
The name will be WS-BPEL v2.0
Links: Announcement, 20 Feb 2004
Peter Furniss, 9 Jun 2004
Yaron Y. Goland, 9 Nov 2004
Changes: 20 Feb 2004 - new issue;
23 Feb 2004 - fields: Links;
9 Jun 2004 - fields: Links;
10 Nov 2004 - fields: Links;
11 Nov 2004 - fields: Status, Resolution;
19 Nov 2004 - fields: In spec
This restriction makes less sense for BPEL abstract processes. Because of this restriction, the abstract process of the party that initiates a message exchange must be extended and a start activity must be introduced (also additional WSDL elements, such as port types, messages, must be defined as well as partner link type). But how the initiating process is started is an implementation detail and does not have to be included in the BPEL abstract process since it is not part of the "business protocol".
Submitter's proposal: Allow the invoke activity to be used as the start activity for abstract processes.
Proposed resolution: Ivana Trickovic, 10 Mar 2004
Vote announcement: waiting on issue 107
Links: Announcement, 3 Mar 2004
Danny van der Rijn, 3 Mar 2004
Ivana Trickovic, 4 Mar 2004
Danny van der Rijn, 4 Mar 2004
Satish Thatte, 6 Mar 2004
Ivana Trickovic, 9 Mar 2004
Proposed resolution (Ivana Trickovic, 10 Mar 2004)
Yaron Y. Goland, 12 Mar 2004
Ivana Trickovic, 15 Mar 2004
Yaron Y. Goland, 5 May 2004
Alex Yiu, 6 May 2004
Alex Yiu, 6 May 2004
Ivana Trickovic, 7 May 2004
Yaron Y. Goland, 10 May 2004
Yaron Y. Goland, 10 May 2004
Ivana Trickovic, 12 May 2004
Yaron Y. Goland, 17 May 2004
Ivana Trickovic, 21 May 2004
Yaron Y. Goland, 21 May 2004
Ivana Trickovic, 26 May 2004
msg on abstract list (Diane Jordan, 4 Jun 2004)
issue 99 explanation from the previous link (document details)
uddi and bpel4ws document referred to in the previous link (document details)
Peter Furniss, 23 Jun 2004
Changes: 3 Mar 2004 - new issue;
3 Mar 2004 - fields: Links;
4 Mar 2004 - fields: Links;
6 Mar 2004 - fields: Links;
9 Mar 2004 - fields: Links;
10 Mar 2004 - fields: Links, Status, Proposed resolution;
13 Mar 2004 - fields: Links;
15 Mar 2004 - fields: Links;
29 Apr 2004 - fields: Vote announcement;
6 May 2004 - fields: Links;
8 May 2004 - fields: Links;
11 May 2004 - fields: Links;
15 May 2004 - fields: Links;
17 May 2004 - fields: Links;
21 May 2004 - fields: Links;
27 May 2004 - fields: Links;
23 Jun 2004 - fields: Links
Closed with no change to the spec.
Rationale: In the present (1.34 or earlier) spec, there is no possibility that a valid XML document
manipulated by a BPEL process can become invalid.
Some currently open issues might change this - the resolution of such issues needs to take account of the possibility
of temporary invalidation. Identified issues are issue 11 : Query in <to> close should allow assigning to new locations , issue 51 : Section 9.3.1 & Schema Validation and issue 103 : Standardizing $varName syntax for XPath to refer to a BPEL variable .
Links: Announcement, 4 Mar 2004
Discussed at Walldorf f-t-f (document details)
Changes: 4 Mar 2004 - new issue;
4 Mar 2004 - fields: Links;
22 Apr 2004 - fields: Links;
23 Jun 2004 - fields: Status, Resolution, In spec, Rationale
remove the following from 9.2:
It is not permitted to have variables with same name but different messageType/type/element within an enclosing scope hierarchy.
add the following:
Variable access follows common lexical scoping rules. A variable resolves to the nearest enclosing scope, regardless of the type of the variable.
"bpws:getVariableProperty(stockResult,level) > 100" "bpws:getVariableProperty(stockResult,level) >= 0" "bpws:getVariableData(orderDetails) > 100"
We need to put quotations on function parameters.
It becomes like:
"bpws:getVariableProperty('stockResult','level') > 100" "bpws:getVariableProperty('stockResult','level') >= 0" "bpws:getVariableData('orderDetails') > 100"
In some of the examples the "bpws:" is actually extra and incorrect. The prefix-namespace mapping of a function call in XPath typically
inherited from that of the hosting element.
Links: Announcement, 9 Mar 2004
Ron Ten-Hove, 9 Mar 2004
Alex Yiu, 9 Mar 2004
Chris Keller, 17 Mar 2004
Announcement, Wed Mar 17 10:59:27 2004
Alex Yiu, 17 Mar 2004
Discussed at Walldorf f-t-f (document details)
Changes: 9 Mar 2004 - new issue;
9 Mar 2004 - fields: Links;
10 Mar 2004 - fields: Links;
17 Mar 2004 - fields: Links;
22 Apr 2004 - fields: Links
Right now, there are three BPWS functions defined in BPEL can
be called in an XPath Query / Expression.
bpws:getVariableProperty ('variableName', 'propertyName') bpws:getVariableData ('variableName', 'partName'?, 'locationPath'?) bpws:getLinkStatus('linkName')For refering to a variable data, if data is of an XSD complex type or XSD simple type (not WSDL 1.1 type), we want to add one more way to refer to a variable on top of getVariableData() Function Call? That is using "$varName" syntax.
"bpws:getVariableData(orderDetails) > 100"The additional way will look like:
"$orderDetails > 100"Note that:
<invoke name="settleTrade" joinCondition="bpws:getLinkStatus('buyToSettle') and bpws:getLinkStatus('sellToSettle')"> <target linkName="getBuyerInformation"/> <target linkName="getSellerInformation"/> <source linkName="toBuyConfirm"/> <source linkName="toSellConfirm"/> </invoke>
In 12.5.3. Flow Graph Example, replace "getBuyerInformation" and "getSellerInformation"
with "buyToSettle" and "sellToSettle", respectively.
Links: Announcement, 10 Mar 2004
Proposed resolution (Yuzo Fujishima, 11 Mar 2004)
Changes: 10 Mar 2004 - new issue;
10 Mar 2004 - fields: Links;
11 Mar 2004 - fields: Links, Status, Proposed resolution;
17 Mar 2004 - fields: Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
Include a table of prefixes used within the document, and the name space URIs to which they are
assigned, in section 2, Notational Conventions.
Links: Announcement, 17 Mar 2004
Proposed resolution (Ron Ten-Hove, 4 Jun 2004)
Changes: 17 Mar 2004 - new issue;
17 Mar 2004 - fields: Links;
9 Jun 2004 - fields: Links, Status, Proposed resolution;
24 Jun 2004 - fields: Status, Proposed resolution, Resolution
<any-activity> <precondition> <expression language="XPath"> some-xpath-expression </expression> </precondition> <postcondition> <expression language="XPath"> some-xpath-expression </expression> </postcondition> .... </any-activity>Interpetation of the <pre-/post-condition> elements would be optional, but if assertions are enabled the expressions must evaluate to "true" or else the process instance is immediately terminated (ala <terminate>). Assertions would be available to both executable and abstract processes. -standard argument for assertions goes here-.
Closed with no change to the spec.
Rationale: Since an assertion would not need to be evaluated and the semantics would be implementation defined, it
is considered appropriate for an extension (see issue 92 : Mandatory & Optional BPEL Extensibility ).
Links: Announcement, 18 Mar 2004
Ricky Ho, 18 Mar 2004
Danny van der Rijn, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Ricky Ho, 18 Mar 2004
Chris Keller, 18 Mar 2004
Satish Thatte, 18 Mar 2004
David RR Webber, 18 Mar 2004
Maciej Szefler, 18 Mar 2004
Ricky Ho, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Maciej Szefler, 18 Mar 2004
Satish Thatte, 18 Mar 2004
Changes: 18 Mar 2004 - new issue;
18 Mar 2004 - fields: Links;
19 Mar 2004 - fields: Links;
23 Jun 2004 - fields: Status, Resolution, In spec, Rationale
An example of implicitly hiding data is the way that abstract processes deal with some of the variables on message operations. If one doesn't want to specify where a message is recorded on a receive then one may simply leave off the variable attribute.
An example of explicitly hiding data would be introducing something like an <opaque> activity. For example, imagine that one is defining an abstract process and the start activities of the abstract process are to be omitted since they are not relevant to the functionality the abstract process is describing. In that case one could start a process with an <opaque> activity. By putting in <opaque> one is explicitly communicating to the reader of the abstract process 'There is something here but its definition is not relevant to the goal of the abstract process.'
The advantage of explicit versus implicit hiding is in error detection.
In an implicit system where one simply leaves off variables or omits activities there is no way to tell the difference between an error, e.g. the person intended to include the variable or activity but forget and true omission. This is a well known problem with treating the absence of information as information.
In an explicit system where one would have <opaque> activities and special reserved bpel:opaque place holders for attributes there is no possibility for confusion. If an opaque value is specified then one has an unambiguous declaration from the designer of the abstract process as to their intention.
The issue before the group is - should we consistently use an implicit
or explicit omission mechanism for specifying when information has been
intentionally omitted in an abstract process?
Proposed resolution: Peter Furniss, 14 Dec 2004
Danny van der Rijn, 14 Dec 2004
Links: Announcement, 18 Mar 2004
Frank Leymann, 19 Mar 2004
Yaron Y. Goland, 19 Mar 2004
Frank Leymann, 23 Mar 2004
Yaron Y. Goland, 23 Mar 2004
Satish Thatte, 24 Mar 2004
Yaron Y. Goland, 14 Apr 2004
Yuzo Fujishima, 15 Apr 2004
Philip Rossomando, 15 Apr 2004
Yaron Y. Goland, 15 Apr 2004
Yuzo Fujishima, 16 Apr 2004
Yaron Y. Goland, 16 Apr 2004
Yaron Y. Goland, 16 Apr 2004
Tony Fletcher, 17 Apr 2004
Eckenfels. Bernd, 17 Apr 2004
Yuzo Fujishima, 19 Apr 2004
Yaron Y. Goland, 19 Apr 2004
Yuzo Fujishima, 20 Apr 2004
Assaf Arkin, 20 Apr 2004
Yaron Y. Goland, 20 Apr 2004
Assaf Arkin, 22 Apr 2004
Discussed at 14 April con call (document details)
Yaron Y. Goland, 22 Apr 2004
Monica J. Martin, 23 Apr 2004
Yaron Y. Goland, 26 Apr 2004
Assaf Arkin, 28 Apr 2004
Yaron Y. Goland, 30 Apr 2004
Proposed resolution (Yaron Y. Goland, 5 May 2004)
Alex Yiu, 6 May 2004
Dieter Roller, 6 May 2004
Philip Rossomando, 7 May 2004
Alex Yiu, 8 May 2004
Alex Yiu, 8 May 2004
Yaron Y. Goland, 10 May 2004
Proposed resolution (rkhalaf, 30 Sep 2004)
Yaron Y. Goland, 5 Oct 2004
Assaf Arkin, 5 Oct 2004
Yaron Y. Goland, 6 Oct 2004
rkhalaf, 6 Oct 2004
Martin Chapman, 8 Oct 2004
Peter Furniss, 8 Oct 2004
rkhalaf, 8 Oct 2004
Yaron Y. Goland, 11 Oct 2004
rkhalaf, 11 Oct 2004
Proposed resolution (Peter Furniss, 1 Dec 2004)
[See also discussion of;ISSUE=82]
Proposed resolution (Peter Furniss, 14 Dec 2004)
Danny van der Rijn, 14 Dec 2004
Changes: 18 Mar 2004 - new issue;
18 Mar 2004 - fields: Links;
19 Mar 2004 - fields: Links;
20 Mar 2004 - fields: Links;
23 Mar 2004 - fields: Links;
24 Mar 2004 - fields: Links;
15 Apr 2004 - fields: Links;
16 Apr 2004 - fields: Links;
17 Apr 2004 - fields: Links;
19 Apr 2004 - fields: Links;
20 Apr 2004 - fields: Links;
21 Apr 2004 - fields: Links;
22 Apr 2004 - fields: Links;
24 Apr 2004 - fields: Links;
27 Apr 2004 - fields: Links;
29 Apr 2004 - fields: Links;
1 May 2004 - fields: Links;
6 May 2004 - fields: Links, Status, Proposed resolution;
7 May 2004 - fields: Links;
8 May 2004 - fields: Links;
11 May 2004 - fields: Links;
30 Sep 2004 - fields: Status, Proposed resolution, Links;
5 Oct 2004 - fields: Links;
6 Oct 2004 - fields: Links;
7 Oct 2004 - fields: Links;
11 Oct 2004 - fields: Links;
12 Oct 2004 - fields: Links;
2 Dec 2004 - fields: Links, Status, Proposed resolution;
14 Dec 2004 - fields: Links, Status, Proposed resolution
compensationHandler flow compensate scope="foo" compensate scope="bar"In the case of the default compensation handler section 13.3.3 of the latest editor's draft states "If the compensation handler for a scope is absent, the default compensation handler invokes the compensation handlers for the immediately enclosed scopes in the reverse order of the completion of those scopes."
But, if one felt deeply sneaky, one could interpret the spec to mean that one must start the compensation handlers in the completion order but there is no requirement that one must necessarily wait for a compensation handler to complete execution before starting the next one. In other words, one could interpret the current language as allowing default compensation handlers to execute child compensation handlers in parallel.
The purpose of this issue is to clarify the ability to run compensation handlers in parallel so that programmers know what to expect. Since we now allow compensation handlers to manipulate common variables it is critical that programmers know if their handlers can run in parallel.
At a minimum this issue should answer the following questions:
The issue this
addressed was resolved as part of the resolution of issue 10 : Serialization of compensation .
Links: Announcement, 20 Mar 2004
Yaron Y. Goland, 18 Mar 2004
Frank Leymann, 19 Mar 2004
Muruga Chinnananchi, 19 Mar 2004
Alastair J. Green, 30 Mar 2004
Muruga Chinnananchi, 30 Mar 2004
Muruga Chinnananchi, 31 Mar 2004
Discussed at Walldorf f-t-f (document details)
Proposed resolution (Yaron Y. Goland, 23 Nov 2004)
Changes: 20 Mar 2004 - new issue;
20 Mar 2004 - fields: Links;
30 Mar 2004 - fields: Links;
31 Mar 2004 - fields: Links;
1 Apr 2004 - fields: Links;
22 Apr 2004 - fields: Links;
24 Nov 2004 - fields: Links, Status, Proposed resolution, Resolution, In spec
Finally, in the case of invoke, when the operation invoked is synchronous request/response, a pattern attribute is used to indicate whether the correlation applies to the outbound (request) message, the inbound (response) message, or both. These ideas are explained in more detail in the context of the use of correlation in the rest of this example.
There are several issues this text raises about the pattern attribute:
A common BPEL use case is that a programmer has a number of variables that contain data that will be used to create a message. When sending a message the programmer will create a temporary message variable, copy the values from the variables into the temporary message and then submit the temporary message variable. At which point the temporary message variable is discarded.
Similarly, when receiving a message the programmer may actually want the data in the message to be recorded in a number of variables. Currently the programmer has to create a temporary message variable, receive the message into the temporary message variable just to immediately turn around and pull the data out, record the data into individual variables and then discard the temporary message variable.
In both cases the temporary message variable is a transient storage location whose only purpose is to push data in and pull data out of message activities.
It would be extremely friendly if we could provide a macro that would allow programmers to build up a message as part of an invoke/reply from a set of variables rather than having to create a temporary variable for that purpose. Similarly, it would be great if it were possible on pick/receive to pull data directly out of an incoming message and record the data into variables rather than having to put the data into a temporary message variable whose only purpose is to get ripped to pieces.
To be clear, this is a request for a macro, not for a new BPEL feature.
Links: Announcement, 25 Mar 2004
David RR Webber, 26 Mar 2004
Eckenfels. Bernd, 23 Jun 2004
Changes: 25 Mar 2004 - new issue;
25 Mar 2004 - fields: Links;
26 Mar 2004 - fields: Links;
24 Jun 2004 - fields: Links
Currently we require that portType be specified on message activities, even though it is redundant, because it is useful for error checking. But it seems unfair to require programmers to constantly specify portType if they don't want or need the extra error checking.
As such this issue proposes that portType be made optional. If the portType attribute is specified on a message activity
then the BPEL validator MUST check that the value of the portType matches the value for the relevant role in the partnerLink
definition. If the specified value for portType does not match its expected value then the BPEL MUST be rejected.
Resolution: Proposed verbally and decided at San Francisco f-t-f
Closed as being duplicate of (having the same resolution as) issue 44 : portType is duplicated on Invoke activity and partnerLinkType
Links: Announcement, 25 Mar 2004
Changes: 25 Mar 2004 - new issue;
25 Mar 2004 - fields: Links;
23 Jun 2004 - fields: In spec, Resolution, Status
If multiple correlation sets with initiate="no" are used in a receive, pick/onMessage, or eventHandler/onEvent, then they must all match a message for that message to be delivered to the activity in the given process instance.
Resolution: proposed and agreed at f-t-f, 22 Sept 2004
Close with no change to spec.
A sub-group will be formed for interested parties to work on a separate,
non-normative document covering the information intended of appendix C. If this group
compes up with a document they agree to, they will bring it to the TC for endorsement.
Links: Announcement, 1 Apr 2004
Proposed resolution (Satish Thatte, 4 Jun 2004)
Monica J. Martin, 8 Jun 2004
Diane Jordan, 8 Jun 2004
Monica J. Martin, 8 Jun 2004
Satish Thatte, 8 Jun 2004
Martin Chapman, 8 Jun 2004
Satish Thatte, 8 Jun 2004
Martin Chapman, 8 Jun 2004
Satish Thatte, 8 Jun 2004
Monica J. Martin, 8 Jun 2004
Peter Furniss, 25 Jun 2004
Diane Jordan, 25 Jun 2004
Monica J. Martin, 25 Jun 2004
Peter Furniss, 18 Aug 2004
Peter Furniss, 18 Aug 2004
Satish Thatte, 25 Aug 2004
Peter Furniss, 25 Aug 2004
Francisco Curbera, 14 Sep 2004
Yaron Y. Goland, 16 Sep 2004
Martin Chapman, 16 Sep 2004
Alastair J. Green, 20 Sep 2004
Satish Thatte, 22 Sep 2004
Peter Furniss, 22 Sep 2004
Satish Thatte, 22 Sep 2004
Peter Furniss, 22 Sep 2004
Satish Thatte, 22 Sep 2004
Mark Little, 23 Sep 2004
Mark Little, 23 Sep 2004
Changes: 1 Apr 2004 - new issue;
1 Apr 2004 - fields: Links;
25 Jun 2004 - fields: Links, Status, Proposed resolution;
18 Aug 2004 - fields: Links;
26 Aug 2004 - fields: Links;
14 Sep 2004 - fields: Links;
16 Sep 2004 - fields: Links;
21 Sep 2004 - fields: Links;
23 Sep 2004 - fields: Status, Proposed resolution, Resolution, In spec, Links
In older business processes (such as those entirely or predominantly operated by humans) it is very common for fragments of process to survive long after the circumstances that justified those fragments have ceased to be relevant. Long-lived "business" processes, such as procedures and customs of national legislatures are good examples of this.
Although BPEL is concerned with automated processes, it should be possible to re-implement human-implemented
processes in BPEL, and similarly we should expect BPEL processes to evolve in a similar way, with relics of
former requirements continuing to be defined in the script. Thus it would enhance the wide and long-term
usefulness of BPEL if the top-level process element were made optional, allowing a BPEL script to contain
a disconnected collection of process fragments.
Submitter's proposal: Allow alternative top-level element instead of <process>. The name <bag> might
be appropriate.
It is not proposed, at this stage that a BPEL process or bag should be required to be dynamically self-modifying.
Such behaviour is of course common in real processes, and could be considered in future BPEL work.
Resolution: Proposed in Peter Furniss, 15 Oct 2004, decided conf call, 27 October 2004
This issue was raised on 1st April at the end of the Waldorf meeting.
It has been suggested that it should be closed with no change, as the committee has no sense of humour. Discussion disproved this, but the consensus is that BPEL isn't funny.
The issue is closed with no change to the spec.
Since it is date-specific, it will be used to light pumpkin candles on Halloween.
Links: Announcement, 1 Apr 2004
Discussed at Walldorf f-t-f (document details)
Proposed resolution (Peter Furniss, 15 Oct 2004)
Changes: 1 Apr 2004 - new issue;
1 Apr 2004 - fields: Links;
22 Apr 2004 - fields: Links;
18 Oct 2004 - fields: Links, Status, Proposed resolution;
27 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec
Discussion:
Suppose we have the following process:
<flow name="F1"> <links> <link name="L1"/> <!-- L1 is defined here and ... --> </links> <sequence name="S1"> <flow name="F2"> <links> <link name="L1"/> <!-- ... here --> </links> <sequence name="S2"> <invoke name="I1" ...> <target linkName="L1"/> <!-- Which L1? --> </invoke> ...
Note that link L1 is defined at two places.
Q1: Is this definition legal?
Q2: If legal, is I1 target of L1 of F2 (F2.L1)
or L1 of F1 (F1.L1)?
Submitter's proposal: Allow defining links with the same name. For a referencing activity, the inner-most link
for the activity hides all other links with the same name. (In the above example,
activity I1 is the target of link F2.L1, not F1.L1.)
Resolution: Proposed in Yuzo Fujishima, 22 Apr 2004, decided at 28 April conf call
As submitter's proposal.
Links: Yuzo Fujishima, 13 Apr 2004
rkhalaf, 13 Apr 2004
Yaron Y. Goland, 13 Apr 2004
Announcement, 14 Apr 2004
Proposed resolution (Yuzo Fujishima, 22 Apr 2004)
Changes: 14 Apr 2004 - new issue;
14 Apr 2004 - fields: Links;
22 Apr 2004 - fields: Links, Status, Proposed resolution;
29 Apr 2004 - fields: Status, Proposed resolution, Resolution;
9 Jun 2004 - fields: In spec
Normative Change - The schemas for pick and receive make correlation sets optional. That would appear to be wrong.
Also, I'm unclear about what assumptions we make regarding invoke, specifically, is there a requirement to have a correlation set defined on pattern="in" on an invoke? This is kind of a tricky issue. If a synchronous transport is being used then there may not be any explicit information available to mark the response for correlation purposes. In that case do we allow the correlation set for the response to be left off or do we require programmers to use issue 96 : Engine-managed correlation sets ?
Also note, that the WSDL 1.1 spec quite clearly states that
request/responses do not have to be sent over synchronous transports so
there may be values we could use for correlation sets. In other words,
the situation is inconsistent. In some cases a request/response uses a
synchronous transport and in other cases it could be using an
asynchronous transport with some message based correlation. Do we want
to distinguish these cases or do we want to just say that we presume
that any time a request/response pattern is used there is some
correlation mechanism implicitly known to the engine and therefore
correlation sets are always optional on the incoming message? Reply has
the same issue as responses on invokes.
Resolution: Proposed and decided on conf call 7 July 2004
Close with no change to the spec.
The concerns covered under this issue will be dealt with under issue 96 : Engine-managed correlation sets
Links: Announcement, 15 Apr 2004
Ugo Corda, 16 Apr 2004
Danny van der Rijn, 16 Apr 2004
Maciej Szefler, 16 Apr 2004
Yaron Y. Goland, 16 Apr 2004
Yaron Y. Goland, 16 Apr 2004
Ugo Corda, 16 Apr 2004
Danny van der Rijn, 16 Apr 2004
Ugo Corda, 16 Apr 2004
Danny van der Rijn, 16 Apr 2004
Ugo Corda, 16 Apr 2004
Ugo Corda, 17 Apr 2004
Eckenfels. Bernd, 17 Apr 2004
Danny van der Rijn, 19 Apr 2004
Yaron Y. Goland, 19 Apr 2004
Maciej Szefler, 19 Apr 2004
Ugo Corda, 19 Apr 2004
Danny van der Rijn, 19 Apr 2004
Ugo Corda, 19 Apr 2004
Ugo Corda, 19 Apr 2004
Maciej Szefler, 19 Apr 2004
Assaf Arkin, 20 Apr 2004
Assaf Arkin, 20 Apr 2004
Eckenfels. Bernd, 20 Apr 2004
Satish Thatte, 22 Apr 2004
Satish Thatte, 22 Apr 2004
Ugo Corda, 22 Apr 2004
Satish Thatte, 22 Apr 2004
Ugo Corda, 22 Apr 2004
Maciej Szefler, 22 Apr 2004
Satish Thatte, 22 Apr 2004
Ugo Corda, 22 Apr 2004
Yaron Y. Goland, 22 Apr 2004
Ugo Corda, 22 Apr 2004
Yaron Y. Goland, 26 Apr 2004
Proposed resolution (Chris Keller, 23 Jun 2004)
Changes: 15 Apr 2004 - new issue;
16 Apr 2004 - fields: Links;
17 Apr 2004 - fields: Links;
19 Apr 2004 - fields: Links;
20 Apr 2004 - fields: Links;
22 Apr 2004 - fields: Links;
23 Apr 2004 - fields: Links;
27 Apr 2004 - fields: Links;
23 Jun 2004 - fields: Links, Status, Proposed resolution;
7 Jul 2004 - fields: Status, Proposed resolution, Resolution, In spec
The text currently provides an example as to how the shortcut should be interpreted, that goes as follows :
<invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> <catch faultName="SP:POFault" faultVariable="POFault"> <!-- handle the fault --> </catch> </invoke>
is equivalent to / can be re-written as:
<scope> <faultHandlers> <catch faultName="SP:POFault" faultVariable="POFault"> <!-- handle the fault --> </catch> </faultHandlers> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> </invoke> </scope>
This leads to the quesiton of how to "rewrite" an invoke that is also the source of a link:
<invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> <source linkName="foo" /> <catch faultName="SP:POFault" faultVariable="POFault"> <!-- handle the fault --> </catch> </invoke>
The options are either:
<scope> <faultHandlers> <catch faultName="SP:POFault" faultVariable="POFault"> <!-- handle the fault --> </catch> </faultHandlers> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> <source linkName="foo" /> </invoke> </scope>or
<scope> <source linkName="foo" /> <faultHandlers> <catch faultName="SP:POFault" faultVariable="POFault"> <!-- handle the fault --> </catch> </faultHandlers> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> </invoke> </scope>
The two versions do not have the same semantics (according to issue 27). In the former case the
transition condition will be set to false in the event of a fault. In the latter case the
transition condition is evaluated (because the fault is caught and the scope "completes").
While the former interpertation is suggested by the example, the latter interpretation is
the more consistent with the resolution of issue 27.
This question boils down to the nature of implicit scopes, that is: are implicit
scopes merely macros for placing a <scope> around an <invoke>, or does an <invoke>
essentially "mix-in" scope features (fault handling).
Links: issue 27 : Setting link status in case of transition condition
Announcement, 19 Apr 2004
rkhalaf, 6 Oct 2004
Maciej Szefler, 8 Oct 2004
rkhalaf, 8 Oct 2004
Yaron Y. Goland, 11 Oct 2004
Maciej Szefler, 11 Oct 2004
Changes: 19 Apr 2004 - new issue;
19 Apr 2004 - fields: Links;
7 Oct 2004 - fields: Links;
11 Oct 2004 - fields: Links;
12 Oct 2004 - fields: Links
Closed with no change to spec and to be marked as
revisitable in the next version of spec.
Submitter's proposal: Add a finally construct to the <scope> activity.
Credit: the issue and resolution was suggested by Jerry Thomas (CenterStone
Software)
Resolution: Proposed in Alex Yiu, 11 Dec 2004, decided Hawthorne face-to-face
Links: Announcement, 20 Apr 2004
Dieter Koenig1, 27 Apr 2004
Edwin Khodabakchian, 27 Apr 2004
Eckenfels. Bernd, 27 Apr 2004
Edwin Khodabakchian, 27 Apr 2004
Satish Thatte, 20 Jun 2004
Glenn Mi, 21 Jun 2004
Alex Yiu, 2 Nov 2004
Proposed resolution (Alex Yiu, 11 Dec 2004)
Changes: 20 Apr 2004 - new issue;
20 Apr 2004 - fields: Links;
27 Apr 2004 - fields: Links;
29 Apr 2004 - fields: Links;
20 Jun 2004 - fields: Links;
22 Jun 2004 - fields: Links;
3 Nov 2004 - fields: Links;
11 Dec 2004 - fields: Links, Status, Proposed resolution;
14 Dec 2004 - fields: Status, Proposed resolution, Resolution, In spec, Revisitable
A possible resolution would be, to remove the term synchronous, while talking about operations, in favor of the term "two way" or request-response or something similiar.
Note: it is not so easy to use the MEP names from WSDL, since they are afaik
not defined for wsdl1.1 and they refer to an operation from the provider
and consumer side, whereas BPEL only knows the provider side
as receive/replay and the consumer side as invoke.
Resolution: Proposed verbally and decided at San Francisco f-t-f
Editors will ensure that "synchronous" and "asynchronous" are not used in the context of invoking or providing a service,
and in 11.4 relating to reply. All uses of these words will be reviewed and revised to ensure
they are used consistently in any other cases. The term "blocking" will also be avoided.
Links: This issue was discovered in the discussion about issue 118 : When are Correlation Sets Mandatory?
Announcement, 20 Apr 2004
Changes: 20 Apr 2004 - new issue;
20 Apr 2004 - fields: Links;
23 Jun 2004 - fields: In spec, Resolution, Status
The rule of matching a reply activity with a receive activity is not clearly defined in the current specification.
Discussion:
The current specification is not defined clearly enough to answer the following questions.
[Q1] Must <reply> always specify all the correlation sets specified by the corresponding <receive>?
For example, if there are two <receive>'s outstanding as follows,
receive name="rec1" partnerLink="pl" portType="pt" operation="op" correlation set="cs1" initiate="no" correlation set="cs2" initiate="no" correlation set="cs3" initiate="yes" correlation set="cs4" initiate="yes"receive name="rec2" partnerLink="pl" portType="pt" operation="op" correlation set="cs1" initiate="no" correlation set="cs2" initiate="no" correlation set="cs5" initiate="yes" correlation set="cs6" initiate="yes"
Must a <reply> specify all of the corresponding <receive>'s CS's? That is, for rec1,
reply name="rep1" partnerLink="pl" portType="pt" operation="op" correlation set="cs1" initiate="no" correlation set="cs2" initiate="no" correlation set="cs3" initiate="no" correlation set="cs4" initiate="no"
Or only as many as necessary to disambiguate the matching?
reply name="rep1" partnerLink="pl" portType="pt" operation="op" correlation set="cs3" initiate="no"
[Q2] Does it follow that if a <receive> specify a correlation set, the corresponding reply can only send a message that contains the correlation set?
If it does, then the rule seems to be too restrictive. For example, the following process will be illegal.
A reply activity is associated with a receive activity based on the tuple - partnerLink, operation, and messageExchange. The value defined in messageExchange is scoped to the combination of partnerLink and operation. That is, it is legal to use the same messageExchange value in multiple simultaneously incomplete receive activities so long as the combination of partnerLink and operation on the receives are all different from each other. An incomplete receive describes the state of a BPEL process from the point that a request/response receive activity starts execution until its associated reply begins execution.
If there should ever be multiple simultaneous incomplete receive activities which have the same partnerLink, operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown within the BPEL process on the conflicting receive activities subsequent to the execution of the successful incomplete receive.
If a reply activity cannot be associated with an incomplete receive activity by matching the tuples and this error situation is not caught during static analysis, then bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests should have been rejected at the time <receive> is executed, there cannot be more than one corresponding <receive> at the time <reply> is executed.
If the messageExchange attribute is not specified on a receive then its value is taken to be empty. For matching purposes two empty messageExchange values on receives with the same partnerLink and operation values are said to match. Empty value does not match with other non-empty values.
(Please note: there are existing text paragraphs in the spec, which enforces that no more than one <receive>s are waiting for a message associated with the same partner link, port type, operation, and correlation sets. This constraint still exists and will not be affected by the proposal of Issue 123. This proposal simply add one more constraint to receive, when <reply> are needed to be associated with <receive>.)
Links: Yuzo Fujishima, 13 May 2004
Satish Thatte, 13 May 2004
Ugo Corda, 13 May 2004
Eckenfels. Bernd, 17 May 2004
Satish Thatte, 17 May 2004
Announcement, 18 May 2004
Eckenfels. Bernd, 18 May 2004
Francisco Curbera, 4 Jun 2004
Yuzo Fujishima, 7 Jun 2004
Yaron Y. Goland, 7 Jun 2004
Francisco Curbera, 7 Jun 2004
John Evdemon, 16 Jun 2004
20040622-issue123.ppt (document details)
Discussed at San Francisco f-t-f
expected to deal with issue 26
issue 96 : Engine-managed correlation sets
Yuzo Fujishima, 30 Jun 2004
Assaf Arkin, 1 Jul 2004
Danny van der Rijn, 1 Jul 2004
Danny van der Rijn, 1 Jul 2004
Assaf Arkin, 1 Jul 2004
Danny van der Rijn, 1 Jul 2004
Yuzo Fujishima, 2 Jul 2004
Yuzo Fujishima, 2 Jul 2004
Yaron Y. Goland, 2 Jul 2004
Assaf Arkin, 2 Jul 2004
Prasad Yendluri, 2 Jul 2004
Yuzo Fujishima, 5 Jul 2004
Yuzo Fujishima, 5 Jul 2004
Eckenfels. Bernd, 6 Jul 2004
Eckenfels. Bernd, 6 Jul 2004
Yaron Y. Goland, 6 Jul 2004
Ugo Corda, 6 Jul 2004
Satish Thatte, 7 Jul 2004
Satish Thatte, 7 Jul 2004
Francisco Curbera, 7 Jul 2004
Assaf Arkin, 7 Jul 2004
Satish Thatte, 7 Jul 2004
Satish Thatte, 7 Jul 2004
Yaron Y. Goland, 7 Jul 2004
Satish Thatte, 7 Jul 2004
Yuzo Fujishima, 9 Jul 2004
Satish Thatte, 12 Jul 2004
Yaron Y. Goland, 12 Jul 2004
Satish Thatte, 12 Jul 2004
Yaron Y. Goland, 12 Jul 2004
Eckenfels. Bernd, 12 Jul 2004
Satish Thatte, 12 Jul 2004
Yaron Y. Goland, 13 Jul 2004
Francisco Curbera, 20 Jul 2004
Yuzo Fujishima, 21 Jul 2004
Eckenfels. Bernd, 21 Jul 2004
Satish Thatte, 21 Jul 2004
Francisco Curbera, 22 Jul 2004
Yaron Y. Goland, 22 Jul 2004
Eckenfels. Bernd, 23 Jul 2004
Francisco Curbera, 23 Jul 2004
Satish Thatte, 29 Jul 2004
Francisco Curbera, 29 Jul 2004
Satish Thatte, 29 Jul 2004
Francisco Curbera, 29 Jul 2004
Satish Thatte, 29 Jul 2004
Francisco Curbera, 29 Jul 2004
Yaron Y. Goland, 30 Jul 2004
Satish Thatte, 30 Jul 2004
Frank Leymann, 31 Jul 2004
Diane Jordan, 2 Aug 2004
Yaron Y. Goland, 3 Aug 2004
Alex Yiu, 4 Aug 2004
Eckenfels. Bernd, 4 Aug 2004
Francisco Curbera, 4 Aug 2004
Alex Yiu, 5 Aug 2004
Alex Yiu, 5 Aug 2004
Maciej Szefler, 5 Aug 2004
Francisco Curbera, 5 Aug 2004
Alex Yiu, 5 Aug 2004
Alex Yiu, 5 Aug 2004
Yaron Y. Goland, 6 Aug 2004
Yaron Y. Goland, 6 Aug 2004
Alex Yiu, 6 Aug 2004
Alex Yiu, 6 Aug 2004
Satish Thatte, 9 Aug 2004
Yaron Y. Goland, 9 Aug 2004
Yaron Y. Goland, 9 Aug 2004
Alex Yiu, 9 Aug 2004
Satish Thatte, 9 Aug 2004
Alex Yiu, 9 Aug 2004
Yaron Y. Goland, 11 Aug 2004
Yaron Y. Goland, 11 Aug 2004
Alex Yiu, 11 Aug 2004
Satish Thatte, 13 Aug 2004
Alex Yiu, 13 Aug 2004
Satish Thatte, 13 Aug 2004
Alex Yiu, 18 Aug 2004
Yuzo Fujishima, 18 Aug 2004
Yaron Y. Goland, 18 Aug 2004
Alex Yiu, 18 Aug 2004
Danny van der Rijn, 18 Aug 2004
Alex Yiu, 1 Sep 2004
Yuzo Fujishima, 1 Sep 2004
Danny van der Rijn, 1 Sep 2004
Alex Yiu, 1 Sep 2004
Proposed resolution (Alex Yiu, 1 Sep 2004)
Danny van der Rijn, 1 Sep 2004
Alex Yiu, 1 Sep 2004
Proposed resolution (Alex Yiu, 1 Sep 2004)
Proposed resolution (Yaron Y. Goland, 10 Sep 2004)
Francisco Curbera, 14 Sep 2004
Changes: 18 May 2004 - new issue;
18 May 2004 - fields: Links;
9 Jun 2004 - fields: Links;
16 Jun 2004 - fields: Links;
22 Jun 2004 - fields: Links;
30 Jun 2004 - fields: Links;
2 Jul 2004 - fields: Links;
3 Jul 2004 - fields: Links;
5 Jul 2004 - fields: Links;
6 Jul 2004 - fields: Links;
7 Jul 2004 - fields: Links;
13 Jul 2004 - fields: Links;
14 Jul 2004 - fields: Links;
21 Jul 2004 - fields: Links;
22 Jul 2004 - fields: Links;
23 Jul 2004 - fields: Links;
29 Jul 2004 - fields: Links;
30 Jul 2004 - fields: Links;
31 Jul 2004 - fields: Links;
1 Aug 2004 - fields: Links;
2 Aug 2004 - fields: Links;
4 Aug 2004 - fields: Links;
5 Aug 2004 - fields: Links;
6 Aug 2004 - fields: Links;
7 Aug 2004 - fields: Links;
9 Aug 2004 - fields: Links;
10 Aug 2004 - fields: Links;
12 Aug 2004 - fields: Links;
14 Aug 2004 - fields: Links;
18 Aug 2004 - fields: Links;
1 Sep 2004 - fields: Links;
2 Sep 2004 - fields: Links, Status, Proposed resolution;
10 Sep 2004 - fields: Links, Status, Proposed resolution;
13 Sep 2004 - fields: Proposed resolution;
15 Sep 2004 - fields: Links;
29 Sep 2004 - fields: Status, Proposed resolution, Resolution;
23 Oct 2004 - fields: In spec
Part A
Example: A factory consists of manufacturing machines and a system of heat monitors. A BPEL process receives updates from the heat monitors and uses the updates to configure the manufacturing machines so they operate at their ideal temperature. The BPEL process does not know at deployment time what heat monitors are available and the number of available monitors is constantly changed anyway as new ones are added, old ones are replaced, etc. Additionally since the updates can indicate emergency situations its important that the updates be accepted asynchronously and on-demand so that emergency action can be taken if necessary. Therefore an event handler is used to deal with these messages.
Problem Description: The BPEL process wants to create an event handler which can accept incoming heat status updates. All heat status messages are received on the same operation on the same portType. The BPEL code looks like:
process partnerLinks partnerLink name="monitor" ... scope eventHandlers onEvent partnerLink="monitor" portType="tempEvents" operation="tempUpdate" ... ... ...Time 0 - Scope is entered and onEvent is activated
Time 1 - Monitor A sends a "tempUpdate" message that is caught by the onEvent handler. partnerLink monitor is initialized to point at Monitor A.
Time 2 - Monitor B sends a "tempUpdate" message but the message is thrown on the floor because partnerLink monitor is already initialized to point to monitor A.
Part B
Example: A BPEL process places an order for a set of items with a known partner. The BPEL process then expects to receive asynchronous notifications of the status of the shipment. Each notification will contain the orderID used on the initial order. However it is possible for a single order to be broken up into multiple shipments. Therefore each update message contains a shippingID. Upon receiving a shipping update the BPEL process is expected to send back a response confirming receipt of the update that contains both the orderID and the shippingID.
Problem Description:
process partnerLinks partnerLink name="partner" ... correlationSets correlationSet name="orderID" scope <!-- Init partnerLink & orderID, place order --> ... scope correlationSets correlationSet name="shippingID" onEvent partnerLink="partner" ... correlations correlation set="orderID" initiate="no" correlation set="shippingID" initiate="yes" scope ... reply partnerLink="partner" ... correlation set="orderID" initiate="no" correlation set="shippingID" initiate="no" ... ...
Time 0 - The parent scope is entered, the partnerLink pointing at the partner is initialized and the order is placed.
Time 1 - The inner scope is entered, the onEvent handler becomes active and waits for a message from the partner.
Time 2 - The first status message arrives and initiates the shippingID. A response is sent to the partner indicating receipt of the status message.
Time 3 - The second status message arrives. But it turns out that the order has been split and so this second status message has a different shippingID then the first status message. Since the shippingID has already been initialized to a different value the second status message is dropped on the floor.
Note, btw, that strictly speaking all messages after the first one no
matter what correlation set they had would have been rejected because
initiate="yes" would cause an error after the first message. While this
may appear to argue for initiate="maybe" this fault isn't actually
relevant to this issue.
Submitter's proposal:
Part A
The partnerLink attribute on the onEvent element be made optional and a partnerLink element be added as an optional child of the onEvent element. The optional partnerLink element would be used to declare a partnerLink that was local to each instance of the onEvent handler. It would be mandatory that all onEvent handlers either use the partnerLink attribute or the partnerLink element but not both.
In other words:
process scope eventHandlers onEvent portType="tempEvents" operation="tempUpdate" ... partnerLink name="monitor" ... ... ...
Part B
Add the correlationSet element as an optional child of the onEvent element. Any correlation set values defined on the onEvent element are only available within the scope of the onEvent.
process partnerLinks partnerLink name="partner" ... correlationSets correlationSet name="orderID" scope <!-- Init partnerLink & orderID, place order --> ... scope onEvent partnerLink="partner" ... correlationSets correlationSet name="shippingID" correlations correlation set="orderID" initiate="no" correlation set="shippingID" initiate="yes" scope ... reply partnerLink="partner" ... correlation set="orderID" initiate="no" correlation set="shippingID" initiate="no" ... ...
Accept the submitter's proposal above.
Links: Announcement, 10 Jun 2004
Ugo Corda, 11 Jun 2004
Satish Thatte, 12 Jun 2004
Frank Leymann, 13 Jun 2004
Yaron Y. Goland, 14 Jun 2004
Yaron Y. Goland, 14 Jun 2004
Satish Thatte, 14 Jun 2004
Ugo Corda, 14 Jun 2004
Prasad Yendluri, 15 Jun 2004
Yaron Y. Goland, 15 Jun 2004
Prasad Yendluri, 15 Jun 2004
Yaron Y. Goland, 16 Jun 2004
Prasad Yendluri, 16 Jun 2004
Yaron Y. Goland, 16 Jun 2004
Prasad Yendluri, 16 Jun 2004
Assaf Arkin, 16 Jun 2004
Prasad Yendluri, 16 Jun 2004
Dieter Koenig1, 17 Jun 2004
Yaron Y. Goland, 17 Jun 2004
Prasad Yendluri, 17 Jun 2004
Assaf Arkin, 18 Jun 2004
Yaron Y. Goland, 18 Jun 2004
Prasad Yendluri, 18 Jun 2004
Francisco Curbera, 23 Jun 2004
Yaron Goland, 30 Jun 2004
Proposed resolution (Yaron Y. Goland, 30 Jun 2004)
Prasad Yendluri, 2 Jul 2004
Yaron Y. Goland, 6 Jul 2004
Changes: 10 Jun 2004 - new issue;
10 Jun 2004 - fields: Links;
11 Jun 2004 - fields: Links;
13 Jun 2004 - fields: Links;
15 Jun 2004 - fields: Links;
16 Jun 2004 - fields: Links;
17 Jun 2004 - fields: Links;
18 Jun 2004 - fields: Links;
19 Jun 2004 - fields: Links;
23 Jun 2004 - fields: Links;
30 Jun 2004 - fields: Links;
1 Jul 2004 - fields: Links, Status, Proposed resolution;
3 Jul 2004 - fields: Links;
6 Jul 2004 - fields: Links;
7 Jul 2004 - fields: Status, Proposed resolution, Resolution;
15 Jul 2004 - fields: Status, Resolution, Proposed resolution
Links: Announcement, 11 Jun 2004
Changes: 11 Jun 2004 - new issue;
12 Jun 2004 - fields: Links
The example imports the XSD file as:
<definitions ... <import namespace="http://manufacturing.org/xsd/purchase" location="http://manufacturing.org/xsd/purchase.xsd"/>
where this kind of import is prohibited in WS-I BP section 5.1.2:
R2001: A DESCRIPTION MUST only use the WSDL "import" statement to import
another WSDL description.
R2002: To import XML Schema Definitions, a DESCRIPTION MUST use the XML
Schema "import" statement.
R2003: A DESCRIPTION MUST use the XML Schema "import" statement only within
the xsd:schema element of the types section.
Submitter's proposal: Modify the example as follows:
<definitions ... <types> <xsd:schema> <xsd:import namespace="http://manufacturing.org/xsd/purchase" location="http://manufacturing.org/xsd/purchase.xsd"/>
Apply the submitter's proposal
Kevin Liu will review the spec for examples that need similar correction and bring them to the spec editing team and the TC.
The spec editing team will check the wording arising from issue 72 : What to do with WS-I BP1.0? to ensure it is strong enough.
Links: Announcement, 14 Jun 2004
Ugo Corda, 14 Jun 2004
Proposal to vote (Yuzo Fujishima, 15 Jun 2004)
20040622-issue128.ppt (document details)
Changes: 14 Jun 2004 - new issue;
14 Jun 2004 - fields: Links;
15 Jun 2004 - fields: Status, Proposed resolution, Links;
23 Jun 2004 - fields: Status, Proposed resolution, Resolution;
17 Aug 2004 - fields: In spec
All other "name" attributes in the WSBPEL specificaiton are used to define the name of the object defined there, not the object referenced. Accordingly, all other "name"s are NCName where only the above portType name is QName.
<plnk:partnerLinkType name="ncname"> <plnk:role name="ncname">+ <plnk:portType name="qname"/> </plnk:role> </plnk:partnerLinkType>
<plnk:partnerLinkType name="ncname"> <plnk:role name="ncname">+ <plnk:responsibility portType="qname"/> </plnk:role> </plnk:partnerLinkType>
Replace the portType element of the partnerLinkType role definition with a portType attribute as the role is one-to-one with portType. New abbreviated partnerLinkType syntax would be:
<plnk:partnerLinkType name="ncname"> <plnk:role name="ncname" portType="qname"/>+ </plnk:partnerLinkType>
Some of the constraints imposed by Section 9.3.1 "Type Compatibility in Assignment" in the current version of the specification (as of July 12, 2004) are not so reasonable.
For example, it said:
The from-spec is a variable of a WSDL message type and the to-spec is not, or vice versa. This is not legal because parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly.
If my reading is right, it outlaws a simple copy of a element or a text-node from a part of a WSDL message to a element-based or a simple-type-based variable and vice versa. This usage pattern is clearly needed.
Other considerations suggested by other TC members includes: simple type conversion: e.g. a string type => a boolean type conversion.
We need to re-visit that section of the specification and come up with a more reasonable of type compatiblity constraints.
Resolution: Closed as a duplicate of issue 51 : Section 9.3.1 & Schema Validation
Links: Announcement, 13 Jul 2004
Yaron Y. Goland, 13 Jul 2004
Alex Yiu, 13 Jul 2004
Peter Furniss, 13 Jul 2004
Changes: 13 Jul 2004 - new issue;
13 Jul 2004 - fields: Links;
14 Jul 2004 - fields: Links, Status, In spec, Resolution;
16 Jul 2004 - fields: Links
Remove all but the first paragraph of section 9.1.4.
Raise a new issue (issue 163 : languageExecutionFault ) to cover language problems.
Links: Announcement, 15 Jul 2004
Yaron Y. Goland, 27 Aug 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 15 Jul 2004 - new issue;
16 Jul 2004 - fields: Links;
27 Aug 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
23 Sep 2004 - fields: Status, Proposed resolution, Resolution;
23 Oct 2004 - fields: In spec
The semantics of the forcedTermination handler, that it can't throw any
faults, makes sense but I think the way we specify fault handlers could
cause programmers some serious headaches. For example, if someone
defines a catchAll handler and they don't define a forcedTermination
handler then if a scope is killed the catchAll handler will catch the
forcedTermination fault. However the catchAll handler's logic probably
thinks it can throw its own faults, which will normally be true unless
the fault it caught was a forcedTermination fault. Yuck.
Submitter's proposal: Change the name to something like faultCleanUpHandler.
We should probably define an implicit forcedTermination handler on all
scopes. If someone doesn't define an explicit forcedTermination handler
then the implicit one (which will do nothing) will run. This means that
catchAll will never catch a forcedTermination fault.
Resolution: Proposed in Satish Thatte, 24 Sep 2004, decided 13 Oct 2004 conf call
Overview:
The bpws:forcedTermination "fault" in the current specification is not a normal fault. It is simply a way to permit interception of forced termination by a scope to perform special handling to shut the scope down in an orderly manner. The differences from a normal fault include the inability to be caught by a catchAll handler, and the inability to throw or rethrow any fault within the handler. It is thus proposed that we eliminate the notion of a bpws:forcedTermination fault from the specification and replace it with a notion of a special handler for forced termination. A secondary part of the proposal is to replace the <terminate/> activity with an <exit/> activity with identical semantics, simply to avoid terminological confusion with the notion of forced termination.
Detailed proposal:
In all the text of the specification, including section 5 and Appendix A, eliminate the mention of bpws:forcedTermination and remove this token from the bpws namespace.
In Sections 6.2 and 13
Replace the syntax
<scope variableAccessSerializable="yes|no" standard-attributes> standard-elements <variables>? ... </variables> <correlationSets>? ... </correlationSets> <faultHandlers>? ... </faultHandlers> <compensationHandler>? ... </compensationHandler> <eventHandlers>? ... </eventHandlers> activity </scope>
with the syntax
<scope variableAccessSerializable="yes|no" standard-attributes> standard-elements <variables>? ... </variables> <correlationSets>? ... </correlationSets> <faultHandlers>? ... </faultHandlers> <compensationHandler>? ... </compensationHandler> <terminationHandler>? ... </terminationHandler> <eventHandlers>? ... </eventHandlers> activity </scope>
In Section 13.4.2
Replace the text
Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the behavior of the scope is interrupted and the fault handler for the standard bpws:forcedTermination fault is run. Note that this applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then as stated above, all other fault handlers including the handler for bpws:forcedTermination are uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete.The fault handler for the bpws:forcedTermination fault is designed like other fault handlers, but this fault handler cannot rethrow any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already faulted, which is what is causing the forced termination of the nested scope.
In other respects this is a normal fault handler. Its behavior begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active. It can invoke compensate activities. And when it is missing, it is provided by using the same implicit behavior that is used for all other implicit fault handlers.
Note that forced termination of nested scopes occurs in innermost-first order as a result of the rule (quoted above) that the behavior of any fault handler begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active.
with the text
Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the forced termination of a scope begins by terminating all activities directly enclosed within its associated scope that are currently active. Following this, the custom termination handler for the scope, if present, is run. If the custom termination handler is missing, the default termination handler performs compensation of all successfully completed nested scopes in the same order as in the case of a default fault handler.Forced termination for a scope applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then the termination handler is uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete.
The termination handler for a scope is permitted to use the same range of activities as a fault handler, including the <compensate/> activity. However, a termination handler cannot throw any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already either faulted or is in the process of being terminated, which is what is causing the forced termination of the nested scope.
Forced termination of nested scopes occurs in innermost-first order as a result of the rule (stated above) that the termination handler is run after terminating all activities (including scope activities) directly enclosed within its associated scope that are currently active.
<if standard-attributes> standard-elements <condition expression-language="URI"> bool-expr </condition> <then> activity </then> <else>? activity </else> </if>This would effectively be a macro for:
<switch> <case> <condition>bool-expr</condition> activity </case> <otherwise> activity </otherwise> </switch>
Imagine a variable that contains a purchase order and the NumOrder
property which contains a count of how many orders are in the PO. Now
imagine that after the variable is set and the property initialized then
the variable is edited to change one PO into two. Now the NumOrder
property, still set to the value 1, will no longer have the correct
count of orders in the variable.
Submitter's proposal: 1) We should require that any time a variable's value is updated (e.g.
with assign) that the property alias for all the properties on the
variable should be re-run so the property values will be updated.
2) We should either ban assigning directly to properties or we should
specify that properties that are not LValues (e.g. resolve to a single
node in the underlying variable) are read-only and properties that are
LValues can be written to but the consequence of doing so is that the
node in the underlying variable is changed.
Resolution: proposed and agreed at f-t-f, 22 Sept 2004
Closed as an editing change, spec. editing team to work on final wording
Links: Announcement, 15 Jul 2004
Satish Thatte, 18 Jul 2004
Yaron Y. Goland, 19 Jul 2004
Chris Keller, 19 Jul 2004
Yaron Y. Goland, 20 Jul 2004
Satish Thatte, 21 Jul 2004
Satish Thatte, 21 Jul 2004
Satish Thatte, 21 Jul 2004
Satish Thatte, 29 Jul 2004
Yaron Y. Goland, 29 Jul 2004
Satish Thatte, 29 Jul 2004
Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 15 Jul 2004 - new issue;
16 Jul 2004 - fields: Links;
18 Jul 2004 - fields: Links;
19 Jul 2004 - fields: Links;
21 Jul 2004 - fields: Links;
29 Jul 2004 - fields: Links;
30 Jul 2004 - fields: Links;
16 Sep 2004 - fields: Links, Status, Proposed resolution;
23 Sep 2004 - fields: Status, Proposed resolution, Resolution;
25 Nov 2004 - fields: In spec
<until standard-attributes> standard-elements <condition expression-language="URI"> bool-expr </condition> activity </until>This would effectively be a macro for:
<scope> activity1 <while> <condition>bool-expr</condition> activity1 </while> </scope>
<staticSwitch standard-attributes> standard-elements <condition expression-language="URI">general-expr</condition> <case value="xs:string">+ activity </case> <otherwise> activity </otherwise> </staticSwitch>This is effectively a macro for:
<switch> <case>+ <condition>general-expr = string</condition> activity </case> <otherwise> activity </otherwise> </switch>
For example, Section 6.5 of the spec states "A receive activity for an inbound request/response operation is said to be open if that activity has been performed and no corresponding reply activity has been performed. If the process instance reaches the end of its behavior, and one or more receive activities remain open, then the status of the instance becomes undefined."
Should this be undefined or should a fault be required to be thrown
followed by the process exiting? The actual solution isn't as important
as providing a well defined behavior.
Submitter's proposal: Put together a table of all undefined behaviors and then review them to
decide if they should be changed. It would be useful to put the table
into the spec as an appendix in order to help programmers and
implementers know exactly which behaviors are undefined.
Links: Announcement, 15 Jul 2004
Alex Yiu, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;
16 Jul 2004 - fields: Links
Allow for the definition of properties on non-WSDL messages.
Rationale: Properties represent a fundamental design approach where information in potentially very complex XML variables is made available in a simple name/value fashion. This feature is just as useful for regular XML variables as it is for WSDL messages and should be available for both.
Changes Required: Change propertyAlias to make messageType and part attributes optional and introduce element and type attributes. Specify that getVariableProperty can take arbitrary BPEL variables as arguments. Clarify the matching rules for properties/propertyAliases/variables. Update the terminology to make message properties a type of variable properties. Also fixed a bug where there is an ambiguity as to what happens if two propertyaliases for the same property on the same message type, the new text requires this to be statically detected and rejected.
Section 1:
From: WS-BPEL uses a notion of message properties to identify protocol-relevant data embedded in messages.
To: WS-BPEL uses a notion of message properties, which are a type of variable property, to identify protocol-relevant data embedded in messages.
Section 6.4:
From: Process definitions also rely on other constructs such as partner link types, message properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.
To: Process definitions also rely on other constructs such as partner link types, variable properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.
Section 8:
Change title to “Variable Properties”
Note: There are references in the spec to (see Message Properties) this will need to be changed to (see Variable Properties)
Section 8.1:
Create section 8.1.1 titled “Motivation for Message Properties”, insert current section 8.1 text there.
Create section 8.1.2 titled “Motivation for Variable Properties” with the following value:
Message properties are an instance of a more generic mechanism, variable properties. All variables in BPEL can have properties defined on them. Properties are useful on non-message variables as a way to isolate the BPEL process’s logic from the details of a particular variable’s definition. Using properties a BPEL process can isolate its variable initialization logic in one place and then set and get properties on that variable in order to manipulate it. If the variable’s definition is later changed the bulk of the BPEL process definition that manipulates that variable can remain unchanged.
Section 8.2:
From: “Properties can occur anywhere in a message, including in the message context.”
To “Properties can occur anywhere in a variable.”
Insert the following paragraph after the existing paragraph that begins “In correlation, the property name must have global significance…”:
Even in the general case of properties on XML typed WS-BPEL variables the property name should maintain its generic nature. The name is intended to identify a certain kind of value, often with an implied semantic. Any variable the property is available on is therefore expected to provide a value that meets not just the syntax of the property definition but also its semantics.
End section 8.2 after the schema for property definitions (which this proposal does not change).
Insert section 8.3 titled "Defining Property Aliases", the content of this new section is based on the text that was originally in section 8.2 after the property schema definition:
Properties used in business protocols are typically embedded in application-visible variables. The notion of aliasing is introduced to map a global property to a field in a specific message part or variable value. The property name becomes an alias for the message part and/or location, and can be used as such in Expressions and Assignment in abstract business processes. As an example, consider the following WSDL message definition:
1234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 <definitions name="messages" targetNamespace="http://example.com/taxMessages.wsdl" xmlns:txtyp="http://example.com/taxTypes.xsd" xmlns="http://schemas.xmlsoap.org/wsdl/"> <!-- define a WSDL application message -->The definition of a global property and its location in a particular field of the message are shown in the next WSDL fragment:<message name="taxpayerInfoMsg">
<part name="identification" element="txtyp:taxPayerInfoElem"/>
</message>
...
</definitions>
1234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 <definitions name="properties" targetNamespace="http://example.com/properties.wsdl" xmlns:tns="http://example.com/properties.wsdl" xmlns:txtyp="http://example.com/taxTypes.xsd" xmlns:txmsg="http://example.com/taxMessages.wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"><!-- define a correlation property -->
<bpws:property name="taxpayerNumber" type="txtyp:SSN"/>
...
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
messageType="txmsg:taxpayerInfoMsg" part="identification">
<query>
/txtyp:taxPayerInfoElem/txtyp:socialsecnumber
</query> </bpws:propertyAlias>
<bpws:propertyAlias propertyName="tns:taxpayerNumber" element="txtyp:taxPayerInfoElem"> <query>
/txtyp:taxPayerInfoElem/txtyp:socialsecnumber
</query> </bpws:propertyAlias> </definitions>
The first bpws:propertyAlias defines a globally named property tns:taxpayerNumber as an alias for a location in the identification part of the message type txmsg:taxpayerInfo.
The second bpws:propertyAlias provides a second definition for the same globally named property tns:taxpayerNumber but this time as an alias for a location inside of the element txtyp:taxPayerInfoElem.
The presence of both aliases means that it is possible to retrieve the social security number from both a variable holding a message of messageType txmsg:taxpayerInfo as well as an element defined using txtyp:taxPayerInfoElem.
The syntax for a propertyAlias definition is:
1234567890123456789012345678901234567890123456789012345678901234567890A property alias element MUST use one of the three following combinations of attributes:1 2 3 4 5 6
<definitions name="ncname" ... > <bpws:propertyAlias propertyName="qname" messageType="qname"? part="ncname"?
type="qname"? element="qname"?>
<query queryLanguage="anyURI"?>?
... queryString ...
</query>
</bpws:propertyAlias> ... </wsdl:definitions>
When a propertyAlias is used with the messageType/part combination then the property MUST be available on all BPEL variables where the qname value used in the messageType attribute on the declaration of both the variable and the propertyAlias are identical. The part attribute and query element is applied against the BPEL messageType variable to either set or get the property variable in the same way that the part attribute and query element are used in the first from and to specs in copy assignments.
If a propertyAlias is used with a type attribute then the property MUST be available on all BPEL variables where the qname value used in the type attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against BPEL variables defined using a type.
If a propertyAlias is used with an element attribute then the property MUST be available on all BPEL variables where the qname value used in the element attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against BPEL variables defined using an element definition.
A BPEL process MUST NOT be accepted for processing if it defines two or more propertyAlias’s for the same property name and BPEL variable type. For example, it is not legal to define two propertyAlias’s for the property taxpayernumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two propertyAliases on the same element qname and property name value or two propertyAliases on the same type qname and property name value.
Section 9.0
From: Abstract processes are restricted to limited manipulation of values contained in message properties but are permitted to use nondeterministic values to reflect the consequences of hidden private behavior.
To: Abstract processes are restricted to limited manipulation of values contained in variable properties but are permitted to use nondeterministic values to reflect the consequences of hidden private behavior.
Section 9.1
From: If the given property does not appear in any of the parts of the variable's message type, then the semantics of the process is undefined.
To: If the referenced property is not defined or if there does not exist a propertyAlias to associate the property with the referenced variable then the semantics of the process is undefined.
Section 9.3
From: The third from-spec and to-spec variants allow explicit manipulation of message properties (see Message Properties) occurring in variables.
To: The third from-spec and to-spec variants allow explicit manipulation of variable properties (see Variable Properties) occurring in variables.
Section 10.2
From: They are abstract in the sense that their occurrence in messages needs to be separately specified (see Message Properties).
To: They are abstract in the sense that their occurrence in variables needs to be separately specified (see Variable Properties).
Section 14.1
From: If the given property does not appear in any of the parts of the variable's message type or the given property definition selects a node set of a size other than one, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.
To: If the referenced property is not defined, if there does not exist a propertyAlias to associate the property with the referenced variable or if the given property definition selects a node set of a size other than one, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.
Links: Announcement, 15 Jul 2004
Proposed resolution (Yaron Y. Goland, 10 Dec 2004)
Ron Ten-Hove, 10 Dec 2004
General agreement at Hawthorne f-t-f
Proposed resolution (Yaron Goland, 15 Dec 2004)
Diane Jordan, 15 Dec 2004
Changes: 15 Jul 2004 - new issue;
16 Jul 2004 - fields: Links;
10 Dec 2004 - fields: Links, Status, Proposed resolution;
11 Dec 2004 - fields: Links;
15 Dec 2004 - fields: Links, Status, Proposed resolution;
16 Dec 2004 - fields: Links, Status, Proposed resolution, Resolution
<complexType name="tVariable"> <!-- variable does not allow extensibility elements because otherwise its content model would be non-deterministic --> <attribute name="name" type="NCName" use="required"/> <attribute name="messageType" type="QName" use = "optional"/> <attribute name="type" type="QName" use = "optional"/> <attribute name="element" type="QName" use = "optional"/> <anyAttribute namespace="##other" processContents="lax"/> </complexType>Which means that one cannot add new values into tVariable. :Submitter's proposal: It is unclear to me why restricting the extensibility of tVariable is necessary to make the model deterministic. An ANY element would fit in just fine so we should add it.
Change the definition of tVariable to:
<complexType name="tVariable"> <complexContent> <extension base="bpws:tExtensibleElements"> <attribute name="name" type="NCName" use="required"/> <attribute name="messageType" type="QName" use="optional"/> <attribute name="type" type="QName" use="optional"/> <attribute name="element" type="QName" use="optional"/> </extension> </complexContent> </complexType>
<foreach iteratorVariableName="ncname" iteratorVariableType="qname"\ parallel="xs:Boolean" standard-attributes> standard-elements <expression expressionLanguage="anyURI">...</query> activity </foreach>The expression element would be responsible for returning a node-set with 0 or more nodes in it. Each node MUST be of the type specified by iteratorVariableType.
If parallel equals false then each node would be assigned, serially and in document order, to the variable created in an implicit local scope by the attribute iteratorVariableName and the activity would be executed. After the activity successfully completes the variable would be assigned to the next node and the activity run again.
If parallel equals true then a series of parallel scopes, with the same operational semantics as parallel executing event handlers, equal in number to the number of nodes in the node-set would be created and each node would be assigned to a variable local to each of the scopes.
Note that the scope in which the iterator variable is defined is local to the foreach activity and does not contain either an implicit fault or compensation handler. The lack of these handlers is very similar to the logic that was discuss at the 6/2004 F2F for issue 126.
For example:
foreach iteratorVariableName="anOrder" iteratorVariableType="b:ar"/ expression expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116" parallel="false" $orderManifest/somePart/ordermanifest/orders ...
Would be equivalent to:
scope variables variable name="anOrder" type="b:ar" variable name="currentInstanceNum" type="xs:int" sequence assign replace from expressionLanguage="static" "1" to expressionLanguage="xpath" $currentInstanceNum while condition expressionLanguage="xpath" $currentInstanceNum <= count($orderList/somePart/ordermanifest/orders) sequence assign replace from expressionLanguage="xpath" $orderList/somePart/(ordermanifest/orders)[$currentInstanceNum] to expressionLanguage="xpath" $anOrder assign replace from expressionLanguage="xpath" $currentInstanceNum+1 to expressionLanguage="xpath" $currentInstanceNum ...
What isn't clear is what we should do if someone gives us a WSDL with a
solicit/response or notification. Should we ignore it? Should we throw
an error? If only one role in a partnerLink has a WSDL should we
transmute the solicit/response or notification on that WSDL into a
mirror image WSDL for the other role using request/response or one way?
What if both roles have a fully specified WSDL? In that case should we
validate that the solicit/response or notification on one role's WSDL is
matched with a request/response or one way on the other role's WSDL? If
there isn't a matching pair should we create a match on the other role's
WSDL?
Submitter's proposal: I suspect the simplest and most robust solution
is that if BPEL is given a WSDL with a solicit/response or notification
then an error MUST be thrown. I don't like ignoring things in cases like
this, it causes confusion. If a tool wants to be really smart and do
pre-processing to turn solicit/response or notification into a mirror
image WSDL that's fine but it's also out of scope for BPEL. I think that
all BPEL should care about is that when the WSDLs are submitted they
don't have any solicit/response or notification operations.
Links: Announcement, 17 Jul 2004
Changes: 17 Jul 2004 - new issue;
17 Jul 2004 - fields: Links
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd" /> <element name="documentation" id="documentation"> <complexType mixed="true"> <sequence minOccurs="0" maxOccurs="unbounded"> <any processContents="lax"/> </sequence> <attribute name="source" type="anyURI"/> <attribute ref="xml:lang"/> </complexType> </element> <complexType name="tExtensibleElements"> <annotation> <documentation> This type is extended by other component types to allow elements and attributes from other namespaces to be added. </documentation> </annotation> <sequence> <element ref="bpws:documentation" minOccurs="0" maxOccus="unbounded" /> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </complexType>
Add <documentation> element to all BPEL extensible elements.
Description of <documentation> to be added to the specification text:
The content of <documentation> are for human-consumption. Example types for those content are: plain text, HTML and XHTML. On the other hand, tool-implementation specific information (e.g. the graphical layout details) should be added through elements and attributes of other namespaces, using the general BPEL extension mechanism. (i.e. bpws:tExtensibleElements).
In the schema, add as shown here in bold:
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd" /> <element name="documentation" id="documentation"> <complexType mixed="true"> <sequence minOccurs="0" maxOccurs="unbounded"> <any processContents="lax"/> </sequence> <attribute name="source" type="anyURI"/> <attribute ref=<a class="moz-txt-link-rfc2396E" href="xml:lang">"xml:lang"</a>/> </complexType> </element> <complexType name="tExtensibleElements"> <annotation> <documentation> This type is extended by other component types to allow elements and attributes from other namespaces to be added. </documentation> </annotation> <sequence> <element ref="bpws:documentation" minOccurs="0" maxOccus="unbounded" /> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </complexType>
Relaxing this restriction would be useful when we want a process instance to start at a particular
time, possibly on a periodical base. An alternative way of achieving the same effect would be by
defining a receive from a "partner" representing the deployment environment, and having the
environment itself send a message at the appropriate time. But I think it would be more clear
if we use the pick-onAlarm construct instead.
Revisitable: yes
Resolution: Proposed in Ugo Corda, 7 Sep 2004, decided conf call, 15 Sept 2004
Close this issue with no change to the spec.
Mark as revisitable.
Links: Ugo Corda, 22 Jul 2004
Dieter Koenig1, 23 Jul 2004
Dieter Roller, 23 Jul 2004
Ugo Corda, 23 Jul 2004
Ugo Corda, 23 Jul 2004
Ron Ten-Hove, 23 Jul 2004
Prasad Yendluri, 23 Jul 2004
Prasad Yendluri, 23 Jul 2004
Announcement, 26 Jul 2004
Eckenfels. Bernd, 26 Jul 2004
Yaron Y. Goland, 28 Jul 2004
Monica J. Martin, 28 Jul 2004
Satish Thatte, 29 Jul 2004
Eckenfels. Bernd, 29 Jul 2004
Ugo Corda, 29 Jul 2004
Ugo Corda, 29 Jul 2004
Satish Thatte, 29 Jul 2004
Yaron Y. Goland, 29 Jul 2004
Yaron Y. Goland, 29 Jul 2004
Ugo Corda, 29 Jul 2004
Ugo Corda, 29 Jul 2004
Proposed resolution (Ugo Corda, 7 Sep 2004)
Changes: 26 Jul 2004 - new issue;
26 Jul 2004 - fields: Links;
29 Jul 2004 - fields: Links;
30 Jul 2004 - fields: Links;
7 Sep 2004 - fields: Links, Status, Proposed resolution;
15 Sep 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, In spec
Here are some suggested usage:
(A) Keep it required as mentioned in original proposal of Issue 34:
The “bpws:service-ref” has a required attribute called “reference-scheme” to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of bpws:service-ref. Most likely, the URI of reference scheme will have the same value for the namespace URI of the child element of bpws:service-ref. But they are not necessarily the same.
(B) Make it optional:
The “bpws:service-ref” has an optional attribute called “reference-scheme” to to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of bpws:service-ref.
Most likely, the URI of reference scheme and the namespace URI of the child element of bpws:service-ref are not necessarily the same. Typically, this optional attribute is used ONLY when the child element of the “bpws:service-ref” is ambiguous by itself. The optional attribute supplies further information to disambiguate the usage of the content.
Example: different treatments of wsdl:service element
I personally prefer (B) over (A).
Resolution: Proposed in Alex Yiu, 11 Aug 2004, approved by Web ballot (ended 29 Oct 2004)
Make the "reference-scheme" attribute of of "service-ref" element optional.
See proposal email for details. The ballot was multiple choice
(see also Web ballot (ended 29 Oct 2004) , Web ballot (ended 29 Oct 2004) , Web ballot (ended 29 Oct 2004) , resolved by condorcet counting
Links: Announcement, 27 Jul 2004
Yaron Y. Goland, 28 Jul 2004
Francisco Curbera, 28 Jul 2004
Alex Yiu, 28 Jul 2004
Satish Thatte, 29 Jul 2004
Satish Thatte, 29 Jul 2004
Yaron Y. Goland, 29 Jul 2004
Alex Yiu, 6 Aug 2004
Yaron Y. Goland, 9 Aug 2004
Alex Yiu, 9 Aug 2004
Proposal to vote (Alex Yiu, 11 Aug 2004)
Yaron Y. Goland, 11 Aug 2004
Alex Yiu, 12 Aug 2004
Yaron Y. Goland, 13 Aug 2004
Martin Chapman, 25 Aug 2004
Yaron Y. Goland, 26 Aug 2004
Martin Chapman, 26 Aug 2004
Yaron Y. Goland, 27 Aug 2004
Ron Ten-Hove, 27 Aug 2004
Martin Chapman, 31 Aug 2004
Kristofer Agren, 1 Sep 2004
Kristofer Agren, 1 Sep 2004
New proposal to vote (Francisco Curbera, 2 Sep 2004)
Ron Ten-Hove, 2 Sep 2004
Alex Yiu, 2 Sep 2004
Francisco Curbera, 3 Sep 2004
Francisco Curbera, 3 Sep 2004
Martin Chapman, 3 Sep 2004
Ron Ten-Hove, 7 Sep 2004
Chris Keller, 7 Sep 2004
Ron Ten-Hove, 8 Sep 2004
Chris Keller, 8 Sep 2004
Alex Yiu, 8 Sep 2004
Chris Keller, 8 Sep 2004
Yaron Y. Goland, 9 Sep 2004
Yaron Y. Goland, 9 Sep 2004
Martin Chapman, 9 Sep 2004
Ron Ten-Hove, 9 Sep 2004
Yaron Y. Goland, 14 Sep 2004
Proposed resolution (Francisco Curbera, 21 Oct 2004)
Martin Chapman, 5 Nov 2004
Diane Jordan, 5 Nov 2004
Changes: 27 Jul 2004 - new issue;
27 Jul 2004 - fields: Links;
29 Jul 2004 - fields: Links;
30 Jul 2004 - fields: Links;
7 Aug 2004 - fields: Links;
9 Aug 2004 - fields: Links;
10 Aug 2004 - fields: Links;
11 Aug 2004 - fields: Links;
12 Aug 2004 - fields: Links;
14 Aug 2004 - fields: Links;
18 Aug 2004 - fields: Status, Proposed resolution;
26 Aug 2004 - fields: Links;
27 Aug 2004 - fields: Links;
31 Aug 2004 - fields: Links;
2 Sep 2004 - fields: Links;
3 Sep 2004 - fields: Links;
7 Sep 2004 - fields: Links;
8 Sep 2004 - fields: Links ;
9 Sep 2004 - fields: Proposed resolution (corrected by hand, submitted 2 Sep), Links;
15 Sep 2004 - fields: Links, Proposed resolution;
21 Oct 2004 - fields: Links, Status, Proposed resolution;
6 Nov 2004 - fields: Links;
8 Nov 2004 - fields: Status, Proposed resolution, Resolution;
4 Dec 2004 - fields: In spec
Here are two use cases to explain the request:
(It is possible the resolution of issue 103 : Standardizing $varName syntax for XPath to refer to a BPEL variable will address this issue, in which case this issue can be dropped)
Links: Announcement, 27 Jul 2004
Changes: 27 Jul 2004 - new issue;
27 Jul 2004 - fields: Links
WS-I addressed this issue in R2204 by requiring that all parts in a
doc/lit MUST be element definitions. However I am told that the most
common behavior previous to WS-I was to only allow doc/lit messages to
have a single body part which could be a complexType. I suspect we need
to support both of these scenarios. So why don't we just specify in the
spec that any doc/lit WSDL binding MUST either have a single body part
or if multiple body parts are used then all the parts MUST be element
definitions?
Links: Announcement, 28 Jul 2004
Kevin Liu, 28 Jul 2004
Yaron Y. Goland, 29 Jul 2004
Changes: 28 Jul 2004 - new issue;
28 Jul 2004 - fields: Links;
29 Jul 2004 - fields: Links;
30 Jul 2004 - fields: Links
Allow the type attributes on variable declarations to point to complex as well as simple types.
Rationale: WSDL message parts can be defined using complex types, in the case of WS-I RPC/literal it is actually required that WSDL message parts be defined using a type, either simple or complex. But currently doing something as simple as copying a part defined using a complex type into a variable is difficult because variables are not allowed to be complex types. Also, having complex type based variables allows code to be reused more effectively when dealing with data with the same complex type but different element names. (e.g. A same piece of code can deal with data of element "shipTo" and element "billTo" of the same "address" complex type.)
Changes Required: Mostly removing the limitation that type can only specify a simple type and specifying that the infoset for a complexType is a document information item that contains a wildcard document element (e.g. it can be anything) that then contains the actual complex type value.
Section 6.1:
Current: The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema simple types, or XML Schema elements.
Replacement: The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema types (simple or complex) or XML Schema elements.
Section 9.2:
Current: The type of each variable may be a WSDL message type, an XML Schema simple type or an XML Schema element.
Replacement: The type of each variable may be a WSDL message type, an XML Schema type (simple or complex) or an XML Schema element.
Current: Attribute type refers to an XML Schema simple type.
Replacement: Attribute type refers to an XML Schema type (simple or complex).
Delete: An XML Schema complex type must be associated with an element to be used by a BPEL4WS variable.
Insert after the paragraph which begins "The messageType, type or element attributes...": The infoset for a complexType variable consists of a document information item that contains exactly one child, an element information item which is pointed at by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification, as such an implementation MUST specify whatever legal property values it likes. However the children of the document element MUST exclusively consist of the complexType values assigned to the variable."
Section 9.3:
Current: When the variable is defined using XML Schema simple type or element, the part attribute MUST NOT be used.
Replacement: When the variable is defined using XML Schema types (simple or complex) or element, the part attribute MUST NOT be used.
Section 14.1:
Current: When only the first argument is present, the function extracts the value of the variable, which in this case must be defined using an XML Schema simple type or element.
Replacement: When only the first argument is present, the function
extracts the value of the variable, which in this case must be defined
using an XML Schema type (simple or complex) or element. Note that in
the case of a complexType variable the document element's name cannot be
generally known at design time. Therefore to refer to the contents of a
complexType variable one would use an XPATH 1.0 expression of the form
"/*/..."
Links: Announcement, 28 Jul 2004
Proposed resolution (Yaron Y. Goland, 7 Dec 2004)
Changes: 28 Jul 2004 - new issue;
28 Jul 2004 - fields: Links;
8 Dec 2004 - fields: Links, Status, Proposed resolution;
9 Dec 2004 - fields: Status, Proposed resolution, Resolution
Updates MAY support an explicit or implicit in-place XML Schema validation
Updates MUST enforce schema validity at transactional boundaries. It MAY provide a mechanism to allow this constraint to be relaxed.
Resolving this issue will not lead to the addition of any new features.. However, it will enhance and clarify the text in a significant manner and therefore is worth tackling at this time.
The process of adding such a conformance section will cause us to think about and address the following questions:
scope compensationHandler compensate "A" <-- don't know which one scope name="A" <-- first enclosed scope scope name="A" <-- second enclosed scope
Add text to section 13.3.3 "Invoking a Compensation Handler" to clarify that activity names used in a compensate activity must be unique within the scope.
The names of all activities directly nested (ie, not within another nested scope) within a scope will be unique.
Rationale: Currently, there is no constraint on activity names, i.e. the activity name (standard attribute) does not have to be unique. As a result, a compensate activity may become ambigous:
scope compensationHandler compensate "A" <-- don't know which one scope name="A" <-- first enclosed scope scope name="A" <-- second enclosed scope
This arose from the discussion resolving issue 134 : Non-Integer XPATHS at the 21 Sept 2004 face-to-face meeting.
Submitter's solution: To add a new standard fault, languageExecutionFault, which is
thrown if the expression language or xxx throws an unhandled fault.
Add to the end of section 14.1 "If execution of the expression language yields an unhandled fault, the standard fault languageExecutionFault is thrown."
Add to the end of section 14.3 "If execution of the query language yields an unhandled fault, the standard fault languageExecutionFault is thrown."
Question: Should this fault define a message type (or should a generic
message type be defined) to carry any additional data that is received
from the executing language?
Links: Announcement, 22 Sep 2004
Changes: 22 Sep 2004 - new issue;
22 Sep 2004 - fields: Links;
23 Sep 2004 - fields: Description;
14 Oct 2004 - fields: Status, Date accepted
In a throw activity, one may specify a faultVariable with a NCName of a declared BPEL variable (11.6). Such variables can be declared with exactly one of {messageType, type, element} (9.2).
In catch fault handler, one may specify a faultVariable with a faultMessageType that is a QName of a WSDL message (13.4).
As a result, one cannot catch faults that are thrown with variables declared with type or element.
Submitter's proposal: Add the ability to catch faults that have faultVariables declared with type or element, e.g.:
Option 1:
<catch faultName="qname"? faultVariable="ncname"? faultVariableMessageType="qname"? faultVariableType=”qname”? faultVariableElement=”qname”? > ... </catch>
Option 2:
<catch faultName="qname"? faultVariable="ncname"? > <variable name="ncname" messageType="qname"? type=”qname”? element=”qname”? /> ... </catch>
Option 3:
<catch faultName="qname"? > <variable name="ncname" messageType="qname"? type=”qname”? element=”qname”? /> ... </catch>
Currently, http://www.w3.org/TR/1999/REC-xpath-19991116 is used as the default value of both expression language and query language, which represents XPath 1.0.
In order for us to make use of XPath 1.0 within BPEL, the BPEL spec needs to define additional semantics for the cross-language bindings. Those details are actually specific to BPEL language in a sense. Strictly speaking, it is not appropriate to "hijack" the W3C namespace for our own use.
(This was raised by Chris Keller in the course of issue 89 : Handling Unrecognized Query/Expression Languages discussion at the face-to-face today)
Submitter's proposal:
Replace the following text in BPEL spec:
The default value for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.with:
The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.
See also:
Replace the following text in BPEL spec:
The default value for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.with:
The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.
The urn will be adjusted as needed when the OASIS naming procedures are finalized.
Links: Announcement, 23 Sep 2004
Peter Furniss, 23 Sep 2004
Proposed resolution (Alex Yiu, 28 Oct 2004)
Changes: 23 Sep 2004 - new issue;
24 Sep 2004 - fields: Links;
14 Oct 2004 - fields: Status, Date accepted;
28 Oct 2004 - fields: Links, Status, Proposed resolution;
11 Nov 2004 - fields: Status, Proposed resolution, Resolution;
4 Dec 2004 - fields: In spec
int counter counter = 0 flow sequence counter = counter + 1; if (counter == 2) { throw "counter is 2" } sequence counter = counter + 1; if (counter == 2) { throw "counter is 2" }If assign doesn't imply placing a read/write lock on variables referenced in the assign then it is possible for the previous code to exit without ever throwing a fault. After all, both assigns could execute simultaneously, both read in the same value (0), both add 1 and both write out the same counter value, 1 and thus both end without throwing a fault.
scope variableAccessSerializable="yes" flow assign ... assign ...
In section 14.3
Change current text:
An important characteristic of assignment in BPEL4WS is that assignment activities are atomic.
to:
The assign activity is atomic, that is, the assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process being executed. The mechanisms used to implement the previous requirement are implementation dependent.
The current specification needs clarification on the behavior of the rethrow activity.
For example, it is unclear that a rethrown fault can be caught by a fault handler defined inside the fault handler that has caught the fault.
Suppose we have the following process definition snippet:
<faulthandlers> <catch name="FH1" faultName="x:foo"> <sequence> ... <scope> <faulthandlers> <catch name="FH2" faultName="x:foo"> ... </catch> </faultHandlers> <rethrow/> </scope> </sequence> </catch> </faultHandlers>
Will FH2 catch the rethrown fault?
Champion: Yuzo Fujishima <fujishima@bc.jp.nec.com>
Submitter's proposal:
Consider rethrow as a throw with a faultVariable attribute that specifies the implicit fault variable associated with the fault handler.
Therefore, the answer to the question above is: Yes, FH2 will catch the fault.
In addition, it should be noted that a rethrow is associated with the innermost enclosing fault handler.
Resolution: Proposed in Yuzo Fujishima, 15 Oct 2004, decided conf call, 27 October 2004
Consider a <rethrow> as a macro for a <throw> that throws the fault caught by the corresponding fault handler.
A fault handler is said to be corresponding to a <rethrow>
if the handler encloses the <rethrow> without intervening
fault handlers.
Links: Announcement, 4 Oct 2004
Proposed resolution (Yuzo Fujishima, 15 Oct 2004)
Changes: 4 Oct 2004 - new issue;
4 Oct 2004 - fields: Links;
14 Oct 2004 - fields: Status, Date accepted;
15 Oct 2004 - fields: Links, Status, Proposed resolution;
27 Oct 2004 - fields: Status, Proposed resolution, Resolution
On the one hand, the spec suggests that process creation is "implicit" and that the createInstance flag is merely an annotation that defines which message events cause an instance to be created and that once created the process instance processes all activities in the same manner largely oblivious to the value of that annotation.
On the other hand, the spec restricts the set of activities that are "initial" activities, and establishes exceptional semantics (for process-level event handlers) that could be construed to imply that createInstance activities are actually activated before any other activities, irrespective of their actual location in the process.
I posit that the former interpretation provides a concise and manageable view of the instance creation process. By making the spec consistent with it we can define execution semantics of a single process instance without reference to instance creation. We can handle instance creation simply and separately by stipulating that a process instance is created when a message event that would match one of the createInstance activities is received. This message event is "allocated" to that activity, so that when that activity is actually activated (in the normal course of process instance evaluation) it will receive the said event.
The major implication of this model on execution semantics is the elimination of the notion of "initiate" activities. This concept becomes unnecessary. One might object on the basis that without the initiate activity restrictions the following process would be perfectly legal:
<sequence> <invoke .../> <receive createInstance="yes" .../> </sequence>Such a process certainly seems objectionable. However, the details of normal execution semantics would make such a process unlikely. That is to say, the <invoke> would need to use a message variable (for the request), and that variable could not have been initialized unless some activity preceded the <invoke>. One might then object with the following:
<sequence> <receive createInstance="no" .. var="foo"/> <invoke ... inVar="foo"/> <receive createInstance="yes" ..> </sequence>However, in this process the first receive is invalid unless a correlation set is used. But in order to use the correlation set, it first needs to be initialized, and the only way to do that is with an invoke or a receive/pick that precedes it, so you're back to needing a <receive> to precede the <invoke>. This receive would have to have createInstance="yes" lest it run into the same problem. But if this receive had createInstance="yes" then the same annotation on the second <receive> would be invalid.
Now, one might get cleverer still and object based on the following somewhat convoluted process:
<sequence> <assign> <copy> <to variable="foo"/> <from> literal </from> </copy> </assign> <invoke ... inVar="foo"> <correlation name="cset1" initiate="yes" pattern="in"/> </invoke> <receive createInstance="no" ..> <correlation name="cset1" initiate="no" /> </receive> <receive createInstance="yes" ..> </sequence>However the above construct would result in ALL process instances having the same correlation set value, which does not make any sense.
But one could still object by changing the pattern to "out" on the invoke, and asserting that the partner generates unique output messages for each invocation thereby yielding unique correlation keys. But even this very brink of the edge case forces us to change nothing in the semantics. The only significant implication is that in certain unlikely circumstances, the implementation might have to handle <invoke>s and non-createInstance <receive> before it has a chance to offload the createInstance message to the createInstance <receive> (i.e. it needs to provide a "memory" for the message that created the instance). The only plausible use case for this kind of behavior is for initialization of static content.
Finally, adopting uniform execution semantics would lead us to elimination of the exceptional language in the spec that requires that process-level alarm handlers can use data that would normally only be valid after a receive activity completes. This is not so onerous, as it is possible to move a process-level event handler into a scope following the initial receives.
Resolution: Agreed by Web ballot (ended 24 Nov 2004)
We should guarantee that an initial start activity will complete before any other activities are allowed to execute. This will prevent race conditions, prevent us from having to discuss the dispatcher, prevent a bunch of edge cases and make sure that the existing event handler model will work just fine. See email with full info at: Yaron Y. Goland, 9 Nov 2004
Add the following two sentences to section 6.5:
Amongst the start activities the particular start activity that causes a specific new process instance to be created is termed the 'initial start activity'. When a BPEL process instance is created and begins executing the initial start activity MUST fully complete execution before any other initial activity may begin execution.
Suppose activity A has multiple link sources S1, S2, and S3, with transition conditions, and that the transition condition of S1 is evaluated and the result is an error. The status of S1 is negative according to 12.5.1 of the specification. What will happen for S2 and S3?
E1. The transition conditions of S2 and S3 are evaluated and the status of the links are set accordingly, independently of S1.
E2. The transition conditions of S2 and S3 are not evaluated and the status of the links are set to be negative.
Further suppose that, assuming we chose E1 as the right behavior, evaluating S3's transition condition resulted in an error. Then what will happen?
F1. Only one fault will be thrown from A.
F2. Two faults, one for each error, will be thrown from A.
Submitter's proposal:
Add text to 12.5.1. to explain that the correct behaviors are E1 and F1.
Proposed resolution: Yuzo Fujishima, 7 Dec 2004
Links: Announcement, 18 Oct 2004
Proposed resolution (Yuzo Fujishima, 7 Dec 2004)
Satish Thatte, 10 Dec 2004
Changes: 18 Oct 2004 - new issue;
18 Oct 2004 - fields: Links;
27 Oct 2004 - fields: Status, Date accepted;
7 Dec 2004 - fields: Links, Status, Proposed resolution;
10 Dec 2004 - fields: Links
Even though those three elements don't appear in a WSDL definition, they (especially the faultcode) convey information that is too important just to ignore.
Submitter's proposal:
I think we have to do either of the following:
One way to support faultcode, faultstring and faultactor is as follows:
Add optional faultCodeVariable, faultStringVariable, faultActorVariable attributes to <catch>, <throw>, and <reply>. For a <catch>, the attributes specify the names of the variables to set the values to, while for the latter two, the variables to get the values from.
The default values (not the variable names) are "soap:Server", "", "" for faultcode, faultstring, faultactor, respectively.
Proposed resolution: Yaron Y. Goland, 2 Dec 2004
Resolution: Agreed at conf call, 10 November 2004
To be fixed as a bug. The implementor's note proposed
in submitter's proposal A) is referred to the editing team.
Yaron Goland will send a draft of the implementor's note to the main list.
Links: Announcement, 18 Oct 2004
Yaron Y. Goland, 25 Oct 2004
Yuzo Fujishima, 26 Oct 2004
Eckenfels. Bernd, 26 Oct 2004
Yaron Y. Goland, 26 Oct 2004
Yuzo Fujishima, 27 Oct 2004
Yaron Y. Goland, 2 Nov 2004
Proposed resolution (Yaron Y. Goland, 2 Dec 2004)
Changes: 18 Oct 2004 - new issue;
18 Oct 2004 - fields: Links;
25 Oct 2004 - fields: Links;
26 Oct 2004 - fields: Links;
27 Oct 2004 - fields: Links;
2 Nov 2004 - fields: Links;
10 Nov 2004 - fields: Status, Vote announcement;
11 Nov 2004 - fields: Status, Date accepted, Resolution, Vote announcement;
2 Dec 2004 - fields: Links, Status, Proposed resolution;
3 Dec 2004 - fields: Status
<catch faultName="qname" faultVariable="ncname"? faultMessageType="qname"?>*To be consistent with a fault handler defined for a process or a scope, this attribute should be optional.
In 6.2 and 11.3, replace
faultName="qname"with
faultName="qname"?
In "6.2. The Structure of a Business Process" and "11.3. Invoking Web Service Operations",
Replace
faultName="qname"With
faultName="qname"?
Passed to editing team to be fixed as a bug
Links: Announcement, 18 Oct 2004
Changes: 18 Oct 2004 - new issue;
18 Oct 2004 - fields: Links;
27 Oct 2004 - fields: Status, Date accepted;
29 Oct 2004 - fields: Status, Resolution;
25 Nov 2004 - fields: In spec
The first two receive's in the process (under the flow activity) have initiate="yes".
It looks like it should be initiate="rendezvous" instead.
Resolution: Agreed at conf call, 27 October 2004
Passed to editing team to be fixed as a bug
Links: Announcement, 20 Oct 2004
Changes: 20 Oct 2004 - new issue;
21 Oct 2004 - fields: Links;
27 Oct 2004 - fields: Status, Date accepted;
29 Oct 2004 - fields: Status, Resolution;
25 Nov 2004 - fields: In spec
The text should be clear.
Links: Announcement, 23 Oct 2004
Alex Yiu, 24 Oct 2004
Prasad Yendluri, 24 Oct 2004
Yaron Y. Goland, 25 Oct 2004
Prasad Yendluri, 25 Oct 2004
Danny van der Rijn, 25 Oct 2004
Prasad Yendluri, 25 Oct 2004
jim@parasoft.com, 26 Oct 2004
Prasad Yendluri, 26 Oct 2004
jim@parasoft.com, 26 Oct 2004
Prasad Yendluri, 26 Oct 2004
Changes: 23 Oct 2004 - new issue;
24 Oct 2004 - fields: Links;
25 Oct 2004 - fields: Links;
26 Oct 2004 - fields: Links;
27 Oct 2004 - fields: Links;
11 Nov 2004 - fields: Status, Date accepted
The problem is that when executing a message operation like a receive just specifying the partnerLink, portType and operation is not enough to uniquely identify which operation is intended in an overloaded portType. Strictly speaking one also needs to specify both the name of the input and (if present) the output elements in order to uniquely identify an overloaded operation.
There are a number of consequences to this ambiguity:
Receive/Pick & Reply - It is impossible to know which overloaded operation one is waiting for.
Even using the variable type as a tie breaker isn't guaranteed to work since it is legal to have two input elements in two overloaded operations with different names but identical types. In the case of a one-way we might just fudge things and say that the receive/pick is able to wait for two or more operations using the same variable type simultaneously but in the case of request/reply we can be in big trouble since there is no way to statically know if the reply is correct. E.g. if two operations have the same name and same inputs but different outputs.
Just to make things even more fun one could have two identically named operations whose input and output elements have different names but identical types. In that case the BPEL variable typing will work but there is no way for the WSDL binding to know which of the overloaded operations was intended since BPEL doesn't communicate the input/output element names as part of the BPEL messaging operation.
Invoke - Same issues in reverse.
Submitter's proposal: I can see two ways to solve this issue. The one I prefer is that we just
declare in the spec that BPEL doesn't support overloaded WSDLs and call
it a day.
But another choice is to extend our messaging operations to optionally
allow for the specification of the input/output element names (we would
need both in the case of request/response operations).
Resolution: Agreed at conf call, 10 November 2004
A clarification will be added that BPEL must not process WSDL with a single port type and
multiple operations of the same name. Final wording to be determined by the spec editing team.
Links: Announcement, 27 Oct 2004
Eckenfels. Bernd, 27 Oct 2004
Alex Yiu, 27 Oct 2004
Yuzo Fujishima, 3 Nov 2004
Changes: 27 Oct 2004 - new issue;
27 Oct 2004 - fields: Links;
28 Oct 2004 - fields: Links;
3 Nov 2004 - fields: Links;
11 Nov 2004 - fields: Status, Date accepted, Resolution;
25 Nov 2004 - fields: In spec
Section 4 will be deleted
Text will be deleted in the next editing, but the section may remain until final editing when cross references will be cleaned up.
Links: Announcement, 27 Oct 2004
Changes: 27 Oct 2004 - new issue;
28 Oct 2004 - fields: Links;
11 Nov 2004 - fields: Status, Date accepted, Resolution;
19 Nov 2004 - fields: In spec
A clarification will be added to say that all handlers associated with scope are lexically local to that scope.
Links: Announcement, 2 Nov 2004
Dieter Koenig1, 4 Nov 2004
Yaron Y. Goland, 9 Nov 2004
Yaron Y. Goland, 9 Nov 2004
Changes: 2 Nov 2004 - new issue;
2 Nov 2004 - fields: Links;
4 Nov 2004 - fields: Links;
10 Nov 2004 - fields: Links;
11 Nov 2004 - fields: Status, Date accepted, Resolution;
25 Nov 2004 - fields: In spec
The from-spec is a variable of a WSDL message type and the to-spec is not, or vice versa. This is not legal because parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly.
One could interpret this as if an assignment from a variable of a WSDL message type to a partner link is not allowed because the partner link is not itself a variable of a WSDL message type. Likewise for assignments in the reverse direction.
Submitter's proposal: Clarify that an assignment to/from a partner link IS allowed when the from/to spec is a variable of a WSDL message type.
The endpoint reference is in a message part of this WSDL message, either the complete part or an element contained in the part.
Resolution: Accepted and immediately closed on conf call 24 Nov 2004
Closed as duplicate (or will be treated as part of) issue 51 : Section 9.3.1 & Schema Validation
Links: Announcement, 12 Nov 2004
Yaron Y. Goland, 15 Nov 2004
Prasad Yendluri, 23 Nov 2004
Dieter Koenig1, 24 Nov 2004
Changes: 12 Nov 2004 - new issue;
17 Nov 2004 - fields: Links;
24 Nov 2004 - fields: Links, Status, Resolution, In spec
Imagine however the following WSDL whose target namespace prefix is "foo" :
portType name="aPort" operation name="o1" ... fault name="aFault" ... ... operation name="o2" ... fault name="aFault" ... ... operation name="o3" ... fault name="aNewFault" ... ...
Now imagine the following BPEL fragment:
... reply partnerLink="..." portType="foo:aPort" operation="o1"/ variable="..." faultName="foo:aFault" ... reply partnerLink="..." portType="foo:aPort" operation="o1"/ variable="..." faultName="foo:aNewFault"
Which of the replies, if any, are legal?
Is the language in section 11.3 only meant to apply when receiving a fault? If so then the first reply is legal (and unambiguous) and the second is not.
If, on the other hand, the language in section 11.3 is meant to apply both to receiving and sending faults then the first reply is illegal but the second is probably legal.
The first reply is illegal because the situation is ambiguous. If 11.3 applies then BPEL overrides the WSDL semantics and requires that faults be identified exclusively by portType name and fault name. In that case having "aFault" defined twice in the same portType (even if the message types were different) is an error that should be caught by static analysis and thus require the process to be rejected.
The second reply is legal because although "aNewFault" is not defined in
operation o1 its fault name and portType combination are unique and so
we can resolve the reference even though it isn't in the same operation
and thus, strictly speaking, isn't legal in canonical WSDL.
Submitter's proposal: I propose that the language in section 11.3 only
apply to receiving faults on invokes and that we make this limitation
explicit in sections 11.3 and 11.4 so there is no confusion. When
sending a fault using a reply we should follow the normal WSDL rules and
identify the fault using the unique combination of portType, operation
name and fault name. This would mean that in the previous example the
WSDL would be accepted and the first reply would be legal and the second
would not.
Links: Announcement, 4 Dec 2004
Changes: 4 Dec 2004 - new issue;
5 Dec 2004 - fields: Links;
8 Dec 2004 - fields: Status, Date accepted
Appendix 1 in table A.1 in the row marked uninitializedVariable currently states "Thrown when there is an attempt to access the value of an uninitialized part in a message variable."
In both cases there is a presumption that variables can only be of WSDL message type.
Thanks to Ron Ten-Hove for finding this problem.
Submitter's proposal: Change the text in 14.2 to read: "An attempt during process execution to
use a variable or in the case of a message type variable a part of a
variable before it is initialized MUST result in the standard
bpws:uninitializedVariable fault."
Change the text in table A.1 to read: "Thrown when there is an attempt
to access the value of an uninitialized variable or in the case of a
message type variable one of its uninitialized parts."
Links: Announcement, 11 Dec 2004
Changes: 10 Dec 2004 - new issue;
11 Dec 2004 - fields: Links;
14 Dec 2004 - fields: Status, Date accepted
According to our current fault matching rules IF a fault has a body THEN it can only be three ways - by a catch that specifies the name and body, by a catch that just specifies the body or by catch all. But notice what can't catch it, a catch that just catches on the name.
That means, if someone needs to add a data body to the fault later (to add optional interesting data) then all existing catches will be broken.
Proposed Solution:
It would be better to allow <catch faultName="qname"> to catch with fault data body as well.
Changes: 6 Jan 2005 - new issue
This file last updated 0:50 6 Jan 2005 (UTC)