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 / Bindings (SCA-Bindings) Technical Committee [3 of 6]

To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Service Component Architecture / Bindings (SCA-Bindings)
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-bindings

OASIS Service Component Architecture / Bindings TC

1. Normative Material

a. Name
OASIS Service Component Architecture / Bindings (SCA-Bindings) Technical Committee

b. 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
1. SCA Web Services Binding [1]
2. SCA JMS Binding [2]
3. SCA JCA Binding [3]

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

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:


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 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:

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

d. 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.


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

f. 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

g. Language

The TC shall conduct its proceedings in English.


[1] SCA Web Service Binding Specification, Version 1.0, March 2007

[2] SCA JMS Binding Specification, Version 1.0, March 2007

[3] SCA JCA Binding Specification Draft

[4] WSDL 1.1

[5] WSDL 2.0

[6] WS-Addressing

[7] Open SOA Collaboration

[8]  JMS Specification

[9] J2EE Connector Architecture Specification

2. Non-normative information regarding the startup of the TC

a. 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.

b. Proposed date, time, and location of first TC meeting

Date: Sept 6
Time: 11:00 EDT
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD
Sponsor: IBM

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: IBM

c. On-going schedule

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

d. Supporters

Martin Chapman, Oracle, martin.chapman@oracle.com
Anish Karmarkar, Oracle, anish.karmarkar@oracle.com
Jeff Mischkinsky, Oracle, jeff.mischkinsky@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

e. Convener:

Mike Edwards, IBM, mike_edwards@uk.ibm.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 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.

h. Draft FAQ Document

Intentionally left empty.

i. Proposed working title

Service Component Architecture / Web Service Binding Specification
Service Component Architecture / JMS Binding Specification
Service Component Architecture / JCA Binding Specification

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