Scope
The scope of this TC includes work to define any of the following:
-
Java annotations and API's for 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 Java EE 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:
-
Web Components
-
EJB Components
-
Session Beans
-
Message-Driven Beans
-
JAX-WS annotated session beans
-
JAX-WS Components
-
JCA Resource Adapter Components
-
SCA implementation types for Java EE module types, such as EJB JARs and EARs.
-
SCA deployment for Java EE
-
For Enterprise Application packages (.ear)
-
For single module packages (ejb-jar, .war, .rar)
-
The use of SCA assembly:
-
Within the deployment package that can be used with Java EE
-
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:
-
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.
-
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:
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.
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.
