2022年面向服务体系结构漫谈) .pdf

《2022年面向服务体系结构漫谈) .pdf》由会员分享，可在线阅读，更多相关《2022年面向服务体系结构漫谈) .pdf（4页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、面向服务体系结构（ SOA）漫谈摘要：本文简单的对于面向服务体系结构(SOA)进行了介绍，并且对SOA 的特点进行了整理，以及对SOA 的未来做了展望。一 SOA 定义SOA 是指为了解决在 Internet 环境下业务集成的需要， 通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点：1) 软件系统架构： SOA 不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说， 它更像一 种模式 (Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同

2、的应用场景，用来满足不同的特定需求。2) SOA 的使用范围：需求决定同时也限制功能。 SOA 并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet 环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点如何决定SOA 的特点，这里我们只需要先简单回顾一下Internet 环境区别于Intranet 环境的几个特点：a) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b) 大量、频繁的数据传输仍然速度缓慢并且不稳定；c) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。前看来大多数软件的

3、功能最终将作为服务来交付和使用。当然，它们可以实现为紧密耦合的系统，但从门户、设备以及其它终端使用的观点看，它们将使用一种面向服务的接口。我们已经注意到有人提出体系架构师和设计者应该谨慎避免将所有功能都作为服务。我们认为这是不正确和不适当的。如果有了成熟的 Web服务协议和技术，再考查是否将所有功能实现为Web服务是否有效，这可能会更加有效，但这并不会减弱从服务的角度来设计所有功能的需求。服务是发布的主要构造成分，应该在每一重要的接口中使用。面向服务的体系结构可以让我们按照相关的服务来管理使用（发送、接收、使用，等等）服务。这将对我们如何管理软件生命周期产生重大影响从需求规格说明开始就作为服务

4、，服务的设计，服务的获取和外包，以及服务的评估等等。随着时间推移，功能被说明、发布或使用的抽象级别会逐渐越来越高。我们已经经历了从模块化、对象，到现在的服务的发展过程。然而，在许多方面，SOA 的命名还是令人遗憾的。当然，SOA 也和体系结构相关，不可能将讨论限制在体系结构方面，因为一些事物，如业务设计和发送过程也是重要的考虑因素。一个更有用的命名方法可能是面向服务（ServiceOrientation）或 SO。实际上这与面向对象（ OO） 和基于组件的开发（ CBD）有许多相似之处：类似于对象和组件， 服务代表了自然的建造单元块，它可以让我们按更熟悉的方式来组织功能。 类似于对象和组件，

5、服务是一个功能建造单元块， 它可以组名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 4 页 - - - - - - - - - 合信息和行为。 隐藏内部的工作， 以防外部入侵。 为其它部分提供一个相对简单的接口。对象使用了抽象数据类型和数据抽象，服务可以通过方面或上下文环境提供类似级别的适应性。 对象和组件可以按照类或继承行为的服务层次来组织，服务可以单独发布和使用，或者按层次或协作方式来使用。对于许多组织来说，研究面向服务的体系结构的起点是对Web 服务的考虑。然而 W

6、eb服务不是内在的面向服务的。一种 Web服务只是提供一种符合Web服务协议的功能。在本文中，我们将要标识一个结构良好的服务所具有的特征，并为系统架构师和设计者提供关于如何交付面向服务的应用程序的指导。基于上面的前提，下面就让我们一起看一下SOA 的基本特征。二 SOA 三大基本特征1 独立的功能实体在 Internet 这样松散的使用环境中， 任何访问请求都有可能出错，因此任何企图通过 Internet 进行控制的结构都会面临严重的稳定性问题。SOA 非 常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NETRemoting，EJB，COM 或者 CORBA，都需要有

7、一个宿主 (Host 或者 Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。SOA 架构中非常强调实体自我管理和恢复能力。 常见的用来进行自我恢复的技术，比如事务处理 (Transaction)，消息队列 (MessageQueue)，冗余部署 (RedundantDeployment)和集群系统 (Cluster)在 SOA 中都起到至关重要的作用。2 大数据量低频率访问对 于.NET Remoting，EJB 或者 XML-RPC 这些传统的分布式计算模型而言，他们

8、的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet 的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在 Internet 环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA 系统推荐采用大数据量的方式一次性进行信息交换。3 基于文本的消息传递由 于 Internet中大量异构系统的存在决定了SOA 系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA 这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某

9、些功能； 但是在 Internet 环境下，不同语言，不同平台对数据、 甚 至是一些基本数据类型定义不同， 给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。此外，对于一个服务来说，Internet与局域网最大的一个区别就是在 Internet 上的版本管理极其困难， 传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。HTTP 协议：

10、一个典型的SOA 实现每 一项新技术都是在一些旧的技术基础上发展出来的。正如XML 根本思想来自于在 60 年代就已经出现的早期标记性语言一样，SOA 虽然这两年才出现，但名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 4 页 - - - - - - - - - 是它所 表达的观念应该说在网络这种分布式系统结构出现不久就已经广泛应用了。例如我们最熟悉的HTTP 协议就是一个非常典型的SOA 架构设计。 HTTP协议的工作过程简单叙述如下：1) 客户端，通常是通过浏览器，向

11、服务器端以文本的方式发送一个请求，索取一个 Web页面；2) 服务器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML 语法的文本；3) 客户端接收到服务器端的响应文本后调用本地的程序，通常还是浏览器，把返回的 HTML 文本的内容展现出来。下面来看一下 HTTP 协议如何满足了 SOA 的特点：* 独立的功能实体：作为服务器端的Web服务器是绝对不会因为客户端的状况变化而改变的，它总是非常稳定地按照自己的内在逻辑运行，响应外部的请求，管理自 己的资源和数据。这里一个非常好的例子就是Web服务器对缓存 (Cache)的处理，很多 Web服务器为了提高性能都或多或少的对数据进行

12、缓存，但是缓存 数据、刷新数据这些于客户端完全无关的操作完全由服务器端独立完成，完全不受客户端的影响。* 大数据量低频率访问： 对于一个 HTTP 请求来说，客户端与服务器之间访问的边界非常简单：就是一个请求，一个响应，没有任何其它的信息往返。无论客户端申 请的网页上除了文字之外还有什么信息，对于客户端来说，它发出的请求只是简单的告诉Web服务器它所需要的网页的位置；至于为了生成这个网页，服务器端是否需要访问数据库，执行 Servlet或者其它的 CGI 程序对客户端而言，都是完全透明的。* 基于文本的消息传递： 迄今为止兼容性最好的系统可能就是HTTP 协议支撑的大部分的 web应用了，我们

13、可以在 Windows 平台下用 IE 查看互联网上一个LinuxApache服务器上的由 Perl 脚本自动生成的网页。这里的关键就是所有内容都是以格式化的文本方式传递的，不管Perl 脚本如何执行，只要它的输出是符合HTML 规范的网页， 就可以被客户端的浏览器解释。 而由于不同的操作系统上对于相同的 HTML 的解释遵循相同的规范， 因此不同操作系统下仍然能够看到一致的用户界面。我们上面基本描述了SOA 作为一种软件架构有哪些特点，下面让我们一起看看WebService与 SOA 的关系。SOA 与 WebServiceWebService是就现在而言最适合实现SOA 的一些技术的集合，

14、事实上最近 SOA的火爆在很大程度上归功于WebService标准的成熟和应用的普及为广泛的实现SOA 架构提供了基础。 下面让我们看看 WebService中的各种协议是如何互相工作来满足 SOA 所需的特点的：* 独立的功能实体： 通过 UDDI 的目录查找， 我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP 访问进行，只要WSDL 接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。* 大数据量低频率访问：通过使用WSDL 和基于文本 (Literal)的 SOAP 请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SO

15、AP 请求分文本方式和远程调用 (RPC)两种方式，正如上文已经提到的，采用远程调用方式的 SOAP 请求并不符合这点要求。但是令人遗憾的是现有的大多数 SOAP 请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM WebSphere的早名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 4 页 - - - - - - - - - 期版本，甚至没有提供文本方式的SOAP 支持。* 基于文本的消息传递： WebService所有的通讯是通过SOAP 进行的，而 S

16、OAP是基于 XML 的，不同版本之间可以使用不同的DTD 或者 XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。SOA 对于软件架构设计的影响无论您现在的系统是否牵涉到基于Internet 的业务集成，采用 SOA 推荐的架构都对提高您系统的扩展性有很大帮助，下面是在系统中引入SOA 后需要在软件架构方面做出的改变：* 使用基于文本方式的SOAP 调用， 摆脱远程调用中出现的函数参数类型等与数据无关的信息， 保证所有 SOAP传递的都是有意义的商业数据。依赖于 Schema ，而不是类定义对这些数据进行解释。* 传统的三层 Web应用

17、将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA 层。SOA 的前景现在的 Web 服务实现往往是简单的，通常类似于客户端-服务器模型。然而，平台中立的交换是受支持的， 这就使一系列不同的客户端实现可以与作为服务器函数的新代码或遗留代码进行交互。许多文章都介绍了使这样的应用程序直接实现的技术。 现在是看一看我们能够如何使用它们的更大图景的时候了。公元前 221 年，秦始皇将以前交战的几个国家统一为一个新的国家，我们现在称之为中国。中国作为一个国家存在下来的一个可能的原因就是秦朝引入了标准，标准巩固了文化

18、，促进了贸易：标准的轮距使得马车可以有效地行使在任何的道路，共同的书面语言使得每个人都可以交换信息（即使他们说的并不是相同的语言） ，而坚固的工事（比如中国的长城）使得人们可以防御外敌入侵。您可以说，他为标准化传输、消息交换和防火墙开发了一些模型。同样地，现代的业务集成同样也受益于标准，它使异构的计算机系统能够有效 地互操作。这些技术合在一起称作Web 服务。 Web 服务的出现是以SOAP1.1 的引入为标志的， SOAP 1.1 定义了将XML内容用于分布式系统，而同时隐藏实现的细节。四年后的今天，许多公司正在使用Web 服务，并且可以毫无疑问地地说，业界正处在Web 服务主流时代的开端。IBM 将面向服务的体系结构（Service-OrientedArchitecture，SOA）视为它的按需（ On demand）业务前景的互操作性和灵活性的关键。面向服务的体系结构（SOA）支持跨企业和业务合作伙伴之间间的端到端集成。这就提供了一种灵活的业务流程模型，使得客户可以迅速地响应新的顾客需求、新的业务机会以及竞争的威胁。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 4 页 - - - - - - - - -