OASIS TC Charter Proposal: SCA-BPEL

OASIS Open CSA Member Section: SCA-BPEL TC Charter Proposal

Subject:  Proposed Charter for OASIS Service Component Architecture BPEL (SCA BPEL)
          Technical Committee - 5 of 6
From:     "Mary McRae" <mary.mcrae@oasis-open.org>
To:       <members@lists.oasis-open.org>,
          <tc-announce@lists.oasis-open.org>
Date:     Mon, 2 Jul 2007 09:26:49 -0400

To OASIS Members:

A draft TC charter has been submitted to establish the OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee. In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process.php#2.2) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 16 July 2007.

OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.

A telephone conference will be held among the Convenor, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.

We encourage member comment and ask that you note the name of the proposed TC (SCA-BPEL) in the subject line of your email message.

Regards,

Mary

Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 603.232.9090

Proposed Charter for Review and Comment

OASIS Service Component Architecture BPEL TC

Contents

Normative Information
Non-normative Information Regarding the Startup of the TC

Normative Information

Name

OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee

Member Section Affiliation

Open CSA Member Section

Statement of Purpose

The SCA BPEL TC will specify how SCA component implementations can be written using the WS-BPEL language [1]. The SCA WS-BPEL specification must allow any executable WS-BPEL 2.0 and BPEL4WS 1.1 process to be used without any knowledge of SCA. In addition, SCA specific extensions will be defined such that an executable WS-BPEL process may be aware of SCA and take advantage of that environment.

This TC will continue development of the SCA BPEL Client and Implementation Specification Version 1.0 [2] and aims to establish it as an OASIS Standard.

Scope

The SCA Assembly Model defines the environment in which SCA component implementations exist. The SCA WS-BPEL specification must conform to this environment and as a result,the following should be covered by the SCA WS-BPEL specification:

1. Mapping of WS-BPEL PartnerLinks to SCA Services and References. This must take into account:

the directionality of the roles in the PartnerLink
the initializePartnerRole attribute
whether a role is initialized through assignment before it is used

2. Ensure correct behaviour of SCA call-backs and conversations. SCA extensions may be defined to support conversations for SCA aware WS-BPEL implementations.

3. Ensure support for dynamic binding of partner links in SCA environment, especially the wire-by-impl feature.

4. SCA extensions to WS-BPEL to support a PartnerLink that may have multiple partners of the same type. This should provide a simple mechanism to iterate over a number of partners of the same type as in an RFQ interaction, for example.

5. SCA extensions to WS-BPEL to enable SCA properties to be used for initialization purposes.

6. SCA extensions to WS-BPEL to enable other features defined in the SCA specifications to be explicitly used.

The TC will accept as input the March 2007 Version 1.0 of the Service Component Architecture (SCA) BPEL Client and Implementation Specification as published by the Open SOA collaboration [2].

The TC will also accept as input for reference the March 2007 Version 1.0 of the other SCA Specifications which were published at the same time as the SCA BPEL Client and Implementation Specification [3].

Other contributions may be made by TC Members on or after the first meeting of the TC. Such other contributions shall be considered by the TC Members on an equal basis to improve the original starting point contribution in a manner that is compliant with this charter.

Upwards Compatibility

There are no formal requirements for upwards compatibility from the input documents to this TC. This is to ensure that the TC has maximum freedom of action in defining the OASIS standard. However it is recognized that there will be early implementations in the marketplace based upon these input documents and careful consideration must be applied to any change of feature/function that would cause incompatibilities in the OASIS standard at:

Source Code level
Compiled Object Code
XML data definitions

At minimum, known enhancements to the input documents that will cause compatibility issues with early implementations in the marketplace will be specified in a chapter in the specification offering migration guidance.

Conformance

In line with the OASIS TC process, the TC will produce normative conformance information describing the normative characteristics of the specification and specific statements about what an implementation must do to conform to the specification, and what aspects are optional (if any).

Test Suite

The TC will produce a test suite which can be used to test conformance to the specification which will include:

1. A series of valid and invalid test cases which cover as much as is practical of the conformance statements of the specifications produced by this TC, with a description of each of the artifacts involved, constraints on the environment, the test case characteristics and their expected behavior. The artifacts should include example WS-BPEL implementations used to drive the test cases.

2. With the exception of necessary WS-BPEL implementation test artifacts, the provided artifacts should be independent of implementation language and binding type, and show clear mappings which allow the provision of suitable concrete implementations and concrete binding type, with any required policies. The artifacts may include SCA composites expressed in XML, WSDL interface files, and XSD files, along with other similar files that express the required characteristics of the environment for each test.

3. Example bindings may form part of the test suite, and are only provided as working samples which can be replaced by other specific bindings.

The Test Suite shall be packaged separately from the specifications produced by the TC and will contain a set of materials including but not limited to SCA composite and related SCA files, WS-BPEL files, WSDL files, XSD files.

The TC shall develop the test suite in collaboration with other TCs within the Open-CSA Member Section.

The following material should be considered as best practice for the preparation of conformance and test suite materials:

From OASIS: material on specification conformance statements:
http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf

From the W3C, material on specification variability, test metadata and specification clarity:
http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/
http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/
http://www.w3.org/TR/qaframe-spec/

Out of Scope

The following are explicitly out of scope for the SCA BPEL TC:

Any changes to the WS-BPEL language as published by OASIS [1]
Definitions of any new profiles of WS-BPEL
Extensions to the WS-BPEL language that are not related to SCA, as directed by the SCA specifications model
Abstract WS-BPEL
Additional workflow, orchestration and choreography languages and notation

Deliverables

The TC has the following set of deliverables:

A revised SCA BPEL Client and Implementation specification inclusive of XML Schema and other ancillary documents, together with a complete set of conformance statements
A complete Test Suite specification for the SCA BPEL C+I Specification, including documents and the related materials described in the scope section

An approved Test Suite is scheduled for completion within 12 months of the first TC meeting. The TC may decide to change the names of the documents included in the starting point contribution, and the TC may decide to modularize into multiple documents.

Exit Criteria

The TC shall define concrete exit criteria that include at least two independent offerings that implement and are compliant with the all normative portions of specifications and demonstrate interoperability and portability as appropriate. Note that these are minimums and that the TC is free to set more stringent criteria.

Maintenance

Once the TC has completed work on a deliverable and it has become an OASIS standard, the TC will enter "maintenance mode" for the deliverable.

The purpose of maintenance mode is to provide minor revisions to previously adopted deliverables to clarify ambiguities, inconsistencies and obvious errors. Maintenance mode is not intended to enhance a deliverable or extend its functionality.

The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and shall periodically create a new minor revision of the deliverables including these updates. Periodically, but at least once a year, the TC shall produce and vote upon a new minor revision of the deliverables.

IPR Mode

The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy.

Anticipated Audience

The anticipated audience for the documents produced by this TC includes:

Software product vendors supporting Service Component Architecture and BPEL
Software developers, architects and other roles involved with design, development, deployment and maintenance of SCA components implemented in BPEL

Language

The TC shall conduct its proceedings in English.

Non-normative Information Regarding the Startup of the TC

Related and Similar Work

This work builds upon the WS-BPEL OASIS Standard, by enabling that language to be used as a first class citizen within an SCA environment. Similar TCs will exist for enabling other languages in SCA, notably Java.

Proposed Date, Time, and Location of First TC Meeting

Date: Sept 4, 2007
Time: 10:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: IBM

Date: Sept 18, 2007
Time: 09:00 EDT
Duration: 3 days (in parallel with F2F meetings of other
TCs affiliated with this member section)
Mode: F2F meeting in East-Coast USA location (location TBC)
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: IBM

Ongoing Schedule

Biweekly 60 Minute teleconferences sponsored by TBC.
Time TBC by the TC.

It is anticipated that the committee will meet face-to-face once every quarter at a date and venue to be decided by the TC, but with a commitment to hold meetings in different regions of the world so as to share the effort of travel.

Supporters

The following eligible individuals are in support of this proposal:

Martin Chapman, Oracle, martin.chapman@oracle.com
Mike Edwards, IBM, mike_edwards@uk.ibm.com
Ivana Trickovic, SAP ivana.trickovic@sap.com
Alex Yiu, Oracle, alex.yiu@oracle.com
Sanjay Patil, SAP, sanjay.patil@sap.com
Khanderao Kand, Oracle, khanderao.kand@oracle.com
Dieter Kvnig, IBM, dieterkoenig@de.ibm.com
Sabin Ielceanu, TIBCO, sabin@tibco.com
Michael Rowley, BEA, mrowley@bea.com
James Pasley, Cape Clear, james.pasley@capeclear.com

Convenor

Mike Edwards, IBM, mike_edwards@uk.ibm.com

Name of Member Section to Which This TC is Affiliated

Open CSA member section

Anticipated Contributions

It is expected that the Open SOA Collaboration [3] will contribute the SCA BPEL Client and Implementation Specification [2], and any other related documents such as errata, etc, and such documents will be the starting point contribution for initiating the work of this TC.

Draft FAQ Document

Intentionally left empty.

Proposed Working Title

Service Component Architecture BPEL Client and Implementation Specification

References

[1] WS-BPEL Version 2.0, OASIS Standard, April 2007

[2] SCA BPEL Client and Implementation, V1.00, March 2007
http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf

[3] SCA Assembly Model, V1.00, March 2007
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf

[4] Open SOA Collaboration
http://www.osoa.org

[Source: http://lists.oasis-open.org/archives/tc-announce/200707/msg00004.html]

Prepared by Robin Cover for The XML Cover Pages archive. News story: "Six Technical Committees Proposed for the OASIS Open CSA Member Section." See also the 2007-03-21 news story: "Open SOA Collaboration Vendors Advance SCA and SDO Specs for Standardization." The OSOA Collaboration represented by eighteen leading technology vendors announced that key Service Component Architecture (SCA) and Service Data Objects (SDO) Final Specifications have completed incubation and will be submitted to OASIS and the Java Community Process (JCP) for standardization. SCA provides an executable model for composition of individual service components into a service network. SDO supports format-independent handling of business data.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	OASIS TC Charter Proposal: SCA-BPEL OASIS Open CSA Member Section: SCA-BPEL TC Charter Proposal Subject: Proposed Charter for OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee - 5 of 6 From: "Mary McRae" <mary.mcrae@oasis-open.org> To: <members@lists.oasis-open.org>, <tc-announce@lists.oasis-open.org> Date: Mon, 2 Jul 2007 09:26:49 -0400 To OASIS Members: A draft TC charter has been submitted to establish the OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee. In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process.php#2.2) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 16 July 2007. OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail. A telephone conference will be held among the Convenor, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar. We encourage member comment and ask that you note the name of the proposed TC (SCA-BPEL) in the subject line of your email message. Regards, Mary Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae@oasis-open.org web: www.oasis-open.org phone: 603.232.9090 Proposed Charter for Review and Comment OASIS Service Component Architecture BPEL TC Contents Normative Information Name Member Section Affiliation Statement of Purpose Scope Upwards Compatibility Conformance Test Suite Out of Scope Deliverables Exit Criteria Maintenance IPR Mode Anticipated Audience Language Non-normative Information Regarding the Startup of the TC Related and Similar Work Proposed Date, Time, and Location of First TC Meeting Ongoing Schedule Supporters Convenor Name of Member Section to Which This TC is Affiliated Anticipated Contributions Draft FAQ Document Proposed Working Title References Normative Information Name OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee Member Section Affiliation Open CSA Member Section Statement of Purpose The SCA BPEL TC will specify how SCA component implementations can be written using the WS-BPEL language [1]. The SCA WS-BPEL specification must allow any executable WS-BPEL 2.0 and BPEL4WS 1.1 process to be used without any knowledge of SCA. In addition, SCA specific extensions will be defined such that an executable WS-BPEL process may be aware of SCA and take advantage of that environment. This TC will continue development of the SCA BPEL Client and Implementation Specification Version 1.0 [2] and aims to establish it as an OASIS Standard. Scope The SCA Assembly Model defines the environment in which SCA component implementations exist. The SCA WS-BPEL specification must conform to this environment and as a result,the following should be covered by the SCA WS-BPEL specification: 1. Mapping of WS-BPEL PartnerLinks to SCA Services and References. This must take into account: the directionality of the roles in the PartnerLink the initializePartnerRole attribute whether a role is initialized through assignment before it is used 2. Ensure correct behaviour of SCA call-backs and conversations. SCA extensions may be defined to support conversations for SCA aware WS-BPEL implementations. 3. Ensure support for dynamic binding of partner links in SCA environment, especially the wire-by-impl feature. 4. SCA extensions to WS-BPEL to support a PartnerLink that may have multiple partners of the same type. This should provide a simple mechanism to iterate over a number of partners of the same type as in an RFQ interaction, for example. 5. SCA extensions to WS-BPEL to enable SCA properties to be used for initialization purposes. 6. SCA extensions to WS-BPEL to enable other features defined in the SCA specifications to be explicitly used. The TC will accept as input the March 2007 Version 1.0 of the Service Component Architecture (SCA) BPEL Client and Implementation Specification as published by the Open SOA collaboration [2]. The TC will also accept as input for reference the March 2007 Version 1.0 of the other SCA Specifications which were published at the same time as the SCA BPEL Client and Implementation Specification [3]. Other contributions may be made by TC Members on or after the first meeting of the TC. Such other contributions shall be considered by the TC Members on an equal basis to improve the original starting point contribution in a manner that is compliant with this charter. Upwards Compatibility There are no formal requirements for upwards compatibility from the input documents to this TC. This is to ensure that the TC has maximum freedom of action in defining the OASIS standard. However it is recognized that there will be early implementations in the marketplace based upon these input documents and careful consideration must be applied to any change of feature/function that would cause incompatibilities in the OASIS standard at: Source Code level Compiled Object Code XML data definitions At minimum, known enhancements to the input documents that will cause compatibility issues with early implementations in the marketplace will be specified in a chapter in the specification offering migration guidance. Conformance In line with the OASIS TC process, the TC will produce normative conformance information describing the normative characteristics of the specification and specific statements about what an implementation must do to conform to the specification, and what aspects are optional (if any). Test Suite The TC will produce a test suite which can be used to test conformance to the specification which will include: 1. A series of valid and invalid test cases which cover as much as is practical of the conformance statements of the specifications produced by this TC, with a description of each of the artifacts involved, constraints on the environment, the test case characteristics and their expected behavior. The artifacts should include example WS-BPEL implementations used to drive the test cases. 2. With the exception of necessary WS-BPEL implementation test artifacts, the provided artifacts should be independent of implementation language and binding type, and show clear mappings which allow the provision of suitable concrete implementations and concrete binding type, with any required policies. The artifacts may include SCA composites expressed in XML, WSDL interface files, and XSD files, along with other similar files that express the required characteristics of the environment for each test. 3. Example bindings may form part of the test suite, and are only provided as working samples which can be replaced by other specific bindings. The Test Suite shall be packaged separately from the specifications produced by the TC and will contain a set of materials including but not limited to SCA composite and related SCA files, WS-BPEL files, WSDL files, XSD files. The TC shall develop the test suite in collaboration with other TCs within the Open-CSA Member Section. The following material should be considered as best practice for the preparation of conformance and test suite materials: From OASIS: material on specification conformance statements: http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf From the W3C, material on specification variability, test metadata and specification clarity: http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/ http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/ http://www.w3.org/TR/qaframe-spec/ Out of Scope The following are explicitly out of scope for the SCA BPEL TC: Any changes to the WS-BPEL language as published by OASIS [1] Definitions of any new profiles of WS-BPEL Extensions to the WS-BPEL language that are not related to SCA, as directed by the SCA specifications model Abstract WS-BPEL Additional workflow, orchestration and choreography languages and notation Deliverables The TC has the following set of deliverables: A revised SCA BPEL Client and Implementation specification inclusive of XML Schema and other ancillary documents, together with a complete set of conformance statements A complete Test Suite specification for the SCA BPEL C+I Specification, including documents and the related materials described in the scope section An approved Test Suite is scheduled for completion within 12 months of the first TC meeting. The TC may decide to change the names of the documents included in the starting point contribution, and the TC may decide to modularize into multiple documents. Exit Criteria The TC shall define concrete exit criteria that include at least two independent offerings that implement and are compliant with the all normative portions of specifications and demonstrate interoperability and portability as appropriate. Note that these are minimums and that the TC is free to set more stringent criteria. Maintenance Once the TC has completed work on a deliverable and it has become an OASIS standard, the TC will enter "maintenance mode" for the deliverable. The purpose of maintenance mode is to provide minor revisions to previously adopted deliverables to clarify ambiguities, inconsistencies and obvious errors. Maintenance mode is not intended to enhance a deliverable or extend its functionality. The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and shall periodically create a new minor revision of the deliverables including these updates. Periodically, but at least once a year, the TC shall produce and vote upon a new minor revision of the deliverables. IPR Mode The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy. Anticipated Audience The anticipated audience for the documents produced by this TC includes: Software product vendors supporting Service Component Architecture and BPEL Software developers, architects and other roles involved with design, development, deployment and maintenance of SCA components implemented in BPEL Language The TC shall conduct its proceedings in English. Non-normative Information Regarding the Startup of the TC Related and Similar Work This work builds upon the WS-BPEL OASIS Standard, by enabling that language to be used as a first class citizen within an SCA environment. Similar TCs will exist for enabling other languages in SCA, notably Java. Proposed Date, Time, and Location of First TC Meeting Date: Sept 4, 2007 Time: 10:00 EDT Duration: 1 hour Mode: Teleconference Telephone: Dial-in TBC, along with e-Meeting facilities Sponsor: IBM Date: Sept 18, 2007 Time: 09:00 EDT Duration: 3 days (in parallel with F2F meetings of other TCs affiliated with this member section) Mode: F2F meeting in East-Coast USA location (location TBC) Telephone: Dial-in TBC, along with e-Meeting facilities Sponsor: IBM Ongoing Schedule Biweekly 60 Minute teleconferences sponsored by TBC. Time TBC by the TC. It is anticipated that the committee will meet face-to-face once every quarter at a date and venue to be decided by the TC, but with a commitment to hold meetings in different regions of the world so as to share the effort of travel. Supporters The following eligible individuals are in support of this proposal: Martin Chapman, Oracle, martin.chapman@oracle.com Mike Edwards, IBM, mike_edwards@uk.ibm.com Ivana Trickovic, SAP ivana.trickovic@sap.com Alex Yiu, Oracle, alex.yiu@oracle.com Sanjay Patil, SAP, sanjay.patil@sap.com Khanderao Kand, Oracle, khanderao.kand@oracle.com Dieter Kvnig, IBM, dieterkoenig@de.ibm.com Sabin Ielceanu, TIBCO, sabin@tibco.com Michael Rowley, BEA, mrowley@bea.com James Pasley, Cape Clear, james.pasley@capeclear.com Convenor Mike Edwards, IBM, mike_edwards@uk.ibm.com Name of Member Section to Which This TC is Affiliated Open CSA member section Anticipated Contributions It is expected that the Open SOA Collaboration [3] will contribute the SCA BPEL Client and Implementation Specification [2], and any other related documents such as errata, etc, and such documents will be the starting point contribution for initiating the work of this TC. Draft FAQ Document Intentionally left empty. Proposed Working Title Service Component Architecture BPEL Client and Implementation Specification References [1] WS-BPEL Version 2.0, OASIS Standard, April 2007 [2] SCA BPEL Client and Implementation, V1.00, March 2007 http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf [3] SCA Assembly Model, V1.00, March 2007 http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf [4] Open SOA Collaboration http://www.osoa.org [Source: http://lists.oasis-open.org/archives/tc-announce/200707/msg00004.html] Prepared by Robin Cover for The XML Cover Pages archive. News story: "Six Technical Committees Proposed for the OASIS Open CSA Member Section." See also the 2007-03-21 news story: "Open SOA Collaboration Vendors Advance SCA and SDO Specs for Standardization." The OSOA Collaboration represented by eighteen leading technology vendors announced that key Service Component Architecture (SCA) and Service Data Objects (SDO) Final Specifications have completed incubation and will be submitted to OASIS and the Java Community Process (JCP) for standardization. SCA provides an executable model for composition of individual service components into a service network. SDO supports format-independent handling of business data.