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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: [FWD: [members] Proposed Charter for OASIS Service Component Architecture Bindings TC - 3 of 6]

Hmmm.  Eventually this will allow us additional options for REST interfaces...

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: [members] Proposed Charter for OASIS Service Component
Architecture Bindings TC - 3 of 6
From: "Mary McRae" <mary.mcrae@oasis-open.org>
Date: Mon, July 02, 2007 9:09 am
To: <members@lists.oasis-open.org>,  <tc-announce@lists.oasis-open.org>
Cc: <oasis-charter-discuss@lists.oasis-open.org>,

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:
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-Bindings) in the subject line of
your email message. 


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


OASIS Service Component Architecture Bindings TC

1. Normative Material

a. Name

OASIS Service Component Architecture Bindings (SCA Bindings) Technical

Member Section Affiliation

Open CSA Member Section (Open CSA MS)

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

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
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
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
*	Specify whether the binding is applicable to both the Service and
*	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
*	Ensure alignment with the generic binding architecture in the SCA

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
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
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 
*	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
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
(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 

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


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
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
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
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
and other ancillary documents.  
*	A revised SCA JMS Binding specification inclusive of XML Schema and
ancillary documents.  
*	A revised SCA JCA Binding specification inclusive of XML Schema and
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
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

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 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
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: 12:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC
Sponsor: IBM

Date: Sept 18
Time: 09:00 EDT
Duration: 3 days (in parallel with F2F meetings of other TCs
affiliated with this member 
Mode: F2F meeting in East-Coast USA location (location TBC)
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: IBM

c. On-going schedule

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

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

e. Convener:

Mike Edwards, IBM, mike_edwards@uk.ibm.com

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

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 Java Message System (JMS) Binding
Service Component Architecture J2EE Connector Architecture (JCA) Binding 


This email list is used solely by OASIS for official consortium

Opt-out requests may be sent to member-services@oasis-open.org,
however, all members are strongly encouraged to maintain a
subscription to this list.

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