(转)SOA之SCA/SDO标准体系介绍

SOA 之 SCA/SDO 标准体系介绍

 

Open CSA 组织促进了服务组件架构（ SCA ）和服务数据对象（ SDO ）规范系列的创建和采用。

 

服务组件架构（ SCA ）

服务组件架构（ SCA ）是一组规范，它描述了利用面向服务架构（ SOA ）来构建应用程序和系统的模型。 SCA 是基于开放标准（例如 Web 服务）构建的，它扩展和补充了先前的服务实现方法。

 

SCA 的基本思想是将业务功能作为一系列服务来提供，这些服务组合到一起，以创建满足特定业务需要的解决方案。这些复合应用程序既可以包含专门为该应用程序创建的新服务，也可以包含来自现有系统和应用程序的业务功能（作为复合应用程序的一部分来重用）。 SCA 为服务组合和服务组件的创建（包括 SCA 复合应用程序内部现有应用程序功能的重用）提供了模型。

 

SCA 这一模型旨在包含广泛的服务组件技术以及用于连接这些组件的访问方法。对于组件，它不仅包括各种编程语言，还包括通常与这些语言一起使用的框架和环境。对于访问方法， SCA 复合应用程序允许使用各种常用的通信和服务访问技术，例如， Web 服务、消息传递系统和远程过程调用（ RPC ）。

 

SCA 包含以下规范：

 

SCA EJB 组件模型

SCA Java EJB 客户及实现（ SCA Java EJB Client and Implementation ）规范描述了如何在 SCA 复合应用程序中使用 EJB 和 EJB 模块。它在两个层次上定义了 EJB 的使用：

l          可以将完整的 EJB 模块像 SCA 复合体一样使用，不需要做任何内部细节上的改动，借助 SCA 连接到 EJB 模块提供的服务上，并将 EJB 模块的服务需求连接到 EJB 模块的外部组件所提供的服务上。

l          可以使用单个 EJB ，由 SCA 提供所有的连接。

 

SCA 装配模型

SCA 装配模型（ SCA Assembly Model ）定义了构成一个 SCA 系统的各种构件和他们之间的关系。包括： SCA 复合体， SCA 构件，服务，服务实现，服务需要，连线等等。

 

 

SCA 策略框架（ SCA Policy Framework ）

非功能性需求（例如安全性）的捕获和表示是服务定义的一个重要方面，在组件和复合应用程序的整个生命周期中都会对 SCA 产生影响。 SCA 提供了策略框架以支持约束、能力和服务质量（ QoS ）预期的规范，从组件设计直到具体部署。此规范描述了框架及其使用。

 

SCA Java 注释、 API 和组件实现

SCA Java 公共注释和 API （ SCA Java Common Annotations and API ）规范定义了 Java API 和注释，以支持使用 Java 编程语言来构建服务组件和服务客户。有一些紧密相关的模型，它们描述了如何在 SOA 上下文中使用其他基于 Java 的框架和模型，例如 Spring 和 EJB ，这些模型也使用此规范定义的公共注释和 API 。此外， Java 组件实现规范还定义了用于创建服务组件的简单 Java POJO 模型。

 

 

SCA 客户及实现： C++

SCA C++ 客户及实现（ C++ C&I ）规范定义了 API 和注释，以支持使用 C++ 来编写适合 SCA 组装模型的服务组件和服务客户。

 

SCA 客户及实现： BPEL

SCA WS-BPEL 客户及实现（ BPEL C&I ）模型指定了如何将 WS-BPEL 进程用作 SCA 组件。

 

 

SCA 客户及实现： PHP

针对 PHP 的 SCA 客户及实现模型定义了如何在“ SCA 装配”中使用 PHP 脚本和对象。

 

SCA 客户机及实现： Spring

针对 Spring 的 SCA Java 客户及实现模型指定了 Spring 框架如何与 SCA 一起使用，以实现以下目的：

 

进行粗粒度的集成：与 Spring 的集成将在 SCA 复合体层次进行，其中 Spring 应用程序上下文提供了完整的 SCA 复合体，并通过 SCA 暴露的服务和服务需求。这意味着 Spring 应用程序上下文定义了 SCA 复合体的具体实现的内部结构。

 

从 SCA 组件类型开始：利用 Spring ，可以实现任何 SCA 复合应用程序，这些应用程序使用 WSDL 或 Java 接口来定义可能具有某些特定于 SCA 扩展的服务。

 

从 Spring 上下文开始：可以将任何有效的 Spring 应用程序上下文用作 SOA 中的组件实现。特别地，应该可以从任何 Spring 上下文生成 SCA 复合应用程序，并在“ SCA 装配”中使用这些复合应用程序。

 

SCA 绑定规范

SCA 绑定（ SCA Binding ）规范适用于服务和服务需求。绑定允许通过特定的访问方法或传输来提供服务并满足服务需求。

 

Web 服务绑定允许利用 Web 服务技术来访问外部需求或公开 SCA 服务。 SCA 提供了服务组件之间的互连的复合视图，而 Web 服务提供了用于访问服务组件的互操作方式。 Web 服务绑定还提供了 SCA 系统与其他服务之间的互操作衔接，这里的其他服务是指 SCA 系统的外部服务，但它们供 SCA 复合体使用。

 

JMS 绑定允许 SCA 组件使用 JMS API 来通信。它提供了连接到所需的 JMS 资源的 JMS 特有的连接细节。它支持使用 Queue 和 Topic 类型的目标。

 

EJB Session Bean 绑定可以将先前部署的 Session Bean 集成到 SCA 装配中，并允许向使用 EJB 编程模型的客户公开 SCA 服务。 EJB 绑定既支持无状态的 Session Bean 模型也支持有状态的 Session Bean 模型。

 

服务数据对象（ SDO ）

服务数据对象（ SDO ）的设计是为了简化和统一应用程序处理数据的方式。利用 SDO ，应用程序编程人员可以一致地访问和操纵来自异构数据源的数据，包括关系数据库、 XML 数据源、 Web 服务和企业信息系统。

 

为支持各种可能的应用，标准中包括了对各种常用语言的支持，包括： SDO for Java and C++ ， SDO for PHP ， SDO for C ， SDO for COBOL 。详细内容可以从相关的白皮书和规范正文中获得。

 

SOA之SCA/SDO标准体系介绍

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)

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

SCA comprises the following specifications:

SCA EJB Component Model

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:

·It is possible to use complete EJB modules as if they are SCA composites, without changing their internal details, using SCA to wire to services offered by EJBs in the module and wiring from unsatisifed EJB-refs of the module to services provided by components outside the EJB module.

·It is possible to use individual EJBs with SCA providing all the wiring

This specification can be downloaded from the Open SOA Collaboration. For more information, see the Open SOA EJB white paper.

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

This specification can be downloaded from the Open SOA Collaboration.

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

This specification can be downloaded from the Open SOA Collaboration.

SCA Java Annotations, APIs, and Component Implementation

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.

SCA Client & Implementation: C++

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.

SCA Client & Implementation: BPEL

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.

SCA Client & Implementation: PHP

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.

SCA Client & Implementation: Spring

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.

SCA Bindings Specifications

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)

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.

SDO for Java and C++

These specifications can be downloaded from the Open SOA Collaboration.

SDO for PHP

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.

SDO for C

An SDO for C draft specification proposal is available from the Open SOA Collaboration.

SDO for COBOL

An SDO for COBOL draft specification proposal is available from the Open SOA Collaboration.