|
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。详细内容可以从相关的白皮书和规范正文中获得。
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.
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.
| 
