| << Back to previous view |
|
[BPEL-1] support for BPEL4WS 1.1
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
STATUS: New
SUBMITTED BY: Martin Chapman TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: The contributed specification from OSOA supports WS-BPEL 2.0 and BPEL4WS 1.1. Do we still have a requirement to support BPEL4WS 1.1. and formally support its use in OASIS SCA? PROPOSAL: none |
| Comments |
| Comment by Alex Yiu [ 04/Oct/07 10:26 AM ] |
| http://lists.oasis-open.org/archives/sca-bpel/200709/msg00025.html |
| Comment by Michael Rowley [ 21/Feb/08 10:14 AM ] |
|
Resolved on the 2008-02-07 call:
http://lists.oasis-open.org/archives/sca-bpel/200802/msg00016.html The resolution was: "Make the chapter 4 non-normative." |
[BPEL-2] Does the spec allow a componentType side file
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: Does the spec allow a componentType side file
STATUS: New SUBMITTED BY: Anish Karmarkar TARGET: BPEL C&I spec DESCRIPTION: The spec does not say whether a componentType side file is allowed. If it is allowed then it should override the default rules specified in the spec. PROPOSAL: <none> |
| Comments |
| Comment by Alex Yiu [ 04/Oct/07 10:24 AM ] |
|
http://lists.oasis-open.org/archives/sca-bpel/200709/msg00026.html
|
| Comment by Michael Rowley [ 17/Apr/08 10:21 AM ] |
|
Issue 36: Compatibility of the component type side file
was opened for this topic. http://www.osoa.org/jira/browse/ASSEMBLY-36 This resolves the issue as decided on call of 7-feb-08 |
| Comment by Martin Chapman [ 05/Sep/08 08:58 AM ] |
| The resolution is at http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/27285/2008-02-07.html |
| Comment by Martin Chapman [ 05/Sep/08 09:25 AM ] |
| Applied to CD-01-rev10: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/29222/sca-bpel-1%5B1%5D.1-spec-cd-01-rev10.doc |
[BPEL-3] Correlation disagreement between SCA and BPEL
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: Correlation disagreement between SCA and BPEL
STATUS: New SUBMITTED BY: Najeeb Andrabi TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: SCA conversation mechanism primarily deals with correlations at the transport/messaging level not at an application/component level. Currently, there is no mechanism to handle a case where SCA runtime correlates correctly but BPEL correlation fails. PROPOSAL: none http://lists.oasis-open.org/archives/sca-bpel/200709/msg00027.html |
| Comments |
| Comment by Alex Yiu [ 06/Dec/07 11:05 AM ] |
|
The issue is formally resolved by this proposal:
http://lists.oasis-open.org/archives/sca-bpel/200711/msg00061.html |
| Comment by Najeeb Andrabi [ 09/Jul/08 09:14 PM ] |
|
This issue resolution is applied in committee draft 01 revision 7:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/28771/sca-bpel-1.1-spec-cd-01-rev7.doc |
| Comment by Najeeb Andrabi [ 09/Jul/08 09:20 PM ] |
|
This issue resolution is applied in workign draft version 4:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/26339/sca-bpel-1.1-spec-WD-04.doc |
| Comment by Najeeb Andrabi [ 09/Jul/08 09:30 PM ] |
|
This issue resolution was applied in committee draft 01 revision 7:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/28771/sca-bpel-1.1-spec-cd-01-rev7.doc |
[BPEL-4] Title of the resulting spec shouldn't be confusing
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: Title of the resulting spec shouldn't be confusing
STATUS: New SUBMITTED BY: Danny van der Rijn TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: The title in the current Working Draft is "Service Component Architecture Client and Implementation Model Specification for WS-BPEL Version 2.0." This can be misconstrued as being a specification that deals with WS-BPEL 2.0, not that it's a 2.0 spec for dealing with WS-BPEL. PROPOSAL: Liaise with the other TCs to come up with a format for the title that will be acceptable to all, and not leave us with an ambiguity. http://lists.oasis-open.org/archives/sca-bpel/200709/msg00028.html |
| Comments |
| Comment by Alex Yiu [ 04/Oct/07 10:49 AM ] |
|
Mike Edwards moved the motion to close with "Service Component Architecture WS-BPEL Client and Implementation Specification Version 1.1"
Martin Chapman seconded. Motion is passed. |
| Comment by Alex Yiu [ 04/Oct/07 10:49 AM ] |
|
Mike Edwards moved the motion to close with "Service Component Architecture WS-BPEL Client and Implementation Specification Version 1.1"
Martin Chapman seconded. Motion is passed. |
| Comment by Martin Chapman [ 05/Oct/07 10:22 AM ] |
| The status should be RESOLVED, LATER, and only changed to RESOLVED, FIXED when the editors have made the changes. |
| Comment by Dieter Koenig [ 11/Oct/07 10:30 AM ] |
| Fixed in working draft 3 - http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=25646 |
| Comment by Michael Rowley [ 25/Sep/08 09:56 AM ] |
|
Closed with acceptance of CD-01. |
[BPEL-5] The algorithm for deciding whether a partnerLink is a service or a reference needs to be deterministic
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: The algorithm for deciding whether a partnerLink is a service or a reference needs to be deterministic
STATUS: New SUBMITTED BY: Danny van der Rijn TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: Section 2.1 currently states "If a static analysis of the process determines that it is possible that the first message for a partner link will be received in a <receive> activity, the <onMessage> element of a <pick> activity or the <onEvent> element of an event handler then the partner link has a corresponding SCA service in the component type." I have concerns that this will leave cases where one vendor can make such determination, where another vendor, with a less sophisticated static analysis can not. This will leave the algorithm implementation-dependent. The goal of the algorithm is to produce a component type from a BPEL file in a deterministic way, with no external dependencies. PROPOSAL: none http://lists.oasis-open.org/archives/sca-bpel/200709/msg00029.html |
| Comments |
| Comment by Alex Yiu [ 08/Nov/07 11:04 AM ] |
|
Proposal email link:
http://lists.oasis-open.org/archives/sca-bpel/200711/msg00036.html |
| Comment by Michael Rowley [ 25/Sep/08 09:52 AM ] |
|
Applied in revision 4 (2007-12-05)
Closed with acceptance of CD-01. |
[BPEL-6] Make local partnerLink aliases deterministic
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: Make local partnerLink aliases deterministic
STATUS: New SUBMITTED BY: Danny van der Rijn TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: Section 2.4 lists some rules for deriving service/reference alias names for partnerLinks when there is a name-hiding in a scope. The rules, though are non-deterministic. This will leave the algorithm that derives a component type from a BPEL file as implementation-dependent. The goal of the algorithm is to produce a component type from a BPEL file in a deterministic way, with no external dependencies. PROPOSAL: none http://lists.oasis-open.org/archives/sca-bpel/200709/msg00030.html |
| Comments |
| Comment by Alex Yiu [ 25/Oct/07 10:20 AM ] |
|
Original proposal:
http://lists.oasis-open.org/archives/sca-bpel/200710/msg00038.html The proposal was amended by Mark Ford to change the wordings from "document order" to "lexical order". Amendment is seconded by Mike Pellegrini. Alex accepted the amendment as friendly. The amended proposal was accepted in the conf call on Oct 18, 2007. |
| Comment by Michael Rowley [ 25/Sep/08 09:52 AM ] |
|
Applied in revision 4 (2007-12-05)
Closed with acceptance of CD-01. |
[BPEL-7] Apply Editing Action Items 0001 - 0003
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: Apply Editing Action Items 0001 - 0003
STATUS: New SUBMITTED by: Dieter Koenig TARGET: SCA Client and Implementation Model Specification for WS-BPEL DESCRIPTION: Apply Editing Action Items 0001 - 0003, as noted in the F2F meeting: #0001 Editors: Refer to assembly and policy spec in the related spec section. Also, to add participants (TC) members list and the OSOA contributors list in the Acknowledgement (page 16) section #0002 Editors: Reference Section 1 (Page 2): Addition to reference element there should be a service element #0003 Editors: Update the syntax of Component in the introduction section to align with assembly syntax PROPOSAL: Re: #0001 In section "Related Work", add the following entries: SCA Assembly Model Specification - <link> SCA Policy Framework Specification - <link> In "Appendix A - Acknowledgements", add all TC members and OSOA contributors, as in: A.1 Members of the SCA-BPEL Technical Committee [Participant Name, Affiliation | Individual Member] ... A.2 OSOA Contributors [Participant Name, Affiliation | Individual Member] ... Re: #0002 and #0003 In "Chapter 1 - Introduction" - component example, add the <service> element and align with SCA-Assembly syntax, as in: <component name="xs:NCName" autowire="xs:boolean"? requires="list of xs:QName"? policySets="list of xs:QName"? constrainingType="xs:QName"?>* <implementation.bpel process="xs:QName"/> <service name="xs:NCName" requires="list of xs:QName"? policySets="list of xs:QName"?>* <interface/>? <binding uri="xs:anyURI"? requires="list of xs:QName"? policySets="list of xs:QName"? />* </service> <reference name="xs:NCName" multiplicity="0..1 or 1..1 or 0..n or 1..n" ? autowire="xs:boolean"? target="list of xs:anyURI"? wiredByImpl="xs:boolean"? requires="list of xs:QName"? policySets="list of xs:QName"?> * <interface/>? <binding uri="xs:anyURI"? requires="list of xs:QName"? policySets="list of xs:QName"? />* </reference> <property name="xs:NCName" (type="xs:QName" | element="xs:QName")? mustSupply="xs:boolean"? many="xs:boolean"? source="xs:string"? file="xs:anyURI"?>* property-value? </property> </component> http://lists.oasis-open.org/archives/sca-bpel/200709/msg00052.html |
| Comments |
| Comment by Alex Yiu [ 04/Oct/07 11:02 AM ] |
|
Michael Rowley: Motion moved to mark the issue (g) as resolved.
Dieter seconds. Motion passed. |
| Comment by Martin Chapman [ 05/Oct/07 10:23 AM ] |
| The status should be RESOLVED, LATER, and only changed to RESOLVED, FIXED when the editors have made the changes. |
| Comment by Dieter Koenig [ 11/Oct/07 10:30 AM ] |
| Fixed in working draft 3 - http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=25646 |
| Comment by Michael Rowley [ 25/Sep/08 09:55 AM ] |
|
Applied in revision 2 (2007-10-10)
Closed with acceptance of CD-01. |
[BPEL-8] Clarify what will be the version number of SCA BPEL TC's final output.
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: Clarify what will be the version number of SCA BPEL TC's final output.
SUBMITTED BY: Ivana Trickovic TARGET: SCA Client and Implementation Model Specification for WS-BPEL DESCRIPTION: Clarify what will be the version number of SCA BPEL TC's final output. PROPOSAL: none http://lists.oasis-open.org/archives/sca-bpel/200710/msg00005.html |
| Comments |
| Comment by Michael Rowley [ 25/Sep/08 10:13 AM ] |
| We decided on 1.1. |
[BPEL-9] SCA-BPEL XML Namespaces
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Sanjay Patil |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: SCA-BPEL XML Namespaces
SUBMITTED BY: Dieter Koenig TARGET: SCA Client and Implementation Model Specification for WS-BPEL - note that the SCA Assembly Model is also affected. DESCRIPTION: All SCA assembly model elements have a common namespace (currently "http://www.osoa.org/xmlns/sca/1.0" - which will change to an OASIS namespace - to be clarified with the SCA-Assembly TC and OASIS). This issue is about two SCA-BPEL areas that sould be separated from the common namespace. 1. For the SCA extensions (sca:property, sca:multiReference, etc.) in a WS-BPEL process, there is no point in having these extensions in a common schema with the SCA assembly model (processes and assemblies are disjoint artifacts). 2. The XML schema element "serviceReferenceList" introduced in the SCA-BPEL specification is neither an SCA assembly model nor a BPEL process model element and should be separated as well. PROPOSAL: Use separate XML namespaces for SCA and SCA-BPEL, e.g. something like this: SCA Assembly Model (to be verified) ==> http://docs.oasis-open.org/sca/1.1/assembly WS-BPEL 2.0 extensions for SCA ==> http://docs.oasis-open.org/sca/1.1/bpel/process Data element "serviceReferenceList" ==> http://docs.oasis-open.org/sca/1.1/bpel/types The SCA-BPEL TC may resolve this issue by separating these namespaces now, i.e. by using different prefixes, and aligning the namespace declarations with the SCA-Assembly TC and OASIS later. http://lists.oasis-open.org/archives/sca-bpel/200710/msg00027.html |
| Comments |
| Comment by Alex Yiu [ 08/Nov/07 02:22 PM ] |
|
Message from Sanjay Patil: Issue 9 was resolved on the Oct 18th conf-call [1]. Could you please update the JIRA accordingly. Thanks, Sanjay [1] http://lists.oasis-open.org/archives/sca-bpel/200710/msg00058.html |
| Comment by Alex Yiu [ 08/Nov/07 04:00 PM ] |
|
Message from Sanjay Patil: ============================ Hi Alex, I am sorry I gave you the incorrect reference of the meeting in which the Issue 9 was resolved. This issue was resolved in Oct 25th [1] meeting (and no Oct 18th). The resolution was: use http://docs.oasis-open.org/opencsa/sca-bpel/[yyyymm] for the new namespace Thanks, Sanjay [1] http://lists.oasis-open.org/archives/sca-bpel/200710/msg00059.html ============================ |
| Comment by Najeeb Andrabi [ 09/Jul/08 09:29 PM ] |
|
This issue resolution was applied in workign draft version 4:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/26339/sca-bpel-1.1-spec-WD-04.doc |
[BPEL-10] test issue please ignore
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Martin Chapman | Assigned To: | Anish Karmarkar |
| Resolution: | Applied | Votes: | 0 |
| Description |
|
testing the resolution/closed workflow
|
| Comments |
| Comment by Martin Chapman [ 11/Oct/07 10:29 AM ] |
| can we change from resolved, later to resolved, applied? |
| Comment by Martin Chapman [ 11/Oct/07 10:31 AM ] |
| edits applied now |
| Comment by Martin Chapman [ 18/Oct/07 07:46 AM ] |
| testing |
[BPEL-11] BPEL variable initialization and SCA properties
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: BPEL variable initialization and SCA properties SUBMITTED BY: Mark Ford TARGET: SCA Client and Implementation Model Specification for WS-BPEL DESCRIPTION: Is the target variable allowed to have an initialization defined within the BPEL process and if so, is this initialization ignored? It seems like the initialization should be allowed but not executed in the case where a process is packaged as an SCA and the property is provided by the component. It's probably also worth pointing out that the variable must be an element or type variable. Message variables cannot be initialized by an SCA property. http://lists.oasis-open.org/archives/sca-bpel/200710/msg00036.html |
| Comments |
| Comment by Alex Yiu [ 10/Jan/08 10:55 AM ] |
|
Proposal (by Michael Rowley):
------------------------------ If the variable has an initialization from-spec then that becomes the default value for the variable in cases where the SCA component does not provide a value for that property. If a value is provided for the property, the initialization from-spec MUST be evaluated, but the value of the variable will be changed to the value specified for the property on the component immediately after the initialization is evaluated (before any following variable initialization from-spec is evaluated). If the from-spec is a literal value, where it has the following form: <from><literal>literal value</literal></from> then the literal value will be represented as the default value in the component type for the process. Any other kind of initialization from-spec will not be represented in the component type. However, even though the other kinds of initialization from-spec are not represented in the component type, they would still be computed and used as the default value for the property when the component does not provide a value for that property. If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration. ------------------------------ |
| Comment by Michael Rowley [ 10/Jul/08 02:42 PM ] |
| Applied as of version 5, and later accepted into CD01. |
[BPEL-12] Long-Running Request-Response Operations
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: Long-Running Request-Response Operations
SUBMITTED BY: Dieter Koenig TARGET: SCA Client and Implementation Model Specification for WS-BPEL - note that a resolution will likely affect other SCA specifications. DESCRIPTION: Consider a WS-BPEL 2.0 process that implements a service containing a WSDL request-response operation, using an inbound message activity (<receive> or <pick>/<onMessage> or <eventHandlers>/<onEvent>) and a corresponding <reply> activity referencing this operation. Furthermore, assume that there are long-running activities between the inbound message activity and the <reply>. At this point in time, such long-running implementations of request-response operations are NOT SUPPORTED by SCA. As a result, the very first SCA-BPEL goal ("... use any valid WS-BPEL process definition as the implementation of a component within SCA") is NOT MET. Many concrete WS-BPEL scenarios involving such long-running request-response behavior EXIST TODAY - long interrupts may be caused by timer-driven activities and service invocations bound to asynchronous protocols or involving user interactions. Many of these long-running processes expose request-response operations as this is a more convenient modeling style, for example, when the business logic is structured in hierarchies of parent and sub-processes. SCA must support using such processes as implementations of SCA components. As an example, without loss of generality, consider the following very simple <sequence> containing a <wait> activity delaying the response by 14 days (of course, real-world processes would do useful work here instead of calling the <wait> activity :-) . <sequence> <receive ... operation="rrOperation" .../> <wait><for>'P14D'</for></wait> <reply ... operation="rrOperation" .../> </sequence> The SCA implementation as well as a caller of this operation should be made aware of the long-running behavior. Note that inspecting the process implementation is not sufficient as the long-running nature of activities may not be visible in the process model. Regardless of the structure of the SCA assembly (component/service directly/transitively wired within/across composites), an SCA implementation would want to execute calls to this operation using some asynchronous means internally. PROPOSAL: ********** To Be Discussed ********** A "longRunning" intent is introduced (policy-related details tbd.), which indicates the long-running behavior of an operation: <operation name="rrOperation" ... requires="sca:longRunning"/> Its runtime semantics are defined by the following naming convention - a request-response operation (with the "longRunning" intent): <wsdl:operation name="rrOperation" ...> <wsdl:input ... message="x:inputMessage"/> <wsdl:output ... message="x:outputMessage"/> <wsdl:fault name="fault1" message="x:fault1Message"/> <wsdl:fault name="fault2" message="x:fault2Message"/> ... </wsdl:operation> is executed AS IF it was specified as a one-way operation (delivering the request): <wsdl:operation name="rrOperationRequest" ...> <wsdl:input ... message="x:inputMessage"/> </wsdl:operation> AND a set of one-way callback operations (delivering the response or fault): <wsdl:operation name="rrOperationResponse" ...> <wsdl:input ... message="x:outputMessage"/> </wsdl:operation> <wsdl:operation name="rrOperationFault1" ...> <wsdl:input message="x:fault1Message"/> </wsdl:operation> <wsdl:operation name="rrOperationFault2" ...> <wsdl:input message="x:fault2Message"/> </wsdl:operation> ... This naming convention enables an SCA implementation to execute a long-running request-response operation in exactly the same way as the corresponding one-way operations defined in a bidirectional interface. All existing SCA means (Java APIs etc.) for bidirectional interfaces can be reused and no new APIs are required. The following rules apply to SCA services and references: (1) Attach a "longRunning" intent to a request-response operation in a component's service if and only if its implementation exposes the long-running behavior described above. (2) Attach a "longRunning" intent to a request-response operation in a component's reference if and only if its invocation exposes the long-running behavior described above. (3) Interfaces of references and services are considered compatible (eligible for wiring) if both sides match w.r.t. the "longRunning" intent on their contained operations. |
| Comments |
| Comment by Alex Yiu [ 06/Dec/07 10:17 AM ] |
|
BPEL-12 ("Long-Running Request-Response Operations") has now been opened in the SCA-Assembly TC as |
| Comment by Anish Karmarkar [ 19/Feb/09 05:31 PM ] |
|
Resolved at the 2009-02-19 call http://lists.oasis-open.org/archives/sca-bpel/200902/msg00024.html with the resolution text (allowing for ed changes):
Note: The assembly spec defines a "asyncInvocation" policy intent for long-running operation. BPEL processes that implement a long-running req-res operation are encouraged to mark the interface with this intent |
| Comment by Anish Karmarkar [ 26/Feb/09 07:38 PM ] |
| Applied in CD01-rev16 http://www.oasis-open.org/committees/download.php/31438/sca-bpel-1.1-spec-cd-01-rev16.doc |
[BPEL-13] ComponentType should not contain implementation.bpel
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: ComponentType should not contain implementation.bpel
SUBMITTED BY: Anish Karmarkar TARGET: SCA Client and Implementation Model Specification for WS-BPEL DESCRIPTION: Section which describes the component Type associated with a BPEL process has a schema snippet that contains <implementation.bpel>. A Component type should not contain this, this belongs to the component. PROPOSAL: Replace <implemenation.bpel> with <service>, <reference> and <property> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00004.html |
| Comments |
| Comment by Alex Yiu [ 29/Nov/07 10:41 AM ] |
|
Copied from the chat room minute:
------------------------------------ Ashok Malhotra1: Issue 13 anish: http://www.osoa.org/jira/browse/BPEL-13 Ashok Malhotra1: Anish: This is a cut and paste error charlton: +1 to Dieter Ashok Malhotra1: Anish: Straightforward typo we need to fix. charlton: (thanks Ashok) Ashok Malhotra1: Deiter moves, Ashok seconds Ashok Malhotra1: Agreed to fix typo with no objection ------------------------------------ |
| Comment by Najeeb Andrabi [ 09/Jul/08 09:24 PM ] |
|
This issue resolution was applied in workign draft version 4:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/26339/sca-bpel-1.1-spec-WD-04.doc |
[BPEL-14] Allow sca-aware processes to specify everything that can be specified in a CT side file
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Title: Allow sca-aware processes to specify everything that can be specified in a CT side file
Submitted by: Anish Karmarkar http://lists.oasis-open.org/archives/sca-bpel/200711/msg00005.html Target: BPEL C&I spec Description: The spec allows one to specify a SCA property and multi-ref in a BPEL process. It should be possible to configure a SCA component without requiring a component Type side file. For example, this is true of Java. This would make the component type side file optional for sca-aware processes. Proposal: <none> |
| Comments |
| Comment by Michael Rowley [ 27/Mar/08 10:58 AM ] |
|
Resolved on 03-27 based on the changed markings in CD01-Rev1:
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/27734/sca-bpel-1.1-spec-cd-01-rev1.doc |
| Comment by Michael Rowley [ 01/May/08 10:37 AM ] |
|
Reopened on 4/17/2008. |
| Comment by Michael Rowley [ 01/May/08 11:07 AM ] |
|
Decided on 5/1/2008: Accept definition of SCA:requires as it is defined in the current spec i.e. in the same namespace as the other BPEL extension attributes (which is different from the SCA Assembly namespace). |
| Comment by Michael Rowley [ 25/Sep/08 09:59 AM ] |
| Applied in rev 8 and 9 (2008-03-27 & 22008-04-10) |
[BPEL-15] Define Conformance Targets
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TITLE: Define Conformance Targets SUBMITTED BY: Martin Chapman TARGET: SCA BPEL C+I Specification DESCRIPTION: In order to write a normative statement or conformance clause using RFC2119 language, the target or subject of the rule needs to be included. Some of these are obvious, as we have rules governing components, composites, services, references etc. Other targets are less so, especially when it comes to conformance, as we need to identify artefacts that vendors can claim they handle according to the rules of the spec. We should enumerate a list of conformance targets early on, so that every time we use a MUST, MAY, or SHOULD, we know to what the rule applies to. PROPOSAL: none http://lists.oasis-open.org/archives/sca-bpel/200711/msg00028.html |
| Comments |
| Comment by Michael Rowley [ 29/May/08 10:26 AM ] |
|
Resolved on the call of 22-May-2008
http://lists.oasis-open.org/archives/sca-bpel/200805/msg00023.html The resolution adopted the following proposal ------------------------- The Liaison SC agreed the following recommendation: "Conformance targets can be categorized into 1) document artifacts (or constructs within them) that can be checked statically. 2) SCA runtimes, which we may require to exhibit certain behaviors. " Therefore in the SCA BPEL C+I spec we can talk about SCA documents (scdl), BPEL documents, and runtimes. Specifically I propose the following conformance targets, in addition to any targets defined by Assembly: WS-BPEL Process: as defined in WS-BPEL 2.0. An unmodified (from and SCA perspective) process description. SCA WS-BPEL Process: a WS-BPEL 2.0 process that uses the SCA specific BPEL extensions. SCA WS-BPEL Runtime: derived from "SCA Runtime" in the Assembly spec and "WS-BPEL processor" in WS-BPEL 2.0. |
| Comment by Michael Rowley [ 11/Sep/08 10:25 AM ] |
| Closed by resolution on 2008-09-11. No changes to the spec are required. |
[BPEL-16] Ambigous Service Resolution
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
TITLE: Ambigous Service Resolution SUBMITTED BY: Dieter Koenig Target: BPEL C&I spec Email link: http://lists.oasis-open.org/archives/sca-bpel/200712/msg00002.html (The SCA-Assembly TC has decided to let this issue be discussed in the SCA-BPEL TC first.) ------------------------------------------------------- Reference: Original issue ------------------------------------------------------- TARGET: SCA-BPEL (at least as a starting point). DESCRIPTION: WS-BPEL processes may assign an EPR (pointing to themselves) to a variable in order to e.g. pass it as a callback EPR to another service partner: <assign> <copy> <from partnerLink="NCName" endpointReference="myRole" /> <to variable="BPELVariableName" /> </copy> </assign> If the component's interface (the WSDL port type referenced by the WS-BPEL partner link type) is exposed as a service multiple times (e.g. with different bindings or with different policies) then it is not clear which of these service endpoints should be used to create the EPR. The WS-BPEL runtime is not able to make this decision. PROPOSAL: None so far. |
| Comments |
| Comment by Michael Rowley [ 29/May/08 11:00 AM ] |
|
Closed with no action on 29-May-2008.
See slides in email at: http://lists.oasis-open.org/archives/sca-bpel/200805/msg00026.html |
[BPEL-17] Allow Component Type side file to override defaults for service/reference
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Target: BPEL C&I Spec Submitted by: Anish Karmarkar Title: Allow Component Type side file to override defaults for service/reference Description: One use of CT side files is to override defaults used for figuring out what is a service v. reference. It should be possible to specific whether a partnerlink is a service or a reference using the CT side file. Proposal: Two possible solutions are: 1) extend the CT syntax to specific the partnerlink for a service/reference 2) require that a service/reference name specified in the CT side file correspond to the partnerlink name. http://lists.oasis-open.org/archives/sca-bpel/200801/msg00021.html |
| Comments |
| Comment by Michael Rowley [ 28/Feb/08 10:47 AM ] |
|
On the SCA-BPEL TC call of 2008-02-28 we resolved that the following text will be used as the resolution of this issue, if the SCA Assembly specification adopts the @implementationRef attribute that has been proposed:
The @implementationRef attribute MUST contain a valid XPath 1.0 expression, which when executed on a BPEL process returns exactly one <partnerLink> element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the @implementationRef attribute. If a service or reference does not have an @implementationRef attribute, then it will act as if it had @implementationRef=//partnerLink[@name=$name], where $name is the value of the @name attribute of that service or reference. |
| Comment by Sanjay Patil [ 30/Apr/08 01:01 PM ] |
|
Corresponding Assembly TC Issue: |
| Comment by Anish Karmarkar [ 23/Jun/08 06:32 PM ] |
| Assembly-52 was closed by the SCA Assembly TC with no action |
| Comment by Michael Rowley [ 10/Jul/08 02:37 PM ] |
|
Resolution accepted on 2008-07-10:
An @sca-bpel:implementationRef attribute on a component type's service or reference MUST contain a valid XPath 1.0 expression, which when executed on a BPEL process returns exactly one <partnerLink> element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the @sca-bpel:implementationRef attribute. If a service or reference does not have an @sca-bpel:implementationRef attribute, then it will act as if it had @sca-bpel:implementationRef=//partnerLink[@name=$name], where $name is the value of the @name attribute of that service or reference. |
[BPEL-18] Need to rewrite the SCA-BPEL specifications with RFC-2119 keywords/statements
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Yiu | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TITLE: Need to rewrite the SCA-BPEL specifications with RFC-2119 keywords/statements TARGET: SCA BPEL Specification SUBMITTED BY: KHANDERAO KAND DESCRIPTION: As discussed during initial meetings we need to use RF-2119 words for normative statements. As discussed in the context of Issue # 15, such normative statements would potentially be target for defining conformance. PROPOSAL: Recommend an action item to editors to rewrite the specifications with RFC-2119 http://lists.oasis-open.org/archives/sca-bpel/200801/msg00044.html |
| Comments |
| Comment by Michael Rowley [ 25/Sep/08 10:44 AM ] |
|
On 2008-09-25 we resolved how we will talk about component types as part of RFC 2119 rules.
The proposal that was accepted is here: http://lists.oasis-open.org/archives/sca-bpel/200809/msg00019.html |
| Comment by Anish Karmarkar [ 06/Feb/09 07:08 PM ] |
|
Partial resolution for this issue was accepted on the 2009-02-05 telcon. The resolution was to accept the changes in http://www.oasis-open.org/committees/download.php/31061/sca-bpel-1.1-spec-cd-01-rev14.doc
|
| Comment by Michael Rowley [ 12/Feb/09 11:00 AM ] |
| Actually, this isn't resolved yet. We will be voting on this at the meeting on 19 Feb. |
| Comment by Anish Karmarkar [ 19/Feb/09 05:29 PM ] |
|
Resolved at the 2009-02-19 call http://lists.oasis-open.org/archives/sca-bpel/200902/msg00024.html
The resolution is also applied in cd01-rev 15 http://www.oasis-open.org/committees/download.php/31120/sca-bpel-1.1-spec-cd-01-rev15.doc |
[BPEL-19] SCA-BPEL XML Schema
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Dieter Koenig | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
RAISER: Dieter Koenig
TARGET: SCA Client and Implementation Model Specification for WS-BPEL - Committee Draft 01. DESCRIPTION: The SCA-BPEL XML Schema (namespace " http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801") is missing. Moreover, a number of minor XML Schema related changes are needed - see (1) - (4) in the proposal below. PROPOSAL: The XML Schema for the SCA-BPEL constructs needs to be made available as a standalone artifact (see attached file) and as an Appendix chapter in the spec - see below, something along the lines of the following ... (See attached file: sca-bpel.xsd) A. XML Schema <?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) OASIS Open 2008. All Rights Reserved. --> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" xmlns:sca-bpel="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:sref="http://docs.oasis-open.org/wsbpel/2.0/serviceref" elementFormDefault="qualified"> <!-- WS-BPEL 2.0 XML Schema for Executable Processes --> <import namespace=" http://docs.oasis-open.org/wsbpel/2.0/process/executable" schemaLocation=" http://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd "/> <!-- WS-BPEL 2.0 XML Schema for Service References --> <import namespace="http://docs.oasis-open.org/wsbpel/2.0/serviceref" schemaLocation=" http://docs.oasis-open.org/wsbpel/2.0/OS/serviceref/ws-bpel_serviceref.xsd "/> <!-- WS-BPEL extension attribute for a variable representing an SCA property --> <attribute name="property" type="bpel:tBoolean"/> <!-- WS-BPEL extension element for a variable representing an SCA multi-valued reference --> <element name="multiReference"> <complexType> <simpleContent> <extension base="string"> <attribute name="partnerLinkType" type="QName"/> <attribute name="partnerRole" type="NCName"/> <attribute name="multiplicity" type="sca-bpel:Multiplicity" use="optional" default="1..n"/> </extension> </simpleContent> </complexType> </element> <simpleType name="Multiplicity"> <restriction base="string"> <enumeration value="0..n"/> <enumeration value="1..n"/> </restriction> </simpleType> <!-- WS-BPEL extension attribute for a partner link associated with an SCA multi-valued reference --> <attribute name="multiRefFrom" type="bpel:BPELVariableName"/> <!-- XML Schema element representing an SCA multi-valued reference --> <element name="serviceReferenceList"> <complexType> <sequence> <element ref="sref:service-ref" minOccurs="0" maxOccurs=" unbounded"/> </sequence> </complexType> </element> </schema> In addition, the following changes should be made in the spec: (1) The SCA-BPEL namespace on line 195 is wrong, it should be: <extension namespace=" http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" instead of <extension namespace="http://www.osoa.org/xmlns/sca/bpel/1.0" (2) The XML Schema syntax for the serviceReferenceList (lines 250-257) definition should have the orange background (used for syntax) instead of the grey background (used for examples). (3) The multiRefFrom attribute should reuse the type defined for BPEL variable names - in line 266, use <partnerLink ... sca-bpel:multiRefFrom="bpel:BPELVariableName" /> instead of <partnerLink ... sca-bpel:multiRefFrom="xs:NCName" /> (4) The BPEL service-ref element is defined in the namespace associated with the prefix "sref:", so the XPath expression in line 288 should be count($vendors/sref:service-ref) instead of count($vendors/bpel:service-ref) and in line 301 <from>$vendors/sref:service-ref[$idx]</from> instead of <from>$vendors/bpel:service-ref[$idx]</from> |
| Comments |
| Comment by Michael Rowley [ 17/Apr/08 10:22 AM ] |
|
Resolved by adding the appropriate schema definitions to the spec.
|
[BPEL-20] SCA-BPEL spec can not require bpel:mustUnderstand to be true
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: Section 3 currently reads as follows: --------- It is possible to use WS-BPEL processes in conjunction with SCA, while the processes have no knowledge of SCA. A few SCA concepts are only available to WS-BPEL processors that support SCA specific extensions. The capabilities that require knowledge of SCA are provided by an SCA extension, which must be declared in any process definition as follows: <process ...> <extensions> <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" mustUnderstand="yes" /> </extensions> ... </process> --------- This is too restrictive. There should be no requirement on the value of bpel:mustUnderstand. Let's examine what the attribute actually means. From section 14 of the BPEL spec itself: ------- If a WS-BPEL processor does not support one or more of the extensions with mustUnderstand="yes", then the process definition MUST be rejected. Optional extensions are extensions which the WS-BPEL process MAY ignore. There is no requirement to declare any optional extensions. Optional extension can be declared using the extensions element with mustUnderstand="no". The purpose of allowing optional extensions to be declared using the extensions element is to provide a well defined location where additional information about the optional extension can be found. ------- Reading the current language of both specifications, consider the following edge case: <process...> <extensions> <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" mustUnderstand="yes" /> <extensions/> ... a process where NO items from the sca-bpel namespace are used ... OR ... a process where sca-bpel items are used, but the processor need not know about them in order to run ... </process> In this case, a "vanilla" BPEL processor will process the file with no issue. An SCA-BPEL processor MUST reject the process as invalid, since the requirement in section 3 is not followed. This is not correct behavior. SCA-BPEL processors must accept a superset of what BPEL processors can process. To do otherwise would introduce a nightmare of compatibility issues. PROPOSAL: change the wording in Section 3 to read as follows It is possible to use WS-BPEL processes in conjunction with SCA, while the processes have no knowledge of SCA. A few SCA concepts are only available to WS-BPEL processors that support SCA specific extensions. The capabilities that require knowledge of SCA are provided by an SCA extension, whose namespace is "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801". An example of using the namespace in a BPEL process is as follows: <process ...> <extensions> <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" mustUnderstand="yes" /> </extensions> ... </process> |
| Comments |
| Comment by Michael Rowley [ 29/May/08 10:42 AM ] |
|
Resolved at meeting: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/28377/2008-05-15.html
Resolution: It is possible to use WS-BPEL processes in conjunction with SCA, while the processes have no knowledge of SCA. A few SCA concepts are only available to WS-BPEL processors that support SCA specific extensions. The capabilities that require knowledge of SCA are provided by an SCA extension, whose namespace is "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801". Whether this extension is mandatory or optional is specified by the mustUnderstand attribute as described in [section 14 of bpel spec]. An example, where the SCA extension is mandatory, is as follows: <process ...> <extensions> <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" mustUnderstand="yes" /> </extensions> ... </process> |
| Comment by Martin Chapman [ 05/Sep/08 09:24 AM ] |
| Applied to CD-01-rev10: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/29222/sca-bpel-1%5B1%5D.1-spec-cd-01-rev10.doc |
[BPEL-21] BPEL SCA extension NS, what should be the value of mustUnderstand?
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Raiser: Anish Karmarkar Target: BPEL C&I spec Description: In the BPE C&I spec we define the namespace "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801", this namespace contains BPEL extensions for SCA. For BPEL extensions, a mustUnderstand attribute is specified as follows: <extensions> <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" mustUnderstand="[yes|no]" /> </extensions> This attribute tells the BPEL processor whether it is necessary to understand the extension. There are two issues here: 1) Since the granularity of MU is at the namespace level, does it make sense to bundle all our extensions attributes in a single NS? 2) Does this mean that the 'requires' attribute that we intend to use for intents in a BPEL process be part of "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" or can it be part of "http://docs.oasis-open.org/ns/opencsa/sca/200712"? Proposal: I don't think we need a finer granularity. It is possible that in a certain BPEL process, it is ok to ignore the sca:service attribute but not the sca:property attribute. But this is about 'understanding' the extension, if a BPEL processor understands sca:service it must also understand sca:property and vice versa. It can't choose to understand only part of the C&I. WRT requires attribute, I prefer to not copy it from the main SCA NS into BPEL NS. There are three potential problems with having two extension namespaces: 1) it is now possible that in a particular process, one of the namespaces is MU='yes' and the other is MU='no'. We should disallow that. 2) it is now possible that a BPEL process may contain a sca attribute/element from the main SCA NS whose use is not defined by the BPEL C&I. For example, what does it mean for the 'autowire' attribute or sca:binding element to appear in the BPEL process. We should disallow that. 3) 'requires' attribute is not currently defined as a global attribute in the main SCA namespace. This will have to change. Alternately, we can copy the requires attribute into the SCA BPEL NS, but this adds the burden of keeping them in sync. |
| Comments |
| Comment by Michael Rowley [ 29/May/08 10:48 AM ] |
|
Resolved at meeting: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/28358/2008-05-08.html
Resolution: Close with no action (although the resolution of issue 20 may be relevant). |
| Comment by Michael Rowley [ 29/May/08 10:51 AM ] |
|
No action.
See issue 20. |
[BPEL-22] Include mapping of interface.partnerLinkType to interface.wsdl
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Target: BPEL C&I Description: The BPEL C&I spec defines a new interface type called interface.partnerLinkType in section 2.3. That section also says: "This form does not provide any more information than is present in the <interface.wsdl> element." It is quite possible that services and references of a component that uses implementation.bpel and interface.partnerLinkType may be wired to components that have interface.wsdl. The BPEL C&I spec should specific how to generate an equivalent interface.wsdl from a interface.partnerLinkType. Proposal: Something along the lines of: A partnerLinkType that has only one role: The equivalent interface.wsdl will be a non-callback interface. The interface.wsdl's 'interface' attribute will point to the same portType as the one pointed to by plnk:partnerLinkType/plnk:role/plnk:portType/@name attribute. Note that partnerLinkType points to the portType's QNames whereas interface.wsdl uses the URL of the form <target-NS>#wsdl.interface(...). A partnerLinkType that has two roles: The equivalent interface.wsdl will be a callback interface. The forward interface will have the same portType as the one pointed to by the partnerLinkType role whose @name attribute value matches that of the @serviceRole attribute. The callback interface be the portType that is not assigned to the forward interface. |
| Comments |
| Comment by Michael Rowley [ 06/Nov/08 11:02 AM ] |
|
Resolved on Oct 30 with the following resolution:
Resolve issue 22 by removing the concept of interface.partnerLinkType from the spec. |
[BPEL-23] Additional Integrity Constraints for SCA Extensions to WS-BPEL
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Dieter Koenig | Assigned To: | Dieter Koenig |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TARGET: SCA Client and Implementation Model Specification for WS-BPEL, Chapter 3 "SCA Extensions to WS-BPEL" DESCRIPTION: Chapters 3.2 and 3.3 of the SCA-BPEL spec introduce several SCA extensions to WS-BPEL partner links. The sca-bpel:multiRefFrom and sca-bpel:reference attributes are only meaningful for partner links used in outbound interactions. Conversely, the sca-bpel:service attribute is only meaningful for partner links used in inbound interactions. PROPOSAL: Add normative constraints to chapter 3 in order to avoid contradicting (and therefore useless) partner link attribute specifications. Add the following to section 3.2: "The sca-bpel:multiRefFrom attribute MUST not be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type. Furthermore, sca-bpel:multiRefFrom attribute MUST not be specified for a partner link that has the sca-bpel:service attribute." Add the following to section 3.3: "The sca-bpel:service attribute MUST not be specified for a partner link with a partnerRole attribute referencing a role which is the only role of a partner link type." and "The sca-bpel:reference attribute MUST not be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type." |
| Comments |
| Comment by Michael Rowley [ 23/Oct/08 10:46 AM ] |
|
Resolved according to the proposal in the issue on the call of 23-Oct-2008.
|
[BPEL-24] BPEL C&I spec needs to define how effective CT is synthesized
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Target: BPEL C&I spec Description: Assembly TC resolved issue 36 [1] with the following resolution: ----- Component type represents the configurable aspects of an implementation. A component type consists of services that are offered, references to other services that can be wired and properties that can be set. The settable properties and the settable references to services are configured by a component that uses the implementation. An implementation type specification (for example, the WS-BPEL Client and Implementation Specification Version 1.1 [ref]) specifies the mechanism(s) by which the component type associated with an implementation of that type is derived. Since SCA allows a broad range of implementation technologies, it is expected that some implementation technologies (for example, the Java Client and Implementation Specification Version 1.1 [ref]) allow for introspecting the implementation artifact(s) (for example, a Java class) to derive the component type information. Other implementation technologies might not allow for introspection of the implementation artifact(s). In those cases where introspection is not allowed, SCA encourages the use of a SCA component type side file. A component type side file is an XML file whose document root element is sca:componentType. The implementation type specification defines whether introspection is allowed, whether a side file is allowed, both are allowed or some other mechanism specifies the CT. The component type information derived through introspection is called the 'introspected component type'. In any case, the implementation type specification specifies how multiple sources of information are combined to produce the 'effective component type'. The effective component type is the component type metadata that is presented to the using Component for configuration. The extension of a componentType side file name MUST be .componentType. The name and location of a componentType side file, if allowed, is defined by the implementation type specification. If a component type side file is not allowed for a particular implementation type, the effective component type and introspected component type are one and the same for that implementation type. For the rest of this document, when the term 'component type' is used it refers to the 'effective component type'. ----- This puts requirements on C&I wrt defining whether side files are allowed, how they interact with introspected CT and how effective CT is synthesized. We need to define these things in the C&I. Proposal: None at this point. |
| Comments |
| Comment by Michael Rowley [ 15/Jan/09 10:52 AM ] |
|
Resolved with the following proposal:
Remove section 2.5 Component Type Side Files. Introspection must be used. If someone wants to modify what is generated, they can wrap it in a composite file. |
| Comment by Anish Karmarkar [ 26/Feb/09 07:43 PM ] |
| Resolved on the 2009-01-15 call |
[BPEL-25] Additional Integrity Constraints for Component Type Side Files
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Dieter Koenig | Assigned To: | Dieter Koenig |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
TARGET: SCA Client and Implementation Model Specification for WS-BPEL
(sca-bpel-1.1-spec-cd-01-rev13.doc) DESCRIPTION: Section 2.6 "Hand-Generated Component Type Files" (in the Nov 20 TC call renamed to "Component Type Side Files") describes how service and reference definitions in a component type side file may use the sca-bpel:implementationRef attribute for identifying a BPEL partner link. Similar to the situations resolved with Issue 23, this section also allows useless combinations: (a) A service may have an sca-bpel:implementationRef attribute referencing a BPEL partner link that has no inbound role. (b) A reference may have an sca-bpel:implementationRef attribute referencing a BPEL partner link that has no outbound role. PROPOSAL: Add normative constraints to this section in order to avoid such useless specifications. "A service MUST NOT identify a partner link with a partnerRole attribute referencing a role which is the only role of a partner link type." and "A reference MUST NOT identify a partner link with a myRole attribute referencing a role which is the only role of a partner link type." |
| Comments |
| Comment by Anish Karmarkar [ 14/Jan/09 06:10 PM ] |
| Accepted on 2008-12-11 http://lists.oasis-open.org/archives/sca-bpel/200901/msg00006.html |
| Comment by Anish Karmarkar [ 14/Jan/09 06:11 PM ] |
| Accepted the proposal in JIRA on 2008-12-11 http://lists.oasis-open.org/archives/sca-bpel/200901/msg00006.html |
[BPEL-26] Removal of XPath 1.0 query language constraint on implementationRef attriibute.
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Najeeb Andrabi | Assigned To: | Najeeb Andrabi |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
TARGET: SCA Client and Implementation Model Specification for WS-BPEL
(sca-bpel-1.1-spec-cd-01-rev13.doc) DESCRIPTION: Section 2.6 "Hand-Generated Component Type Files" (in the Nov 20 TC call renamed to "Component Type Side Files") puts a constraint on the implementationRef attribute to always use XPath 1.0 as the query language. This restricts forward mobility of the "SCA client and Implementation Model Specification for WS-BPEL" as it requires that if XPath 2.0 becomes the defacto standard for query languages or a new query language emerges, an update or a new version of this specification has to be released. PROPOSAL: Change implementationRef attribute to an element that defines an attribute for the query language used. The schema for this element will be similar to the query element defined in WS-BPEL 2.0 specification. Change text in section 2.6 so that it describes implementationRef as an element rather than as an attribute. Change "The corresponding partner link is determined by either the value of the sca-bpel:implementationRef attribute or the value of the name attribute, if no sca-bpel:implementationRef attribute is present.The @sca-bpel:implementationRef attribute MUST contain a valid XPath 1.0 expression, which when executed on a BPEL process returns exactly one <partnerLink> element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the @sca-bpel:implementationRef attribute. If a service or reference does not have an @sca-bpel:implementationRef attribute, then it will act as if it had @sca-bpel:implementationRef=//partnerLink[@name="{name}"], where {name} is the value of the @name attribute of that service or reference." to "The corresponding partner link is determined by either the value of the sca-bpel:implementationRef element or the value of the name attribute, if no sca-bpel:implementationRef element is present. sca-bpel:implementationRef element provides the ability to override the default query language. sca-bpel:implementationRef element MUST support the use of [XPath 1.0] as the query language. XPath 1.0 is indicated by the default value of the queryLanguage attribute, which 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 @sca-bpel:implementationRef element MUST contain a valid query in the specified query language, which when executed against the BPEL <process> returns exactly one <partnerLink> element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the sca-bpel:implementationRef element. If a service or reference does not have an sca-bpel:implementationRef element, then it will act as if it had an element having a value in default XPath 1.0 expression language <sca-bpel:implementationRef>//partnerLink[@name="{name}"]</sca-bpel:impl ementationRef>, where {name} is the value of the @name attribute of that service or reference. " Change schema in Section 5.A XML Schemas "XML Schema for SCA-BPEL Extensions of WS-BPEL 2.0" <attribute name="implementationRef" type="xsd:string" /> to <xsd:element name="implemetationRef" type="sca:tImplementationRef"/> <xsd:complexType name="tImplementationRef" mixed="true"> <xsd:sequence> <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="queryLanguage" type="xsd:anyURI" default= "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"/> <xsd:anyAttribute namespace="##other" processContents="lax"/> </xsd:complexType> </xsd:element> Also, the SCA Liaison subcommittee should push for adopting this query language scheme across the C+Is. |
| Comments |
| Comment by Anish Karmarkar [ 14/Jan/09 06:14 PM ] |
|
Issue opened during the 2009-01-08 call
http://lists.oasis-open.org/archives/sca-bpel/200901/msg00005.html |
| Comment by Michael Rowley [ 12/Feb/09 10:53 AM ] |
| No action. |
[BPEL-27] Complete the Conformance Section
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised by: Martin Chapman
Title: Complete the Conformance Section Target: BPEL C&I Description: The latest revision of the spec (http://www.oasis-open.org/committees/download.php/29852/sca-bpel-1.1-spec-cd-01-rev13.doc) has a "TBD" under the conformance section. The TBD needs to be replaced with text that defines what vendors and possibly users (process writers) must do to conform to the SCA BPEL spec. There may be multiple conformance points that vendors may conform to. For example we may not require all vendors to support the sca extensions in one conformance point, and just allow them to execute plain old ws-bpel in an sca environment according to spec. Proposal: None |
| Comments |
| Comment by Michael Rowley [ 26/Feb/09 11:43 AM ] |
|
Resolved on Feb 26 with http://lists.oasis-open.org/archives/sca-bpel/200902/msg00029.html
|
| Comment by Anish Karmarkar [ 26/Feb/09 07:46 PM ] |
| Resolution applied in http://www.oasis-open.org/committees/download.php/31438/sca-bpel-1.1-spec-cd-01-rev16.doc |
[BPEL-28] Assembly has removed the conversational interface feature
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Title: Assembly spec has removed the conversational interface feature
Target: SCA BPEL spec Description: See http://lists.oasis-open.org/archives/sca-bpel/200901/msg00019.html Proposal: Remove section 2.4 Support for conversational interfaces [Do we still need Appendix C if 2.4 is removed?] |
| Comments |
| Comment by Anish Karmarkar [ 04/Feb/09 05:51 PM ] |
| Original email @ http://lists.oasis-open.org/archives/sca-bpel/200902/msg00000.html |
| Comment by Anish Karmarkar [ 19/Feb/09 05:25 PM ] |
| Issue opened at the 2009-02-19 call http://lists.oasis-open.org/archives/sca-bpel/200902/msg00024.html |
| Comment by Michael Rowley [ 26/Feb/09 11:49 AM ] |
|
Resolved on Feb 26, with a decision to delete section 2.4 and appendix section titled "Non-Normative Text"
|
| Comment by Anish Karmarkar [ 26/Feb/09 07:46 PM ] |
| Resolution applied in http://www.oasis-open.org/committees/download.php/31438/sca-bpel-1.1-spec-cd-01-rev16.doc |
[BPEL-29] BPEL1001 is an incorrect normative statement
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
The "MUST" in the statement is placing a constraint that shouldn't be made. It currently says: "When an SCA composite file contains a component whose implementation is a WS-BPEL process according to this specification, then the component MUST specify an <implementation.bpel> element with a process attribute." |
| Comments |
| Comment by Michael Rowley [ 26/Feb/09 11:47 AM ] |
|
Resolved on Feb 26. The normative assertion BPEL1001 will be removed. The specification text will be replaced to say:
"For an SCA component to use a WS-BPEL process as an implementation, it uses an <implementation.bpel/> element:" |
| Comment by Anish Karmarkar [ 26/Feb/09 07:47 PM ] |
| Resolution applied in http://www.oasis-open.org/committees/download.php/31438/sca-bpel-1.1-spec-cd-01-rev16.doc |
[BPEL-30] Schema contains ##any for
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Title: Schema contains ##any for <anyAttribute>
Description: Filed by Anish at: http://lists.oasis-open.org/archives/sca-bpel/200903/msg00059.html The <implementation.bpel> element schema has: <anyAttribute namespace="##any" processContents="lax" /> To keep the schemas aligned with all the other SCA TCs, adhere to previous decisions in assembly (and in BPEL) TC, and the fact that we decided to use a single NS/effective schema for all SCA TCs means that this has to be changed to say "##other" Proposal: Replace the above line with: <anyAttribute namespace="##other" processContents="lax" /> |
| Comments |
| Comment by Michael Rowley [ 02/Apr/09 10:19 AM ] |
|
Resolved on TC call of April 2, 2009 according to the proposal in the issue.
|
| Comment by Anish Karmarkar [ 24/Jun/09 06:51 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-31] SBPEL3011 Assertion needs to be clarified
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
The assertion: [SBPEL3011] The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched. is vague. Proposal: It should be changed to the following: [SBPEL3011] The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>. |
| Comments |
| Comment by Michael Rowley [ 02/Apr/09 10:45 AM ] |
|
Opened and resolved, according to the proposal in the issue, on the TC call of 02 April 2009. |
| Comment by Anish Karmarkar [ 24/Jun/09 06:51 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-32] SBPEL3011 Assertion needs to be clarified
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
The assertion:
[SBPEL3011] The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched. is vague. Proposal: It should be changed to the following: [SBPEL3011] The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>. |
| Comments |
| Comment by Anish Karmarkar [ 02/Apr/09 07:39 PM ] |
| Duplicate of issue 31 |
[BPEL-33] SBPEL3013 and SBPEL3014 use of RFC2119 'MAY' incorrectly
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Use of 'MAY' in SBPEL3013 and SBPEL3014 incorrect.
Proposal: Use alternative wording for RFC 2119 'MAY' e.g. 'can'. |
| Comments |
| Comment by Anish Karmarkar [ 02/Apr/09 07:42 PM ] |
| Raised and opened during the 2009-04-02 call |
| Comment by Anish Karmarkar [ 23/Apr/09 02:17 AM ] |
|
Resolved during the 2009-04-09 call (http://lists.oasis-open.org/archives/sca-bpel/200904/msg00035.html) with the following:
1) Replacing [SBPEL3013] with A WS-BPEL process definition can override the default mapping of partner links to services or references as described in section 2.1 by explicitly marking the partner link with an SCA attribute that describes the service or reference 2) Changing [SBPEL3014] to: To explicitly map a partner link to a service, the sca-bpel:service attribute MUST be specified for the partner link |
| Comment by Anish Karmarkar [ 24/Jun/09 06:55 PM ] |
| Applied in http://www.oasis-open.org/committees/document.php?document_id=32011 |
[BPEL-34] Incorrect uses of RFC 2119 'MAY' in SBPEL3017
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised by Sanjay Patil @ http://lists.oasis-open.org/archives/sca-bpel/200904/msg00015.html
Title: Incorrect uses of RFC 2119 'MAY' in SBPEL3017 Target: SCA BPEL spec Description: The RFC 2119 guideline for using the word 'MAY' is: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. SBPEL3017 reads as: To explicitly map a partner link to a reference, the sca-bpel:reference attribute MAY be specified for the partner link. The word 'MAY' in this statement is intended to point out a feature that is available for users of the products implementing the specification and is not intended to point out the optionality from a vendor implementation point of view. Proposal: Change SBPEL3017 to read as: To explicitly map a partner link to a reference, the sca-bpel:reference attribute is specified for the partner link. |
| Comments |
| Comment by Anish Karmarkar [ 23/Apr/09 02:18 AM ] |
| Opened on the 2009-04-09 call http://lists.oasis-open.org/archives/sca-bpel/200904/msg00035.html |
| Comment by Anish Karmarkar [ 23/Apr/09 02:19 AM ] |
|
Resolved on the 2009-04-09 call http://lists.oasis-open.org/archives/sca-bpel/200904/msg00035.html with the following:
"To explicitly map a partner link to a reference, the sca-bpel:reference attribute MUST be specified for the partner link. " |
| Comment by Anish Karmarkar [ 24/Jun/09 06:55 PM ] |
| Applied in http://www.oasis-open.org/committees/document.php?document_id=32011 |
[BPEL-35] Incorrect uses of RFC 2119 'MAY' in SBPEL3021
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised by Sanjay Patil @ http://lists.oasis-open.org/archives/sca-bpel/200904/msg00017.html
Title: Incorrect uses of RFC 2119 'MAY' in SBPEL3021 Target: SCA BPEL spec Description: The RFC 2119 guideline for using the word 'MAY' is: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. SBPEL3021 reads as: An SCA extension attribute sca-bpel:requires MAY be used to declare required policy intents on a partner link. The word 'MAY' in this statement is intended to point out a feature that is available for users of the products implementing the specification and is not intended to point out the optionality from a vendor implementation point of view. Proposal: Change SBPEL3021 to read as: An SCA extension attribute sca-bpel:requires is used to declare required policy intents on a partner link. |
| Comments |
| Comment by Anish Karmarkar [ 23/Apr/09 02:20 AM ] |
| Opened on the 2009-04-09 call http://lists.oasis-open.org/archives/sca-bpel/200904/msg00035.html |
| Comment by Anish Karmarkar [ 23/Apr/09 02:21 AM ] |
|
Resolved on the 2009-04-09 call http://lists.oasis-open.org/archives/sca-bpel/200904/msg00035.html with the following --
Change SBPEL3021 to read as: To declare policy intents on a partner link element, the SCA extension attribute sca-bpel:requires MUST be used . |
| Comment by Anish Karmarkar [ 24/Jun/09 06:55 PM ] |
| Applied in http://www.oasis-open.org/committees/document.php?document_id=32011 |
[BPEL-36] Remove SBPEL2009 as a tagged conformance item.
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
The MUST requirement in SBL2009 is redundant to SBL2010-2013. PROPOSAL: Changing "MUST be" to "is" in the sentence marked by SBPEL2009 and remove the marking. RESOLVED With the proposal above on the TC meeting of 2009-04-16. |
| Comments |
| Comment by Anish Karmarkar [ 24/Jun/09 06:52 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-37] Unnecessary MUST in SBPEL2009
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
SBPEL2009 has a 'MUST' which is an unnecessary repetition what is in [SBPEL2010]-[SBPEL2013]
|
| Comments |
| Comment by Anish Karmarkar [ 23/Apr/09 02:12 AM ] |
|
Dup of issue 26
Screw up on the filers part |
[BPEL-38] Is the 'MUST' in section 2.1.2 needed?
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised in the email http://lists.oasis-open.org/archives/sca-bpel/200904/msg00048.html
Description: This issue came up as a result of discussion of test assertion SBL-TA-2012. The test assertion, which is based on SBPEL2014, is not really testable. OR to be more precises perhaps could be testable for some corner cases, which the SCA BPEL TC (very likely) is not going to test. The problem is that the requirement states that the binding configured must know the identity of the partner as soon as the PL becomes active. It is not clear how that would happen for the bindings that we define. It seems to assume that the binding and the port associated with the binding is visible only to other SCA references. It is not clear why/how this would be true. A related minor issue is that it talks about the 'identity' of the partner. Does it really mean 'identity' or the 'location'? The parenthetical statement seems to indicate that it is the location, not identity. Proposal: Two possible solutions: 1) If this is indeed a corner case which we want to enable but not test, we could s/MUST/SHOULD/ 2) If this is a corner case that we don't intend to test nor do we see it serve a useful purpose then we should just get rid of section 2.1.2 |
| Comments |
| Comment by Anish Karmarkar [ 06/May/09 03:53 PM ] |
| Issue opened at the 2009-04-23 telcon http://lists.oasis-open.org/archives/sca-bpel/200904/msg00065.html |
| Comment by Michael Rowley [ 14/May/09 10:51 AM ] |
|
Resolved in TC meeting of May 14, 2009.
The resolution is to replace section 2.1.2 with the following: 2.1.2 Handling @initializePartnerRole If a partner link is marked with initializePartnerRole="yes" then any component that uses this business process as an implementation MUST configure the corresponding service or reference using binding, promotion and wiring configuration that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active. If the partner link is mapped to a service, the callback binding would be the relevant binding for this requirement. |
| Comment by Anish Karmarkar [ 24/Jun/09 06:52 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-39] References to WS-BPEL 2.0
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised via email at http://lists.oasis-open.org/archives/sca-bpel/200904/msg00055.html
Target: SCA-BPEL 1.1 - Committee Draft 02 and Public Review Draft 0 Description: In the April 23 TC call, I mentioned a potential problem w.r.t. referencing the WS-BPEL 2.0 <partnerLink> attributes myRole and partnerRole in SCA-BPEL normative statements, and took an action item for investigating the situation in (1) the SCA-BPEL specification and (2) the test assertion document. Background: In WS-BPEL 2.0, the specification of the @myRole and @partnerRole attributes of a <bpel:partnerLink> element is optional: "Within a <partnerLink>, the role of the business process itself is indicated by the attribute myRole and the role of the partner is indicated by the attribute partnerRole. When a partnerLinkType has only one role, one of these attributes is omitted as appropriate. [SA00016] Note that a <partnerLink> MUST specify the myRole, or the partnerRole, or both. This syntactic constraint MUST be statically enforced." (Reference: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html, section 6.2. Partner Links). In other words, if there is a two-role partner link type, it is sufficient for the <partnerLink> to specify **only one** of the @myRole / @partnerRole attributes because the other one is implied. As a result, there may be situations with two-role partner link types where SCA-BPEL mentions a @partnerRole attribute while the <bpel:partnerLink> element only contains a @myRole attribute, or vice versa. I checked the normative statements in SCA-BPEL 1.1: [SBPEL2015] The WSDL port type in the <interface.wsdl> declaration for the service in the introspected component type MUST be the same as the port type of the myRole of the partner link. [SBPEL2016] If the partner link type has two roles, then the <interface.wsdl> declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the partnerRole of the partner link. [SBPEL2017] The WSDL port type in the <interface.wsdl> declaration for the reference MUST be the same as the port type of the partnerRole of the partner link. [SBPEL2018] If the partner link type has two roles, then the <interface.wsdl> declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the myRole of the partner link. [SBPEL3011] The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched. [SBPEL3012] There MUST be at least one code-path where the values from the multi-valued reference variable are copied to the partnerRole of the partner link. The rule [SBPEL3011] explicitly refers to the "partnerRole attribute" (so it has the problem mentioned above). The other rules only talk about the "myRole" or "partnerRole" (which **can** be interpreted in an abstract way and not as the name of an existing attribute), so we may leave that as-is. Proposal: (1) As a minimal-invasive change, I suggest changing [SBPEL3011] as follows in order to avoid the explicit reference of the "partnerRole" attribute of a <partnerLink> element (which may not be present): [SBPEL3011] The partnerLinkType attribute of the partner link and multi-valued reference variable MUST be matched and the partnerRole attribute of the multi-valued reference variable MUST match the partnerRole of the partner link. (2) The test assertions SBL-TA-2014 and SBL-TA-2015 should be changed as well. In the same way as the SCA-BPEL spec statements, they should say "myRole" instead of "@myRole attribute" and "partnerRole" instead of "@partnerRole attribute". |
| Comments |
| Comment by Anish Karmarkar [ 06/May/09 03:51 PM ] |
| Accepted on the 2009-04-30 telcon http://lists.oasis-open.org/archives/sca-bpel/200905/msg00001.html |
| Comment by Michael Rowley [ 14/May/09 10:54 AM ] |
|
Resolved in TC meeting of 14 May 2009 with the following:
Change from (the resolution of [SBPEL3011] The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>. To: [SBPEL3011] For the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>, both of the following MUST be true: (1) The partnerLinkType attribute of the <partnerLink> is the same as the partnerLinkType attribute of the <sca-bpel:multiReference>. (2) The name of the partnerRole for the <partnerLink> is the same as the partnerRole attribute of the <sca-bpel:multiReference>. |
| Comment by Anish Karmarkar [ 24/Jun/09 06:53 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-40] SBPEL2019 is redundant
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised at: http://lists.oasis-open.org/archives/sca-bpel/200905/msg00005.html
Title: SBPEL2019 is redundant Target: BPEL C&I spec PR 01 Description: SBPEL2019 states: "When multiple partner links share the same name, the scheme defined by [SBPEL2020]-[SBPEL2022] MUST be used to disambiguate different occurrences of partner link declaration." SBPEL2020-SBPEL2022 specify rules that contain RFC2119 keywords. Given this, SBPEL2019 does not add anything of value. Proposal: Remove the tag [SBPEL2019] from section 2.3 as well as Appendix B and replace the 'MUST' in the statement with 'is'. |
| Comments |
| Comment by Anish Karmarkar [ 11/May/09 02:37 PM ] |
|
Opened at the 2009-05-07 telcon
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00016.html |
| Comment by Anish Karmarkar [ 11/May/09 02:39 PM ] |
|
Resolved at the 2009-05-07 telcon with the proposal in JIRA (replace 'MUST' with 'is')
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00016.html |
| Comment by Anish Karmarkar [ 24/Jun/09 06:53 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-41] SBPEL2022 has an incorrect 'MAY' and is not applied recursively
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raised at:http://lists.oasis-open.org/archives/sca-bpel/200905/msg00006.html
Title: SBPEL2022 has an incorrect 'MAY' and is not applied recursively Target: SCA BPEL C&I PR 01 Description: SBPEL2022 states the following: "If any "_orginalName_i" (where 1 <= i <= N) is already the name of a partner link declaration in the process definition, additional underscore characters MAY be added at the beginning of all aliases consistently to avoid collision." 'MAY' here means that some runtimes may not choose to do this. We want deterministic names that are independent of the runtime. It is also possible that after an additional underscore is added at the beginning it still results in a conflict. SBPEL2022 needs to be applied recursive till there is no collision. Proposal: Replace SBPEL2022 with -- "If any "_orginalName_i" (where 1 <= i <= N) is already the name of a partner link declaration in the process definition, then an additional underscore characters MAY MUST be added at the beginning of all aliases names, recursively, consistently to avoid collision, until a collision is avoided." (alternately, we can say something along the lines of "... additional minimum number of underscore characters that results in no collision MUST be added at the beginning of all names consistently." |
| Comments |
| Comment by Anish Karmarkar [ 11/May/09 02:38 PM ] |
|
Opened at the 2009-05-07 telcon
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00016.html |
| Comment by Anish Karmarkar [ 10/Sep/09 05:18 PM ] |
|
resolved at the 2009-09-10 telcon with the proposal at http://lists.oasis-open.org/archives/sca-bpel/200908/msg00051.html + 4 changes:
... remove SBPEL2zzzz ... remove the phrase "or the name of the multivalued variable" in the 3rd and 4th subbullet in section 2.3.1 ... remove the phrase "and sca-bpel:multiReference/@name attributes" in the 2nd last sentence |
| Comment by Anish Karmarkar [ 21/Jan/10 04:21 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-42] SBPEL3004 has an incorrect 'MAY'.
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Najeeb Andrabi |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Target: SCA BPEL C&I PR 01 Description: SBPEL3004 states the following: "In a WS-BPEL process definition, a variable MAY include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference." 'MAY' implies that some runtimes may choose not to implement multi-valued reference using sca:bpel:multiReference extension element. We want that the implementation of multi-valued reference using sca-bpel:multiReference extension element be portable across different runtimes. Proposal: Replace with -- "In a WS-BPEL process definition, a variable can include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference." -Najeeb |
| Comments |
| Comment by Anish Karmarkar [ 15/May/09 05:18 PM ] |
| Opened at the 2009-05-14 telcon |
| Comment by Anish Karmarkar [ 23/Jul/09 01:59 AM ] |
| Issue resolved at the 2009-07-16 telcon with the proposal at http://lists.oasis-open.org/archives/sca-bpel/200907/msg00015.html |
| Comment by Anish Karmarkar [ 21/Jan/10 04:25 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-43] Invalid start-from-componentType scenario in abstract
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
DESCRIPTION: The second paragraph of the specification says that the specification covers the following scenario: Start from SCA Component Type. It should be possible to use WS-BPEL to implement any SCA Component Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition. I believe that this scenario is no longer covered. PROPOSAL: Change it to talk about constraining types: Implement an SCA Constraining Type. It should be possible to use WS-BPEL to implement any SCA Constraining Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition. |
| Comments |
| Comment by Michael Rowley [ 21/May/09 02:53 PM ] |
|
Opened and Resolved, using the proposal above, in the TC of May 21, 2009. |
| Comment by Anish Karmarkar [ 24/Jun/09 06:53 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-44] Incorrect use of 'MAY' in SBPEL3014 and SBPEL3017 statements
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Title: Incorrect use of 'MAY' in SBPEL3014 and SBPEL3017 statements
Target: SCA BPEL C&I PR 01 Description: The statements SBPEL3014 and SBEL3017 describe how a partnerLink can be mapped to an SCA service or a reference respectively by attaching the corresponding attribute defined by the SCA BPEL specification. The use of RFC 2119 'MAY' keyword is not appropriate for such descriptive and non-normative statements. Proposal: Replace the keyword 'MAY' with 'can' and delete the conformance IDs for the SBPEL3014 and SBPEL3017 statements. Note: This proposal is to override the previously adopted resolution for the same problem (replace 'MAY' with 'MUST') under issues BPEL-33 and BPEL-34 |
| Comments |
| Comment by Anish Karmarkar [ 04/Jun/09 10:31 AM ] |
| Opened on the 2009-06-04 call |
| Comment by Anish Karmarkar [ 04/Jun/09 10:32 AM ] |
|
Resolved on the 2009-06-04 call with the proposal in Jira
|
| Comment by Anish Karmarkar [ 24/Jun/09 06:53 PM ] |
| Applied in http://www.oasis-open.org/apps/org/workgroup/sca-bpel/document.php?document_id=32890 |
[BPEL-45] SBPEL3022 has redundancy in it
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Title: SBPEL3022 has redundancy in it
Target: BPEL C&I PRD Description: [SBPEL3022] The contents of the sca-bpel:requires attribute MUST be a space separated list of SCA intent QNames, exactly as specified in the SCA Policy Framework Specification for the contents of the @sca:requires attribute. The fact that it is a space separated list of QNames is already part of the XML Schema. The fact that the QNames are intents is already covered by the ref to the Policy framework spec. Proposal: Replace 3022 with -- [SBPEL3022] The contents of the sca-bpel:requires attribute MUST be exactly as specified in the SCA Policy Framework Specification for the contents of the @sca:requires attribute. |
| Comments |
| Comment by Anish Karmarkar [ 25/Jun/09 07:31 PM ] |
| opened and resolved on the 2009-06-25 telcon |
| Comment by Anish Karmarkar [ 21/Jan/10 04:25 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-46] SBPEL3006 isn't deterministic
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
SBPEL 3006 has language left over from when the component type was not simply derived from the process. This came up during discussion of issue 42.
[SBPEL3006] The introspected component type MUST include a reference with a multiplicity of either "0..n" or "1..n" that corresponds to a variable with the sca-bpel:multiReference element. We need to actually specify how to derive the multiplicity from the process. |
| Comments |
| Comment by Anish Karmarkar [ 25/Jun/09 07:32 PM ] |
| Opened on the 2009-06-25 telcon |
| Comment by Sanjay Patil [ 05/Nov/09 02:58 PM ] |
|
Resolved on 11/5/09
Close with no action - http://lists.oasis-open.org/archives/sca-bpel/200911/msg00006.html |
| Comment by Sanjay Patil [ 05/Nov/09 02:59 PM ] |
|
On 11/5/09 call, TC resolved to close the issue 46 with no action
http://lists.oasis-open.org/archives/sca-bpel/200911/msg00006.html |
[BPEL-47] Section 2.1.2 (initializePartnerRole) needs an example
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
PR 01 comment filed at:
http://lists.oasis-open.org/archives/sca-bpel-comment/200906/msg00000.html It is hard to understand the motivation and utility behind Section 2.1.2 without an example. An example such as binding.jms where the callback address is specified in the composite would help. |
| Comments |
| Comment by Anish Karmarkar [ 10/Jul/09 05:10 PM ] |
| Opened at the 2009-07-09 telcon |
| Comment by Anish Karmarkar [ 24/Jul/09 07:04 PM ] |
|
Resolved during the 2009-07-23 telcon with the following proposal:
Add the following at the section 2.1.2 -- ----- One way this can be achieved is by specifying a callback binding that includes endpoint information, on a bidirectional SCA service of a component. For example: <service name="inventory"> <interface.wsdl interface="..." callbackInterface="..."/> <binding.ws/> <callback> <binding.ws> <endpointReference> <wsa:Address>http://example.org/callbackService?inventory</wsa:Address> </endpointReference> </binding.ws> </callback> </service> ----- |
| Comment by Anish Karmarkar [ 21/Jan/10 04:24 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-48] BPEL C&I spec does not say anything about component type side files
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
PR01 comment filed at: http://lists.oasis-open.org/archives/sca-bpel-comment/200906/msg00001.html
The SCA Assembly spec says: "The implementation type specification defines whether introspection is allowed, whether a side file is allowed, both are allowed or some other mechanism specifies the component type." The BPEL C&I spec is silent on whether side files are allowed or not. |
| Comments |
| Comment by Anish Karmarkar [ 10/Jul/09 05:11 PM ] |
| Opened at the 2009-07-09 telcon |
| Comment by Anish Karmarkar [ 23/Jul/09 02:01 AM ] |
| Resolved at the 2009-07-16 telcon with proposal at http://lists.oasis-open.org/archives/sca-bpel/200907/msg00009.html |
| Comment by Anish Karmarkar [ 21/Jan/10 04:24 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-49] BPEL process QName is assumed to be unique
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
PR 01 comment filed at: http://lists.oasis-open.org/archives/sca-bpel-comment/200906/msg00002.html
The BPEL specification does not say that the BPEL process QName is unique. The SCA BPEL C&I spec assumes that it is, but does not state this assumption in the spec. |
| Comments |
| Comment by Anish Karmarkar [ 10/Jul/09 05:11 PM ] |
| Opened at the 2009-07-09 telcon |
| Comment by Anish Karmarkar [ 06/Aug/09 02:23 PM ] |
|
Resolved at the 2009-08-06 telcon
Proposal at http://lists.oasis-open.org/archives/sca-bpel/200907/msg00029.html is accepted as the resolution with the proposed text: "SCA's artifact resolution mechanism, defined in section 11.2 of the SCA Assembly Specification, MUST be used to resolve the specified QName to a WS-BPEL process." is to be added as the last sentence of section 1 (just prior to 1.1) |
| Comment by Anish Karmarkar [ 21/Jan/10 04:24 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-50] Need more examples in the specification
|
|
| Status: | Open |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
PR 01 comment filed at: http://lists.oasis-open.org/archives/sca-bpel-comment/200906/msg00003.html
The specification needs a lot more examples to help the reader understand the concepts. The specification requires understanding of both the BPEL technology and SCA technology. This, at this point, is not something that is common. Readers are familiar with BPEL or SCA, in most cases, and provide plenty of examples would help newcomers grok the specification. |
| Comments |
| Comment by Anish Karmarkar [ 10/Jul/09 05:11 PM ] |
| Opened at the 2009-07-09 telcon |
[BPEL-51] Conformance statement SBPEL3021 is inappropriate and unnecessary
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Mike Edwards | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raiser: Mike Edwards Target: sca-bpel-1.1-spec-cd02.pdf Description: Normative statement SBPEL3021 reads: [SBPEL3021] An SCA extension attribute sca-bpel:requires MAY be used to declare required policy intents on a partner link. First, the MAY is invalid, since it is required that an SCA runtime supports the sca-bpel:requires attribute. The MAY here actually is talking about the option that a BPEL process writer has to express policy intents using that attribute. Second, the mandatory conformance aspects of the sca-bpel:requires attribute are defined in SBPEL3022 and SBPEL3023, making SBPEL3021 redundant. Proposal: Remove the normative statement SBPEL3021 and the following sentences in the same paragraph and replace it with the following text: --------------------- The sca-bpel:requires attribute on a partnerLink is available for BPEL process designers to associate SCA abstract policy intents with a partnerLink element. Policy intents specified on a partnerLink element using the sca-bpel:requires attribute become part of the componentType of the BPEL process, appearing as the content of a @requires attribute on either a <service/> or a <reference/> element in the componentType, depending on whether the partnerLink is used as a service or as a reference. The form of the sca-bpel:requires attribute is as follows: --------------------- This proposal also means the removal of the corresponding Test Assertion from the TestAssertions document for BPEL. |
| Comments |
| Comment by Anish Karmarkar [ 10/Jul/09 05:12 PM ] |
| Opened at the 2009-07-09 telcon |
| Comment by Anish Karmarkar [ 10/Jul/09 05:21 PM ] |
| Resolved at the 2009-07-09 telcon with the proposal in JIRA |
| Comment by Anish Karmarkar [ 21/Jan/10 04:24 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-52] CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Title: CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute
Target: BPEL C&I spec Description: If a partnerLink does not contain a sca-bpel:reference or a sca-bpel:service attribute, the algorithm in section 2.1.1 Generating Services and References requires doing a static analysis (SBPEL2005) to figure out if the PL should be mapped to a sca reference or a service. It does not give any consideration to the sca-bpel:multiRefFrom attribute that may be present on the PL. A PL with such a attribute should be mapped to an SCA reference and never to a SCA service. Proposal: Add two new requirement (after SBPEL2004): [SBPEL2004.1] If a partner link specifies a sca-bpel:multiRefFrom attribute, then a reference MUST be generated for the introspected component type. [SBPEL2004.2] If the name of the partner link is unique within the process, then it MUST be used as the name of the reference. Otherwise, the name is determined according to the rules of section 2.3. Modify SBPEL2005 as follows: s/If neither sca-bpel:service nor sca-bpel:reference is present/If none of the attributes: sca-bpel:service, sca-bpel:reference or sca-bpel:multiRefFrom is present/ Modify SBPEL2007 to include the two new requirements. -Anish -- |
| Comments |
| Comment by Anish Karmarkar [ 23/Jul/09 01:56 AM ] |
| Opened at the 2009-07-16 telcon |
| Comment by Anish Karmarkar [ 10/Sep/09 05:16 PM ] |
|
Issue resolved at the 2009-09-10 telcon with the proposal at http://lists.oasis-open.org/archives/sca-bpel/200909/msg00017.html + one change:
the example at the end of section 3.2 -- remove the attributes partnerLinkType and partnerRole on the element <sca-bpel:multiReference> |
| Comment by Anish Karmarkar [ 28/Jan/10 01:57 AM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-53] BPEL Process: References with Multiplicity 0..1 - how are they supposed to work?
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Raiser: Mike Edwards Target: Description: Multi-valued references (ie 0..n and 1..n) are discussed in the specification at some length, particularly in section 3.2. Unfortunately, the case of 0..1 references is mentioned only in passing, although it has some significant matters that need discussion and clarification. Section 2.1.1 makes it clear that 0..1 multiplicity references do exist for BPEL processes. Basically, it states that where a partnerLink is determined to be a reference, it will be 0..1 if @initializePartnerRole="no" OR @initializePartnerRole is omitted. It must also be the case that the partnerLink must not have its "first use" as the target of an <assign/> operation. Now, reading the BPEL 2.0 specification: @initializePartnerRole="no" means that the BPEL Processor MUST NOT initialize the partnerLink variable. @initializePartnerRole omitted means that the BPEL Processor MAY initialize the partnerLink variable. Now, the problems are these: A) If the partnerLink is NOT initialized, then it is essential that it is initialized by the BPEL process itself, since any attempt to use that partnerLink variable will otherwise result in a fault. So, if the partnerLink is marked @initializePartnerRole="no", the partnerLink must be supplied with a value - but how is such a value supplied to the BPEL process by SCA? The SCA BPEL spec talks about the way in which serviceReferences are supplied in a variable typed as a serviceReferenceList for multi-valued references. There is no such equivalent for 0..1 references. Even if the partnerLink is not marked with @initializePartnerRole at all, it is STILL possible for the partnerLink to be uninitialized and so unusable without being assigned a value by the BPEL process - this is the result of that "MAY" in the BPEL 2.0 spec, listed above. Again, there is no means by which the BPEL process can get a serviceReference to assign into the partnerLink. B) If the partnerLink IS initialized, how can the BPEL process determine the difference between the case where the reference is wired and the case where the reference is unwired? There is no standard means for doing this in BPEL. So, I think we may have a problem with 0..1 references in the SCA BPEL spec. Proposal: None |
| Comments |
| Comment by Anish Karmarkar [ 06/Aug/09 02:20 PM ] |
| Opened at the 2009-08-06 telcon |
| Comment by Michael Rowley [ 17/Sep/09 10:36 AM ] |
| Resolved on 2009-09-17 TC call according to the email at: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00021.html |
| Comment by Anish Karmarkar [ 21/Jan/10 04:23 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-54] sca-bpel:multiReference/@partnerLinkType and sca-bpel:multiReference/@partnerRole cardinality
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
http://lists.oasis-open.org/archives/sca-bpel/200908/msg00031.html
Title: sca-bpel:multiReference/@partnerLinkType and sca-bpel:multiReference/@partnerRole cardinality Target: SCA BPEL C&I Description: There is an inconsistency between the pseudo-schema and the schema. partnerLinkType and partnerRole attributes of sca-bpel:multiReference are listed as optional in the appendix schema but the pseudo-schema lists them as required. Proposal: Change the schema in the appendix to make these attributes required. |
| Comments |
| Comment by Anish Karmarkar [ 20/Aug/09 02:08 PM ] |
| Issue opened at the 2009-08-20 telcon |
| Comment by Michael Rowley [ 17/Sep/09 10:37 AM ] |
| Closed with no action on TC call of 2009-09-17. |
[BPEL-55] Co-occurrence constraints on sca-bpel:property attribute and sca-bpel:multiReference element
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
http://lists.oasis-open.org/archives/sca-bpel/200908/msg00032.html
Title: Co-occurrence constraints on sca-bpel:property attribute and sca-bpel:multiReference element Target: SCA BPEL C&I Description: A variable can either be a SCA property or an SCA reference (or nothing) in the introspected component type. But never both. The spec does not say that a variable must not have both sca-bpel:property='yes' and sca-bpel:multReference extension attribute. Proposal: Add the following to section 3: In the introspected component type a variable cannot be both an SCA property and an SCA reference. [SBPELXXXX] A BPEL variable declaration MUST NOT have both the sca-bpel:property extension attribute with a value of "yes" and the sca-bpel:multiReference extension child element. |
| Comments |
| Comment by Anish Karmarkar [ 20/Aug/09 02:08 PM ] |
| Issue opened at the 2009-08-20 telcon |
| Comment by Michael Rowley [ 17/Sep/09 10:42 AM ] |
| Resolved on TC call of 2009-09-17 according to the proposal in the issue. |
| Comment by Anish Karmarkar [ 21/Jan/10 04:23 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-56] No scoping rules specified to resolve variable name referred by sca-bpel:multiRefForm extension for the partner link
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Najeeb Andrabi | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Description:
Spec does not say that in-order to resolve variable name referred by sca-bpel:multiRefFrom extension for the partner link it must follow the same scoping rules to resolve variable name as BPEL. Proposal: Add a note in section 3.2 where sca-bpel:multiRefForm extension is declared stating: The variable name referred by sca-bpel:multiRefForm can be resolved using the same scoping rules as BPEL uses to resolve variable names. |
| Comments |
| Comment by Anish Karmarkar [ 10/Sep/09 05:35 PM ] |
| Opened at the 2009-08-27 telcon |
| Comment by Sanjay Patil [ 23/Oct/09 06:02 PM ] |
|
Resolved on 10/22/09 as follows:
Add the following to section 3.2: "The variable name referred by sca-bpel:multiRefForm MUST be resolved using the same scoping rules as [WS-BPEL] uses to resolve variable names." with instructions to the editors to give a label to the normative stmt and clean it up |
| Comment by Anish Karmarkar [ 28/Jan/10 01:57 AM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-57] No initialization mechanism specified for the variable with sca-bpel:multiReference extension
|
|
| Status: | Closed |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Najeeb Andrabi | Assigned To: | Anish Karmarkar |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
Description: Variable with sca-bpel:multiReference extension needs to be initialized/Set before it can be used to set the partner link endpoint reference. Specification does not say anything about variable initialization mechanism. Proposal: None |
| Comments |
| Comment by Anish Karmarkar [ 10/Sep/09 05:36 PM ] |
| Opened at the 2009-08-27 telcon |
| Comment by Sanjay Patil [ 05/Nov/09 03:01 PM ] |
|
On 11/5/09 con-call, the TC resolved to close this issue with no action
http://lists.oasis-open.org/archives/sca-bpel/200911/msg00007.html |
[BPEL-58] Need to add Capability to indicate that a PartnerLink should be ignored when introspecting the ComponentType of a BPEL Process
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Raiser: Mike Edwards
Target: sca-bpel-1.1-spec-cd02.doc Description: Currently, any declaration of a partnerLink within a BPEL process results in a <service/> or a <reference/> appearing in the componentType of the BPEL process. This is not desirable in all circumstances: - it may be that a BPEL process is written with an inner loop, where the inner loop is implemented as a nested <scope/>. In this inner loop, it may be that a partnerLink is declared within the nested scope and used purely as a "local variable" within the loop, for example where it is a reference and the reference target/EPR is assigned to it from the contents of a variable held in an outer scope. In these circumstances, the partnerLink in the inner loop is shadowing a partnerLink in the outer scope - logically it represents the same partnerLink reference as the partnerLink in the outer scope. At present, SCA cannot handle a situation such as this - the inner partnerLink is introspected as a <reference/> and so is the outer partnerLink - this means 2 references appear when only one is called for. To change this, it is necessary to provide a capability for the writer of a BPEL process to indicate that a given partnerLink should NOT be used to introspect a <service/> or a <reference/> in the componentType. Proposal: Add a new SCA BPEL extension attribute that can be used to annotate a <partnerLink/> element. @skip boolean - default value is false When @skip="true", the <partnerLink/> element is ignored when introspecting the compoenntType of the BPEL Process. The changes are shown in this marked up version of CD02, where the changes are in Section 3.3 and Appendix A. |
| Comments |
| Comment by Anish Karmarkar [ 10/Sep/09 11:14 AM ] |
| Issue opened on the 2009-09-10 telcon |
| Comment by Anish Karmarkar [ 11/Feb/10 10:54 AM ] |
| Issue resolved on the 2010-02-11 telcon with the proposal at http://lists.oasis-open.org/archives/sca-bpel/201001/msg00032.html |
[BPEL-59] How does a SCA Extended WS-BPEL Runtime deal with a non-conformant BPEL process?
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
http://lists.oasis-open.org/archives/sca-bpel/200909/msg00022.html
Title: How does a SCA Extended WS-BPEL Runtime deal with a non-conformant BPEL process? Target: SCA BPEL C&I Description: The spec says nothing about what a SCA Extended WS-BPEL Runtime must do when it encounters a non-conformant BPEL process containing SCA BPEL extensions. For example, if a PL contains both a sca-bpel:service and sca-bpel:reference attribute, the runtime can just ignore it and deploy the process/component. Other SCA specs have a requirement that the runtimes must raise an error when such problems are encountered. Proposal: Not a specific proposal, but a genera outline -- require the SCA Extended WS-BPEL runtime to generate errors (either at deployment or runtime) when the artifacts used (in our case the process definition) do not conform to our spec. -Anish -- |
| Comments |
| Comment by Anish Karmarkar [ 22/Sep/09 02:12 PM ] |
| Opened at the 2009-09-17 call |
| Comment by Anish Karmarkar [ 09/Dec/09 01:34 AM ] |
|
Issue resolved at the 2009-11-19 concall with proposal at http://lists.oasis-open.org/archives/sca-bpel/200911/msg00008.html (modulo s/Extendd/Extended/)
|
| Comment by Anish Karmarkar [ 21/Jan/10 04:23 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-60] Removal of constrainingType from SCA-BPEL specification
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
http://lists.oasis-open.org/archives/sca-bpel/200910/msg00014.html
Target: SCA-BPEL 1.1 - Committee Draft 02 Revision 3 - Abstract section Description: Following the resolution of SCA-Assembly issue 157, the constrainingType feature should also be removed from the SCA-BPEL specification. Proposal: In the Abstract section on page 2, change the third paragraph from: "Implement an SCA Constraining Type. It should be possible to use WS-BPEL to implement any SCA Constraining Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition." to: "Implement an SCA Component Type. It should be possible to use WS-BPEL to implement any SCA Component Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition." |
| Comments |
| Comment by Sanjay Patil [ 23/Oct/09 06:05 PM ] |
|
On 10/22/09 conf-call:
issue 60 is resolved with the proposal in JIRA |
| Comment by Anish Karmarkar [ 21/Jan/10 04:22 PM ] |
| Applied in cd02-rev6 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/35952/sca-bpel-1.1-spec-cd02-rev6.zip |
[BPEL-61] Need to deal with variable initialization not being idempotent
|
|
| Status: | Applied |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
RAISER: Danny van der Rijn
TARGET: SCA C+I WS-BPEL spec, General DESCRIPTION: WS-BPEL section 8.1 contains the following requirement: [SA00026] Variable initialization logic contained in scopes that contain or whose children contain a start activity MUST only use idempotent functions in the from-spec. The use of idempotent functions allows for all the values for such variables to be pre-computed and re-used on each process instance. SCA-BPEL 3.2 (CD02-rev4) has the following new text Variable (sic) with "sca-bpel:multiReference" extension is initialized by sca runtime using an implicit <from-spec> that uses an expression that points to a virtual sca runtime variable holding a list of endpoint references for the targets of the multi-reference represented by a partner link referencing this variable. Which is in conflict with WS-BPEL SA00026. Similarly, but not as precisely, SCA-BPEL 3.1 describes how properties are initialized, and that section runs afoul of the same statement. PROPOSAL: none |
| Comments |
| Comment by Anish Karmarkar [ 09/Dec/09 01:31 AM ] |
| Opened at the 2009-11-19 concall |
| Comment by Anish Karmarkar [ 21/Jan/10 04:17 PM ] |
| resolved with wordings in http://lists.oasis-open.org/archives/sca-bpel/201001/msg00014.html added at the the end of Section 3.1. Resolution approved on the 2010-01-21 concall |
| Comment by Anish Karmarkar [ 21/Jan/10 04:18 PM ] |
| Applied in cd02-rev7 http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/36024/sca-bpel-1.1-spec-cd02-rev7.zip |
[BPEL-62] More on multiplicity 0..1
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Rowley | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
sca-bpel-1.1-Issue53A.doc
|
| Description |
|
TARGET: SCA C+I WS-BPEL spec, General RAISED BY: Danny van der Rijn DESCRIPTION: Two areas of concern came out of the discussions of Issue 53. a) For a reference whose multiplicity is 0..1, there is no requirement that the runtime present data configured in the domain composite b) There is no way to see if the partnerRole is set, short of attempting to use it, and getting an exception PROPOSAL: The attached document is a proposal which started with the CD02-rev7 document posted by Dieter on 21-JAN-2010, with its changes accepted. DISCUSSION: Points a) and b) above are orthogonal issues. The proposed changes are in separate areas. Point a) may be more appropriately resolved in Assembly, rather than in BPEL. |
| Comments |
| Comment by Anish Karmarkar [ 11/Feb/10 10:53 AM ] |
| Issue opened at the 2010-01-28 telcon |
| Comment by Anish Karmarkar [ 10/Mar/10 11:58 PM ] |
| Resolved on the 2010-02-25 call with proposal at http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/36481/sca-bpel-1.1-spec-cd02-rev7-Issue62c.doc |
[BPEL-63] SBPEL2005 doesn't take into account the fact that a PL may have sca-bpel:ignore="false" on it
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Title: SBPEL2005 doesn't take into account the fact that a PL may have sca-bpel:ignore="false" on it
Target: SCA BPEL C&I Description: 2005 says -- "[SBPEL2005] If none of the attributes sca-bpel:ignore, sca-bpel:service, or sca-bpel:reference are present on the partner link, then if a static analysis of the process determines that it is possible that the first message for a partner link will be received in a <receive> activity, the <onMessage> element of a <pick> activity or the <onEvent> element of an event handler then the introspected component type MUST include an SCA service that corresponds to the partner link in the component type. " The 'if' condition has to include a PL that has sca-bpel:ignore attribute with a value of "false", since it is equivalent to the attribute not being present. Proposal: Change 2005 to -- "[SBPEL2005] If none of the attributes sca-bpel:ignore with a canonical value of "false", sca-bpel:service, or sca-bpel:reference are present on the partner link, then if a static analysis of the process determines that it is possible that the first message for a partner link will be received in a <receive> activity, the <onMessage> element of a <pick> activity or the <onEvent> element of an event handler then the introspected component type MUST include an SCA service that corresponds to the partner link in the component type. " |
| Comments |
| Comment by Sanjay Patil [ 24/Mar/10 05:38 PM ] |
|
Issue was opened and resolved on the 3/18/2010 conf-call
http://lists.oasis-open.org/archives/sca-bpel/201003/msg00020.html |
[BPEL-64] Name of the generated SCA reference for a partnerLink declared with multiRefFrom extension
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Sanjay Patil | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Title: Name of the generated SCA reference for a partnerLink declared with multiRefFrom extension
Target: SCA WS-BPEL C&I Specification Version 1.1 CD 2 Rev 9 Description: There is no normative statement in the specification for generating name of an SCA reference which corresponds to a partnerLink that uses the multiRefFrom extension. There is discrepancy in how the name of a reference is generated for a partnerLink with multiRefFrom extension: * Section 2.3.1 uses the name of the variable with multiReference extension as the name of the generated reference. See the text: 'Else if the name attribute is present on the sca-bpel:multiReference extension ...' * Section 3.2 uses the name of the partnerLink as the name of the generated reference. See the text at the bottom of the section: 'A multi-value reference named "vendorLink" , which his categorized as ..." Proposal: Add a normative statement after the SBPEL2024 statement: The name of the reference MUST be the value of the name attribute of the partnerLink. Update the sections 2.3.1 and 3.2 to comply with the added normative statement. |
| Comments |
| Comment by Anish Karmarkar [ 08/Sep/10 01:08 PM ] |
|
Issue opened at the 2010-08-19 telcon
http://lists.oasis-open.org/archives/sca-bpel/201008/msg00012.html |
| Comment by Anish Karmarkar [ 09/Sep/10 02:36 PM ] |
|
Resolved during the 2010-09-09 telcon
http://lists.oasis-open.org/archives/sca-bpel/201009/msg00003.html Resolution: Resolve 64 with proposal in http://lists.oasis-open.org/archives/sca-bpel/201008/msg00018.html with the change of SBPEL3020 statement as "A partnerLink MUST NOT have the sca-bpel:ignore attribute with a value of "true" when either an sca-bpel:service or an sca-bpel:reference or an sca-bpel:multiRefFrom attribute is also present on that partnerLink." and a new normative stmt: [SBPELXXXX] A partnerLink MUST NOT have both the sca-bpel:service and sca-bpel:reference attributes present on it. |
[BPEL-65] sca-bpel:ignore attribute value is relevant only when it is "true" (and not "1")
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Anish Karmarkar | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Title: sca-bpel:ignore attribute value is relevant only when it is "true" (and not "1")
Specification: SCA BPEL C&I Description: [Note: this issue was discussed briefly in the context of a different issue and we decided to leave it as is. I now feel strongly enough to file a separate issue] All the normative statements with the sca-bpel:ignore attribute as the target (SPEL2005, SBPEL2007, SBPEL2025, SBPEL3020) are conditional to its literal value being "true" or not "true". The type of the attribute is xs:boolean, which means that the value space is {0, 1, false, true}. With the current formulation of the normative statements, the only value that matters is "true". One cannot use "1" and have that partnerLink be ignored by the introspection algorithm. The introspection algorithm currently has to treat a partnerLink with sca-bpel:ignore="1" no different than a partnerLink with sca-bpel:ignore="false". This is counter-intuitive and IMHO wrong. Proposal: I would like to suggest resolving it in one of two ways (I prefer the second approach): 1) restrict the value space to just {true, false} -- just a schema change 2) keep the value space as is, but refer to the canonical value of true in our normative statements. |
| Comments |
| Comment by Anish Karmarkar [ 06/Oct/10 05:22 PM ] |
| Issue opened at the 2010-09-30 telcon |
| Comment by Anish Karmarkar [ 15/Oct/10 05:11 PM ] |
| resolved on the 2010-10-14 telcon with value space of {0, 1, true, false}. Normative stmts in the spec to be fixed to account for these values |
[BPEL-66] sca-bpel:ignore attribute must act as a switch enabling or disabling the projection of partner links as services or references.
|
|
| Status: | Resolved |
| Project: | OASIS SCA BPEL TC |
| Component/s: | Public Review 1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Najeeb Andrabi | Assigned To: | Anish Karmarkar |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Title: sca-bpel:ignore attribute must act as a switch enabling or disabling the projection of partner links as services or references.
Specification: SCA BPEL C&I Description: SBPEL3020 states the following: A partnerLink MUST NOT have the sca-bpel:ignore attribute when an sca-bpel:service or an sca-bpel:reference or an sca-bpel:multiRefFrom attribute is also present on that partnerLink. This normative statement restricts the use of the sca:bpel:ignore attribute as a switch. It will be very convenient for the designer/implementer of the SCA-BPEL composite application to enable or disable the projection of a partner link as a service or reference just by changing the value of the ignore attribute. Proposal: Remove normative statement: [SBPEL3020] A partnerLink MUST NOT have the sca-bpel:ignore attribute when an sca-bpel:service or an sca-bpel:reference or an sca-bpel:multiRefFrom attribute is also present on that partnerLink. |
| Comments |
| Comment by Anish Karmarkar [ 15/Oct/10 05:09 PM ] |
| Opened on the 2010-10-14 telcon |
| Comment by Anish Karmarkar [ 15/Oct/10 05:10 PM ] |
| resolved on the 2010-10-14 telcon with proposal in jira |