The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: July 06, 2007.
News: Cover StoriesPrevious News ItemNext News Item

Six Technical Committees Proposed for the OASIS Open CSA Member Section.

Contents

Update 2007-08-09: On August 09, 2007 OASIS announced the formation of six new technical committees to simplify SOA application development by advancing the SCA family of specifications. Each of the six new OASIS committees will address a different aspect of SCA. This will allow smaller groups of members with specific expertise or interest in one area to collaborate more effectively. See the text of the announcement "Six OASIS Committees Form to Standardize Service Component Architecture (SCA) for SOA. Axway, BEA Systems, IBM, Oracle, Primeton Technologies, Progress Software, Red Hat, SAIC, SAP, Sun Microsystems, TIBCO, and Others Collaborate on Standards to Simplify SOA Application Development."

[July 06, 2007] OASIS has published six (6) Proposed Charter documents for new Technical Committees to be created within the Open Composite Services Architecture (Open CSA) Member Section. Formation of new Technical Committees was anticipated in the announcement of March 21, 2007, where eighteen technology vendors reported that key Service Component Architecture (SCA) and Service Data Objects (SDO) specifications had completed incubation, and would be formally submitted to OASIS for advancement through its open standards process. On April 11, 2007, OASIS announced the formation of the Open CSA Member Section.

Some sixty-three (63) names are given as proposers (or supporters) in the six TC Proposed Charters, representing thirty-two (32) different individuals. Eleven (11) company names are associated with the proposers, including BEA, Cape Clear, IBM, Interface21, Oracle, Progress, Quovadx, Rogue Wave, SAP, Siemens, Sun, and TIBCO. Vendors participating in the initial joint announcement included BEA Systems, Cape Clear, IBM Corporation, Interface21, IONA, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG, Siemens AG, Software AG, Sun Microsystems, Sybase, TIBCO Software, Xcalia, and Zend.

The TC Charters as proposed would build upon the existing Service Component Architecture Version 1.0 Specifications, as described in earlier announcements.

The draft charters submitted to establish the OASIS TCs are subject to review, and published comments are available online. The deadlines for review comments are 13-July-2007 (SCA-Assembly, SCA-Policy) and 16-July-2007 (SCA-Bindings, SCA-J, SCA-BPEL, SCA-C).

Excerpts from the TC Proposed Charters are provided below. In brief:

  • SCA-Assembly TC: The Service Component Architecture Assembly TC will define the core composition model of Service Component Architecture, where SCA defines a model for the creation of business solutions using a Service-Oriented Architecture, based on the concept of Service Components which offer services and which make references to other services. The TC would accept as input SCA Service Component Architecture: Assembly Model Specification from the Open SOA Collaboration, producing a revised Service Component Architecture Assembly Specification.

  • SCA-Policy TC: The Service Component Architecture Policy TC will define a Policy Framework and policies Reliable Messaging, Security, and Transactions for the Service Component Architecture. The SCA Policy Framework specification from the Open SOA Collaboration will be the chief initial contribution.

  • SCA Bindings TC: The Service Component Architecture Bindings TC will standardize bindings for the SCA services and references to various communication protocols, technologies and frameworks. In particular, this TC would continue development of the following OSOA SCA Binding specifications and aim to establish them as OASIS Standards: SCA Web Services Binding, SCA JMS Binding, SCA JCA Binding.

  • SCA J TC: The SCA-J Technical Committee will develop specifications that standardize the use of the use of Java technologies within an SCA domain, producing five key deliverables: SCA Java Component Implementation Specification; SCA Java Common Annotations and APIs Specification; SCA Spring Component Implementation Specification; SCA EJB Session Bean Binding Specification; SCA Java EE Integration Specification.

  • SCA-BPEL TC: The SCA BPEL Technical Committee will specify how SCA component implementations can be written using the WS-BPEL language; the SCA WS-BPEL specification must allow any executable WS-BPEL 2.0 and BPEL4WS 1.1 process to be used without any knowledge of SCA. Work will be based upon the OSOA SCA BPEL Client and Implementation specification v1.00; this work also builds upon the WS-BPEL OASIS Standard, by enabling that language to be used as a first class citizen within an SCA environment.

  • SCA-C TC: The Service Component Architecture for C and C++ (SCA-C) TC will develop specifications that standardize the use of C and C++ technologies within an SCA domain. In particular, 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 schemas 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 construct from C and C++.

OASIS Service Component Architecture Assembly (SCA-Assembly) Technical Committee (TC)

Excerpted and adapted from the complete Proposed Charter:

Statement of Purpose

The purpose of the Service Component Architecture Assembly Technical Committee is to define the core composition model of Service Component Architecture. Service Component Architecture (SCA) defines a model for the creation of business solutions using a Service-Oriented Architecture, based on the concept of Service Components which offer services and which make references to other services. SCA models business solutions as compositions of groups of service components, wired together in a configuration that satisfies the business goals. SCA applies aspects such as communication methods and policies for infrastructure capabilities such as security and transactions through metadata attached to the compositions.

This work will be carried out through continued refinement of the Service Component Architecture Assembly Specification Version 1.0 as published by the Open SOA collaboration in March 2007.

Scope

The TC will accept as input the March 2007 Version 1.0 of the Service Component Architecture (SCA) Assembly Specification as published by the Open SOA collaboration.

The TC will also accept as input for reference the March 2007 Version 1.0 of the other SCA Specifications which were published at the same time as the SCA Assembly Specification [Service Component Architecture Version 1.0 Specifications].

Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.

The scope of the TC's work is to continue further refinement and finalization of the Input Documents to produce as output specifications that standardize the concepts, XML documents and XML Schema renderings of the areas described below.

1. A model for the composition of systems based on a service-oriented architecture, based on the concepts of a) service components and b) composites. This model is independent of implementation languages and technologies and also independent of communication technologies.

2. Describing the characteristics of a service component in terms of its externally visible features including services offered, service references made and configurable properties. Includes the configuration aspects of the services, references and of the implementation used by the component.

3. Describing the externally visible characteristics of a component implementation in terms of its componentType

4. Describing the design aspects of a component in terms of a constrainingType.

5. Describing the characteristics of composites including the external aspects of services, references and configurable properties, plus the aspects of internal wiring of the composite, including autowiring.

6. Use of Composite as implementations. Use of Composites through inclusion.

7. Definition of the nature of interfaces as used by services and references, including local and remote interfaces, bidirectional and conversational interfaces, oneway operations, plus the message flow patterns involved. Rendering of these concepts in terms of WSDL is in-scope, including necessary additional annotations of WSDL documents to hold SCA concepts.

8. Declaration and setting of property values, including simple and complex types.

9. Rendering of the model in terms of XML documents and their associated XML Schemas. Defining the model in terms of XML Infoset to permit other parties to render the model in other serialization forms is also regarded as in-scope.

10. Describing the extension points of the model, including implementation types, binding types, interface types. The relationship of the model to these types is part of the scope, but the details of individual types will be dealt with elsewhere, except for the handling of the composite implementation type, the SCA ("default") binding type and the WSDL interface type. Specific extensions to WSDL are in-scope for the purposes of making a WSDL document contain information relevant to its usage in an SCA context.

11. The handling of service interfaces, including the nature of the message exchange patterns and the handling of synchronous, asynchronous and one-way interactions. Techniques including Pub/Sub and Queue handling form part of this description.

12. Description of SCA Bindings in general terms, plus a definition and description of the SCA Binding.

13. The SCA Domain and its characteristics and contents, including Domain-level composite.

14. Packaging and deployment of SCA related artifacts, including the relationship to a runtime and characteristics of the runtime are part of the specification. SCA Artifact resolution, plus the use of existing non-SCA mechanisms. SCA Contributions and their metadata. SCA packaging format.

15. The place in the model for the attachment of Intents and Policies are described in general terms. Specifics of Intents and Policies are handled in another TC.

16. Portability and interoperability of SCA artifacts and SCA components between different SCA runtimes.

17. Diagrammatic representation of SCA composites and components.

Deliverables

The TC has the following set of deliverables:

1. A revised Service Component Architecture Assembly Specification and associated Schema, plus conformance statements. A Committee Specification is scheduled for completion within 12 months of the first TC meeting.

2. A complete Test Suite specification for the SCA Assembly Specification, including documents and the related materials described in the scope section. A Committee Specification is scheduled for completion within 12 months of the first TC meeting.

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 (e.g., to define specific implementation types for artifacts such as JEE EJBs).

Supporters

The following eligible individuals are in support of this proposal:

Convenor

Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com

OASIS Service Component Architecture Policy (SCA-Policy) Technical Committee (TC)

Excerpted and adapted from the complete Proposed Charter:

Statement of Purpose

The purpose of the Service Component Architecture Policy (SCA-Policy) Technical Committee is to define a Policy Framework and policies Reliable Messaging, Security and Transactions for the Service Component Architecture. Service Component Architecture (SCA) defines a model for the creation of business solutions using a Service-Oriented Architecture, based on the concept of Service Components which offer services and which make references to other services. SCA models business solutions as compositions of groups of service components, wired together in a configuration that satisfies the business goals. SCA allows abstract requirements and concrete policies for infrastructure capabilities such as security and transactions to be specified through metadata attached to the compositions.

This work will be carried out through continued refinement of the Service Component Architecture Policy Specification Version 1.0 [OSOA source] as published by the Open SOA collaboration in March 2007.

Scope

The TC will accept as input the March 2007 Version 1.0 of the Service Component Architecture (SCA) Policy Framework Specification as published by the Open SOA collaboration.

The TC will also accept as input for reference the March 2007 Version 1.0 of the other SCA Specifications which were published at the same time as the SCA Policy Specification: SCA Assembly Model Specification Version 1.0 and SCA Java Common Annotations and APIs Specification Version 1.0.

Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.

The scope of the TC's work is to continue further refinement and finalization of the Input Documents to produce as output specifications that standardize the concepts, XML documents and XML Schema renderings of the areas described below.

Specific aims of the SCA Policy TC shall be as follows:

1. The TC shall address both interaction policies that apply to messages passed between SCA components as well as implementation policies that influence the behavior of SCA components and composites.

2. The TC shall develop mechanisms to define new abstract QoS requirements (intents) and associate them with SCA constructs. [...] Users must be able to customize such abstract requirements i.e., select the exact policies they want to fulfill a particular requirement. The definition of specific intents is in-scope.

3. The TC shall develop mechanisms to associate concrete policies with SCA constructs. Policies may be expressed and attached using WS-Policy or other policy mechanisms.

4. The TC shall specify how abstract requirements are mapped into concrete policies. A single requirement may map to multiple policies, for example the WS-I profiles, BP, BSP, RSP. Multiple abstract requirements may map to a single policy. The capability for a set of one or more concrete policies to declare which abstract requirements that the set satisfies shall be specified.

5. For interaction policies, defining how policies on services and references may be matched on an SCA wire through static analysis, is in scope.

6. The TC shall define how a binding type implementation or component implementation type can declare intents that it is capable of supporting either natively or through configuration/attachment of concrete policy.

7. The TC shall specify intents for, but not limited to, Reliable Messaging, Security and Transactionality. It may also specify intents for common usage profiles such as the WS-I profiles.

8. The TC may specify concrete policies for, but not limited to, Reliable Messaging, Security and Transactionality. It may also specify concrete policies for common usage profiles such as the WS-I profiles.

Deliverables

The TC has the following set of deliverables:

1. A Service Component Architecture Policy Framework Specification and associated Schema which encompasses the following items. A Committee Specification is scheduled for completion within 12 months of the first TC meeting.

  1. A set of XML structures to specify abstract requirements and policy wrappers and associate them with SCA constructs
  2. Semantics for the use of the above structures
  3. A set of commonly used intents and policies that every SCA implementation must support to be compliant
  4. Conformance statements

2. A complete Test Suite specification for the SCA Policy Framework Specification, including a document and the related materials described in the scope section. A Committee Specification is scheduled for completion within 12 months of the first TC meeting.

3. For each deliverable listed above, the TC shall define a concrete exit criteria as early as possible after the TC starts operating. The exit criteria should include measures to ensure that the specifications produced by the TC are implementable, the test suite produced by the TC is useful to test the compliance of the implementations, and the stated goal of the specifications (such as interoperability, portability, etc) is demonstratably achieved by the implementations.

Proposers

The following eligible individuals are in support of this proposal:

Convenor

Michael Rowley, BEA Systems, Inc., mrowley@bea.com

OASIS Service Component Architecture Bindings (SCA Bindings) Technical Committee

Excerpted and adapted from the complete Proposed Charter:

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]

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 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 elements
  • 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 Specification

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.

Supporters

Convenor

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

OASIS Service Component Architecture for Java(tm) (SCA J) Technical Committee

Excerpted and adapted from the complete Proposed Charter:

Statement of Purpose

The purpose of the OASIS SCA-J Technical Committee (TC) is to develop specifications that standardize the use of the use of Java(tm) 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:

  • APIs and annotations that facilitate the declaration and use of SCA constructs from Java
  • A Java-based programming model for creating SCA component implementations that depends only on Java Standard Edition, version 5 or greater
  • A Java-based programming model for creating SCA component implementations that use the technologies of the Spring Framework Core
  • Mechanisms that allow an SCA domain to use and interoperate with constructs defined by Java Enterprise Edition, enabling the following scenarios:
    1. Accessing EJB session beans that have been deployed to JavaEE runtimes through SCA references that use an EJB-specific binding
    2. Providing SCA services through an EJB session bean binding
    3. Consumption of SCA-exposed services from Java EE components in an SCA-aware JavaEE runtime
    4. Use of Java EE components as Service Component Implementations
    5. Use of recursive SCA assembly in Java EE applications
    6. Use of Java EE modules as Service Component Implementations

The work of this committee will be based the following specifications, submitted to the TC as a reference:

  • SCA Java Component Implementation Specification
  • SCA Java Common Annotations and APIs
  • SCA Spring Component Implementation
  • SCA EJB(tm) Session Bean Binding

Scope

The scope of this TC includes work to define any of the following:

  • Java annotations and API's for declaring, using or configuring any SCA-related construct
  • Java API's for accessing and manipulating data that is associated with the runtime context of an SCA component or client
  • A Java-based programming model for creating SCA component implementations that depends only on Java Standard Edition, version 5 or greater
  • A Java-based programming model for creating SCA component implementations that use the technologies of the Spring Framework Core
  • An EJB session bean binding that allows access to services that are deployed as JavaEE EJBs or to make SCA services available as EJBs
  • Java-specific characteristics of the packaging format used for an SCA contribution that may be deployed to Java-based runtimes
  • Mechanisms for resolving Java class names, QNames and other artifact references within a Java-based SCA runtime; such a mechanism may make use of existing standardized artifact resolution mechanisms
  • Annotations for standard policy intents that may be used by components in a Java-based SCA runtime

The following additional in-scope items relate to the development of a specification for the integration of SCA with Java EE:

  • SCA implementation types for components of Java EE programming models:
    1. Web Components
    2. EJB Components
      1. Session Beans
      2. Message-Driven Beans
      3. JAX-WS annotated session beans
    3. JAX-WS Components
    4. JCA Resource Adapter Components
  • SCA implementation types for Java EE module types, such as EJB JARs and EARs
  • SCA deployment for Java EE
    1. For Enterprise Application packages (.ear)
    2. For single module packages (ejb-jar, .war, .rar)
  • The use of SCA assembly:
    1. Within the deployment package that can be used with JavaEE
    2. Over existing packages within the SCA Domain
  • Definition of the relationship between policy equivalents in Java EE and the SCA policies framework
  • Defining constructs for accessing SCA components from Java EE presentation tier technologies

Deliverables

The TC has the following set of deliverables:

  • A revised SCA Java Component Implementation Specification
  • A revised SCA Java Common Annotations and APIs Specification
  • A revised SCA Spring Component Implementation Specification
  • A revised SCA EJB Session Bean Binding Specification
  • A specification that standardizes SCA integration with Java EE

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.

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, the Spring Framework and CORBA also have a relationship to SCA and SCA anticipates optionally using these in relevant parts of the specifications (e.g. to define specific implementation types for artifacts such as JEE EJBs and Spring application contexts).

Supporters

The following eligible individuals are in support of this proposal:

Convenor

Henning Blohm, SAP, henning.blohm@sap.com

OASIS Service Component Architecture BPEL (SCA BPEL) Technical Committee

Excerpted and adapted from the complete Proposed Charter:

Statement of Purpose

The SCA BPEL TC will specify how SCA component implementations can be written using the WS-BPEL language [1]. The SCA WS-BPEL specification must allow any executable WS-BPEL 2.0 and BPEL4WS 1.1 process to be used without any knowledge of SCA. In addition, SCA specific extensions will be defined such that an executable WS-BPEL process may be aware of SCA and take advantage of that environment.

This TC will continue development of the SCA BPEL Client and Implementation Specification Version 1.0 [2] and aims to establish it as an OASIS Standard.

Scope

The SCA Assembly Model defines the environment in which SCA component implementations exist. The SCA WS-BPEL specification must conform to this environment and as a result,the following should be covered by the SCA WS-BPEL specification:

1. Mapping of WS-BPEL PartnerLinks to SCA Services and References. This must take into account:

  1. the directionality of the roles in the PartnerLink
  2. the initializePartnerRole attribute
  3. whether a role is initialized through assignment before it is used

2. Ensure correct behaviour of SCA call-backs and conversations. SCA extensions may be defined to support conversations for SCA aware WS-BPEL implementations.

3. Ensure support for dynamic binding of partner links in SCA environment, especially the wire-by-impl feature.

4. SCA extensions to WS-BPEL to support a PartnerLink that may have multiple partners of the same type. This should provide a simple mechanism to iterate over a number of partners of the same type as in an RFQ interaction, for example.

5. SCA extensions to WS-BPEL to enable SCA properties to be used for initialization purposes.

6. SCA extensions to WS-BPEL to enable other features defined in the SCA specifications to be explicitly used.

The TC will accept as input the March 2007 Version 1.0 of the Service Component Architecture (SCA) BPEL Client and Implementation Specification as published by the Open SOA collaboration [2].

The TC will also accept as input for reference the March 2007 Version 1.0 of the other SCA Specifications which were published at the same time as the SCA BPEL Client and Implementation 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.

Deliverables

The TC has the following set of deliverables:

  • A revised SCA BPEL Client and Implementation specification inclusive of XML Schema and other ancillary documents, together with a complete set of conformance statements
  • A complete Test Suite specification for the SCA BPEL C+I Specification, including documents and the related materials described in the scope section

An approved Test Suite is scheduled for completion within 12 months of the first TC meeting. The TC may decide to change the names of the documents included in the starting point contribution, and the TC may decide to modularize into multiple documents.

Supporters

The following eligible individuals are in support of this proposal:

Convenor

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

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

Excerpted and adapted from the complete Proposed Charter:

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 construct 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]

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

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.

Supporters

The following eligible individuals are in support of this proposal:

Convenor

Bryan Aupperle, IBM, aupperle@us.ibm.com

Open CSA Member Section

The OASIS Open Composite Services Architecture (Open CSA) Member Section advances open standards that simplify SOA application development. Open CSA brings together vendors and users from around the world to collaborate on standard ways to unify services regardless of programming language or deployment platform.

Open CSA has been formed to take over key specification development initiatiated in the Open Service Oriented Architecture Collaboration. Summary from OSOA:

The SCA specifications were first published as a 0.9 version in November 2005, including the Assembly Specification, the Client and Implementation Specification for Java and the Client and Implementation Specification for C++. In July 2006, the specifications all had significant improvements made to them. The improvements increased the generality of the SCA development model, simplified the model, and clarified the semantics. The collaboration also developed a series of new specifications that describe the general model for bindings and policies; provide details of specific bindings; and describe how additional implementation technologies can be incorporated into an SCA-based service network.

In March 2007, a set of Final V1.0 Specifications were published, together with an indication that OASIS would take over future development and stewardship.

Service Component Architecture (SCA) provides a programming model for building applications and systems based on a Service Oriented Architecture. It is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA compositions.

SCA is a model that aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, Messaging systems and Remote Procedure Call (RPC).

Assembly Model: The SCA Assembly Model consists of a series of artifacts which define the configuration of an SCA system in terms of service components which implement and/or use services and the connections which describe how they are linked together. The assembly is defined in terms of a set of SCA composites, which define components and reference the implementation code that provide business function and which also describe services and references and the wires that link them.

Policy Framework: The capture and expression of non-functional requirements such as security is an important aspect of service definition, and has impact on SCA throughout the lifecycle of components and compositions. SCA provides the Policy Framework to support specification of constraints, capabilities and Quality of Service (QoS) expectations, from component design through to concrete deployment. This specification describes the framework and its usage.

Bindings: SCA Bindings apply to services and references. Bindings allow services to be provided, and references to be satisfied, via particular transports. There is a binding available for each different access method. The Web service bindings allow one to access an external reference or expose SCA services using Web services technologies. SCA provides a compositional view of interconnections among service components whereas Web services provide an interoperable way to access the service components. The Web service binding also provides the interoperability glue between an SCA system and other services that are external to the SCA system but are used by composites within the SCA system. The JMS binding allows SCA components to communicate using the JMS API. It provides JMS-specific details of the connection to the required JMS resources. It supports the use of Queue and Topic type destinations. The EJB Session Bean bindings integrate a previously deployed session bean into an SCA assembly, and allows one to expose SCA services to clients which use the EJB programming model. The EJB binding supports the stateless session bean model as well as the stateful session bean model.

Java: Annotations, APIs and Component Implementation: The SCA Java Common Annotations and APIs specification define Java APIs and annotations which enable service components and service clients to be built in the Java programming language. There are closely related models describing how other Java-based frameworks and models can be used in the context of SCA, such as Spring and EJBs, which also use the common annotations and APIs defined here. In addition, the Java Component Implementation specification defines a simple Java POJO model for creating service components.

Client and Implementation: C++: The C++ Client and Implementation (C++ C&I) specification defines APIs and annotations which enable service components and service clients to be written in C++ which fit with the broader SCA Assembly model for SOA solutions. The C++ Client and Implementation model has added a number of features in support of asynchronous programming, including support for non-blocking calls, callbacks and conversational services. The model also defines the use of annotations to declare the SCA aspects of a C++ interface or implementation, similar to the annotations used in the Java C&I model. Since C++ does not have language support for annotations, the annotations are inside C++ line comments (e.g. // @Remotable). These annotations provide an alternative to defining C++ components and services using SCDL side files. The V1.0 specification also defines a C++ to WSDL mapping.

Client and Implementation: BPEL: The SCA WS-BPEL Client and Implementation model specifies how WS-BPEL processes can be used with SCA, both as service implementations and as service clients. The goal of the specification is to address the following scenarios. Start from WS-BPEL process. It should be possible to use any valid WS-BPEL 2.0 process definition as the implementation of a component within SCA. In particular, it should be possible to generate an SCA Component Type from any WS-BPEL process definition and use that type within an SCA assembly. Most BPEL4WS 1.1 process definitions may also be used with SCA by using the backward compatibility approach described in the specification. Start from SCA Component Type. It should be possible to use WS-BPEL to implement any SCA Component Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition. Start from WS-BPEL with SCA extensions. It should be possible to create a WS-BPEL process definition that uses SCA extensions and generate an SCA Component Type and use that type within an SCA assembly. Some SCA capabilities (such as properties and multi-party references) can only be used by WS-BPEL process definitions that use SCA extensions.

Principal References
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2007-07-06-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org