[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsbpel] Issue 244 - Proposal for Vote
Seems like I responded to the wrong mail and this one ended up in the general list, my apologies. Hre it goes again so you can get it in the right mail folder :-) Paco ----- Forwarded by Francisco Curbera/Watson/IBM on 02/27/2006 09:30 PM ----- Francisco Curbera/Watson/IB To: Dieter Koenig1 <dieterkoenig@de.ibm.com> M@IBMUS cc: wsbpel@lists.oasis-open.org, Rania Khalaf/Watson/IBM@IBMUS, cbarreto@adobe.com 02/27/2006 05:40 Subject: Re: [wsbpel] Issue 244 - Proposal for Vote PM I completed the edit of 82.1. The pen goes to Vinky. I made a small to the resolution in the following paragraph, in Section 13.4.3. To the original paragraph Charlton had added a "template" prefix in front of the "createInstance" attribute, so the resolution text read as follows: ------------ All start activities MUST be defined in a process of this Template Profile. This implies that NO new start activity is allowed to be added during executable completion (that is a message inbound activity annotated with a template:createInstance="yes" attribute). ------------ Nowhere else in the text is introduced or mentioned the "template:createInstance" attribute; there is no explanation of why a different createInstance is needed. This is not right from the readability and completeness points of view. It will also make makes the paragraph above sound really mysterious to uninitiated public. I have replaced the text above by the following, which seems to convey the appropriate meaning much more explicitly: ------------ All start activities MUST be defined in a process of this Template Profile. This implies that NO new start activity (that is a message inbound activity annotated with a createInstance="yes" attribute) is allowed to be added during executable completion. The Template Profile introduces a new "template:createInstance" attribute for use with opaque activities, since the standard "createInstance" attribute defined in the common abstract process schema is not allowed on opaque activities. ------------ Note that I changed two things: 1. I removed the "template" prefix from the phrase in parenthesis, since its use is yet completely unexplained; it also seems actually inaccurate (are startable activities with regular createInstance attributes allowed? I don't think so). 2. I have added a note explaining the fact that a template:createInstance attribute is being introduced to support <opaque>. If I am wrong in my interpretation of the resolution in this particular aspect, please let me know. I have copied Rania and Charlton since they were directly involved in the drafting the resolution. In any case, I have committed the spec so the editing process can proceed; we can always go back and tweak this paragraph if we conclude that my text is not accurate. Paco Dieter Koenig1 <dieterkoenig@de. To: wsbpel@lists.oasis-open.org ibm.com> cc: Subject: [wsbpel] Issue 244 - Proposal for Vote 02/27/2006 10:31 AM In order to fix the definition of bpws:conflictingRequest, and remove bpws:invalidReply in favor of bpws:missingRequest, I propose the following changes to the spec. Note that all remaing references to the tuple (partner link, port type, operation, correlation set) - dealing with bpws:conflictingReceive - are correct. ---------------- (1) Section 10.4 - paragraph 10 - wrong text: The correlation between a request and the corresponding reply is based on the constraint that more than one outstanding synchronous request from a specific partner link for a particular portType, operation and correlation set(s) MUST NOT be outstanding simultaneously. If this constraint is violated during execution, then the standard fault bpws:conflictingRequest MUST be thrown by a conforming implementation. Note that this is semantically different from the bpws:conflictingReceive, because it is possible to create the conflictingRequest by consecutively receiving the same request on a specific partner link for a particular portType, operation and correlation set(s). For the purposes of this constraint, an onMessage clause in a pick is equivalent to a receive (see Pick). Action - drop this text from paragraph (paragraph 15 already explains bpws:conflictingRequest correctly). The text starting with "Moreover, ..." remains. ---------------- (2) Section 10.4 - paragraph 12 - wrong text: If a reply activity is being carried out during the execution of a business process instance and no synchronous request is outstanding for the specified partnerLink, portType, operation and correlation set(s), then the standard fault bpws:invalidReply MUST be thrown by a conforming implementation. Action - drop this paragraph completely (paragraph 16 already explains it correctly using bpws:missingRequest). ---------------- (3) Appendix A. - wrong text (table row explaining conflictingRequest): Thrown when more than one synchronous inbound request on the same partner link for a particular port type, operation and correlation set(s) are active. Action - replace with new text (table row explaining conflictingRequest): Thrown when more than one synchronous inbound request on the same partner link, operation and message exchange are active. ---------------- (4) Appendix A. - wrong text (table row explaining invalidReply): Thrown when a reply is sent on a partner link, portType and operation for which the corresponding receive with the same correlation has not been carried out. Action - drop this row completely (bpws:missingRequest is sufficient). --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]