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

引言

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所示。

Web服务用机器可处理的格式，以特定的Web服务描述 语言描述接口及其他系统与Web服务的互动，以SOAP消息 实现通信。事实上，可以把Web服务看做是一种至少具有以 下制约的SOA :

第一是接口必须基于互联网协议，如HTTP、FTP、 SMTP ；第二是消息必须是XML格式的。

REST （Representational State Transfer，表现层状态转化） 在Web领域已经得到了广泛的接受，是基于SOAP和WSDL 的Web服务的更为简单的替代方法。REST定义了一组体系架 构原则，可以根据这些原则设计以系统资源为中心的Web服 务，包括使用不同语言编写的客户端如何通过HTTP处理和 传输资源状态。Web服务具体实现应具备以下SOA技术点： 2关键技术研究

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

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

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

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

-采用同质技术体系

中心辐射型(Hub-and-spoke)的主要方式是总线型(ESB)) 有些ESB厂商认为ESB不属于中心辐射型，其实ESB在逻 辑拓扑上仍然属于中心辐射型，只不过其组件可能是分布式的, 以消除性能瓶颈和单点故障(SPOF, single-point-of-failure)。 图3所示是总线型连接方式。

图3总线型连接方式

近年来，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服 务，包括以下方面：

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

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

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

交易正确性；

不可抵赖；

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

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

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

安全策略的分布执行；

跨领域的身份标识。支持不同领域身份标识的映射;

安全的发现机制；

发现与信任。

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 的示例作为参考，主要代码如下：

<?xml version=v1.0 v?>

<wsdl : definitions name= ” WikiService ” targetNamespace=” http : //wiki.hyperats.com/”

xmlns : ns1=” http : //schemas.xmlsoap.org/soap/ http”xmlns : soap=” http : //schemas.xmlsoap.

org/wsdl/soap/‘‘ xmlns : tns=” http : //wiki.hyperats. com/”xmlns : wsdl=” http : ^schemas.xmlsoap.

org/wsdl/” xmlns : xsd=” http : //www.w3.org/2001/ XMLSchema” >

<!-- Messages -->

<wsdl: message name=” helloResponse” >

<wsdl : part element=” tns : helloResponse” name=” parametersv>

</wsdl part>

</wsdl message>

<wsdl: message name=” hello” >

< w s d l : part el e m e n t = ” tns : hello ” name=” parametersv>

</wsdl part>

</wsdl message>

<!--省略-->

</wsdl message>

<!-- Operations -->

<wsdl: portType name="WikiWs">

<wsdl: operation name="hello">

<wsdl : input message= "tns : hello" name="hello">

</wsdl input>

<wsdl : output message="tns : helloResponse" name="helloResponse"〉

</wsdl output>

</wsdl operation>

<!--省略-->

</wsdl portType>

<!-- Protocol binding -->

<wsdl : binding name="WikiServiceSoapBinding"

type="tns : WikiWs">

<soap : binding style="document" transport="http : // schemas.xmlsoap.org/soap/http"></soap binding>

<wsdl: operation name=” hello” >

<soap : operation soapAction=””

style=” documentv></soap : operation>

<wsdl: input name=” hello” >

<soap : body use=” literalv></

soap body>

</wsdl input>

<wsdl: output name=” helloResponse” >

<soap : body use=” literalv></

soap body>

</wsdl output>

</wsdl operation>

<!--省略-->

</wsdl binding>

<!-- Service endpoint -->

<wsdl: service name="WikiService">

<wsdl: port binding="tns : WikiServiceSoapBinding" name="WikiPort">

<soap : address location="http :

〃192.168.12.44/ws.php"></soap : address>

</wsdl port>

</wsdl service>

</wsdl definitions>

这样就完成了服务发布工作。

3结语

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

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