OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: OASIS Call for Participation: OASIS Service Component Architecture / J (SCA-J) Technical Committee [5 of 6]

To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Service Component Architecture / J (SCA-J) Technical
Committee has been proposed by the members of OASIS listed below.  The proposal, below, meets the requirements of the
OASIS TC Process [a]. The TC name, statement of purpose, scope, list of deliverables, audience, and language specified
in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC, and
the beginning of technical discussions, may occur no sooner than the TC's first meeting.

   This TC will operate under our 2005 IPR Policy [b]. The eligibility requirements for becoming a participant in the TC
at the first meeting (see details below) are that:

   (a) you must be an employee of an OASIS member organization or an individual member of OASIS;
   (b) the OASIS member must sign the OASIS membership agreement [c];
   (c) you must notify the TC chair of your intent to participate at least 15 days prior to the first meeting, which
members may do by using the "Join this TC" button on the TC's public page at [d]; and
   (d) you must attend the first meeting of the TC, at the time and date fixed below.

Of course, participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties.

   Non-OASIS members who wish to participate may contact us about joining OASIS [c]. In addition, the public may access
the information resources maintained for each TC: a mail list archive, document repository and public comments facility,
which will be linked from the TC's public home page at [d].

   Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards
organization; we encourage your feedback.



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

[a] http://www.oasis-open.org/committees/process.php
[b] http://www.oasis-open.org/who/intellectualproperty.php  
[c] See http://www.oasis-open.org/join/ 
[d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-j


1. Normative information

a. Name

OASIS Service Component Architecture / J (SCA-J) Technical Committee

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 JavaT 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:
	o Accessing EJB session beans that have been deployed to JavaEE runtimes through SCA references that use an
EJB-specific binding.
	o Providing SCA services through an EJB session bean binding.
	o Consumption of SCA-exposed services from Java EE components in an SCA-aware JavaEE runtime.
	o Use of Java EE components as Service Component Implementations.
	o Use of recursive SCA assembly in Java EE applications.
	o 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 EJBT Session Bean Binding

c. 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
* 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
* 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:
	o Web Components
	o EJB Components
		* Session Beans
		* Message-Driven Beans
		* JAX-WS annotated session beans
	o JAX-WS Components
	o JCA Resource Adapter Components
* SCA implementation types for Java EE module types, such as EJB JARs and EARs.
* SCA deployment for Java EE
	o For Enterprise Application packages (.ear)
	o For single module packages (ejb-jar, .war, .rar)
* The use of SCA assembly:
	o Within the deployment package that can be used with Java EE
	o 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.


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
* From OASIS: material on specification conformance statements:

* From the W3C, material on specification variability, test metadata & specification clarity:

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.

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.


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

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 7
Time: 1:00pm EDT
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD, 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 TBD location
Telephone: Dial-in TBD, along with e-Meeting facilities
Sponsor: SAP

c. On-going schedule

Weekly 60 Minute teleconferences sponsored by TBD.
Time TBD 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
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
Henning Blohm, SAP, henning.blohm@sap.com
Ron Barack, SAP, ron.barack@sap.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:

Sanjay Patil, sanjay.patil@sap.com

f. Name of Member Section to which this TC is Affiliated

This TC is affiliated with the 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 Service Component Architecture / J Component Implementation Specification.
Service Component Architecture / J Common Annotations and APIs Specification
Service Component Architecture / J Spring Component Implementation Specification
Service Component Architecture / J Session Bean Binding Specification.
Service Component Architecture / J JEE Integration Specification

[1] Service Component Architecture Assembly Specification Version 1.0

[2] Service Component Architecture Version 1.0 Specifications

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]