New and updated WS-BPEL issues

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Title: Message

Dear Colleagues, 

 

I would like to draw some new issues to your attention.  At Yaron's request I have added (as 'received' ) sub-issue 12.2 - and I am still trying to find out what happened to 12.1 - answers on the back of a (pretty) postcard please!

 

Then there are three new issues for the TC's consideration 182 (where I have modified the description at Alex's request - I assumed this was all right as we still have a week to go before we consider it at the next TC meeting), 183 and 184.  The latest issues list is available at http://www.choreology.com/external/WS_BPEL_issues_list.html for your review and I plan to put a copy on the OASIS site just before the meeting next week.

 

At Diane's request and suggestion I have added some cross linking on a few issues to show strong interrelationship.  See for instance  Issue 103  and Issue 28, Issue 29, Issue 102, Issue 153 and Issue 156.

 

 Please obey the rules as previously stated when sending mail about issues.   (I am currently unable to run the script that usually generates the new issue messages.)  Please send further new issues,any comments / anomaly notifications (etc.) to myself (Tony Fletcher) with a copy to Peter Furniss for the present.  Thank you.

 

 

---

Issue 12.2: Accessing messageType properties under issue 12

Status: received
Date added: 7 Jan 2005
Categories: Data handling
Date submitted: 23 December 2004
Submitter: Yaron Y. Goland
Description: If someone has defined a property on a messageType and a programmer uses issue 12.1 : to pass in and out an element for that messageType then how does the programmer get access to the messageType specific properties? After all, if they pass the element into getVariableProperty they will (per issue 145 : Properties on Non-Message Variables ) only get the properties defined on the element, not the messageType.
This issue is being opened as a result of the resolution of issue 12.1.

Submitter's proposal: I don't have one yet.
Links:
Changes: 7 Jan 2005 - new sub-issue

---

Issue 182: How to add bodies later to BPEL faults without breaking BPEL code written assuming there is no fault body?

Status: received
Date added: 6 Jan 2005
Categories: Fault handling
Date submitted: 15 December 2004
Submitter: Alex Yiu
Champion: Alex Yiu
Document: BPEL specification
Description:

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.

How do we make it possible for people to later add bodies to BPEL faults without breaking BPEL code written assuming there is no fault body?

Please note that this problem already affect us on BPEL standard faults. We define BPEL standard faults with their name but without their bodies. If an implementation decides to introduce extra fault information in the body later, all existing fault handlers for that fault will not work. We need to ask users to change their fault handlers or add new fault handlers.

Proposed Solution:

(A) allow <catch faultName="qname"> to catch with fault data body as well ?
(B) introduce a standard fault body that is thrown with all BPEL standard faults. And, the fault body will contain an xsd:any ?
(C) add new version of fault handler that specifies both a name and a body and can catch either just on name or on both name and body ?
(D) Other ideas .... ?

Links: Original message, 15 Dec 2004     Alex Yiu, 12 Jan 2005     Yaron Y. Goland, 14 Jan 2005
Changes: 6 Jan 2005 - new issue;    13 Jan 2005 - fields: Links;    14 Jan 2005 - fields: Links

---

Issue 183: Ambiguity in Rethrow Semantics

Status: received
Date added: 7 Jan 2005
Categories: Fault handling
Date submitted: 23 December 2004
Submitter: Yaron Y. Goland
Description: If one catches a fault and then modifies the fault variable and then rethrows the fault what is rethrown? The original fault variable or the modified fault variable? Similarly, with issue 12 : XML types and WS Interactions , if someone catches a messageType fault using an element based catch and then uses rethrow, what is rethrown, the original messageType fault or the element that was caught?

Submitter's proposal: Clarify the language to specify that the original fault is always rethrown regardless of what variable is bound or modified. So in the first example above the original variable, not the modified version, would be rethrown. In the second example the original messageType variable and not the element variable would be rethrown.

Links:
Changes: 7 Jan 2005 - new issue

---

Issue 184: Fully Specify Examples

Status: received
Date added: 18 Jan 2005
Categories: Specification Editing
Date submitted: 13 January 2005
Submitter: Yaron Y. Goland
Description: Section 6.1 includes an example which imports schema elements from the (fictitious) namespace "http://manufacturing.org/xsd/purchase". But the actual contents being imported are never specified so the example cannot be implemented.
Submitter's proposal: We should provide actual schema definitions (they can be trivial), even if just in an appendix, so that all of our examples are fully implementable.
Changes: 18 Jan 2005 - new issue

 

Best Regards,

Tony                          

	Tony Fletcher Technical Advisor Choreology Ltd. 68, Lombard Street, London EC3V 9L J   UK
	Phone:	+44 (0) 1473 729537
	Mobile:	+44 (0) 7801 948219
	Fax:	+44 (0) 870 7390077
	Web:	www.choreology.com
Cohesions™
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com
Home: amfletcher@iee.org