SOA体系架构及实现技术介绍

（一）SOA体系架构

SOA体系架构中存在三种角色：服务提供者、服务注册中心、服务请求者，概念如下。

（1）服务请求者（Service Customer）。服务请求者是一个应用程序、一个软件模块或需要一个服务的另一个服务，用于实现服务的查询和调用。它发起对注册中心中服务的查询，发现满足条件的、可获得的服务，一旦发现，服务请求者将绑定到服务提供者，并调用实际的服务功能。

（2）服务提供者（Service Provider）。即服务的拥有者，负责服务的具体实现。它是一个可通过网络寻址的实体，负责将接口的描述信息及服务信息发布到服务注册中心。提供服务请求者可以发现和访问该服务，并控制对服务的访问及服务的维护和升级。

（3）服务注册中心（Service Register）。服务注册中心是一个服务中介，服务提供者在服务注册中心注册服务，服务注册中心集中存储服务信息，服务请求者在服务注册中心查找和发现所需的服务，服务注册中心是服务发现的支持者。

如图2-1所示，服务提供者负责实现并封装独立的服务实体，发布到服务注册中心供外界调用，并利用服务描述语言描述其功能、接口和参数信息；服务注册中心负责注册发布的服务，并提供服务的查找、发现；服务请求者通过服务注册中心按需查询服务描述信息，绑定服务，并根据接口参数信息完成服务调用。

图2-1　SOA体系结构

面向服务的体系结构中每个实体都扮演着服务提供者、服务请求者和服务注册中心这三种角色中的某一种或多种。服务请求者发送查找服务请求，从服务注册中心获得相关服务的描述，按照服务描述文件包含的服务绑定信息，与服务提供者建立绑定关系，并调用相应的服务。服务请求者找到服务提供者后，将直接与之进行消息交互。因此，SOA体系架构定义了三种基本操作：发布、发现、绑定。

（1）发布。服务提供者必须将服务的信息发布到服务注册中心，以提供服务需求者发现和调用。服务的信息包括所有与该服务交互必要的信息，如网络位置、传输协议及参数格式等。

（2）发现。服务请求者使用发现服务来定位服务，发现服务的操作由服务请求者通过界面或者其他服务发起，通过服务注册中心查找满足其标准的服务。

（3）绑定。服务请求者一旦查询到合适的服务，将根据服务描述中的信息直接调用服务。

需要注意的是，服务请求者不一定必须通过服务注册中心查找服务，在封闭环境下，也可以直接从服务提供者那里获取服务描述。

（二）SOA架构的实现技术

SOA是一种标准化、松耦合、粗粒度的软件体系架构模型，是一种不受具体实现技术约束的软件开发思想。因此，实现SOA架构需要一种具体的技术手段。当前常用的实现SOA架构的技术包括CORBA、DCOM、RMI和Jini，下面具体加以介绍。

1.CORBA

CORBA（Common Object Request Broker Architecture，通用对象请求代理体系结构）是由OMG组织制定的一种标准的面向对象应用程序体系规范。CORBA遵循了通用的分布式系统解决方案模式：服务提供者通过在可用的命名目录中发布其服务对象，对此分布式对象感兴趣的客户则通过该命名服务找到服务器对象，然后调用服务器对象上合适的服务。为此，客户必须提前与命名服务及服务器提供的各种服务绑定才能得到相关信息，如服务器对象提供的属性、方法、接口等。这些通过CORBA接口定义语言（Interface Definition Language，IDL）实现。

2.DCOM

DCOM（Microsoft Distributed Component Object Model，分布式组件对象模型）是由Microsoft推出的对象组件模型，由一系列微软的概念和程序接口构成。利用这些接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象。DCOM支持局域网、广域网和Internet上两台不同机器组件间的通信。通过DCOM应用程序能够任意进行空间分布。与CORBA不同，DCOM只能基于Microsoft Windows平台，是Windows-Windows的分布式实现方法。

3.RMI

RMI（Remote Method Invocation，远程方法调用）是Java的远程过程调用机制，是Java面向对象方法的一部分。它使Java程序之间能够实现灵活的、可扩展的分布式通信。通过RMI分布在网络不同地址上的两个应用程序之间可相互操作。同时，RMI允许通信双方存在于多个指定地址空间，分布在各种Java虚拟机上。每个指定地址空间可以在同一台计算机上或网络上的不同计算机上。采用RMI通信的两个应用程序之间的调用方式采用经典的客户—服务器模型。

4.Jini

Jini（Java Intelligent Network Infrastructure，Java智能网络基础设施）是Sun公司在Java和RMI基础上推出的新的分布式计算系统，它以Java技术为核心，通过使用一个简易的“即插即用”模型，能够随时改变硬件或者软件的配置，提供了一个支持快速配置的分布式计算环境。所有支持Jini的设备，可以是数字相机、打印机、PDA或者蜂窝式电话，只要接入到TCP/IP网络，就可以自动发现并使用附近其他支持Jini的设备。Jini目标是将成组的硬件设备和软件组件联合成一个单一的、动态的分布式系统，联合后的网络系统更加易于管理和使用，同时在保持单机灵活性、统一响应和控制的情况下，还能支持由系统提供的共享能力。

相比其他技术，Web Service技术具有更好的可靠性、扩展性、易用性和协议开放性，成为SOA架构的一种主要实现技术。

（三）SOA特点与优势

1.SOA特点

SOA的实施具有几个鲜明的基本特征。

（1）可从企业外部访问。通常被称为业务伙伴的外部用户也能像企业内部用户一样地访问相同服务。业务伙伴采用先进的B2B协议相互合作，或者访问以Web服务方式提供的企业服务。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。

（2）随时可用。当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为企业门户（就是一个连接企业内部和外部的网站，它可以为企业提供一个单一的访问企业各种信息资源的入口）应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。(www.xing528.com)

许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量地增长，出现短缺的可能性也呈指数级数上升。

相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下是部署在后台的，用户通常不会觉察到短暂的短缺。大部分情况下，异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺的情况下，队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。

服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯的。在多数情况下，采用异步模型可以达到同样的效果，更能够体现SOA的最佳特性。当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

（3）粗粒度服务接口。粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。它们的差异可以由下面的例子说明，假若存在某一计费系统，向其中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如将客户名录入计费系统中，添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次地往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时，粗粒度服务接口的优点更为明显。

除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长，导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务发送大块数据的粗粒度请求可能是获取反馈的唯一途径。

（4）分级。一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

在服务分级方面，须注意服务层的公开服务通常由后台系统或SOA平台中现有的本地服务组成。因此允许在服务层建立私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务能力具有重要的影响。

（5）松散耦合。SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这使服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合都依靠基于服务消息的接口。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。

当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理。由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。

（6）可重用的服务及服务接口设计管理。如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。

服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折中，走捷径的项目战术与企业构建可重用通用服务的长期目标。

超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。

在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估，也是成功利用服务库的关键。

简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制订SOA实施计划时加以考虑。

（7）标准化的接口。近年来出现的两个重要标准——XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求TT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。

Web服务使应用功能得以通过标准化接口（WSBL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。

2.SOA优势

了解了SOA的基本特征后，将会对SOA有一个粗略的印象，再来看看SOA潜在的优点。

（1）编码灵活性。可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。

（2）明确开发人员角色。例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。

（3）支持多种客户类型。借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。

（4）更易维护。服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。

（5）更好的伸缩性。依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。

（6）更高的可用性。该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在WebLogic集群环境中灵活部署，使用者可以被转接到可用的例程上。

SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。