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 / C and C++ (SCA-C-C++) Technical Committee [6 of 6]

To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Service Component Architecture / C and C++ (SCA-C-C++)
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-c-cpp


1. Normative information

a. Name

OASIS Service Component Architecture / C and C++ (SCA-C-C++) Technical Committee

b. Statement of Purpose

The purpose of the OASIS SCA-C Technical Committee (TC) is to develop
specifications that standardize the use of C and C++ 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:
* A C++-based programming model for creating SCA component implementations
* A C-based programming model for creating SCA component implementations.
* XSD schema that define extensions to the SCA Assembly Model [1] for C and
  C++ interfaces and implementations
* APIs and annotations that facilitate the declaration and use of SCA
  constructs from C and C++.

The work of this committee will be based the following specifications,
submitted to the TC as a reference:
* SCA Client and Implementation Model Specification for C++ [2]
* SCA Client and Implementation Model Specification for C Draft [3]

c. Scope

The scope of this TC includes work to define any of the following:
* C and C++ APIs and annotations for declaring, using or configuring any
  construct defined by a specification within the Open-CSA member section.
* C and C++ APIs for accessing and manipulating data that is associated the
  runtime context of an SCA component or client.
* C and C++ APIs for initiating and shutting down a runtime that can host SCA
  components or clients.
* C and C++ APIs associated with the deployment of SCA components (including
* Packaging formats for SCA constructs that may be deployed to C and C++ based

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 for each specification 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.
	The artifacts should include example C and C++ implementations used to
	drive the test cases.

2. With the exception of necessary C and C++ implementation test artifacts,
   the provided artifacts should be independent of implementation language and
	binding type, and show clear mappings which allow the provision of suitable
	concrete implementations and concrete binding type, with any required
	policies.  The artifacts may include SCA composites expressed in XML, WSDL
	interface files, and XSD files, along with other similar files that express
	the required characteristics of the environment for each test.

3. 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 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
composite and related SCA files, C and C++ 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 Client and Implementation Model Specification for C++ ,
  together with a complete set of conformance statements
* A revised SCA Client and Implementation Model Specification for C, together
  with a complete set of conformance statements
* A complete Test Suite specification for the SCA C++ Specification including
  documents and the related materials described in the scope section.
* A complete Test Suite specification for the SCA C Specification including
  documents and the related materials described in the scope section.

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

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

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 C or C++ based SCA runtimes
* Other specification authors that need C or C++ APIs and annotations for SCA
* Software architects and programmers, who design, write or integrate SCA

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

Other existing technologies such as Java Enterprise Edition 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).

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

Date: Sept 6
Time: 1:00pm EDT
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD, along with e-Meeting facilities
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 TBDlocation
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.

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:

Mike Edwards, IBM, mike_edwards@uk.ibm.com
Bryan Aupperle, IBM, aupperle@us.ibm.com
Pete Robbins, IBM, robbins@uk.ibm.com
Andrew Borley, IBM, borley@uk.ibm.com
David Haney, Rogue Wave, haney@roguewave.com
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com

e. Convener:

Pete Robbins, IBM, robbins@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 existing SCA for C++ Version 1.00 as published in
March 2007 will be a contribution from the Open SOA Collaboration (see [2]),
together with the eventual final version of the existing draft SCA for C
specification [3], 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-C TC.

h. Draft FAQ Document

Intentionally left empty.

i. Proposed working title

Service Component Architecture Client & Implementation Assembly / C Specification,
Service Component Architecture Client & Implementation / C++ Specification

[1] Service Component Architecture Assembly Specification Version 1.0

[2] Service Component Architecture Client and Implementation Model Specification for C++

[3] Service Component Architecture Client and Implementation Model Specification for C

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