面向服务体系结构漫谈).docx

面对服务体系结构（SOA）漫谈摘要：本文简洁的对于面对服务体系结构（SOA）进行了介绍，并且对SOA的特点进行 了整理，以及对SOA的将来做了展望。-SOA定义SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独 立功能实体实现的一种软件系统架构。从这个定义中我盼望表达的前提有下面两点：1）软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架 构，它尝试给出在特定环境下推举采纳的一种架构，从这个角度上来说，它更像一种模式 （Pattern）0因此它与很多已有的软件技术比如面对对象技术，是互补的而非互斥的。它们 分别面对不同的应用场景，用来满意不同的特定需求。2） SOA的使用范围：需求打算同时也限制功能。SOA并不是包治百病的万灵丹，它 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在 下面我们会具体争论Internet的各种特点如何打算SOA的特点，这里我们只需要先简洁 回顾一下Internet环境区分于Intranet环境的几个特点：a）大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b）大量、频繁的数据传输仍旧速度缓慢并且不稳定；c）版本升级无法完成,我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。前看来大多数软件的功能最终将作为服务来交付和使用。当然，它们可以实现为紧密 耦合的系统，但从门户、设施以及其它终端使用的观点看，它们将使用一种面对服务的接 口。我们已经留意到有人提出体系架构师和设计者应当谨慎避开将全部功能都作为服务。 我们认为这是不正确和不适当的。假如有了成熟的Web服务合同和技术，再考查是否将 全部功能实现为Web服务是否有效，这可能会更加有效，但这并不会减弱从服务的角度 来设计全部功能的需求。服务是发布的主要构造成分，应当在每一重要的接口中使用。面 对服务的体系结构可以让我们依据相关的服务来管理使用（发送、接收、使用，等等）服 务。这将对我们如何管理软件生命周期产生重大影响-从需求规格说明开头就作为服 务，服务的设计，服务的猎取和外包，以及服务的评估等等。随着时间推移，功能被说明、发布或使用的抽象级别会渐渐越来越高。我们已经经受 了从模块化、对象，到现在的服务的进展过程。然而，在很多方面，SOA的命名还是令 人圆满的。当然，SOA也和体系结构相关，不行能将争论限制在体系结构方面，由于一些 事物，如业务设计和发送过程也是重要的考虑因素。一个更有用的命名方法可能是面对服 务（Service Orientation ）或SO。实际上这与面对对象（00 ）和基于组件的开发（CBD ） 有很多相像之处：类似于对象和组件，服务代表了自然的建筑单元块，它可以让我们按更熟识的方式来 组织功能。类似于对象和组件，服务是一个功能建筑单元块，它可以组合信息和行为。隐 蔽内部的工作，以防外部入侵。为其它部分供应一个相对简洁的接口。对象使用了抽象数 据类型和数据抽象，服务可以通过方面或上下文环境供应类似级别的适应性。对象和组件 可以依据类或继承行为的服务层次来组织，服务可以单独发布和使用，或者按层次或协作 方式来使用。对于很多组织来说，争论面对服务的体系结构的起点是对Web服务的考虑。 然而Web服务不是内在的面对服务的。一种Web服务只是供应一种符合Web服务合同 的功能。在本文中，我们将要标识一个结构良好的服务所具有的特征，并为系统架构师和设计者供应关于如何交付面对服务的应用程序的指导。基于上面的前提，下面就让我们一起看一下SOA的基本特征。二SOA三大基本特征1独立的功能实体在Internet这样松散的使用环境中，任何访问恳求都有可能出错，因此任何企图通过 Internet进行掌握的结构都会面临严峻的稳定性问题。SOA非常强调架构中供应服务的 功能实体的完全独立自主的力量。传统的组件技术，如.NET Remoting , EJB , COM或者 CORBA ,都需要有一个宿主(Host或者Server)来存放和管理这些功能实体;当这些宿主 运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分消失问题的时 候，在该宿主上运行的其它应用服务就会受到影响。SOA架构中特别强调实体自我管理和恢复力量。常见的用来进行自我恢复的技术， 比如事务处理(Transaction),消息队歹I(Message Queue),冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。2大数据量低频率访问对于.NET Remoting , EJB或者XML-RPC这些传统的分布式计算模型而言，他们的 服务供应都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器 来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定 性带来的影响都可以忽视不计，但是在Internet环境下这些因素往往是打算整个系统是否能正常工作的一个关键打算因素。因此SOA系统推举采纳大数据量的方式一次性进行信息 交换。3基于文本的消息传递由于Internet中大量异构系统的存在打算了 SOA系统必需采纳基于文本而非二进制 的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的 是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能"旦是在 Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不 同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理规律 和数据类型的，因此服务间只传递文本，对数据的处理依靠于接收端的方式可以帮忙绕过 兼容性这个的大泥坑。止的卜，对于一个服务来说internet与局域网最大的一个区别就是在Internet上的 版本管理极其困难，传统软件采纳的升级方式在这种松散的分布式环境中几乎无法进行。 采纳基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据, 而忽视其它的数据，从而得到的特别抱负的兼容性。HTTP合同：一个典型的SOA实现每一项新技术都是在一些旧的技术基础上进展出来的。正如XML根本思想来自于在 60年月就已经消失的早期标记性语言一样，SOA虽然这两年才消失，但是它所表达的观 念应当说在网络这种分布式系统结构消失不久就已经广泛应用了。例如我们最熟识的 HTTP合同就是一个特别典型的SOA架构设计。HTTP合同的工作过程简洁叙述如下：1）客户端，通常是通过扫瞄器，向服务器端以文本的方式发送一个恳求，索取一个 Web页面；2）服务器端接收到这个恳求之后，依据恳求的内容进行处理并且返回一个符合HTML 语法的文本；3）客户端接收到服务器端的响应文本后调用本地的程序，通常还是扫瞄器，把返回的 HTML文本的内容呈现出来。下面来看一下HTTP合同如何满意了 SOA的特点：*独立的功能实体祚为服务器端的Web服务器是肯定不会由于客户端的状况变化而 转变的，它总是特别稳定地依据自己的内在规律运行，响应外部的恳求，管理自己的资源 和数据。这里一个特别好的例子就是Web服务器对缓存（Cache）的处理，很多Web服务 器为了提高性能都或多或少的对数据进行缓存，但是缓存数据、刷新数据这些于客户端完 全无关的操作完全由服务器端独立完成，完全不受客户端的影响。* 大数据量低频率访问：对于一个HTTP恳求来说，客户端与服务器之间访问的边界 特别简洁：就是一个恳求，一个响应，没有任何其它的信息来回。无论客户端申请的网页 上除了文字之外还有什么信息，对于客户端来说，它发出的恳求只是简洁的告知Web服 务器它所需要的网页的位置；至于为了生成这个网页，服务器端是否需要访问数据库，执 行Servlet或者其它的CGI程序对客户端而言，都是完全透亮 的。* 基于文本的消息传递：迄今为止兼容性最好的系统可能就是HTTP合同支撑的大部 分的web应用了，我们可以在Windows平台下用IE查看互联网上一个Linux + Apache服务器上的由Perl脚本自动生成的网页。这里的关键就是全部内容都是以格式化的文本方 式传递的，不管Perl脚本如何执行，只要它的输出是符合HTML法律规范的网页，就可 以被客户端的扫瞄器解释。而由于不同的操作系统上对于相同的HTML的解释遵循相同的 法律规范，因此不同操作系统下仍旧能够看到全都的用户界面。我们上面基本描述了 SOA作为一种软件架构有哪些特点，下面让我们一起看看Web Service与SOA的关系。SOA 与 Web ServiceWeb Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的 火爆在很大程度上归功于Web Service标准的成熟和应用的普及为广泛的实现SOA架构 供应了基础。下面让我们看看Web Service中的各种合同是如何相互工作来满意SOA所 需的特点的：* 独立的功能实体：通过UDDI的名目查找，我们可以动态转变一个服务的供应方而 无需影响客户端的应用程序配置。全部的访问都通过SOAP访问进行，只要WSDL接口封 装良好，外界客户端是根本没有方法直接访问服务器端的数据的。* 大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP恳求，我们可 以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP恳求分文本方式和远 程调用(RPC)两种方式，正如上文已经提到的，采纳远程调用方式的SOAP恳求并不符合 这点要求。但是令人圆满的是现有的大多数SOAP恳求采纳的仍旧是远程调用(RPC)方式, 在某些平台上，例如IBM WebSphere的早期版本，甚至没有供应文本方式的SOAP支持。* 基于文本的消息传递：Web Service全部的通讯是通过SOAP进行的，而SOAP是 基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本供应不同的处理就可以轻松实现版本掌握的目标。SOA对于软件架构设计的影响无论您现在的系统是否牵涉到基于Internet的业务集成，采纳SOA推举的架构都对 提高您系统的扩展性有很大关心,下面是在系统中引入SOA后需要在软件架构方面做出的 转变：* 使用基于文本方式的SOAP调用，摆脱远程调用中消失的函数参数类型等与数据无 关的信息，保证全部SOAP传递的都是有意义的商业数据。依靠于Schema ,而不是类定 义对这些数据进行解释。* 传统的三层Web应用将可能变成四层结构传统意义上的商业规律层将被进一步划 分为存放每个会话(Session)信息的客户规律层和与状态无关Sateless的SOA层。SOA的前景现在的Web服务实现往往是简洁的，通常类似于客户端-服务器模型。然而，平台中 立的交换是受支持的，这就使一系列不同的客户端实现可以与作为服务器函数的新代码或 遗留代码进行交互。很多文章都介绍了使这样的应用程序直接实现的技术。现在是看一看 我们能够如何使用它们的更大图景的时候了。公元前221年，秦始皇将以前交战的几个 我国统一为一个新的我国，我们现在称之为中国。中国作为一个我国存在下来的一个可能 的缘由就是秦朝引入了标准，标准巩固了文化，促进了贸易：标准的轮距使得马车可以有 效地行使在任何的道路，共同的书面语言使得每个人都可以交换信息（即使他们说的并不 是相同的语言），而结实的工事（比如中国的长城）使得人们可以防备外敌入侵。您可以 说，他为标准化传输、消息交换和防火墙开发了一些模型。同样地，现代的业务集成同样也受益于标准，它使异构的计算机系统能够有效地互操 作。这些技术合在一起称作Web服务。Web服务的消失是以SOAP 1.1的引入为标志 的，SOAP 1.1定义了将XML内容用于分布式系统，而同时隐蔽实现的细节。四年后的 今日，很多公司正在使用Web服务，并且可以毫无疑问地地说，业界正处在Web服务 主流时代的开端。IBM将面对服务的体系结构（Service-Oriented Architecture , SOA ）视为它的按 需（On demand ）业务前景的互操作性和敏捷性的关键。面对服务的体系结构（SOA ） 支持跨企业和业务合作伙伴之间间的端到端集成。这就供应了一种敏捷的业务流程模型, 使得客户可以快速地响应新的顾客需求、新的业务机会以及竞争的威逼。