SOA架构

SOA架构

摘要：面向服务架构（Service-Oriented Architecture, SOA) 是一种应用框架，将日常的业务应用划分为单独的业务功能服务和流程，通过采用良好定义的接口和标准协议将这些服务关联起来。通过实施甚于SOA的系统架构，用户可以构建、部署和整合服务，无需依赖应用程序及其运行平台，从而提高业务流程的灵活性，帮助企业加快发展速度，降低企业开发成本，改善企业业务流程的组织和资产重用。

关键词：架构、SOA

SOA定义

SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。

要满足这种业务敏捷性，SOA的实践必须遵循以下原则：业务驱动服务，服务驱动技术

从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

业务敏捷是基本的业务需求

SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

一个成功的SOA总在变化之中，SOA工作的场景，更像是一个活的生物体，而不是像传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。

SOA是将业务敏捷和快速创新视为目标的架构设计方法,强调跨业务组建域的系统间的松耦合和服务复用,但不提倡为了SOA而SOA,不论是点对点,EAI,还是SOA,都是要实现系统整合的手段,如果选择构建SOA架构，需要有足够的业务驱动力，需要评估SOA架构对现有架构及应用的改造复杂度，需要明确各SOA功能组件的功能定位以及对总体架构的影响，需要对服务进行定义和规约，需要设计可落地的服务治理的手段和工具,需要考虑数据标准等等，我们需要认识到SOA服务的积累是一个过程，所以SOA架构的成本曲线有可能是先高后低的，如果经过积累，SOA架构将发挥其满足业务敏捷、快速创新、降低成本的目标

在我参与开发的软件系统开发项目中，我组要担任的是项目的项目的材料收集，项目的开发，项目的测试等工作。

SOA的关键技术

SOA 伴随着无处不在的标准，为企业的现有资产或投资带来了更好的复用性。SOA 能够在最新的和现有的系统之上创建应用，借助现有的应用产生新的服务，为企业提供更好的灵活性来构建系统和业务流程。SOA 是一种全新的架构，为了支持其各种特性，相关的技术规范不断推出。与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的。

1. UDDI

UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

在 UDDI 技术规范中，主要包含以下三个部分的内容：

（1）数据模型。UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema。

（2）API。UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。

（3）注册服务。UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角色。

2.WSDL

WSDL（Web ServiceDescription Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义，如图所示。

 

采用抽象接口定义对于提高系统的扩展性很有帮助。服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。

服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应当使用怎样的消息调用模式来访问等。

3.SOAP

SOAP（Simple ObjectAccess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。SOAP 主要包括以下四个部分：

（1）封装。SOAP 封装定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必需的。

（2）编码规则。SOAP 编码规则定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。

（3）RPC 表示。SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协议。

（4）绑定。SOAP 绑定定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。

SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的 SOAP 消息都使用 XML 进行编码。SOAP 消息包括以下三个部分：

（1）封装（信封）。封装的元素名是 Envelope，在表示消息的 XML 文档中，封装是顶层元素，在 SOAP 消息中必须出现。

（2）SOAP 头。SOAP 头的元素名是 Header，提供了向 SOAP 消息中添加关于这条 SOAP 消息的某些要素的机制。SOAP 定义了少量的属性用来表明这项要素是否可选以及由谁来处理。SOAP 头在 SOAP 消息中可能出现，也可能不出现。如果出现的话，必须是 SOAP 封装元素的第一个直接子元素。

（3）SOAP 体。SOAP 体的元素名是 Body，是包含消息的最终接收者想要的信息的容器。SOAP 体在 SOAP 消息中必须出现且必须是 SOAP 封装元素的直接子元素。如果有头元素，则SOAP 体必须直接跟在 SOAP 头元素之后；如果没有头元素，则 SOAP 体必须是 SOAP 封装元素的第一个直接子元素。

4.REST

REST（RepresentationalState Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操作（POST、GET、PUT 和 DELETE），这些操作适用于所有的消息。REST 提出了如下一些设计概念和准则：

（1）网络上的所有事物都被抽象为资源。

（2）每个资源对应一个唯一的资源标识。

（3）通过通用的连接件接口对资源进行操作。

（4）对资源的各种操作不会改变资源标识。

（5）所有的操作都是无状态的。

SOA标准：

1.SOA 参考架构 (SOA Reference Architecture)

2.Open Group 服务集成成熟度模型 (Open Service Integration Maturity Model, OSIMM)

3.SOA 治理 (SOA Governance)

4.SOA 本体论 (SOA Ontolog)

SOA参考架构：

Open Group SOA 参考架构 (SOA RA) 标准为在面向服务解决方案架构包括云计算架构中架构、设计和实现决策提供指导方针和选择。SOA 参考架构标准旨在提供一个蓝图来创建和评估架构。此外，它还提供洞察力、模式和构建块，利用这些将一个 SOA 的基础元素集成到一个解决方案或企业架构中。

Open Group 服务集成成熟度模型：

Open Group 服务集成成熟度模型 (OSIMM) 标准（以及国际标准）提供一种方法来评估其服务的使用并开发一个路线图来实现其 SOA 业务目标。SOA 采纳场景往往相差很大，特别是当企业缺乏一个清晰的路线图时；该路线图是如何继续他们的 SOA 采纳之路的景愿。SOA 之旅并不能开始和终止于一个单一项目。当越来越多的组织继续合并服务定位的使用作为其 IT 策略的基础，从各个维度评估其当前状态（从业务到基础架构），以及寻求最大化其 SOA 旅程的业务获益，对于他们来说日益重要。

SOA治理：

由于与 IBM SOA 治理方法行业的协作，SOA 治理框架已被 The Open Group 标准化。它定义治理，作为建立和执行人们与解决方案共同实现组织目标的方法。治理可帮助确保组织以正确的方法在正确的时间构建正确的服务，然后高效地管理和重用这些服务。SOA 治理是通过监视积极主动地识别、评估、构建和管理高价值业务服务和解决方案流程而实现的，这些服业务服务和解决方案将提供最大的投资回报。这意味着创建服务重用和提供敏捷性能够管理业务和 IT构建SOA架构中遇到了，原有系统架构中的集成需求问题原有系统架构中的集成需求，当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI（Electronic Data Interchange 电子数据交换）系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。服务粒度的控制以及无状态服务的设计

当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方：首先是对于服务粒度的控制，另外就是对于无状态服务的设计