面向服务体系结构.docx
《面向服务体系结构.docx》由会员分享，可在线阅读，更多相关《面向服务体系结构.docx（18页珍藏版）》请在冰点文库上搜索。
面向服务体系结构
面向服务的体系结构
今天，Web服务——特指用Web服务描述语言（WebServicesDescriptionLanguage，WSDL）描述的、通过HTTP发送的、处理XML编码的SOAP消息的分布式服务——正得到广泛的部署。
Web服务可用在各种各样的应用程序集成环境中：
从简单的（特别是防火墙后面的）数据共享到大规模的Internet零售和货币交易。
Web提供了软件组件之间的互操作性，这些软件组件可以在不同的企业之间进行通信，并且可以驻留在不同的基础架构中。
这解决了顾客、软件开发人员和合作伙伴所面临一个最重要的问题。
HTTP和SOAP提供了通信和消息的互操作性。
WSDL提供了消息的描述，以支持开发工具之间的互操作性；它凭借交换接口定义的能力来完成通信互操作性。
一组基本的Web服务规范使顾客和软件厂商能够解决一些重要的问题。
在这些规范成功的基础上，许多开发人员和公司准备解决Web服务方面更难的问题。
Web服务的巨大成功使开发人员想要从Web服务获得更多的能力。
由于重要的工具和通信互操作已经成功了，所以开发人员现在期望增强互操作的功能。
除了基本的消息互操作性和接口交换之外，开发人员越来越需要更高级别的应用程序服务互操作。
许多商业应用程序运行在这样一种环境中（“中间件”或“操作系统”），这种环境为一些功能（比如安全性和事务处理）提供支持。
IBM、Microsoft和业界其他一些公司常常需要使Web更安全、更可靠且更好地支持事务处理。
另外，我们在提供这些能力的同时，还需要保持现在Web服务中必不可少的简单性和互操作性。
面向服务体系结构（SOA）定义
SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。
从这个定义中我希望表达的前提有下面两点：
1）软件系统架构：
SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式（Pattern）。
因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。
它们分别面向不同的应用场景，用来满足不同的特定需求。
2）SOA的使用范围：
需求决定同时也限制功能。
SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。
在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：
a）大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；
b）大量、频繁的数据传输仍然速度缓慢并且不稳定；
c）版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。
基于上面的前提，下面就让我们一起看一下SOA的基本特征。
SOA三大基本特征
1独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。
SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。
传统的组件技术，如.NETRemoting，EJB，COM或者CORBA，都需要有一个宿主（Host或者Server）来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。
这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。
常见的用来进行自我恢复的技术，比如事务处理（Transaction），消息队列（MessageQueue），冗余部署（RedundantDeployment）和集群系统（Cluster）在SOA中都起到至关重要的作用。
2大数据量低频率访问
对于.NETRemoting，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作为一种软件架构有哪些特点，下面让我们一起看看WebService与SOA的关系。
SOA与WebService
WebService是就现在而言最适合实现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层。
下面简要地描述了面向服务的体系结构的发展。
然后探讨面向组件的开发与面向服务的体系结构之间的关系，并说明如何将组件作为实现服务的基础设施。
第一部分：
新方法的商业驱动力
虽然IT经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。
在所有这些压力之下，有两个基本的主题：
异构和改变。
现在，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。
集成来自多个厂商跨不同平台的产品简直就像一场噩梦。
但是我们也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。
在当今IT经理面临的问题之中，改变是第二个主题。
全球化和电子商务加快了改变的步伐。
全球化带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。
在竞争产品和可以从Internet上获得的大量产品信息的推动下，客户要求更快速地进行改变。
因而，在改进产品和服务方面展开的竞争进一步加剧了。
为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。
企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的环境中取得成功了，而IT基础设施必须支持企业提高适应能力。
因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。
重点是扩展供应链，支持客户和合作伙伴访问业务服务。
图1展示了企业的这种发展。
图1企业的发展
如何使IT环境更灵活且更快地响应不断改变的业务需求呢？
我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？
我们如何达到企业目标而不使企业走向破产的深渊呢？
IT响应者/支持者是随着企业的这种发展而并行发展的，如图2所示。
现在，许多IT经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。
图2面向服务的术语
为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：
松散耦合
位置透明
协议独立
基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。
基础设施对请求者隐藏了尽可能多的技术。
特别地，来自不同实现技术（如J2EE或.NET）的技术规范不应该影响SOA用户。
如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。
第二部分：
作为解决方案的面向服务体系结构
自从“软件危机”促进软件工程的开创以来，IT界一直在努力寻求解决上述问题的方案。
在过去几年里，下面简要概述的核心技术进展使我们走到了今天。
我们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决IT问题。
面向对象的分析和设计
在“ApplyingUMLandPatterns-AnIntroductiontoObject-OrientedAnalysisandDesign”中，Larman将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑解决方案”。
在“Object-OrientedSoftwareEngineering:
AUseCaseDrivenApproach”中，Jacobson等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。
在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。
通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。
为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。
基于组件的设计并不是一种新技术。
它是从对象范例中自然发展而来的。
在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。
在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。
这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。
通过这种方式，还可以将打包的解决方案套件封装成这样的“组件”。
一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。
可以将组件看作是打包、管理和公开服务的机制。
它们可以共同使用一组技术：
实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现
面向服务的设计
在“Component-BasedDevelopmentforEnterpriseSystems”中，Allen涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。
它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。
组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。
服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。
图3展示了重要的面向服务术语：
∙服务：
逻辑实体，由一个或多个已发布接口定义的契约。
∙服务提供者：
实现服务规范软件实体。
∙服务使用者（或请求者）：
调用服务提供者的软件实体。
传统上，它称为“客户端”。
服务使用者可以是终端用户应用程序或另一个服务。
∙服务定位器：
一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。
∙服务代理：
一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。
图3面向服务的术语
基于接口的设计
在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。
因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。
下面是一些与接口有关的重要定义：
∙接口：
定义一组公共方法签名，它按照逻辑分组但是没有提供实现。
接口定义服务的请求者和提供者之间的契约。
接口的任何实现都必须提供所有的方法。
∙已发布接口：
一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。
∙公共接口：
一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。
∙双接口：
通常是成对开发的接口，这样，一个接口就依赖于另一个接口；例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。
图4定义了客户关系管理（CRM）服务的UML定义，它表示为一个UML组件，实现接口AccountManagement、ContactManagement和SystemsManagement。
在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。
注意，SystemsManagement接口和ManagementService接口构成了双接口。
CRMservice可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。
甚至有可能给特定类型的客户端提供不同或附加的服务。
在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。
图4已实现的服务
分层应用程序体系结构
如前所述，面向对象的技术和语言是实现组件的极好方式。
虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。
一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。
进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。
图5演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。
为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。
图5应用程序实现层：
服务、组件、对象
第三部分：
近距离审视面向服务的体系结构
面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。
其组成元素可以分成功能元素和服务质量元素。
图6展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。
注意：
面向服务的体系结构堆栈可能是一个容易引起争议的问题，因为各方面的支持者已经提出了几种不同的堆栈。
我们的堆栈不是作为服务堆栈提出的。
我们之所以在此提出它，是因为我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对SOA的讨论。
图6面向服务的体系结构的元素
体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结构的服务质量方面。
这些元素详细描述如下：
功能性方面包括：
∙传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者。
∙服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。
∙服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。
∙服务描述实际可供使用的服务。
∙业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。
注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。
∙服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。
服务注册中心可以给需要集中式存储库的服务提供其他的功能。
服务质量方面包括：
∙策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。
策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能。
∙安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制。
∙传输是属性集，可以应用于一组服务，以提供一致的结果。
例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。
∙管理是属性集，可以应用于管理提供的服务或使用的服务。
SOA协作
图7展示了面向服务的体系结构中的协作。
这些协作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。
如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。
下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。
图7面向服务的体系结构中的协作
∙服务使用者：
服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。
它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。
服务使用者根据接口契约来执行服务。
∙服务提供者：
服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。
它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。
∙服务注册中心：
服务注册中心是服务发现的支持者。
它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。
面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种（或多种）。
面向服务的体系结构中的操作包括：
∙发布：
为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。
∙发现：
服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
∙绑定和调用：
在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。
面向服务的体系结构中的构件包括：
∙服务：
可以通过已发布接口使用服务，并且允许服务使用者调用服务。
∙服务描述：
服务描述指定服务使用者与服务提供者交互的方式。
它指定来自服务的请求和响应的格式。
服务描述可以指定一组前提条件、后置条件和/或服务质量（QoS）级别。
除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具有以下特征：
∙服务是自包含和模块化的。
∙服务支持互操作性。
∙服务是松散耦合的。
∙服务是位置透明的。
∙服务是由组件组成的组合模块。
这些特征也是满足电子商务按需操作环境的要求的主要特征，如“e-businessondemandandService-orientedarchitecture”所定义的。
最后，我们需要说明的是，面向服务的体系结构并不是一个新的概念。
如图8所示，面向服务的体系结构所涉及的技术至少包括CORBA、DCOM和J2EE。
面向服务的体系结构的早期采用者还曾成功地基于消息传递系统（如IBMWebSphereMQ）创建过他们自己的面向服务企业体系结构。
最近，SOA的活动舞台已经扩展到包括WorldWideWeb（WWW）和Web服务。
图8面向服务的体系结构的不同实现
SOA范围中的服务
升级会员 