B5soa与架构的关系

SOA与软件架构的关系姓名：梁兢院系：软件学院0903班学号：M200976060摘要SOA是英文Service-OrientedArchitecture，即服务导向架构的缩写。这个词汇最近一两年频频出现在各种技术期刊上。但是一直以来对于SOA到底是什么一直没有明确的回答；SOA有什么特点？适合用于解决哪些问题？与其他的技术有什么区别与联系？WebService和SOA又是什么关系？SOA的出现对于软件架构设计有什么影响？SOA定义SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点:1)软件系统架构:SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。2)SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵单，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点是如何决定了SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：a)大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b)大量、频繁的数据传输仍然速度缓慢并且不稳定；c)版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。SOA三大基本特征独立的功能实体在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NETRemoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(MessageQueue)，冗余部署(RedundantDeployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。大数据量低频率访问对于.NETRemoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。基于文本的消息传递由于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于WebServiceWebService是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的火爆在很大程度上归功于WebService标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。下面让我们看看WebService中的各种协议是如何互相工作来满足SOA所需的特点的:独立的功能实体:通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，采用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大多数SOAP请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBMWebSphere的早期版本，甚至没有提供文本方式的SOAP支持。基于文本的消息传递:WebService所有的通讯是通过SOAP进行的，而SOAP是基于XML的，不同版本之间可以使用不同的DTD或者XMLSchema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。SOA对于软件架构设的影响无论您现在的系统是否牵涉到基于Internet的业务集成，采用SOA推荐的架构都对提高您系统的扩展性有很大帮助，下面是在系统中引入SOA后需要在软件架构方面做出的改变：使用基于文本方式的SOAP调用，摆脱远程调用中出现的函数参数类型等与数据无关的信息，保证所有SOAP传递的都是有意义的商业数据。依赖于Schema，而不是类定义对这些数据进行解释。传统的三层Web应用将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA层。更好支持商业流程SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-TimeEnterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIORhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。企业流程（enterpriseprocess）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。有利于企业业务的集成,传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构(SOA)的应用开发和集成可以很好的解决其中的许多问题。SOA描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。不同于传统的应用集成方法，