面向服务的体系架构

多年以来,让企业/组织最为头疼的一个问题就是自己的系统没有较强的集成性,而且难以形成一个基于特定行业的去信任网络(trustless
network)。不过现在,区块链和分布式账本技术(DLT)可能成为实现这一颠覆性愿景的基础。企业级集成对于一些大公司和大型机构组织而言,他们的应用程序和
APP
大都是在“孤岛”中独立运行,这些“孤岛”往往需要共享数据和功能才能“步调一致”地运行。对于单个企业而言,如果想要实现数据和业务流程共享,就必须要与其他系统和应用程序进行对接,而这个过程就被称为“企业应用程序集成”(EAI:Enterprise
Application
Integration)。另一方面,在共享数据和功能的时候,企业/组织往往希望寻求一种能够控制方式来管理整个流程,也只有在这种情况下,他们才能放心地把关键业务流程集成(或自动化)扩展到组织外部。这其实是“企业应用程序集成”的一种扩展,可以通过一种被称为“B2B
集成”的消息标准交换结构化数据来实现。从根本上来说,“企业应用程序集成”和“B2B
集成”这两个专业术语都是指跨越多个系统(有时也涉及多方)的数据和功能集成过程。然而需要注意的是,企业内部系统和业务流程会不断发展,而支持
B2B
统一化的技术也在不断进步。企业/组织系统集成技术的进化到目前为止,我们似乎很少看到某一个企业/组织的系统集成技术成为主流,因为这种技术的发展通常是建立在彼此支持的基础之上,而现实世界里的商业竞争往往让企业/组织之间变得越来越封闭。在此,我们并不是要专注于某个特定技术、或是某个特定的年份,而是尝试观察最近几十年来的发展,以便让大家了解为什么说区块链会是下一个技术迭代的关键要素。下表是集成技术的进化历史概览:接下来,我们要探讨上表中列出的每个进化过程中是如何实现技术进步的。数据集成数据集成是最古老的跨系统信息访问机制之一,它具有以下两个主要示例:1、通用数据库方法被用于企业内部的系统集成;2、文件共享方法被用于企业内部和企业之间的数据交换。借助FTP等通用协议,文件共享让应用程序数据在不同设备和操作系统之间被交换。但是这两种方法都不是实时的,而且只能通过批处理的方式才能完成数据集成操作,因此在可扩展性和可靠性方面都存在一定的局限性。功能集成数据集成提供了非实时的数据交换,而这里将要描述的功能集成则提供了实时的数据交换和功能交换:1、远程过程调用(Remote
procedure
call)通过“隐藏”了网络和数据编组复杂性,将基于套接字的低级别集成进行了重大优化,但是它其实是一个依赖于语言的、早期点对点的客户端-服务器架构。2、对象请求代管者体系结构(Object
request broker
architecture)使用公用对象请求代管者体系结构(CORBA)、分布式组件对象模式(DCOM)、以及远程方法调用(RMI)实现,并引入了代管者组件,该组件允许不同语言的多个应用程序重复使用相同的基础结构并以P2P的方式相互通信。此外,公用对象请求代管者体系结构模型还具有命名、安全性、并发性、事务性、注册表、预计与语言无关的接口定义概念。3、消息传递在应用程序之间引入了时间解耦(temporal
decoupling)的概念,并确保异步消息传递。(耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。
解耦就是用数学方法将两种运动分离开来处理问题,常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动,只分析主要的运动。)到目前为止,我们已经看到了许多技术进步,但是他们主要关注的是系统集成而不是应用程序集成。从批处理到实时数据交换、从点对点到
P2P、从同步到异步,所有这些方法都不关心、或是不控制他们交换的数据类型,也不会强制验证数据。尽管如此,这种早期的集成基础设施通过交换基于电子数据交换(EDI)格式的数据来实现
B2B
集成,但是他们其实并不了解企业数据和业务流程,或者只了解了其中的一部分。使用公用对象请求代管者体系结构,我们可以更早地尝试应用程序接口、以及对应用程序集成有用的服务。面向服务架构面向服务架构(SOA)的主要目的,其实是推出一系列
Web 服务标准:1、XML 提供了与语言无关的数据交换格式;2、SOAP
提供了通用消息格式;3、WSDL
提供用于描述服务接口的独立格式。这一切都是构成Web服务的基础,这些标准与企业服务总线(ESB)和业务流程管理(BPM)相结合,使集成更专注于业务集成语言。相比之下,之前的技术更多地是在系统层面进行集成。ESB
全称为 Enterprise Service Bus,即企业服务总线。它是传统中间件技术与
XML、Web 服务等技术结合的产物。ESB
提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB
提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口;另一方面,BPM,即业务流程管理,是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法,常见商业管理教育如
EMBA、MBA 等均将 BPM 包含在内。Web
服务让系统不再盲目地交换数据,而是按照机器可读的合约和接口定义来交换数据,此类合约能够让某个系统和其他系统进行交互之前理解、并验证数据。这里还包含了微服务架构,就其核心而言,微服务架构构建、并改进了面向服务架构和企业服务总线——此阶段的主要进化,是围绕分布式系统从Web
服务向基于表述性状态传递的交互过渡。表述性状态传递(英文:Representational
State Transfer,简称REST)是 Roy Fielding 博士在 2000
年他的博士论文中提出来的一种软件架构风格,它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。目前在三种主流的
Web 服务实现方案中,因为 REST 模式的Web 服务与复杂的 SOAP 和 XML-RPC
对比来讲明显的更加简洁,越来越多的 Web 服务开始采用 REST
风格设计和实现。例如,Amazon.com 提供接近 REST 风格的 Web
服务进行图书查找;雅虎提供的 Web 服务也是 REST
风格的。总之,这个阶段中,在通用协议基础上,分布式系统也能获得通用标准和合约定义(contracts
definitions)。基于区块链的集成虽然利用通用协议和标准对交换数据有一定帮助,但服务合约却无法提供隐藏在合约背后、并在远程系统上运行的业务流程信息。一个业务请求可能在合约层面上有效,但在业务流程的某个状态下无效,这种情况会在两方之间进行集成的时候——比如在客户端-服务器模型、以及在
P2P
模型中多个参与方之间进行集成的时候产生很多问题。有时多个参与方也会是同一业务流程的一部分,有时业务流程也会被其中一方而非所有各方拥有。而这种能够让多方互动正常运作的先决条件,就是要确保共同业务流程及其当前状态的透明度。所有这一切,都让能够在多方之间实施分布式业务流程的区块链技术变得极具吸引力。通过共享业务流程和包含状态,基于区块链技术的集成模型扩展了共享协议和服务合约,而且所有参与实体都能以智能合约的形式共享同一业务流程。但是,为了验证业务请求、处理并得出相同的结论,业务流程也需要保持相同的状态,而这只有通过分布式账本才能实现。共享智能合约过去的全部状态并不是实现这一目标的手段,而是共享业务流程运行的先决条件。从这个角度来可,区块链可以被看作是系统集成进化的下一个阶段。正如我们接下来将会深入解释的那样,区块链网络可以充当一种分布式企业服务总线和业务流程管理机制,它不会包含在某个单独的业务实体之中,而是跨越覆盖到多个企业组织内。下图:集成技术开始从封闭系统进化到共享系统:首先是协议(比如
FTO),然后是应用程序接口合约(比如
WSDL、SOAP),接下来是业务流程本身(比如智能合约),最后数据会移出到封闭系统之外,进入公共共享空间,并成为集成基础设施的一部分。在某些方面,这种趋势类似于微服务的横切责任(cross-cutting
responsibilities)从服务内部转移到支持平台。通过区块链,通用数据模型和当前业务流程可以从企业内部转移到共享业务网络上。但需要注意的是,这种方法并非普遍使用,甚至不太可能成为一种主流系统集成机制。因为只有当网络中的所有参与方对数据模型和业务流程具有相同的理解时,才有可能采取这种行动。所以,基于区块链技术的系统集成只适用于那些有标准化业务流程的行业,比如金融、供应链、医疗保健等。系统集成迭代至此,我们已经按照时间顺序了解了集成技术的进化,现在可以更全面地了解B2B集成进化的各个主要阶段:第一代:系统集成协议这其实是在公用对象请求代管者体系结构(CORBA)和面向服务结构(SOA)之前的集成技术,主要利用通用协议进行数据交换,这种方式并不会理解数据、合约和业务流程:1、集成模式:客户端-服务器,其中服务器组件仅由一方控制,典型的示例有数据库、文件服务器、消息代理等;2、显式共享基础架构:低级系统协议、以及诸如FTP这样的应用程序接口;3、隐式非共享基础架构:应用程序合约、数据格式、以及不支持通用基础基础架构的业务流程。第二代:应用程序集成合约第一代系统集成技术使用的是几年前的系统协议,允许应用程序以通用合约的形式共享应用程序接口。而第二代系统集成技术已经能够让应用程序了解数据、以及数据结构和潜在错误条件了,不过这一代技术仍然无法了解系统中的业务流程和当前状态:1、集成模式:利用合约描述应用程序接口的客户端-服务器模型;2、显式共享基础架构:协议、应用程序合约和应用程序接口定义;3、隐式非共享基础架构:业务流程和远程状态仍是私有的。第三代:分布式业务流程第三代系统集成技术是基于区块链技术的一代,并且又向前迈进了一步,但该技术仍然需要证明是一个可行的企业级系统集成架构。区块链系统集成技术使用
P2P
协议,并且能够在多个系统之间共享业务流程,这些系统都是由去信任的各方控制的。之前的系统集成技术需要对共享协议和应用程序接口的理解,但这需要依赖对完整业务流程及其当前状态的共同理解,也只有这样才能形成有意义的跨组织分布式业务流程网络,并从中获得回报:1、集成模式:通过与分布式业务流程形成业务往来,实现多方
P2P
集成;2、显式共享基础架构:业务流程及其所需的状态;3、隐式非共享基础架构:其他非流程相关的状态。实际上,有许多基于区块链项目采用了不同的方法也解决业务集成难题,在此我们列举一些
B2B 集成领域里最受欢迎、也是最有趣的许可开源区块链项目:1、Hyperledger
Fabric 是目前最受欢迎、也是最先进的区块链框架之一,最初由 IBM
公司开发,现在已经是 Linux Foundation 项目的一部分了;2、Hyperledger
Sawtooth 最初是由英特尔公司开发的项目,现在也归入了 Linux Foundation
旗下分布式项目,它以可更换的模块化和完整组件而广受欢迎;3、Quorum
是一个基于以太坊区块链的企业级分布式系统解决方案;4、Corda
是另一个基于Java虚拟机中间件技术的技术,能够让企业利用合约交易、交换价值。现阶段,已经由很多企业/组织使用上述系统框架构建了业务网络,使网络中的成员组织能够利用这种新型集成模式互相集成和交互。当然,除了上述提供网络节点的全栈区块链项目之外,还有一些“混合”解决方案。举个例子,Unibright
项目旨在利用自动生成的智能合约,将熟悉的标准(比如
BPMN)中定义的内部业务流程与现有区块链网络连接起来。这种智能合约可以有公有链和私有链生成,并且成为企业之间另一个系统集成支柱。实际上,区块链技术已经开始尝试在我们现实生活中的很多领域里应用。一些公有链项目声称将利用这一新兴技术来改变世界,相比之下,私有链和许可区块链并没有做出太多这样的承诺,而是在稳步向前发展。总结企业级的集成往往具有很多细节上的问题,比如所有系统都是由一家实体所控制、参与者之间具有某种程度的信任等等。就目前而言,这些问题仍然由现代企业服务总线、业务流程管理和微服务架构来解决的。但是,当我们谈到多方参与的
B2B
集成时,和传统企业级集成所遇到的问题就不太一样了。这些系统基本上会由多个企业/组织控制,单独一方无法查看业务流程,互相也不信任——在这种场景下,我们看到企业/组织开始尝试一种全新的、基于区块链的集成技术,这种技术不仅依赖于协议与合约的共享,还依赖于端到端的业务流程和状态共享。需要说明的是,“区块链即集成”(Blockchain
as
Integration)这种趋势与区块链行业内多年来不断发展的总体方向是一致的,即从共享最低限度的协议,到以合约、应用程序接口和现有业务流程和状态的共享。这种共享集成基础架构能够支持全新的、透明集成模型——其中,先前那些不公开的业务流程现在将在开源协作模型下被共同拥有、共同拟定、共同构建、共同维护、形成标准化。也只有在这种情况下,才能够让企业/组织获得激励、共享业务流程并形成一个互利互益的网络,促进联合创新、标准化、以及更深层次的集成。

1 概述

ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。

面向服务的体系架构(Service Oriented Architecture,
SOA)就是在分布式的环境中,将各种功能都以服务的形式提供给最终用户或者其他服务。如今,企业级应用的开发都采用面向服务的体系架构来满足灵活多变,可重用性高的需求。

  ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

2 面向服务的体系架构 – SOA

一、ESB的五个基本功能:

  1)服务的MetaData管理:在总线范畴内对服务的注册命名及寻址管理功能。

  2)传输服务:
必须确保通过企业总线互连的业务流程间的消息的正确交付,传输还包括基于内容的路由功能。

  3)中介:提供位置透明性的服务路由和定位服务;多种消息传递形式;支持广泛使用的传输协议。

  4)多种服务集成方式: 如JCA,Web服务,Messaging ,Adaptor等.

  5)服务和事件管理支持:
如调用服务的记录、测量和监控数据;提供事件检测、触发和分布功能;

在经典软件工程理论中,不管是瀑布方法还是原型方法,都是从需求分析做起,一步一步构建起形形色色的软件系统。但是,需求变更像一个挥之不去的阴影,时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段,甚至上线阶段遭遇应接不暇的需求变更的极端痛苦。如何解决这一问题?能否来一场软件开发和架构的革命?SOA的提出,就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。

二、ESB的八个扩展功能:

  1)面向服务的元数据管理:
他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求,以及服务的提供者和他所提供的服务的描述;

  2) Mediation :它必须具有某种机制能够完成中介的作用,如协议转换;

  3)通信:服务发布、订阅,响应 请求,同步异步消息,路由和寻址等;

  4) 集成: 遗留系统适配器,服务编排和映射,协议转换,数据变换,企业应用集成中间件的连续等。

  5)服务交互:
服务接口定义,服务实现的置换,服务消息模型,服务目录和发现等。

  6)服务安全: 认证和授权、不可否认和机密性、安全标准的支持等;

  7)服务质量: 事务,服务的可交付性等;

  8)服务等级: 性能、可用性等。

  ESB 中最常提到的两个功能是消息转换和消息路由。

2.1 什么是SOA

三、ESB的出现改变了传统的软件架构

  ESB
是传统中间件技术与XML、Web服务等技术相互结合的产物,ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

2.1.1 定义

四、企业服务总线(ESB)的用处

  ESB 不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法.

SOA并不是一个新概念,有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在1996年,Gartner
Group就已经提出了SOA的预言,不过那个时候仅仅是一个”预言”,当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年,SOA的技术实现手段渐渐成熟了,在BEA、IBM等软件巨头的极力推动下,才得以慢慢风行起来。

五、企业服务总线(ESB)的应用特征

  大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构(SOA)是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来,只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务,那么其他应用系统就可以很方便的使用这些功能服务。

  支撑SOA的关键是其消息传递架构-企业服务总线(ESB)。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物,用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务协调运作,实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途:

  电信领域:ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。

  电力领域:ESB能够在全方位支持电力行业EMS的数据整合概念,是理想的SCADA系统数据交换平台。

  金融领域:ESB能够在全方位支持银企间业务处理平台的流程整合概念,是理想的B2B交易支撑平台。

  电子政务:ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。

关于SOA,目前尚未有一个统一的、业界广泛接受的定义。一般认为:SOA,面向服务的架构是一个组件模型,它将应用程序的不同功能单元—-服务(service),通过服务间定义良好的接口和契约(contract)联系起来。接口采用中立的方式定义,独立于具体实现服务的硬件平台、操作系统和编程语言,使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。

六、几种ESB的结构

  ESB提供了一种开放的、基于标准的消息机制,通过简单的标准适配器和接口,来完成粗粒度应用(服务)和其他组件之间的互操作,能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。

  通过使用ESB,可以在几乎不更改代码的情况下,以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口,并能够在部署环境中支持任何标准。更重要的是,充当“缓冲器”的ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑相分离,从而使得不同的应用程序可以同时使用同一服务,用不着在应用程序或者数据发生变化时,改动服务代码。

(转:百度百科**)

2.1.2 SOA中的特征

从SOA的定义中,我们看到两点:

  • 软件系统架构:
    SOA不是一种语言,也不是一种具体的技术,更不是一种产品,而是一种软件系统架构,它尝试给出在特定环境下推荐采用的一种架构,从这个角度上来说,它其实更像一种架构模式(Pattern),是一种理念架构,是人们面向应用服务的解决方案框架。
  • 服务(service)是整个SOA实现的核心。SOA架构的基本元素是服务,SOA
    指定一组实体(服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约),这些实体详细说明了如何提供和消费服务。遵循
    SOA
    观点的系统必须要有服务,这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。

基于上面讨论,我们给出SOA的下面一些特征:

  • 服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变,使得用户远离具体实施上的变更。
  • 服务的重用(reuse)。服务的可重用性设计显著地降低了成本。为了实现可重用性,服务只工作在特定处理过程的上下文(context)中,独立于底层实现和客户需求的变更。
  • 服务的互操作(interoperability)。互操作并不是一个新概念。在CORBA、DCOM、web
    service中就已经采用互操作技术了。在SOA中,通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。
  • 服务是自治的(Autonomous)功能实体。服务是由组件组成的组合模块,是自包含和模块化的。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术,如.NET
    Remoting,
    EJB,COM或者CORBA,都需要有一个宿主(Host或者Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候,在该宿主上运行的其它应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术,比如事务处理(Transaction),消息队列(Message
    Queue),冗余部署(Redundant
    Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。
  • 服务之间的松耦合度(Loosly
    Coupled)。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着,服务请求者不知道提供者实现的技术细节,比如程序设计语言、部署平台,等等。服务请求者往往通过消息调用操作,请求消息和响应,而不是通过使用
    API
    和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变,前提是消息模式保持不变。在一个极端的情况下,服务提供者可以将以前基于遗留代码(例如,COBOL)的实现完全用基于
    Java
    语言的新代码取代,同时又不对服务请求者造成任何影响。这种情况是真实的,只要新代码支持相同的通信协议。
  • 服务是位置透明的(location
    transparency)。服务是针对业务需求设计的。需要反应需求的变化,即所谓敏捷(agility)设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说,用户完全不必知道响应自己需求的服务的位置,甚至不必知道具体是哪个服务参与了响应。

2.2 SOA不等于web 服务

由于Web服务与SOA有着很多相同的技术特点,如:基于XML语言,符合SOAP、WSDL和UDDI标准等,很多人都认为下一代Web服务就是SOA。
Web服务可以用来实现SOA,但是如果没有Web服务,企业照样也可以很好地实现SOA。反之,即便是利用Web服务技术,也不一定能保证SOA的效果就更好。

Web服务与SOA关系如图1所示。

图片 1

Web服务是一套技术体系,可以用来建立应用解决方案,解决特定的消息通信和应用集成问题。随着时间的推移,我们发现,这些技术在不断发展、不断成熟,也会更好地帮助你实现SOA。SOA是一种软件架构,而不局限于某个技术的组合(例如Web服务),它超越了技术范畴。在一个商业环境中,纯粹的SOA是一种应用软件架构,其中所有的功能都是相互独立的服务模块,通过完备定义的接口相互联系起来。只要按照一定的顺序来请求这些功能模块所提供的服务,就可以形成完整的业务流程。正如IBM
SOA技术和策略总监Mark
Colan先生强调的那样:”Web服务的确是实现SOA一条最好的路,但不等同于SOA。”

SOA的灵活性将给企业带来巨大的好处。如果把企业的IT架构抽象出来,将其功能以粗粒度的服务形式表示出来,每种服务都清晰地表示其业务价值,那么,这些服务的顾客(可能在公司内部,也可能是公司的某个业务伙伴)就可以得到这些服务,而不必考虑其后台实现的具体技术。更进一步,如果顾客能够发现并绑定可用的服务,那么在这些服务背后的IT系统能够提供更大的灵活性。

但是,要得到这种灵活性,需要有一系列实现架构的新方法,这是一项艰巨的任务。企业架构设计师必须要变成”面向服务的架构设计师”,不仅要理解SOA,还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙,也非常关键。那么目前SOA的实现技术究竟有哪些呢?

3 SOA的实现技术

3.1 实现SOA的核心技术 – web 服务

正如我们前面所讲的,服务是整个SOA实现的核心,web服务相关技术自然成为实现SOA的首选。

  • XML
    XML 1.0 (可扩展标记语言,Extensible Markup Language)
    标准是一个基于文本的 World Wide Web 组织 (W3C) 规范的标记语言。与
    HTML 使用标签来描述外观和数据不同,XML
    严格地定义了可移植的结构化数据。它可以作为定义数据描述语言的语言,如标记语法或词汇、交换格式和通信协议。
  • SOAP
    简单对象访问协议 (Simple Object Access Protocol)
    是一个基于XML的,用于在分布式环境下交换信息的轻量级协议。SOAP
    在请求者和提供者对象之间定义了一个通信协议,这样,在面向对象编程流行的环境中,该请求对象可以在提供的对象上执行远程方法调用。因为SOAP是平台无关和厂商无关的标准,因此尽管SOA并不必须使用SOAP,但在带有单独
    IT基础架构的合作伙伴之间的松耦合互操作中,SOAP仍然是支持服务调用的最好方法。
    W3C SOAP
    1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。将应用程序请求(在XML中)放入
    SOAP 信封中(也是 XML
    ),并从请求者到提供者发送应用程序请求,提供者发回的响应也采用相同的形式。最近
    SOAP 被称为面向服务的架构协议 (Services-Oriented Architecture
    Protocol)。
    SOAP的优点在于它完全和厂商无关,相对于平台、操作系统、目标模型和编程语言可以独立实现。另外,传输和语言绑定以及数据编码的参数选择都是由实现决定的。
  • WSDL
    Web服务描述语言 WSDL (Web Services Description Language)
    是一个提供描述服务IDL标准方法的XML词汇。Web
    服务描述语言(WSDL)规范定义了一个
    XML词汇表,该词汇表依照请求和响应消息,在服务请求者和服务提供者之间定义了一种契约。我们能够将Web服务定义为软件,这个软件通过描述SOAP消息接口的
    WSDL文档来提供可重用的应用程序功能,并使用标准的传输协议来进行传递。
    WSDL描述包含必要的细节,以便服务请求者能够使用特定服务:

    • 请求消息格式
    • 响应消息格式
    • 向何处发送消息。

    WSDL 是基于 XML 的,因此 WSDL
    文档是计算机可读的(machine-readable)。这样开发环境使用WSDL将集成服务的流程自动处理到请求者应用程序。例如
    WebSphere
    Studio产生一个Java的代理对象,它能够像本地对象一样实现服务,但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用Java、C#或者其他的语言实现,生成的Java代理对象都能够从WSDL描述中调用任何的Web服务。实际上,WSDL不能像编程语言那样描述实现细节。

  • UDDI
    统一描述、发现和集成 (Universal Description, Discovery and
    Integration) 规范提供了一组公用的 SOAP
    API,使得服务代理得以实现。UDDI为发布服务的可用性和发现所需服务定义了一个标准接口(基于
    SOAP 消息)。UDDI 实现将发布和发现服务的 SOAP
    请求解释为用于基本数据存储的数据管理功能调用。
    为了发布和发现其他SOA服务,UDDI 通过定义标准的 SOAP
    消息来实现服务注册(Service Registry)。注册是一种服务代理,它是在
    UDDI
    上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务,开发者通常借助于开发工具(如Microsoft
    Visual Studio
    .NET)并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。
    SOA不需要使用UDDI,但由于 UDDI
    是建立在SOA上来完成自身工作的,所以UDDI是服务发现的一个好的解决方案。

3.2 SOA 基础架构的关键组件
-企业服务总线(Enterprise Service Bus,ESB)

  • 企业服务总线ESB(Enterprise Service Bus)是SOA架构的一个支柱技术。
    作为一种消息代理架构它提供消息队列系统,使用诸如SOAP或JMS (Java
    Message Service)等标准技术来实现。
    有人把ESB描述成一种开放的、基于标准的消息机制,通过简单的标准适配器和接口,来完成粗粒度应用(比如服务)和其他组件之间的互操作。

    ESB的主要功能有:通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。ESB由中间件技术实现并作为支持
    SOA
    的一组基础架构,支持异构环境中的服务、消息,以及基于事件的交互,并且具有适当的服务级别和可管理性。

    SOA的原则可以描述如下:

    • 利用显式的与实现无关的接口来定义服务。
    • 利用强调位置透明性和可互操作性的通信协议。
    • 封装可重用业务功能的服务的定义。

    为了实现 SOA,应用程序和基础架构都必须支持 SOA 原则。启用 SOA
    应用程序涉及到创建服务接口,服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看,启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而,基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据
    SOA
    原则指定服务接口,而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是
    ESB 的许多功能中的一部分。

    ESB
    支持这些服务交互功能,并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此,它将当今正在使用的主要企业集成模式组合成一个实体。ESB
    为 SOA
    提供与企业需要保持一致的基础架构,从而提供合适的服务级别和可管理性、以及异构环境中的操作。图2显示了ESB为SOA提供的基础架构:

图片 2

ESB 需要某种形式的服务路由目录(service routing
directory)来路由服务请求。然而,SOA
可能还有单独的业务服务目录(business service
directory),其最基本的形式可能是设计时服务目录,用于在组织的整个开发活动中实现服务的重用。Web
服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI
目录,因而使得可以动态发现和调用服务。这样的目录可以视为 ESB
的一部分;然而,在这样的解决方案变得普遍之前,业务服务目录可能与 ESB
是分离的。

Business Service Choreographer
的作用是通过若干业务服务来组合业务流程;因此,它将通过 ESB
调用服务,然后再次通过 ESB
将业务流程公开为客户端可用的其他服务。然而,Business Service
Choreographer
在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术
ESB 分离的技术。

最后,B2B Gateway
组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到
ESB 的组件,但它们并不是 ESB
的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB
的功能,但是 B2B Gateway 组件的用途是将其与 ESB
分离。事实上,这种用途可能需要附加的功能(如合作伙伴关系管理),这些功能不是
ESB 的一部分,并且不一定受到 ESB 技术的支持。

3.3 实现SOA的方法学 – 模型驱动的开发

SOA强调松散耦合,强调跨平台集成,这与模型驱动的架构和开发不谋而合。模型驱动的架构和开发(Model
Driven Architecture, MDA以及Model Driven Development,
MDD)并没有把业务模型和平台无关模型分开来,而是把平台无关模型做为起点。

MDA由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use
cases,根据系统搭建的平台,架构设计师可以由这个平台无关的模型得到平台相关的模型,这些平台相关模型足够详细,以至于可以用来直接生成需要的代码。

基于MDA的思想,利用MDD方式,我们可以对SOA进行建模,在此基础上,实现各种形式的模型转换或扩展实现SOA.

参考资料

  • IBM developerWorks Software Evaluation Kit: Developing SOA
    applications

  • The developerWorks SOA and Web services
    zone

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

CopyRight © 2015-2020 普京集团娱乐网 All Rights Reserved.
网站地图xml地图