Open CSA promotes the creation and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications.
These specifications are currently available for download from the Open SOA Collaboration.
Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA). SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
SCA 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 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).
Open CSA oversees the work of several OASIS Technical Committees on SCA that address the following specifications:
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.
This specification can be downloaded from the Open SOA Collaboration.
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.
This specification can be downloaded from the Open SOA Collaboration.
The SCA Java Common Annotations and APIs specification defines Java APIs and annotations that 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.
This specification can be downloaded from the Open SOA Collaboration.
The SCA 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.
This specification can be downloaded from the Open SOA Collaboration.
The SCA WS-BPEL Client and Implementation (BPEL C&I) model specifies how WS-BPEL processes can be used as SCA components.
This specification can be downloaded from the Open SOA Collaboration.
The SCA Client and Implementation model for PHP defines how PHP scripts and objects can be used within an SCA assembly.
This specification can be downloaded from the Open SOA Collaboration.
The SCA Java Client and Implementation model for Spring specifies how the Spring Framework can be used with SCA. The goals of this effort are:
Coarse-grained integration: The integration with Spring will be at the SCA Composite level, where a Spring application context provides a complete composite, exposing services and using references via SCA. This means that a Spring application context defines the internal structure of a composite implementation.
Start from SCA Component Type: It should be possible to use Spring to implement any SCA Composite that uses WSDL or Java interfaces to define services, possibly with some SCA specific extensions.
Start from Spring context: It should be possible to use any valid Spring application context as the implementation of a component within SCA. In particular, it should be possible to generate an SCA Composite from any Spring context and use that composite within an SCA assembly.
This specification can be downloaded from the Open SOA Collaboration.
The SCA Java EJB Client and Implementation specification describes how EJBs and EJB modules can be used within an SCA composition. The usage is defined at two levels:
For more information, see the Open SOA EJB white paper.
SCA Bindings apply to services and references. Bindings allow services to be provided, and references to be satisfied, via particular access methods or transports.
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.
This specification can be downloaded from the Open SOA Collaboration. For more information, see the Open SOA SCA Bindings page.
Service Data Objects (SDO) are designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.
These specifications can be downloaded from the Open SOA Collaboration.
For more information, see the SDO v2.1 white paper.
These specifications can be downloaded from the Open SOA Collaboration.
Service Data Objects (SDOs) enable PHP applications to work with data from different sources, such as databases and XML files, using a single interface. The PHP implementation of SDO is the first to map SDO to a weakly and dynamically typed scripting environment. The result is a technology which, at its heart provides the same functionality and compatibility as other implementations, but externally present an API that is tailored to the target language.
For more information, see the SDO for PHP white paper.
An SDO for C draft specification proposal is available from the Open SOA Collaboration.
An SDO for COBOL draft specification proposal is available from the Open SOA Collaboration.