中文XML论坛--Understanding SOA with Web Services中文版连载

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

用Web服务实现SOA的主要优点在于：Web服务是广泛普及的、简单的和平台中立的。

如图1-6所示，基本的Web服务架构包含了SOAP、 WSDL、UDDI等支持服务请求者与服务提供者进行交互，以及用于Web服务发现的规范。服务提供者通常用WSDL来描述它所提供的Web服务，然后将该WSDL描述发布；服务请求者可以通过UDDI或其他注册库（registry）来获取WSDL描述，并通过向服务提供者发送一个SOAP消息来请求执行服务。基本的Web服务标准，已经适于构建基于SOA的应用了，但还不足以构建其他应用。

Why UDDI Is Not a Core Web Services Specification

为什么UDDI不属于基本的Web服务规范

可以肯定地说，UDDI的最初设想并没有实现。UDDI于2000年底推出，其初衷是要实现一个公共目录（public directory）。原先的设想是：一家公司在UDDI中注册它的Web服务，随后其他公司便可动态地发现它们所需要的、支持在Internet上使用的服务。当时UDDI的假定是：各个公司将乐于发现和请求来自之前无合作关系的提供者的服务。这一点已被证明是错误的。另外，UDDI是在WSDL之前被开发的，所以UDDI最初并不能很好地支持WSDL。UDDI的数据结构是无限制的，只规定了很少的信息，而且结构所基于的分类数据（categorization data）也不是被广泛认同的——这样的数据结构造成了极多问题。UDDI曾被定位为企业内部的技术，也就是在这方面UDDI取得了一些成功，但是 UDDI在这方面的标准工作做得仍不够。在内部使用UDDI的公司必须定义它们自己的命名规则和分类结构（categorization structure）与元数据（metadata），这些都妨碍了UDDI被采纳。随着SOAP与WSDL获得了极大的成功和普遍的采纳，UDDI仍在为寻找其在Web服务中的适当应用场合而挣扎。不错，Web服务平台是需要一个服务注册库（service registry），但UDDI是否能够成为解决方案尚不可知。

图1-6 基本的Web服务架构

除基本的Web服务规范（SOAP和WSDL）以外，其他各种用于安全性（security）、可靠性（reliability）、事务性（transactions）、元数据管理（metadata management）以及服务编制（orchestration）等方面的补充Web服务规范也正在标准化的过程之中，这些都为基于SOA的解决方案提供了必需的企业级服务质量，以支持各类任务关键型（mission-critical）、企业级的项目。

Borrowing from the Web

借鉴Web的成功经验

用Web 服务作为实现SOA的技术平台具有许多优点，这些优点的获得与万维网（World Wide Web）取得巨大成功的方式是一脉相承的。其中最主要的是：一种简单的文档标记语言（比如HTML或XML）和一个轻量级的（lightweight）文档传送协议（比如HTTP）；前者提供了强大的互操作性，后者提供了有效的、统一的数据传送机制。在Web上，使用哪个操作系统（比如Linux、 Windows、OS390、HP NonStop或Solaris），采用何种Web服务端（比如Apache或IIS），用什么语言（比如Java、C#、COBOL、Perl或 LIST）编写业务逻辑，以及使用哪种浏览器（比如Netscape、Internet Explorer、Mozilla或W3C的Amaya）都无关紧要。最重要的是Web服务端能够理解请求HTML文件的HTTP请求，以及浏览器知道如何将HTML文件显示出来。Web服务也为IT系统提供了同样层次的抽象。类似地，对于Web服务来说，最重要的是能够理解并处理收到的XML消息并发出回复（如果有定义的话）。任何具备TCP连接的计算机系统都可以增加对HTML和HTTP的支持。同样地，任何能够理解XML和HTTP（或者XML和其他普及的通信传输协议）的计算机都可以增加对Web服务的支持。

图1-7显示了完整的Web服务平台所具有的特性与能力，在该平台上可以构建各种基于SOA的应用。图中既包括了基本的Web服务规范，也包括了一些补充的Web服务规范。关于Web服务平台的详细描述，请参见第二章“SOA概述”。

该Web服务平台包含支持SOA所需的各种基本与补充特性，以及一个用于连接各个服务的企业服务总线（Enterprise Service Bus，ESB）。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

几年前，觉得需要综合集成方案（integration solution）的企业转向了专用于此用途的产品与实务（practices）。可是，这些企业应用集成（Enterprise Application Integration，EAI）产品是昂贵的，它们耗去了大量的时间和精力，而结果却往往是失败的。而且，由于各种专门用途的产品是专有的（它们之间不可互操作），因此如果一个公司购入了多种这样的产品，那么很多项目将遭遇额外的麻烦。

最近的经验表明，一个较好的解决方案是使用Web服务标准。通过使用一种EAI产品来增加一个开放的、基于标准的抽象层，可以更容易地实现与几乎任何现有环境的集成，而不必处理由不兼容的应用引入的复杂性。

BEA、IBM、IONA、Microsoft、SAP、 SeeBeyond、Systinet、Tibco、WebMethods等公司的新一代的、基于Web服务技术的集成产品（integration products）正围绕着面向服务的集成（service-oriented integration）的概念而诞生。

Web服务与SOA的组合，提供了一种快速集成方案，它关注被共享的数据与可重用服务（而不是专有的集成产品），因此能够更快、更轻松地确保IT投入与企业战略保持一致。

下面通过一个例子来展示面向服务的集成（service- oriented integration）的优点。有三种较典型的金融业数据库应用，分别用于支持个人金融业务、公司金融业务和共同基金投资（mutual fund investment）等操作。用传统的三层架构（three-tier architecture）来开发应用，将区分表示逻辑（presentation logic）、业务逻辑（business logic）和数据库逻辑（database logic）。

如图1-8 所示，传统的三层结构的应用可被重用为一个面向服务的应用（service-oriented application）：在业务逻辑层创建服务，利用服务总线（service bus）将上述应用与其他应用集成。面向服务的另一个优点是，如果业务逻辑层支持服务的话，将更易于实现表示逻辑与业务逻辑的分离。如果业务逻辑层支持服务的话，就容易实现各种GUI及移动设备与应用的连接，这比“为各个业务逻辑编写紧耦合的表示逻辑”要好。可以将表示逻辑置于一个独立的设备上，然后通过服务总线实现与应用的通信，而不必为同一种服务端使用与之紧耦合的表示逻辑层。

使用在业务逻辑层定义的Web服务，与使用各种不同的集成技术相比，更利于应用进行数据交换，因为Web服务体现了各种软件的一个公共标准。XML可被用于独立地定义数据类型与结构。最后，在业务逻辑层进行面向服务入口点的开发，令业务流程管理引擎可以启动一个涉及多个服务的自动执行流程。

图1-8 面向服务的集成

为应用的业务逻辑层创建一个公共的业务逻辑层（或称作“覆盖（overlay）”服务），使得我们可以通过公共的服务仓库（service repository）来存放和获取服务描述。如果一个新的应用要使用已有的服务，它可以通过查询服务仓库获得服务描述，然后利用服务描述生成与该服务进行交互的SOAP消息。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

大部分机构（商业的、政府的和非盈利的）的主要目标是为它们的顾客、客户、合作伙伴、公民或其他机构提供服务。这些机构通常通过多种渠道（channels）为其客户提供服务，以保证良好的服务和保持客户忠诚度。银行为了方便客户，提供了各种使用银行服务的方式，比如通过Web、ATM柜员机、出纳员窗口等。同样地，如果其他机构能让其客户通过多种服务渠道使用其服务（直接的或间接的）的话，将会受益于此。

一般而言，业务服务（business services）不如提供服务的渠道变化得频繁。业务服务体现了运营功能（比如账户管理、订单管理、编制账单等），而客户设备和服务渠道是基于新技术的，因此变化更为频繁。

由于Web服务可被各种客户端（比如Web、Java、C#及移动设备等）使用，因此Web服务接口有利于提供多渠道服务（multiple-channel access）。所以，利用SOA与Web服务，机构可以容易地完成提供多种服务渠道的任务。

图1-9展示了多渠道服务的例子。其中，一家机构的客户服务应用发布了各种服务，用于报告问题、跟踪问题报告的状态、发现新的补丁和向用户发布的错误报告等。一位客户经理需要通过移动电话使用服务，以及时追踪客户的问题报告列表。如果产品是通过代理商销售的，代理商可以提供它自己的客户服务。代理商的客户服务可以与供货商的应用连接，以分别提供一级和二级客户服务支持。负责某重要客户的客户服务经理可以直接使用这些特性、功能以及存放在客户服务应用中的信息。客户自己也可以通过移

动PDA设备查询某个已提交问题的状态。最后，呼叫中心接线员需要访问应用所提供的服务来开展他们的工作（也就是与有问题的客户进行互动）。

图1-9 为客户提供多渠道服务

过去，机构开发的解决方案通常要为各种服务渠道分别提供一套完整的应用，比如3270终端、PC接口或浏览器。服务渠道的增加（比如新的最终用户设备），令面向服务的企业可以随时随地为客户、供货商及合作伙伴提供更好的服务。但是，这也是对IT部门的重大挑战，因为需要将现有的单片式应用（monolithic applications）转换为可以提供多渠道服务的应用。当然，基本的方案是通过使用SOA与Web服务来提供这些应用。

Occasionally Connected Computing

偶发连接计算[B][5][/B]

在把移动设备集成到SOA中时存在一个特有的问题，即移动设备不能保证与网络的持久连接。另外，移动设备会跨越不同的网络连接区域，并在重新连接时取得新的IP地址。目前营运环境中的多数应用都不能处理这种网络连接上的变化。正在兴起的新一代“移动（mobilized）”软件将快速而轻松地把移动设备集成到面向服务的企业（service-oriented enterprise）中。

在图1-10所示的移动软件方案中，从移动客户端到服务端的SOAP消息，是通过一种存储转发式的（store-and-forward）异步协议传输的，这种协议令移动客户端可以在网络连接不可用的情况下继续工作。在连接可用的情况下，事务（transactions）通过消息传输协议流向服务端的基于SOA的应用。在连接不可用的情况下，事务被保存在本地，待网络连接可用时再发送出去。


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	2,609.375ms