ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SOA 核心技术及应用,第 1 章

SOA 核心技术及应用,第 1 章

原创 Linux操作系统 作者:isoa 时间:2009-05-07 14:41:51 0 删除 编辑

1.1 公司 IT 部门面临的困境

SOA 来了,可是其究竟为 IT 世界带来了什么,或者说,解决了企业的什么问题?让我们先看一下当前企业 IT 构架所面临的困境。

从企业的 IT 战略角度而言,经过多年的发展,各个企业都已经在不同业务支撑领域架构了一系列的 IT 系统,甚至是一个完整的企业架构(Enterprise Architecture),或者是已经完成了部门级的垂直整合。可是,在日新月异的商业环境下,产品的生命周期变得越来越短,客户的需求也在随时变化,新的业务模式持续地酝酿生成。

新的业务模式需要新的业务流程来支撑,要求更有效率的合作,这不仅仅发生在同一个垂直的部门内部,对跨部门的业务合作和整合的需求被也提到议事日程上。有效的部门间合作,或者企业间的合作,能够满足客户需求并响应外界变化的灵活业务流程,是现代企业竞争力的根本。这不仅仅是一个企业管理和文化能解决的问题,也对企业的 IT 系统提出了进一步的需求。这些需求为企业 IT 架构和策略带来巨大的压力——如何能达到真正的随需应变?如何提高 IT 系统的投资回报(Return On Investment,ROI)?如何重用已有的技术和业务资源以满足新的需求?

另外一个不容忽视的商业趋势是:随着行业发展越来越专精,越来越多的专业服务被提供出来。比如说,自古以来饭店总是要雇佣一些洗碗工清洁堆积如山的碗筷。可是现在出现了一种专业服务,回收用过的碗筷,清洗、消毒,然后包装好派送回各个饭店。于是,饭店便无需雇佣专门的洗碗工,也无需使用一次性筷子,还可以向消费者收取碗筷清洁消毒的费用——相当于原来的一次性筷子的费用,所以消费者也不会抱怨。这是一个标准的三赢场景:

饭店省去了雇佣洗碗工的成本;

消费者避免使用浪费资源并可能有卫生问题的一次性筷子;

洗碗服务的提供者获得了利润。

其中的理念是,饭馆要正常经营,清洁碗具是每个餐馆不得不做的事。但大家都知道,洗碗并不是餐馆最擅长的事,餐馆最擅长的事是烹制美食,而专业的洗碗店最擅长洗碗。为什么不只做自己最擅长的事,把自己不太擅长的事外包给最擅长做这些事的公司,强强联手,给消费者提供更好的服务呢?

反观 IT 业界,同样的场景也会发生。企业可以使用第三方提供的更好服务来支持自身业务流程实现的需要,而不用事必躬亲,这样可以大大节省 IT 开发和维护的成本。在图 1-1 中就是这样一个典型场景,其中企业内部资源包括部门(Division)资源和共享服务(Shared Service)资源两部分。在客户(Customer)使用这一业务流程时,企业业务流程不仅仅是使用自己的既有服务,还整合了供应商(Supplier)的服务,进而供应商又整合了一些外包商(Outsourced)的服务。在这样一个场景中,供应商和外包商提供了流程中的一些专业服务使得业务流程更加敏捷有效,犹如上面例子中的洗碗店一样。实际上,这就是 Web 服务技术产生的一个业务背景。在这样一个商业趋势下,如何整合企业外部资源变成了一个很重要的并亟待解决的问题。


图 1-1 服务整合

从另一个方面,从技术趋势和 IT 架构角度而言,从传统的 C/S(客户端 / 服务器,Client/Server)架构,到 90 年代兴起的 B/S(浏览器 / 服务器,Browser/Server)架构,到现在大家关注的基于服务的架构,IT 技术经过了不同的时代,在不断更新进步。可以说,电子制造业的摩尔定律同样适用于软件行业。相应地,具体的编程技术也在进化和演变,从机器语言到汇编,到以 C 为代表的面向过程编程,到以 C++/Java 为代表的面向对象编程,进而到 J2EE 的模块化分布式企业级编程,可以发现编程的粒度逐渐变大。计算机的计算能力越来越强,计算时间的成本不断降低,程序员时间的成本不断提高。总而言之,随着软件程序的规模越来越大,底层架构和技术能够处理的功能愈发广泛,层次性的封装越发普遍,使得程序员可以更加贴近业务逻辑进行开发;大大节约了程序员的宝贵时间;这是一个趋势。

业务模式的变迁和技术趋势的发展,使得企业的 IT 部门需要认真思考,选择一个符合公司规划发展的 IT 战略,保护现有投资,低风险、高回报,并落实到一个能够和业务真正对齐的技术策略和模型。这也是需要探讨和解答的问题。


.2 决策者的决策——部署 SOA

1.2.1 什么是 SOA

上节中提到了对 IT 战略架构的各种需求,其核心是业务快速变化和随需应变。那么,怎么做才能满足这些需求?如何才能真正解决这些问题?我们的答案是实施 SOA(面向服务的架构,Service Oriented Architecture)。

什么是 SOA?“Service Oriented Architecture,”顾名思义,面向服务的架构,或者说,以服务为基础搭建的企业 IT 架构。SOA 是一个完整的软件系统建构体系,包括运行环境、编程模型、架构风格和相关的方法论等。其核心是服务,并涵盖服务的整个生命周期,建模 - 开发 - 装配 - 运行 - 管理。SOA 的核心理念是业务驱动,采用松耦合的、灵活的体系架构来满足随需应变的业务需求。

服务是 SOA 的核心词。从技术概念而言,服务与模块或者功能的概念类似,是用于封装特定功能的一个实体。但是,值得注意的是,服务的核心理念是业务,服务定义了一个与业务功能或者业务数据相关的接口,以及约束这个接口的契约,是粗粒度的。服务是中立的,不依赖于特定的技术和平台。服务的注册、获取可以通过服务注册库管理。多个服务可以被组装成一个业务流程,完成一个特定的业务功能。由此可见,服务是可重用的,一个定义良好的服务可以被用于组装多个业务流程。这也是 SOA 和服务被比喻成乐高积木的原因。进而言之,如果系统架构师和业务人员联手,是可以用这些“乐高积木”(服务)搭建出一艘航空母舰——已组装好的服务是可以被发布为一个新的服务,这就是服务嵌套封装的特性。

下图表明了 SOA 的概念架构模型。可见 SOA 架构是一个分层的结构,从最底层的功能性服务,到原子服务和服务构件,到顶层的业务流程服务,目的是最大限度地封装不同的服务,从而达到复用的目的。无论哪一个层次,其核心都是服务——简单的和复杂的。一个复杂的服务组件是由不同的原子服务组成,用于提供业务流程所需的功能。


图 1-2 SOA 的概念架构模式

另一个不得不提的 SOA 概念是企业服务总线(Enterprise Service Bus, ESB)。将服务组装成业务流程是目标,但是应该如何实现?点到点的连接是一个方式,可是这种方式增加了系统的复杂度,并降低了服务的可重用性。为了实现真正的 SOA,我们需要一个中间层,来完成服务交互、组装、管理的功能。这就是 ESB 产生的缘由。ESB 采用的是总线的概念,支持服务的即插即用,以消息流转为沟通方式,以标准为基础,可以跨平台、跨技术(如图 1-3 所示)。形象地来讲,ESB 像一条流动的河流,承载着不同的船只(数据)到达相应的码头。


图 1-3 SOA 计算环境的组成部分

这样一个以服务为核心的体系架构可以提供松耦合、异构的企业级计算环境。这是企业 IT 架构的设计思想的一个革新——以业务为导向的设计,而并非传统的技术架构导向。这一 SOA 架构直接的好处是:企业级整合变得更加得心应手,无论是在一个垂直系统内部,还是跨部门的整合,甚至是跨企业的行业整合。进而,可以重用定义好的服务,无论是包装已有系统功能,还是新开发的业务功能,甚至是采用合作伙伴所提供的服务。这是一件很好的事情,不仅节约了企业内部的投资,还可以创收——向外部的客户和合作伙伴提供服务!理念的变革是,由自给自足变为开放,成为服务的提供者和集成者。

不仅如此,SOA 和服务的理念使企业的成长不再受到 IT 架构的制约——业务流程可标准化、可集成。

众所周知,中华餐饮的历史源远流长,美食无数。可是中式快餐很难形成如肯德基或麦当劳那样的大型连锁店,为什么呢?先看一下中餐的烹饪过程:选材备料,主厨掌勺。可是,每一个大师傅烹饪的过程都有所不同,火候、配料是关键,所以菜品的口味也不一样。即使同一道菜,同一品牌,不同的分店,味道也会有所不同。反观西式快餐,材料统一配送,烹饪工具统一,流程规范,做出来的东西自然一样。当有菜品有更新时,只要把原料配送好,操作流程培训好,就可以在全国甚至是全世界的分店里同时推出这道菜品,迅捷有效。

现今,我们的软件行业同中餐类似,关键看主厨的功力,架构师是否能设计出优雅的架构,程序员能否写出健壮的程序,是一个应用成功的关键。可是这又是多么的可遇而不可求。由此可见,建构一个灵活的可扩展的大型解决方案,降低维护成本,标准化是成功之道,服务化则是必由之路。

1.2.2 SOA 实施的主要困难

前面描绘了一幅美丽的图画:一切皆服务,服务可组合。可是,有人会问,事情真的有那么美好吗?这条路到底行不行得通,好不好走?

大家可以回想一下,在 SOA 的概念被旗帜鲜明地提出后,花了几年时间讨论到底什么是 SOA,什么是一个好的 SOA 架构,并试图找出一个可行的技术路线。如今大家的关注点是 SOA 如何着陆,如何真正部署一个 SOA 架构。在先行者的实践中,大家看到了一些设计和实施的关键点和困难点,其中包括:

SOA 不仅仅是 IT 技术思想,也是企业管理思想的革新:一切以业务流程为基础,而不是部门职能。SOA 需要全局性的思考,垂直部门不再是一个封闭的组织,企业也不再封闭,需要采用服务的方式进行开放整合。这一观念需要在企业管理层达成共识,否则可能成为 SOA 成功实施的阻碍。

如何梳理出业务流程,并进行相应的服务划分?这是一个成功的 SOA 实施的关键,需要纵观企业业务的全局思考和分析,并且需要业务和技术人员的共同参与。

对大多数企业而言,SOA 可能并非一场革命,而是一种转变,现有的系统也要参与其中,使现有资产合理重用是一个重要的考虑。

技术架构的选择。会在下面详细地阐述。

可见,SOA 并非一蹴可就的,需要全局的思考和准备。但是 SOA 的实施是可以渐进式的,既有系统可以逐步改造,新的服务可以按需添加,这也是以服务为基础的架构的优点。从小处入手,从长远考虑,这些投资的回报是十分客观的。


图 1-4 IT 与业务并行发展
 

1.3 SOA 的技术抉择

在前面的章节里,已经讲解了什么是 SOA 和为什么要部署 SOA(当然,本书的论述是比较提纲挈领,读者可以在《SOA 原理穃 u26041? 法穃 u23454? 践》中得到更为详尽的论述)。在本书中试图讲解的是如何部署和实施 SOA,以及实施 SOA 所需要的技术。

1.3.1 相关技术概览

在深入理解了 SOA 的理念和架构基础上,可以看到 SOA 的技术必然建立在标准之上——只有做到了“书同文,车同轨”,才能够进行真正意义上的业务整合。在此基础上,有服务运行环境、企业服务总线(ESB)、服务注册和管理工具、流程引擎等 SOA 计算环境所需要的主要组件。同时,还会有业务活动监控(Business Activity Monitoring,BAM)和业务绩效管理(Business Performance Management,BPM)等方面。

SOA 的设计理念在于将企业的 IT 架构建立在一系列执行业务功能的服务基础上,IT 资产通过服务的形式得到重用。业务模式和流程也可以通过服务的重新组合变得更加灵活。可见,要搭建一个灵活多变的架构,其中的几个关键的技术抉择在于:

服务

搭建大厦的砖石,建造航空母舰的“乐高积木”,需要谨慎的选择。服务需要是标准化的,是可以自描述的,是可以组装的,并能够隔离业务功能和具体实现。

数据 / 消息模型

大厦电路中的电流和水管中流动的水流,有了这些资源,一个现代化的大厦才能够真正“活”起来。数据就是客户的“钱”,是服务的目的——准确、迅捷地传送数据。因此,一个好的数据模型可以事半功倍。

服务编排和流程引擎

大厦的设计图纸,用来将已有的服务组装起来定义真正的业务流程。敏捷是对服务编排的一个重要要求。服务编排同时要提供相应的事务管理、流程状态管理、出错处理等支持功能。

以上的三个方面被称为 SOA 编程模式的“铁三角”。


图 1-5 SOA 编程模式的铁三角

1.3.2 服务

作为构建 SOA 的一个基础组件,服务具有下面一些特征:

服务是可以独立操作的。每一个服务都能够提供相应的操作,能够很容易地被独立调用,其执行并不依赖于架构中的其他组件和服务。操作是通过标准方式封装和发布的。

服务是自描述的。其使用标准的描述格式定义了服务提供的操作和消息格式,无论调用者和被调用者都无需关心其他信息,如地址、实现技术等。

服务是松耦合和异构的。服务的使用者和提供者可以是分布部署的,可以位于不同的系统平台上,可以使用不同的技术实现。

服务是可组合的。使用相应的服务组装技术,例如流程编排技术,可以将多个简单的服务组装成一个更加复杂的服务。这一过程是可递归的。这一特性极大地提高了服务的灵活度和计算能力。

服务是动态的。已发布的服务是可以被动态发现和绑定。

服务是标准和开放的。只有在标准的基础上,企业中不同部门或者不同供应商的服务才能够动态地组织到一起提供业务流程。供应商的独立性和互通性是服务的目标。这样才能真正实现理想的“天下大同”。

服务可以包装已有的应用或组件。这一特性使得服务的领域变得更加广泛,并且可以使现有资产可被重用,保护已有 IT 投资。

服务是有质量保障(QoS)的。

一个描述服务的概念模型是:


图 1-6 服务的概念模型

可见,服务是可以自描述并独立注册发布的。在一个服务请求者需要使用某个特定业务功能的服务时,可以先在服务管理者,即服务注册中心中发现符合要求的服务——可能得到一个服务列表,因为不同的供应商会提供同一服务(这也是一种竞争)。服务请求者可以根据需要决定使用哪一个服务,也就是服务绑定,然后就理所应当地使用选定的服务了。

读到这里,读者必然会想到 Web 服务(Web Services)。Web 服务是一个既有的成熟服务技术标准,甚至很多人在提到 SOA 时就会将其自然等同于 Web 服务及其相应的架构。的确,从历史而言,SOA 设计理念的确是在 Web 服务技术产生和发展之后才逐渐形成的,也确实借鉴了 Web 服务技术的概念和开发模式,但是 SOA 的范畴要更加宽泛,解决更加深入的问题,并非仅仅是技术领域(见上文)。由此可见,Web 服务理所当然是 SOA 服务实现技术的一个选择,但并非是唯一的选择。

当前,在业界逐渐得到广泛认可的一个服务封装技术是服务组件架构(Service Component Architecture,SCA)。SCA 是一个跟实现语言无关的服务组件编程模型,可以很好地处理服务网络的建构,因此提供了基于 SOA 简化开发的解决方案。SCA 规范的开发和发布由 Open SOA(Open Service Oriented Architecture,http://www.osoa.org)组织负责。OSOA 组织在世界范围内有广泛的支持者,其中不乏 IBM、BEA、Oracle、SAP、Siebel、Sybase 和 Xcalia 等著名厂商。

最初的 SCA 规范在 2004 由 IBM 和 BEA 共同发布。在 2007 年,SCA 规范终于结束了其孵化期,由 18 家处于 SOA 技术领先地位的厂商正式提交给 OASIS(Organization for the Advancement of Structured Information Standards)组织进入标准化过程,将和其姊妹规范 SDO 一同架构 SOA 的标准编程模型。

SCA 的主要特点如下:

SCA 是用于建构服务的,是松耦合的。

SCA 是一个跟实现语言无关的组件编程模型。SCA 提供了统一的调用方式,可以把不同的服务类型,比如 POJO、EJB、BPEL、JMS、Web 服务等都通过统一的接口来封装调用。这使得整合已有的异构系统成为可能。

SCA 还支持不同的通讯协议,如 Webservices、JMS、Rest、JSON/RPC 等。

SCA 隔离了业务逻辑和具体技术实现。这使得开发者能更集中于业务逻辑而非技术细节,也极大地提高了业务逻辑的灵活度——可以采用不同的服务实现而无需改变业务逻辑。

SCA 提供了许多面向企业计算的 QoS 能力。


图 1-7 SCA 结构和组装

SCA 的这些特性使得企业应用具有良好的分层架构,能够很好地分离业务逻辑和技术逻辑,使应用易于构建、易于部署、易于变更。这些特性,恰恰是 SOA 中服务所需要的。

鉴于读者对 Web 服务的概念和技术已经耳熟能详,本书中就不再针对这一技术进行论述,而试图为读者提供另外一种服务实现的技术选择:SCA。在本书下面的第二部分(第 2 章—第 7 章),会详尽地介绍 SCA 的起源,技术思想,具体规范,以及实际用例。

1.3.3 数据和消息模型

在 SOA 的世界里,消息意味着企业的效益,因为其包含的业务数据代表实际发生的交易,数据的丢失等同于是现金的流失。从这个角度而言,一个完备的、丰富的消息数据模型是必需的。

同 SOA 服务建构技术相辅相成,不同的服务有不同的消息定义方式。比如说,Web 服务采用 SOAP 消息作为其数据表现。相应地,和 SCA 伴生的技术是服务数据对象(Service Data Object,SDO)。SDO 以对象为中心的,层次树型数据模型,是一种最贴近业务表现的方式。

SDO 基于离线数据图的设计理念如图 1-8 所示。数据图是一组树型结构或者图型结构的数据对象。离线的访问方式是指客户端从数据源提取并构建数据图,然后在应用中操作数据图,并在变更摘要(Change Summary)中记录相应的数据操作,在动作结束后由数据访问服务(Data Access Service)批量地将相应的改变反映回数据源,其中数据源可以是异构的,并不仅仅限于关系数据库。


图 1-8 SDO 基本结构

SDO 的数据表现形式基于数据对象(Data Object)和数据图(Data Graph)的概念,其封装形式和 Java 类和 XML 有水到渠成的映射关系。同时,SDO 提供了丰富的数据操作接口——动态接口和静态接口,还可以用 XPath 来直接访问相应的数据对象属性。

SDO 所解决的另外一个问题是异构数据的兼容性,提出了一个简单并统一的模式供服务处理其相关的数据。开发人员可以用 SDO 统一其数据访问和处理模式,即使这些数据来源于异构数据源——关系数据库、XML 数据、Web 服务或者是企业信息系统。

SDO 是 SCA 的姊妹标准,同样由 Open SOA(Open Service Oriented Architecture,www.osoa.org)组织负责。SDO 规范 2.0 版本于 2006 年底发布,现已提交 OASIS 标准化组织。在本书的第三部分(第 8 章—第 13 章)中,会针对这一技术进行详尽的介绍,包括技术起源和思想,具体规范和详尽实例。

1.3.4 服务编排和流程整合

SOA 编程模型的第三个方面是服务编排。诚然,SCA 规范中已经包含了服务组件和组装的概念,但是其并非一个严格意义上的服务编排。在考虑业务流程的编排时,希望流程是可视化的、可定制的、灵活的,并且是可管理的。服务犹如一个个音符,而精心编排的乐谱将其串成优美乐曲。

远在 SOA 概念提出之前,就已经有 Web 服务技术,与之关联的服务编排技术是 Business Process Execution Language for Web Services(BPEL4WS)。2002 年 7 月,IBM、微软、BEA 联手提交了这一规范,奠定了以 Web 服务和 XML 为基础的业务流程规范。此后,BPEL 规范被提交给 OASIS 组织,并更名为 WS-BPEL(在下文中简称为 BPEL)。如今,BPEL 已经得到业界的广泛认可。

一个服务编排模型需要满足 SOA 松耦合和异构的要求,并且需要是敏捷的。反观 BPEL,具有下面的一些特点:

基于服务。BPEL 在对多个服务进行调度与协调,本身只定义业务流程相关的逻辑,而具体的功能则由其所调用的服务来实现,与 BPEL 无关。BPEL 从规范的定义上就自然而然地支持 Web 服务,但并不仅仅限于 Web 服务,也可以支持 SCA 所定义的服务。

嵌套性。相应地,由服务编排而成的 BPEL 业务流程可以被封装为一个新的服务,提供更加复杂的业务功能(回顾图 1-2 中的业务流程服务)。这一点充分体现了服务的可嵌套性。

松耦合性。BPEL 定义本身只需指定相应的接口即可,不需要指定实现该接口的服务。BPEL 致力于业务逻辑的表现,而相应的实现服务完全可以在部署甚至运行时确定。同时,流程与所调用的服务之间以异步的 XML 文档形式传递消息,不直接与服务的实现打交道。因此 BPEL 流程和所调用的服务之间是松耦合的,他们可以独立地进行替换或修改,而不对另一方产生影响。

服务质量、交易和生命周期的管理。BPEL 并不仅仅是简单的服务装配,还支持长时间的流程定义,以及有状态的交互,并且提供了相应的失败处理和补偿机制。不仅如此,还有相应的服务质量(QoS,Quality of Service)和事务处理机制等。

高度的敏捷性。正是由于 BPEL 具有高度的松耦合性和可重用性,才具有敏捷性的特点。


图 1-9 SOA 的标准协议栈

在 SOA 计算环境的协议栈中,业务流程位于协议的顶端,BPEL 是它的具体表现形式。

BPEL 是服务编排的核心技术,也是具体业务流程的表现。在本书的第三部分(第 14 章—第 17 章)中,会对这一技术进行详尽的介绍。



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780828/viewspace-594431/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-07

  • 博文量
    251
  • 访问量
    294979