<< Back to previous view

[BPEL-1] support for BPEL4WS 1.1
Created: 04/Oct/07  Updated: 10/Jul/08

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
Created: 04/Oct/07  Updated: 05/Sep/08

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
Created: 04/Oct/07  Updated: 09/Jul/08

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
Created: 04/Oct/07  Updated: 25/Sep/08

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
Created: 04/Oct/07  Updated: 25/Sep/08

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
Created: 04/Oct/07  Updated: 25/Sep/08

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
Created: 04/Oct/07  Updated: 25/Sep/08

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.
Created: 04/Oct/07  Updated: 25/Sep/08

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
Created: 10/Oct/07  Updated: 09/Jul/08

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
Created: 11/Oct/07  Updated: 25/Sep/08

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
Created: 16/Oct/07  Updated: 10/Jul/08

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
Created: 19/Oct/07  Updated: 26/Feb/09

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 ASSEMBLY-33 - see http://www.osoa.org/jira/browse/ASSEMBLY-33

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
Created: 01/Nov/07  Updated: 09/Jul/08

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
Created: 01/Nov/07  Updated: 25/Sep/08

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
Created: 06/Nov/07  Updated: 11/Sep/08

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
Created: 05/Dec/07  Updated: 29/May/08

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 ASSEMBLY-29: http://www.osoa.org/jira/browse/ASSEMBLY-29

-------------------------------------------------------

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
Created: 17/Jan/08  Updated: 10/Jul/08

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: ASSEMBLY-52 - http://osoa.org/jira/browse/ASSEMBLY-52
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
Created: 31/Jan/08  Updated: 19/Feb/09

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
Created: 13/Mar/08  Updated: 10/Jul/08

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
Created: 01/May/08  Updated: 05/Sep/08

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?
Created: 01/May/08  Updated: 29/May/08

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
Created: 16/Oct/08  Updated: 07/Feb/09

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
Created: 17/Oct/08  Updated: 07/Feb/09

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
Created: 30/Oct/08  Updated: 26/Feb/09

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
Created: 11/Dec/08  Updated: 07/Feb/09

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.
Created: 11/Dec/08  Updated: 12/Feb/09

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
Created: 14/Jan/09  Updated: 26/Feb/09

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
Created: 04/Feb/09  Updated: 26/Feb/09

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
Created: 26/Feb/09  Updated: 26/Feb/09

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
Created: 01/Apr/09  Updated: 24/Jun/09

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
Created: 02/Apr/09  Updated: 24/Jun/09

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
Created: 02/Apr/09  Updated: 02/Apr/09

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
Created: 02/Apr/09  Updated: 24/Jun/09

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
Created: 08/Apr/09  Updated: 24/Jun/09

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
Created: 08/Apr/09  Updated: 24/Jun/09

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.
Created: 16/Apr/09  Updated: 24/Jun/09

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
Created: 23/Apr/09  Updated: 23/Apr/09

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?
Created: 23/Apr/09  Updated: 24/Jun/09

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 Attributes "myRole" and "partnerRole"
Created: 30/Apr/09  Updated: 24/Jun/09

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 BP-31):

[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
Created: 06/May/09  Updated: 24/Jun/09

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
Created: 06/May/09  Updated: 21/Jan/10

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'.
Created: 08/May/09  Updated: 21/Jan/10

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
Created: 15/May/09  Updated: 24/Jun/09

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
Created: 04/Jun/09  Updated: 24/Jun/09

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
Created: 11/Jun/09  Updated: 21/Jan/10

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
Created: 11/Jun/09  Updated: 05/Nov/09

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
Created: 25/Jun/09  Updated: 21/Jan/10

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&lt;/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
Created: 25/Jun/09  Updated: 21/Jan/10

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
Created: 25/Jun/09  Updated: 21/Jan/10

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
Created: 25/Jun/09  Updated: 10/Jul/09

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
Created: 26/Jun/09  Updated: 21/Jan/10

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
Created: 15/Jul/09  Updated: 28/Jan/10

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?
Created: 06/Aug/09  Updated: 21/Jan/10

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
Created: 20/Aug/09  Updated: 17/Sep/09

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
Created: 20/Aug/09  Updated: 21/Jan/10

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
Created: 21/Aug/09  Updated: 28/Jan/10

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
Created: 21/Aug/09  Updated: 05/Nov/09

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
Created: 09/Sep/09  Updated: 11/Feb/10

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?
Created: 17/Sep/09  Updated: 21/Jan/10

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
Created: 15/Oct/09  Updated: 21/Jan/10

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
Created: 05/Nov/09  Updated: 21/Jan/10

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
Created: 22/Jan/10  Updated: 10/Mar/10

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: Microsoft Word 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
Created: 17/Mar/10  Updated: 24/Mar/10

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
Created: 19/Aug/10  Updated: 09/Sep/10

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")
Created: 09/Sep/10  Updated: 15/Oct/10

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.
Created: 13/Oct/10  Updated: 15/Oct/10

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




Generated at Tue Feb 07 19:32:09 CST 2012 by Anish Karmarkar using JIRA 187.