OASIS TC Charter Proposal: SCA-Bindings

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

Subject: Proposed Charter for OASIS Service Component Architecture Bindings
         TC - 3 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:09:35 -0400

To OASIS Members:

A draft TC charter has been submitted to establish the OASIS Service Component Architecture Bindings (SCA Bindings) 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-Bindings) 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 Bindings TC

Contents

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

Normative Material

Name

OASIS Service Component Architecture Bindings (SCA Bindings) Technical Committee

Member Section Affiliation

Open CSA Member Section (Open CSA MS)

Statement of Purpose

The purpose of this Technical Committee [TC] is to standardize bindings for the SCA services and references to various communication protocols, technologies and frameworks. In particular, this TC shall continue development of the following SCA Binding specifications and aim to establish them as OASIS Standards:

SCA Web Services Binding [1]
SCA JMS Binding [2]
SCA JCA Binding [3]

Scope

One of the goals of SCA is to allow binding of SCA services and references to a variety of communication protocols and technologies in a declarative manner. The primary focus of this TC will be to define bindings of SCA services and references to Web Service, Java Message Service (JMS) [8] and J2EE Connector Architecture (JCA) [9] technologies based on the following starting point contribution:

SCA Web Service Binding specification [1]
SCA JMS Binding specification [2]
SCA JCA Binding 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.

For each SCA binding technology this TC will evolve the respective starting point contribution documents to produce one or more specification documents, XML Schema definition documents, possible WSDL documents, and possible language dependant artifacts as appropriate, from which compliant tools and runtimes for that SCA binding technology can be built.

The TC will not explore areas with general applicability and for which typically standards exist. The TC will make efforts to compose with existing standards providing such general functionality.

Following is a list of generic requirements for any binding specification. For each binding specification, the TC shall identify the applicable subset and specify solutions accordingly.

Specify whether the binding is applicable to both the Service and Reference elements
Support for applying the binding to local and remotable interfaces
Support for bi-directional and conversational interfaces (as defined in the SCA Assembly specification)
Description of binding endpoint address formats, including how a URI scheme of a deployed binding can be determined
Identify the intents that the binding type must provide or may provide
Define how to share metadata across different binding instances
Define how to correlate request/response messages
Define how to configure request/response channels
Define the mapping of SCA defined binding metadata to the relevant resource or service description standards
Define the mechanism for selecting the operation targeted by a message, and binding the message data to the runtime representation (this functionality is commonly called as - operation selection/data binding)
Define how to configure binding specific headers, user defined properties and interaction parameters
Define how to support user authentication and security context propagation
Ensure alignment with the generic binding architecture in the SCA Assembly Specification

In addition to the generic requirements above, each binding has specific requirements which are listed below. Note that the list of out-of-scope features and mechanisms is not exhaustive. In general, areas that are not explicitly listed as within the scope should be considered as out-of-scope.

SCA Web Service Binding

SCA Web Service Binding defines how a SCA service can be made available as a Web Service and how a SCA reference can invoke a Web Service.

The scope of the SCA Web Service Binding work, in addition to the generic list above, includes the following functions and mechanisms:

Use existing WSDL 1.1 [4] and WSDL 2.0 [5] documents for the metadata required by SCA WS Binding including any valid WSDL binding
Define SCA metadata to describe the Web Service binding of SCA services and references that use SOAP and are WS-I compliant
Rules for generating WSDL 1.1 and WSDL 2.0 documents based on the SCA Web Service metadata
Use of WS-Addressing [6] endpoint reference for describing the SCA Web Service binding
Rules for determining the effective URI for the binding
Mechanism for retrieving WSDL description for SCA services that are deployed using SCA Web Service binding

The following functions and mechanism are considered as out-of-scope for the SCA Web Service Binding work:

Ensuring interoperability of SCA Web Service Bindings that utilize existing WSDL documents and those that include non standard WSDL extensions
Defining SCA binding metadata for non-WS-I compliant Web services
Defining SCA binding metadata for non-SOAP based Web services
Mapping of the WSDL type system with other interface type systems such as Java interfaces
Metadata specific to implementation of the services e.g., references to JAX-WS handlers to be invoked as part of dispatching a service request
Support for SOAP intermediaries
Defining new wire-level protocols for exchanging conversation identifiers and state. Conversation support may be addressed by reference to existing web service standards

SCA JMS Binding

SCA JMS Binding defines JMS specific details to provide SCA service as a JMS resource or to consume a JMS resource as a SCA reference.

The scope of the SCA JMS Binding work, in addition to the generic list above, includes the following functions and mechanisms:

Binding of SCA services and references to existing or new JMS resources (destinations or connectionFactories)
Binding of SCA services and references to existing or new activationSpecs for JCA 1.5 compliant JMS resource adapters

SCA JCA Binding

SCA JCA Binding defines JCA specific details for access and connectivity to EIS systems external to an SCA system. JCA Binding can be used for SCA services and references.

The scope of the SCA JCA Binding work, in addition to the generic list above, includes the following functions and mechanisms:

Configuration of connection parameters for access to EIS via JCA
Support for managed and unmanaged environments (as defined in the J2EE Connector Architecture specification [9])

The following is considered as out-of-scope for the SCA JCA Binding work:

Specific support for any particular EIS system

Other Bindings

The TC MAY define other bindings explicitly listed below. Before work commences on any of these, the TC Charter MUST be clarified (by following the TC Charter Clarification rules defined in the OASIS Technical Committee Process document) to scope the work of each of the following technologies.

HTTP
REST
SMTP
FTP
SIP
SNMP
JSON-RPC
ATOM
RSS

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 specifications and specific statements about what an implementation must do to conform to the specifications, what aspects are optional (if any).

Test Suite

The TC will produce a test suite for each binding which can be used to test conformance to the specifications which will include:

1. Describe 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.

2. The provided artifacts should be independent of implementation language. The artifacts may include SCA composites expressed in XML, WSDL interface files, and XSD files, sca-definition.xml files along with other similar files that express the required characteristics of the environment for each test.

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

The test suites shall be packaged separately from the specifications produced by the TC and will contain a set of materials including but not limited to SCA composites and related SCA files, WSDL files, XSD files.

The TC shall develop the test suites 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/

Deliverables

The TC has the following set of deliverables:

A revised SCA Web Services Binding specification inclusive of XML Schema and other ancillary documents.
A revised SCA JMS Binding specification inclusive of XML Schema and other ancillary documents.
A revised SCA JCA Binding specification inclusive of XML Schema and other ancillary documents.
A complete Test Suite specification for each binding, including documents and the related materials described in the scope section.

All of the above deliverables are scheduled for completion within 12 months of the first TC meeting. The TC may decide to modularize and produced more number of specification documents out of the starting point contribution or on the contrary the TC may decide to merge and produce less number of specification documents than the starting point contribution. Similarly, the TC may decide to change the names of the documents included in the starting point contribution.

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
Software developers, architects and other roles involved with design, development, deployment and maintenance of SCA compositions involving bindings to service interaction technologies such as Web services, Java Message System, J2EE Connector Architecture, etc
Authors of other specifications that extend and/or compose with the specifications developed by this TC

Language

The TC shall conduct its proceedings in English.

References

[1] SCA Web Service Binding Specification, Version 1.0, March 2007
http://www.osoa.org/download/attachments/35/SCA_WebServiceBinding_V100.pdf

[2] SCA JMS Binding Specification, Version 1.0, March 2007
http://www.osoa.org/download/attachments/35/SCA_JMSBinding_V100.pdf

[3] SCA JCA Binding Specification Draft
http://osoa.org/download/attachments/35/SCA_JCABindings_v097_draft1.pdf?version=1

[4] WSDL 1.1
http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[5] WSDL 2.0
http://www.w3.org/TR/wsdl20-extensions
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803

[6] WS-Addressing
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/

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

[8] JMS Specification
http://jcp.org/en/jsr/detail?id=914

[9] J2EE Connector Architecture Specification
http://jcp.org/en/jsr/detail?id=112

Non-normative Information Regarding the Startup of the TC

Related and Similar Work

Each SCA Binding specification builds upon one or more existing specifications in that domain. For example, SCA Web Service Binding specifications build upon WSDL and SOAP technologies. The goal of any given SCA Binding specification is to simplify the utilization of the underlying technologies in that domain and not to replace them.

Proposed Date, Time, and Location of First TC Meeting

Date: Sept 6, 2007
Time: 12:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC
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

Weekly 60 Minute teleconferences sponsored by TBC
Time TBC by the TC

Supporters

Martin Chapman, Oracle, martin.chapman@oracle.com
Anish Karmarkar, Oracle, anish.karmarkar@oracle.com
Simon Holdsworth, IBM, simon_holdsworth@uk.ibm.com
Sanjay Patil, SAP, sanjay.patil@sap.com
Michael Rowley, BEA, mrowley@bea.com
Sabin Ielceanu, TIBCO, sabin@tibco.com
Piotr Przybylski, IBM, piotrp@us.ibm.com
Mike Edwards, IBM, mike_edwards@uk.ibm.com
Glen Daniels, Progress, gdaniels@progress.com
Kimberly Palko, Progress, kpalko@progress.com
Ron Ten-Hove, Sun Microsystems, Ronald.Ten-Hove@Sun.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 [7] will contribute the SCA Binding Specifications [1], [2], [3] 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 Web Service Binding Specification
Service Component Architecture Java Message System (JMS) Binding Specification
Service Component Architecture J2EE Connector Architecture (JCA) Binding Specification

[Source: http://lists.oasis-open.org/archives/tc-announce/200707/msg00002.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-Bindings OASIS Open CSA Member Section: SCA-Bindings TC Charter Proposal Subject: Proposed Charter for OASIS Service Component Architecture Bindings TC - 3 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:09:35 -0400 To OASIS Members: A draft TC charter has been submitted to establish the OASIS Service Component Architecture Bindings (SCA Bindings) 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-Bindings) 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 Bindings TC Contents Normative Material Name Member Section Affiliation Statement of Purpose Scope SCA Web Service Binding SCA JMS Binding SCA JCA Binding Other Bindings Upwards Compatibility Conformance Test Suite Deliverables Exit Criteria Maintenance IPR Mode Anticipated Audience Language References 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 Normative Material Name OASIS Service Component Architecture Bindings (SCA Bindings) Technical Committee Member Section Affiliation Open CSA Member Section (Open CSA MS) Statement of Purpose The purpose of this Technical Committee [TC] is to standardize bindings for the SCA services and references to various communication protocols, technologies and frameworks. In particular, this TC shall continue development of the following SCA Binding specifications and aim to establish them as OASIS Standards: SCA Web Services Binding [1] SCA JMS Binding [2] SCA JCA Binding [3] Scope One of the goals of SCA is to allow binding of SCA services and references to a variety of communication protocols and technologies in a declarative manner. The primary focus of this TC will be to define bindings of SCA services and references to Web Service, Java Message Service (JMS) [8] and J2EE Connector Architecture (JCA) [9] technologies based on the following starting point contribution: SCA Web Service Binding specification [1] SCA JMS Binding specification [2] SCA JCA Binding 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. For each SCA binding technology this TC will evolve the respective starting point contribution documents to produce one or more specification documents, XML Schema definition documents, possible WSDL documents, and possible language dependant artifacts as appropriate, from which compliant tools and runtimes for that SCA binding technology can be built. The TC will not explore areas with general applicability and for which typically standards exist. The TC will make efforts to compose with existing standards providing such general functionality. Following is a list of generic requirements for any binding specification. For each binding specification, the TC shall identify the applicable subset and specify solutions accordingly. Specify whether the binding is applicable to both the Service and Reference elements Support for applying the binding to local and remotable interfaces Support for bi-directional and conversational interfaces (as defined in the SCA Assembly specification) Description of binding endpoint address formats, including how a URI scheme of a deployed binding can be determined Identify the intents that the binding type must provide or may provide Define how to share metadata across different binding instances Define how to correlate request/response messages Define how to configure request/response channels Define the mapping of SCA defined binding metadata to the relevant resource or service description standards Define the mechanism for selecting the operation targeted by a message, and binding the message data to the runtime representation (this functionality is commonly called as - operation selection/data binding) Define how to configure binding specific headers, user defined properties and interaction parameters Define how to support user authentication and security context propagation Ensure alignment with the generic binding architecture in the SCA Assembly Specification In addition to the generic requirements above, each binding has specific requirements which are listed below. Note that the list of out-of-scope features and mechanisms is not exhaustive. In general, areas that are not explicitly listed as within the scope should be considered as out-of-scope. SCA Web Service Binding SCA Web Service Binding defines how a SCA service can be made available as a Web Service and how a SCA reference can invoke a Web Service. The scope of the SCA Web Service Binding work, in addition to the generic list above, includes the following functions and mechanisms: Use existing WSDL 1.1 [4] and WSDL 2.0 [5] documents for the metadata required by SCA WS Binding including any valid WSDL binding Define SCA metadata to describe the Web Service binding of SCA services and references that use SOAP and are WS-I compliant Rules for generating WSDL 1.1 and WSDL 2.0 documents based on the SCA Web Service metadata Use of WS-Addressing [6] endpoint reference for describing the SCA Web Service binding Rules for determining the effective URI for the binding Mechanism for retrieving WSDL description for SCA services that are deployed using SCA Web Service binding The following functions and mechanism are considered as out-of-scope for the SCA Web Service Binding work: Ensuring interoperability of SCA Web Service Bindings that utilize existing WSDL documents and those that include non standard WSDL extensions Defining SCA binding metadata for non-WS-I compliant Web services Defining SCA binding metadata for non-SOAP based Web services Mapping of the WSDL type system with other interface type systems such as Java interfaces Metadata specific to implementation of the services e.g., references to JAX-WS handlers to be invoked as part of dispatching a service request Support for SOAP intermediaries Defining new wire-level protocols for exchanging conversation identifiers and state. Conversation support may be addressed by reference to existing web service standards SCA JMS Binding SCA JMS Binding defines JMS specific details to provide SCA service as a JMS resource or to consume a JMS resource as a SCA reference. The scope of the SCA JMS Binding work, in addition to the generic list above, includes the following functions and mechanisms: Binding of SCA services and references to existing or new JMS resources (destinations or connectionFactories) Binding of SCA services and references to existing or new activationSpecs for JCA 1.5 compliant JMS resource adapters SCA JCA Binding SCA JCA Binding defines JCA specific details for access and connectivity to EIS systems external to an SCA system. JCA Binding can be used for SCA services and references. The scope of the SCA JCA Binding work, in addition to the generic list above, includes the following functions and mechanisms: Configuration of connection parameters for access to EIS via JCA Support for managed and unmanaged environments (as defined in the J2EE Connector Architecture specification [9]) The following is considered as out-of-scope for the SCA JCA Binding work: Specific support for any particular EIS system Other Bindings The TC MAY define other bindings explicitly listed below. Before work commences on any of these, the TC Charter MUST be clarified (by following the TC Charter Clarification rules defined in the OASIS Technical Committee Process document) to scope the work of each of the following technologies. HTTP REST SMTP FTP SIP SNMP JSON-RPC ATOM RSS 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 specifications and specific statements about what an implementation must do to conform to the specifications, what aspects are optional (if any). Test Suite The TC will produce a test suite for each binding which can be used to test conformance to the specifications which will include: 1. Describe 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. 2. The provided artifacts should be independent of implementation language. The artifacts may include SCA composites expressed in XML, WSDL interface files, and XSD files, sca-definition.xml files along with other similar files that express the required characteristics of the environment for each test. 3. Example implementations and bindings may form part of the test suite, and are only provided as working samples which can be replaced by other specific implementations and bindings. The test suites shall be packaged separately from the specifications produced by the TC and will contain a set of materials including but not limited to SCA composites and related SCA files, WSDL files, XSD files. The TC shall develop the test suites 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/ Deliverables The TC has the following set of deliverables: A revised SCA Web Services Binding specification inclusive of XML Schema and other ancillary documents. A revised SCA JMS Binding specification inclusive of XML Schema and other ancillary documents. A revised SCA JCA Binding specification inclusive of XML Schema and other ancillary documents. A complete Test Suite specification for each binding, including documents and the related materials described in the scope section. All of the above deliverables are scheduled for completion within 12 months of the first TC meeting. The TC may decide to modularize and produced more number of specification documents out of the starting point contribution or on the contrary the TC may decide to merge and produce less number of specification documents than the starting point contribution. Similarly, the TC may decide to change the names of the documents included in the starting point contribution. 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 Software developers, architects and other roles involved with design, development, deployment and maintenance of SCA compositions involving bindings to service interaction technologies such as Web services, Java Message System, J2EE Connector Architecture, etc Authors of other specifications that extend and/or compose with the specifications developed by this TC Language The TC shall conduct its proceedings in English. References [1] SCA Web Service Binding Specification, Version 1.0, March 2007 http://www.osoa.org/download/attachments/35/SCA_WebServiceBinding_V100.pdf [2] SCA JMS Binding Specification, Version 1.0, March 2007 http://www.osoa.org/download/attachments/35/SCA_JMSBinding_V100.pdf [3] SCA JCA Binding Specification Draft http://osoa.org/download/attachments/35/SCA_JCABindings_v097_draft1.pdf?version=1 [4] WSDL 1.1 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 [5] WSDL 2.0 http://www.w3.org/TR/wsdl20-extensions http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 [6] WS-Addressing http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/ [7] Open SOA Collaboration http://www.osoa.org [8] JMS Specification http://jcp.org/en/jsr/detail?id=914 [9] J2EE Connector Architecture Specification http://jcp.org/en/jsr/detail?id=112 Non-normative Information Regarding the Startup of the TC Related and Similar Work Each SCA Binding specification builds upon one or more existing specifications in that domain. For example, SCA Web Service Binding specifications build upon WSDL and SOAP technologies. The goal of any given SCA Binding specification is to simplify the utilization of the underlying technologies in that domain and not to replace them. Proposed Date, Time, and Location of First TC Meeting Date: Sept 6, 2007 Time: 12:00 EDT Duration: 1 hour Mode: Teleconference Telephone: Dial-in TBC 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 Weekly 60 Minute teleconferences sponsored by TBC Time TBC by the TC Supporters Martin Chapman, Oracle, martin.chapman@oracle.com Anish Karmarkar, Oracle, anish.karmarkar@oracle.com Simon Holdsworth, IBM, simon_holdsworth@uk.ibm.com Sanjay Patil, SAP, sanjay.patil@sap.com Michael Rowley, BEA, mrowley@bea.com Sabin Ielceanu, TIBCO, sabin@tibco.com Piotr Przybylski, IBM, piotrp@us.ibm.com Mike Edwards, IBM, mike_edwards@uk.ibm.com Glen Daniels, Progress, gdaniels@progress.com Kimberly Palko, Progress, kpalko@progress.com Ron Ten-Hove, Sun Microsystems, Ronald.Ten-Hove@Sun.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 [7] will contribute the SCA Binding Specifications [1], [2], [3] 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 Web Service Binding Specification Service Component Architecture Java Message System (JMS) Binding Specification Service Component Architecture J2EE Connector Architecture (JCA) Binding Specification [Source: http://lists.oasis-open.org/archives/tc-announce/200707/msg00002.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.