To OASIS Members:
A draft TC charter has been submitted to establish the OASIS Service Component Architecture for Java(tm) (SCA J)
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 Convener, 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-J) 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 FOR
JAVA(TM) TC
1. Normative information
a. Name
OASIS Service Component Architecture for Java(tm) (SCA J) Technical Committee
Member Section Affiliation
Open CSA Member Section
b. Statement of Purpose
The purpose of the OASIS SCA-J Technical Committee (TC) is to develop specifications that
standardize the use of the use of Java(tm) technologies within an SCA domain. This TC is part of
the Open-CSA member section and its work must be coordinated with the work of the other TCs
in the member section.
The TC will define:
* APIs and annotations that facilitate the declaration and use of SCA constructs from Java.
* A Java-based programming model for creating SCA component implementations that
depends only on Java Standard Edition, version 5 or greater.
* A Java-based programming model for creating SCA component implementations that use
the technologies of the Spring Framework Core.
* Mechanisms that allow an SCA domain to use and interoperate with constructs defined
by Java Enterprise Edition, enabling the following scenarios:
1. Accessing EJB session beans that have been deployed to JavaEE runtimes through SCA
references that use an EJB-specific binding.
2. Providing SCA services through an EJB session bean binding.
3. Consumption of SCA-exposed services from Java EE components in an SCA-aware
JavaEE runtime.
4. Use of Java EE components as Service Component Implementations.
5. Use of recursive SCA assembly in Java EE applications.
6. Use of Java EE modules as Service Component Implementations.
The work of this committee will be based the following specifications, submitted to the TC as a
reference:
* SCA Java Component Implementation Specification
* SCA Java Common Annotations and APIs
* SCA Spring Component Implementation
* SCA EJB(tm) Session Bean Binding
c. Scope
The scope of this TC includes work to define any of the following:
* Java annotations and API'sfor declaring, using or configuring any SCA-related construct.
* Java API's for accessing and manipulating data that is associated with the runtime
context of an SCA component or client.
* A Java-based programming model for creating SCA component implementations that
depends only on Java Standard Edition, version 5 or greater.
* A Java-based programming model for creating SCA component implementations that
use the technologies of the Spring Framework Core.
* An EJB session bean binding that allows access to services that are deployed as
JavaEE EJBs or to make SCA services available as EJBs.
* Java-specific characteristics of the packaging format used for an SCA contribution that
may be deployed to Java-based runtimes.
* Mechanisms for resolving Java class names, QNames and other artifact references
within a Java-based SCA runtime. Such a mechanism may make use of existing
standardized artifact resolution mechanisms.
* Annotations for standard policy intents that may be used by components in a Java-
based SCA runtime.
The following additional in-scope items relate to the development of a specification for the
integration of SCA with Java EE:
* SCA implementation types for components of Java EE programming models:
1. Web Components
2. EJB Components
a. Session Beans
b. Message-Driven Beans
c. JAX-WS annotated session beans
3. JAX-WS Components
4. JCA Resource Adapter Components
* SCA implementation types for Java EE module types, such as EJB JARs and EARs.
* SCA deployment for Java EE
1. For Enterprise Application packages (.ear)
2. For single module packages (ejb-jar, .war, .rar)
* The use of SCA assembly:
1. Within the deployment package that can be used with JavaEE
2. Over existing packages within the SCA Domain
* Definition of the relationship between policy equivalents in Java EE and the SCA policies
framework
* Defining constructs for accessing SCA components from Java EE presentation tier
technologies.
Out of Scope
The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function,
mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section
either, then it will be deemed to be out of scope.
The TC will not define Service Provider Interfaces (SPIs) that may be used to extend a Java
based SCA runtime.
The TC will not define APIs that modify the contents of an installed composite definition.
The TC will not define API's related to managing a Java-based SCA runtime, including:
* Java APIs for initiating and shutting down a runtime that can host SCA components or
clients.
* Java APIs associated with the deployment of SCA components (including composites).
The TC will not define new SCA implementation types, other than those mentioned in the in-
scope section.
The TC will not define SCA intents or policy sets.
The TC will not define any wire-level protocols.
The TC will not define a mapping of user-defined data formats (in XML or otherwise) into or out of
Java constructs.
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.
2. 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, Java
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 & 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/
d. Deliverables
The TC has the following set of deliverables.
* A revised SCA Java Component Implementation Specification.
* A revised SCA Java Common Annotations and APIs Specification
* A revised SCA Spring Component Implementation Specification
* A revised SCA EJB Session Bean Binding Specification.
* A specification that standardizes SCA integration with Java EE
These specifications will reflect refinements, corrections or material technological improvements
with respect to the input documents and in accordance with this charter.
Ratification of the above specifications as OASIS Standards, including a brief period to address
any errata, will mark the end of the TC's lifecycle.
The TC may choose to vary the number of the specification documents and their titles.
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.
e. IPR Mode
The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy.
f. Anticipated Audience
The anticipated audience for this work includes:
* Vendors offering Java-based SCA runtimes;
* Other specification authors that need Java APIs and annotations for SCA constructs.
* Software architects and programmers, who design, write or integrate SCA applications.
g. Language
TC business will be conducted in English.
2. Non-normative information regarding the startup of the TC
a. Related and similar work
The SCA specifications are intended to encompass a range of technologies which are
useful in implementing service-oriented solutions. These include the range of Web-
services related specifications such as WSDL and SOAP, the various WS-Security
specifications, WS-Addressing, WS-Notification. The list is extensive and there is no
limit to the relevance of these specifications to SCA. SCA does not intend to replace
these specifications, but to build upon them.
Other existing technologies such as Java Enterprise Edition, the Spring Framework and
CORBA also have a relationship to SCA and SCA anticipates optionally using these in
relevant parts of the specifications (eg to define specific implementation types for
artifacts such as JEE EJBs and Spring application contexts).
b. Proposed date, time, and location of first TC meeting
Date: Sept 6
Time: 13:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: SAP
Date: Sept 18
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: SAP
c. On-going schedule
Weekly 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.
d. Supporters:
The following eligible individuals are in support of this proposal:
Michael Rowley, BEA, mrowley@bea.com
Michael Beisiegel, IBM, mbgl@us.ibm.com
Jim Marino, BEA, jmarino@bea.com
Anish Karmarkar, Oracle, anish.karmarkar@oracle.com
Henning Blohm, SAP, henning.blohm@sap.com
Ron Barack, SAP, ron.barack@sap.com
Adrian Colyer, Interface21, adrian.colyer@interface21.com
Scott Vorthmann, TIBCO, scottv@tibco.com
Dave Booz, IBM, booz@us.ibm.com
Mike Edwards, IBM, mike_edwards@uk.ibm.com
Peter Peshev, SAP, peter.peshev@sap.com
Peter Walker, Sun Microsystems, peter.walker@sun.com
Glen Daniels, Progress, gdaniels@progress.com
Kimberly Palko, Progress, kpalko@progress.com
e. Convener:
Henning Blohm, SAP, henning.blohm@sap.com
f. Name of Member Section to which this TC is Affiliated
Open CSA member section.
g. Anticipated contributions
It is expected that the following SCA Specifications, Version 1.00, as published in March
2007 will be a contributions from the Open SOA Collaboration:
* SCA Java Common Annotations and APIs
* SCA Java Component Implementation
* SCA Spring Component Implementation
(see [2]), along with references to the other SCA Version 1.00 specifications (see [2]),
plus any work performed by the Open SOA collaboration between March 2007 and the
start of the work of the SCA-Assembly TC.
h. Draft FAQ Document
Intentionally left empty.
i. Proposed working title
SCA Java Component Implementation Specification.
SCA Java Common Annotations and APIs Specification
SCA Spring Component Implementation Specification
SCA EJB Session Bean Binding Specification.
SCA Java EE Integration Specification
References
[1] Service Component Archtecture Assembly Specification Version 1.0
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf
[2] Service Component Architecture Version 1.0 Specifications
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.