Introduction to the SCA/SDO standard system of SOA

The Open CSA organization facilitates the creation and adoption of the Service Component Architecture (SCA) and Service data Object (SDO) specification series.

Service Component Architecture (SCA)

Service Component Architecture (SCA) is a set of specifications that describe a model for building applications and systems using service-oriented architecture (SOA). SCA is built on an open standard, such as a Web service, that extends and complements the previous methods of service implementation.

The basic idea of SCA is to provide business functions as a series of services that are grouped together to create solutions that meet specific business needs. These composite applications can contain both new services that are specifically created for the application, or business functions from existing systems and applications that are reused as part of a composite application. SCA provides a model for the creation of service portfolios and service components, including reuse of existing application functionality within SCA composite applications.

The SCA model is designed to encompass a broad range of service component technologies and access methods for connecting these components. For components, it includes not only a variety of programming languages, but also frameworks and environments that are commonly used with these languages. For access methods, SCA composite applications allow the use of a variety of commonly used communication and service access technologies, such as Web services, messaging systems, and remote procedure calls (RPC).

SCA includes the following specifications:

SCA EJB Component Model

The SCA Java EJB Client and implementation (SCA Java EJB Client and Implementation) specification describes how to use EJB and EJB modules in an SCA composite application. It defines the use of EJBS at two levels:

L can use the complete EJB module as an SCA complex, without any internal details changes, connecting to the services provided by the EJB module with SCA, and connecting the service requirements of the EJB module to the services provided by the EJB module's external components.

L can use a single EJB to provide all of the connections by SCA.

SCA Assembly Model

The SCA assembly model (SCA Assembly models) defines the relationships between the various artifacts that make up an SCA system. Includes SCA complexes, SCA components, services, service implementations, service needs, wiring, and so on.

SCA Policy Framework (SCA Policy Framework)

The capture and presentation of non-functional requirements, such as security, is an important aspect of service definition, which has an impact on SCA throughout the lifecycle of components and composite applications. SCA provides a policy framework to support the specification of constraints, capabilities, and quality of service (QoS) expectations, from component design to concrete deployment. This specification describes the framework and its use.

SCA Java annotations, APIs, and component implementations

The SCA Java public Annotations and APIs (SCA Java Common Annotations and API) specification defines Java APIs and annotations to support the use of the Java programming language to build service components and service customers. There are closely related models that describe how to use other java-based frameworks and models in an SOA context, such as spring and EJB, that also use the public annotations and APIs defined by this specification. In addition, the Java Component Implementation specification defines a simple Java Pojo model for creating serviced components.

SCA client and implementation: C + +

The SCA C + + customer and implementation (C + + c&i) specification defines APIs and annotations to support the use of C + + to write service components and service customers that fit the SCA assembly model.

SCA client and implementation: BPEL

The SCA Ws-bpel Customer and implementation (BPEL C&i) model specifies how the Ws-bpel process can be used as an SCA component.

SCA client and implementation: PHP

The SCA client and implementation model for PHP defines how to use PHP scripts and objects in the SCA assembly.

SCA client and implementation: Spring

The SCA Java customer and implementation model for spring specifies how the spring framework is used in conjunction with SCA to achieve the following purposes:

Granular integration: Integration with spring will take place at the SCA complex level, where the spring application context provides a complete SCA complex and exposes service and service requirements through SCA. This means that the spring application context defines the internal structure of the specific implementation of the SCA complex.

Starting with the SCA component type: With spring, you can implement any SCA composite application that uses a WSDL or Java interface to define a service that may have some SCA-specific extensions.

Starting with the spring context: Any valid spring application context can be used as a component implementation in an SOA. In particular, you should be able to generate SCA composite applications from any spring context and use them in the SCA assembly.