基于SOA的Web服务应用构建关键技术研究

摘 要：面向服务的架构（SOA）是一种架构风格，遵循此风格的系统是基于松耦合、粗粒度、自治的组件间的交互来构建的，这类组件被称为服务，Web也是服务的一种。本文详细描述了Web服务的SOA构建关键技术，并就其中的服务发现进行举例说明。

关键词：Web；服务；SOA；SOAP；策略

中图分类号：TP39 文献标识码：A 文章编号：2095-1302（2014）08-0076-04

0 引 言

SOA是一个体系结构概念，与具体的技术无关，Web服务是一种实现方式，也可以基于其他技术来实现SOA，比如OSGi（Open Services Gateway initiative）、CORBA（Common Object Request Broker Architecture，公共对象请求体系结构）、DCOM、RPC等。而且，Web服务不仅仅限于实现SOA，通过将一个方法公开为Web服务，可以实现过程式的RPC。

1 SOA和Web服务

最初，Web服务被描述为一种连接技术。这种方式由于是基于已有的HTTP协议之上，因此具有简单、安全和无障碍的特点。SOAP与WSDL的出现和应用可以说是软件技术史上的一个里程碑。

Web服务之前的CORBA、MQ、EJB、COM/COM+等技术可以很好地解决在某种特定平台或技术之上的分布式计算问题，它们都很强大。然而，业务全球化和企业国际化导致信息现代化必须面临“不同系统平台、不同组件技术和不同技术下的遗留系统整合”的现实情况。而Web服务提供了一种技术，即不管什么平台、什么技术和什么开发语言，它能够通过WSDL技术和标准将不同平台、不同技术和不同开发语言下的业务服务出去，客户端可以通过基于HTTP的SOAP协议来远程调用。由于访问是基于HTTP，因而远程调用可以突破防火墙，实现互联网级别的远程调用。因此，目前软件技术已走向了“无技术”时代。所谓“无技术”时代并不是不要任何技术，而是通过Web服务实现了企业级应用系统基于平台无关性、技术无关性和语言无关性的开发、整合、部署和运行的全新时代。

SOA与Web服务的关系如图1所示。

2 关键技术研究

2.1 服务的连接与集成（Integration）

服务的主要形式是点对点（Point-to-point）和中心辐射（总线式）方式。点对点方式就是服务消费者与服务直接连接。每个服务消费者必须确保与所有相连的服务接口保持一致（例如同步或异步、SOAP或REST、服务的版本、安全性问题等）。图2所示是点对点服务的连接方式。

点对点方式适用于以下环境：

・服务和服务消费者的数量较小

・采用同质技术体系

・预期在业务和技术上变化很小

近年来，ESB往往被视为构建SOA的基石之一。实践证明，ESB是企业构建真正的SOA架构应用所必须的基础设施。ESB可以理解为一类产品，即在服务消息者和服务之间连接和中介所有通信和接口的中间件产品。也可以理解为一种模式，具有多个厂商和开源实现。实际应用中，一般从一个厂商或开源实现开始，根据业务需要增加扩展或定制。

服务使用Web服务或其他标准或适配器连接到一个公共的骨干背板上。ESB管理接口的相容性、服务的路由（基于内容、可用性、负载或其他规则，可能是动态决定，可能是一对多或多对一的聚合）以及数据转换问题（格式和业务语义）。可以促进系统的松耦合。减少连接的复杂性。

ESB适用于技术上异构、变化快速和大规模系统如果具体的把ESB产品和传统EAI里面的消息总线类产品（如ActiveMQ）做个比较，两者差异就很大了，主要有三方面。第一，ESB以SOA面向业务的哲学为基础，所以它主要是通过配置来建立 ，而不是通过编程建立；第二，ESB必须有能力在不同的协议之间建立互通机制，包括传统的消息机制（JMS）和Web服务接口（WS）；第三，除了消息（服务）方式外，ESB还必须为SOA服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由，包括服务、注册、使用、推广、效益统计、升级等。

2.2 服务与发现

服务（publish）指在目录服务（directory service）中和更新Web服务的信息。服务发现（discovery）指客户使用发现服务（discovery service）发现已注册的服务。发现服务是目录服务的一种特例。包括静态和动态两种。服务和发现均可以基于人工，注册库是自动方式的一种。

Repository（翻译为资源仓库或存储库）和Registry（注册中心）经常混用，通常都指用来注册服务的一个中心位置。如果严格区分的话，区别在于Repository除了注册服务及其元数据外，还可以注册任何其他制品；而Registry一般仅用于服务的定位。存储库比注册中心包含的内容更为丰富，目前一般采用存储库的较多，因为同时可以实现治理（Governance）的一些功能。服务注册本就属于SOA治理（SOA governance）的范畴。

通用描述、发现与集成（Universal Description，Discovery and Integration，UDDI）标准旨在为Web服务提供一个平台中立的注册表。UDDI可被用作私有或公开的注册表。然而，UDDI的术语相当晦涩和复杂，它的动态发现功能过于想当然，UDDI Registry的实现比较少。如今只有少数企业用户在使用UDDI，公共的注册表就更少了。现实当中，除了少数几个商业产品（在那里它的复杂度用户看不到），很少用到UDDI。UDDI的失败并不意味着对注册表的需求也随之消失，大多数公司转而寻求别的替代。可以使用简单的数据库或轻量目录访问协议（Lightweight Directory Access Protocol，LDAP）应用，甚至在Wiki上保存一个目录。开源注册表方案，如MuleSource的Galaxy及WSO2的Registry，试图填补这一空白。

2.3 BPM、服务编排与编配

BPM（业务流程管理）是设计、制定规则、控制、分析操作过程的软件，涉及人、组织、应用、文档和其他资源。在寻求良好的性能、对变化迅速的市场及时响应、发展软件等方面，SOA和BPM是天生的“伴侣”。BPM工具和技术在设计和编排SOA服务时，非常有用。目前，有如下几种BPM标准：

BPEL-WS规范在2003年4月提交给了OASIS（Organizationfor the Advancement of Structured Information Standards，结构化信息标准促进组织）并更名为WSBPEL（Web Services Business Process Execution Language）规范， 2007年4月WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相继加入了OASIS组织。除去政治因素，BPEL的流行还在于Web正成为分布式系统架构的平台以及SOA的雄起，SOA强调服务的分解和解耦，而BPEL则对这些Web服务进行编制，两者密不可分。但BPMN到BPEL的转换存在着先天上的缺陷，原因是BPMN是基于图的，而BPEL是基于块的，BPEL是一个结构化（块[Block]）和非结构化（控制链和事件）的混合体。这个缺陷导致有些BPMN建模的流程无法映射到BPEL，两者的双向工程更是存在问题。这个缺陷成为人们反复诟病的对象。许多支持BPEL的产品为了解决这一问题，不得不在用户建模时做出种种限制，让用户绘制不出无法转换的模型。

BPMN2.0正式版本于2011年1月3日。BPMN2.0正式将自己更名为Business Process Model And Notation（业务流程模型和符号），相比BPMN1.x，最重要的变化在于其定义了流程的元模型和执行语义，即它自己解决了存储、交换和执行的问题，BPMN由单纯的业务建模重新回归了它的本源，即作为一个对业务人员友好的标准流程执行语言的图形化前端。BPMN2.0一出手，竞争就结束了，XPDL、BPEL和BPDM各自准备回家钓鱼。看起来胜利者似乎是BPMN，但看看BPMN2.0的领导者，就会发现最后的胜利者还是IBM， Oracle和SAP这些大厂商们，他们提交的草案明确要赋予BPMN2.0以执行语义，这迫使BPDM团队撤回了其提交，并将他们的提议与BPDM团队想法合并，这就是BPMN2.0最后内容的由来。

BPMN的目标是期望通过一套统一的建模、执行模型填起业务人员与开发人员之间的那道鸿沟

服务编排（choreography）：在编排的业务流程中，流程的每个节点都自己决定接下来怎么往前走。举例来说，每个节点可能都在自己的虚拟机里运行，从某个内向（in-port）的队列接收消息，执行处理，然后决定往哪个向外（out-port）的队列发送消息。从某种意义上来说，节点并不知道自己在更大的流程中扮演什么样的角色。在编排的服务中，并没有“流程实例”的概念，而是采用存在于流程节点内部某处的消息。

服务编配（orchestration）：编配的业务流程是集中管理的，通常还是在单个虚拟机内。拿BPEL来说，每一个流程启动，都会创建这个流程的“实例”，交给BPEL引擎管理。如果是长时间的流程，该实例则有可能被持久放在数据库（这个处理过程叫做“脱水”）。

2.4 服务安全

对Web服务的威胁涉及网络基础设施、应用和托管系统。要使Web服务安全，需要一组基于XML的安全机制来解决有关消息层次的安全性、认证、基于角色的接入控制、分布安全策略的执行等。

Web服务需要点到点还是端到端的安全机制，决定于威胁的程度和面临的安全风险。“端到端”是指从最初的请求者到最终的接收者，传统的面向连接的点到点安全机制不能满足Web服务的终端到终端的安全需求。但是，安全性需要在风险和对抗措施的成本之间进行折中，如果风险可以容忍，那么点到点传输层的安全机制也是可用的，只要它能够提供足够的对抗能力。

传统的网络安全机制，如传输层的SSL和TLS、VPN、IPSec、S/MIME等，都可以用于Web安全保护，但它们都是点到点的安全技术，对端到端的安全性是不够的。

现在，Web服务的应用拓扑包括大量移动设备的组合、网关、、负载均衡器、外包数据中心等，并且是全球分布、动态配置的系统。所有这些系统依靠消息处理中介的能力去转发消息。中介设施的数据接收和转发超越传输层，数据的完整性和安全性信息可能丧失。这一情况迫使任何消息处理器要信任前一个中介设施的安全性评估，并且完全相信它们对消息内容的处理。一个全面的Web服务安全性体系结构所需要的是端到端的安全性。成功的Web服务安全性解决方案应当同时成功地对传输层和应用层实现安全保护，提供全面的安全性能力。

信息系统通常采用的安全性保护技术，可以用于Web服务，包括以下方面：

（1）认证。认证是对服务请求者和提供者身份的检验，有时候还需要对双方进行互相认证。可用的技术包括：口令、证书、LDAP、Kerberos、PKI；

（2）授权。控制请求者接入资源，并规定请求者的接入权利。通常采用最小接入权限的策略；

（3）数据完整性和机密性。一般使用数据加密和签名技术；

（4）交易正确性；

（5）不可抵赖；

（6）端到端的消息完整性和机密性；

（7）安全的消息传输。保证信息安全性、消息的加密和签名技术；

（8）审计踪迹。可以通过对资源的监测和守护而得到。

（9）安全策略的分布执行；

（10）跨领域的身份标识。支持不同领域身份标识的映射；

（11）安全的发现机制；

（12）发现与信任。

2 Web服务架构示例

以服务发现为例，完成服务。下面是SOAP服务使用的详细过程。

通过WSOL ESB完成，目前SOAP服务到ESB，必须提供正确可用的WSDL文件。提供方式有两种：第一是给管理员提供可访问WSDL的URL；第二是把WSDL以纯文本文件发送给管理员。

发送URL方式可以访问WSDL所在URL的协议，必须是HTTP/HTTPS协议。例如：http：//yczy.zys.zbb.hj/wiki/ws.php？wsdl，这样，管理员可以在ESB上导入此URL所包含的WSDL内容，从而创建相应的SOAP Web Service。

发送WSDL文件，发送的WSDL文件必须是纯文本文件，内容为XML。这样才能为系统进行解析处理。下面是WSDL的示例作为参考，主要代码如下：

3 结 语

通过构建面向服务的应用支撑环境，各级保障部门、各个业务系统的信息服务，都能够通过服务的包装，成为随取即用的IT 资产，以服务的形式对外，以松耦合原则实现共享，并可将各种服务快速整合，开发出组合式应用，达到“整合即开发”的目的。

参 考 文 献

[1]韩丁，沈建京，万芳，等.基于SOA的服务构件封装技术研究[J].计算机工程与设计，2009（7）：202-205.

[2]杨斌，张卫冬，张利欣，等.基于SOA的物联网应用基础框架[J].计算机工程，2010，36（17）：95-97.

[3]凌晓东.SOA综述[J]；计算机应用与软件；2007（10）122-124.