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

The original Call For Participation for this TC may be found at http://lists.oasis-open.org/archives/tc-announce/200707/msg00017.html

  1. Name

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

  2. 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]
  3. 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 composites).
    • Packaging formats for SCA constructs that may be deployed to C and C++ based runtimes.

    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.

    Conformance

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

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

    Maintenance

    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.

  5. IPR Mode

    The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy.

  6. 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.
  7. Language

    TC business will be conducted in English.

References

[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

 

TOP OF PAGE