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


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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

Subject: Proposed Charter for OASIS Service Component Architecture for C and C++ (SCA-C) Technical Committee - 6 of 6

To OASIS Members:

  A draft TC charter has been submitted to establish the OASIS Service Component Architecture for C and C++ (SCA-C)
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:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. 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-C) in the subject line of your email


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


and C++ TC

1. Normative information
a. Name and abbreviation
OASIS Service Component Architecture for C and C++ (SCA-C) Technical Committee (TC)

Member Section Affiliation

Open CSA Member Section.

b. 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 
The work of this committee will be based the following specifications, submitted to the TC as a 
*	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. 
Ratification of the above specifications as OASIS Standards, including a brief period to address 
any errata, will mark the end of the TC's lifecycle.
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 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
This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the 
OASIS Intellectual Property Rights (IPR) Policy, effective 15 April 2005.

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 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 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: 11:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC, 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 
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.

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

e. Convener:

Bryan Aupperle, IBM, aupperle@us.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 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 Assembly 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]