（管理科学与工程专业论文）基于SOA的集成架构研究及在浙江移动CRM的应用.pdf

基于s o a 的集成架构研究及在浙江移动c r m 的应用 摘要 经过几十年的企业信息化建设，企业内己存在许多分散孤立的应用系 统，随着业务规模不断扩大，集成已经成为当今企业的迫切需求。本文首 先分析了传统企业集成方法和实现技术的不足，如复杂、成本高、而难于 维护的点对点集成和与特定厂商紧密藕合的e a i 中问件集成方法。传统分布 式通讯技术如c o r b a ，d c o m 和r m i 可以实现集成，但由于它们都存在着缺点， 都不能完全实现灵活变化的业务需求。 随着基于h t t p 的s o a p 、w s d l 、u d d i 产生，w e b s e r v i c e 作为一个基于互 联网通用技术基础上发展的数据通讯协议和数据传输访问协议体系产生 了。但是w e b s e r v i c e 只是定义了基于通用互联网技术的数据通讯和数据传 输访问，但是基于上面的应用呢，目前并没有一个规范。 面向服务架构( s e r v i c eo r i e n t e da r c h i t e c t u r e ，s o a ) 已经被i t 业界 越来越广泛地接受，s o a 的理念和架构也逐渐渗透到企业架构中去，在许多 具体的项目中也有所体现。进而，对s o a 实施的讨论正逐渐成为关注的焦点。 在近几年的实践和探索中，业界达成的共识是s o a 必然建立在标准的基础 上。本文试图从服务构建、数据模型，和服务编排以及e s b 来构建系统集成 架构。详细介绍了s o a 的技术标准服务组件架构( s e r v i c ec o m p o n e n t a r c h i t e c t u r e ，s c a ) 、服务数据对象( s e r v i c ed a t ao b j e c t ，s d o ) 和业 务流程执行语言b p e l ，以及企业服务总线e s b 。最后本文利用浙江移动的c r m 项目案例具体阐述了s o a 的开发应用。 关键词：s o a ；b p e l ；s c a ；s d o ；服务组合 r e s e r c ho ns o a - - b a s e di n t e g r a t i o nf r a m e w o r kw i t ha p p l yi n z h e j i a n gm o b i l e 。sc r ms y s t e m a b s t r a c t a f t e rd e c a d e so fe n t e r p r i s ei n f o r m a t i z a t i o n ，t h ee n t e r p r i s eh a sb e e ni n e x i s t e n c ef o rm a n ys c a t t e r e di s o l a t e da p p l i c a t i o n s ，w i t ht h ee x p a n d i n gs c a l eo f o p e r a t i o n s ，b u s i n e s si n t e g r a t i o nh a sb e c o m ea nu r g e n td e m a n d t r a d i t i o n a l d i s t r i b u t e oc o m m u n i c a t i o nt e c h n o l o g ys u c ha sc o r b a ，d c o ma n dr m ic a n a c h i e v es o a ，b u t t h e yh a v el o to f d r a w b a c k w e bs e r v i c e sc a na l s ob eu s e dt oi m p l e m e n ts y s t e mi n t e g r a t i o n b u ti th a s i t sd r a w b a c kt o o c r i t i c so fn o n - r e s t f u lw e bs e r v i c e so f t e nc o m p l a i nt h a t t h e ya r et o oc o m p l e xa n db a s e du p o nl a r g es o f t w a r ev e n d o r so ri n t e g r a t o r s ， r a t h e rt h a no p e ns o u r c ei m p l e m e n t a t i o n s i nr e c e n ty e a r st h ep r a c t i c ea n de x p l o r a t i o n ，t h e i n d u s t r yc o n s e n s u s r e a c h e dt h a ts o ai si n e v i t a b l ei nt h ee s t a b l i s h m e n to fs t a n d a r d s t h i sa r t i c l e a t t e m p t st ob u i l d b u i l daf r a m e w o r kf o rs y s t e mi n t e g r a t i o nu s i n gs e r v i c e c o m p o n e n ta r c h i t e c t u r e ( s c a ) ，s e r v i c ed a t ao b j e c t s ( s d o ) a n db u s i n e s s p r o c e s se x e c u t i o nl a n g u a g e ( b p e l ) ，a sw e l la st h ee n t e r p r i s es e r v i c eb u s ( e s b ) f i n a l l y ，t h ea p p l i c a t i o no fz h e j i a n gm o b i l e sc r mp r o j e c ts p e c i f i cc a s e o ft h ed e v e l o p m e n ta n da p p l i c a t i o no fs o a k e y w o r d s ：s o a ：b p e l ；s c a ；s d o ；s e r v i c ec o m p o s i t i o n 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及 取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论 文中不包含其他人已经发表或撰写过的研究成果，也不包含本人为获得浙 江工商大学或其它教育机构的学位或证书而使用过的材料。与我一同工作 的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示谢 意。 签名：么丞盏超日期：口可年；月日 关于论文使用授权的说明 本学位论文作者完全了解浙江工商大学有关保留、使用学位论文的规 定：浙江工商大学有权保留并向国家有关部门或机构送交论文的复印件和 磁盘，允许论文被查阅和借阅，可以将学位论文的全部或部分内容编入有 关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学 位论文，并且本人电子文档的内容和纸质论文的内容相一致。 保密的学位论文在解密后也遵守此规定。 签名：趑纽筵 导师签名： 日期：矿歹年岁月日 1 1 研究背景 第一章绪论 从企业的i t 战略角度而言，经过多年的发展，各个企业都已经在不同业务支 撑领域架构了一系列的i t 系统，甚至是一个完整的企业架构( e n t e r p r i s e a r c h i t e c t u r e ) ，或者是已经完成了部门级的垂直整合。可是，在日新月异的商业 环境下，产品的生命周期变得越来越短，客户的需求也在随时变化，新的业务模式 持续地酝酿生成n 1 。 新的业务模式需要新的业务流程来支撑，要求更有效率的合作，这不仅仅发生 在同一个垂直的部门内部，对跨部门的业务合作和整合的需求被也提到议事日程 上。有效的部门间合作，或者企业间的合作，能够满足客户需求并响应外界变化的 灵活业务流程，是现代企业竞争力的根本。这不仅仅是一个企业管理和文化能解决 的问题，也对企业的i t 系统提出了进一步的需求。这些需求为企业i t 架构和策略 带来巨大的压力如何能达到真正的随机应变? 如何提高i t 系统的投资回报 ( r e t u r no ni n v e s t m e n t ，r o i 乜1 ) ? 如何重用已有的技术和业务资源以满足新的需 求? 另外一个不容忽视的商业趋势是：随着行业发展越来越专精，越来越多的专业 服务被提供出来。企业可以使用第三方提供的更好服务来支持自身业务流程实现的 需要，而不用事必躬亲，这样可以大大节省i t 开发和维护的成本。在图卜1 中就 是这样一个典型场景，其中企业内部资源包括部门( d i v i s i o n ) 资源和共享服务 ( s h a r e ds e r v i c e ) 资源两部分。在客户( c u s t o m e r ) 使用这一业务流程时，企业 业务流程不仅仅是使用自己的既有服务，还整合了供应商( s u p p l i e r ) 的服务，进 而供应商又整合了一些外包商( o u t s o u r c e d ) 的服务。在这样一个场景中，供应商 和外包商提供了流程中的一些专业服务使得业务流程更加敏捷有效。实际上，这就 是w e b 服务技术产生的一个业务背景。在这样一个商业趋势下，如何整合企业外部 资源变成了一个很重要的并亟待解决的问题臼1 。本文的工作正是围绕这一具有深刻 技术背景和广泛应用前景的热点研究问题展开。 12 传统企业集成的方法和技术 幽1 - l 般务梏f 1 21 点对点集成 根据m e t ag r o u p 的统计，经过相当一个时期不断的i t 系统建设，一家典型的大 型企业平均拥有4 9 个应用系统，3 3 的1 t 预算是花在传统的集成上，通过零星的“点 对点”连接，使众多的“信息孤岛”联系起来，以便让不同的系统之间交换信息。这 使得企业的应用系统看起来像一张复杂的蜘蛛网。孤立的信息系统无法有效地提供跨 部门、跨系统的综合性的信息。孤立的信息系统也无法实现实时的信息存取和对业务 流程的透视，无法实现对客户、供应商、项目、订单、资产等的全面掌控，无法实现 企业价值链的全面的、彻底的透视和控制。在点对点的集成方法中，每个企业信息系 统( e n t e r p r i s e i n f o r m a t i o ns y s t e m ，e i s 。1 ) 都紧密地与其它e i s 通过它们的点对点连 接在一起，它的优点是容易理解并且当只有少量系统需要集成时可以快速实现。但如 果一个e i s 发生改变就会打破与它有关的应用集成；另一个缺点是每个e i s 都要求有 足够多的整合点来支持更多的系统集成如果有5 个互相集成的e i g ，就需要l o 个不 同的整合点如图卜2 所示。因此，这种方法很难集成大量的应用系统，且集成的系统 越多维护就越困难。 1 2 2 消息中间件 豳l 一2 点对点集成 由于点对点的集成方法很复杂、成本高、而且难于维护，于是引入了另外一种集 成方法，称为e a i 抽1 ( e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ，企业应用集成) 。它基于 消息总线代理或者中问件。在这种情况下，e i s 和消息中间件之间的连通性是用私有 总线a p i 和应用程序a p i 来实现的，见图1 - 3 ： 图卜3 基j 二消息巾闻件的集成 消息中问件和应用程序之问的紧密藕合使所有的应用程序都需要了解与其集成的 其他应用程序的内部工作方式。系统之间的集成都是粒状的，并且通过消息类型紧密 耦合。传统e a i 实现中所使用的业务流程管理工具是私有的，这阻碍了最优产品的应 用 1 2 3c o r b a ，d o o m ，r mi 3 c o r b a ，d c o m 和r m i 是传统企业集成中常用的分布式通讯技术，它们在早期的e a i 中发挥过积极的作用。 1 2 4c o r b a 分布式对象技术 c o r b a 盯1 ( c o m m o no b j e c tr e q u e s tb r o k e ra r c h it e c t u r e ，公用对象请求代理体系 结系结构) ，是o m g ( o b j e c tm a n a g e m e n tg r o u p ，对象管理组织) 为了增强异构软硬件系 统的协同工作能力而提出的方案和相关的标准规范。c o r b a 允许应用程序和其它的应用 程序通讯，而不论它们在什么地方、什么环境或用什么编程语言实现。c o r b a l 1 由o m g 在1 9 9 1 年发布，定义了接口定义语言( i d l ) 和应用编程接口( a p i ) 。i d l 是中立于任何 语言的，c o r b a 通过i d l 来实现与编程语言的无关性。i d l 有助于描述服务而无需深入 到具体实现细节。用这种方法可以将实现( i m p l e m e n t a t i o n ) 与接口( i n t e r f a c e ) 相分 离。c o r b a 服务器必须实现i d l 接口，而c o r b a 客户使用此接口。c o r b a 2 0 于1 9 9 4 年 的1 2 月发布，定义了如何跨越不同的o r b 提供者而进行通讯。 c o r b a 为实现分布式对象的透明远程通讯使用了代理的概念。c o r b a 会产生两个代 理，一个是客户程序的代理称为s t u b ，另一个是服务程序的代理称为s k e l e t o n 。s t u b 是以客户程序使用的程序语言的方式执行，它通过提供与服务程序对象相同的界面来 模拟服务程序对象，但它不能实现本地操作。s k e l e t o n 是一个以服务程序对象的程序 语言方式执行的本地对象，在服务程序处理中对它进行配置。s t u b 与s k e l e t o n 之间的 通讯是使用i i o p 哺1 ( i n t e r n e ti n t e ro r bp r o t o c 0 1 ) 协议。 o r b 是c o r b a 的请求代理中间件，它能在对象间建立客户服务器模型。客户s t u b 将需要调用的方法和参数串行化并输送给o r b ，o r b 截获这个请求后使用 i o r 阳3 ( i n t e r o p e r a b l eo b j e c tr e f e r e n c e ，可互操作对象引用) 找到合适的服务器对象 通过h o p 协议传送给另一个与服务器相关联的o r b 。服务器的o r b 负责激活s k e l e t o n 或使用对象配置器调用服务对象的方法，最后将结果返回给客户。这样客户就不用知 道对象在哪罩，是用什么语言实现的，它的操作系统以及其它与o r b 接口无关的东西。 i d l n 明( i n t e r f a c ed e f i n i t i o nl a n g u a g e ，接口定义语言) 是c o r b a 描述服务对象 接口的设计语言，它包含了服务对象接口的所有信息包括方法名、参数类型、返回值 类型等。可以使用i d l 来产生与客户程序和服务程序的设计语一言相对应的s t u b 和 s k e l e t o n 。i d l 可以映射成多对程序语言如c ，c + + ，j a v a ，s m a l l t a l k 等程序设计语言。 4 1 2 5d c o m 分布式组件技术 矧卜4c o r b a 丁作缘理 m i c r o s o f t 的d c o m n 订( d i s t r i b u t e dc o m p o n e n to b j e c tm o d e l ，分布式组件对象模 型) 扩展了组件对象模型技术( c o m ) ，使其能够支持在局域网、广域网甚至i n t e r n e t 上 不同计算机的对象之问的通讯。d c o m 的工作原理与c o r b a 十分相似，也使用了s t u b 和 s k e l e t o n 代理机制，使得客户程序并不知道它正同一个远程的对象进行通讯。代理之 问的通讯使用了r p c n 幻( r e m o t ep r o c e s sc a ll e d ，远程过程调用) 的d c o m 协议。服务对 象接口使用m s - i d l 进行描述，服务对象必须实现其接口。d c o m 与c o r b a 的最大区别是 d c o m 只能基于m i c r o s o f tw i n d o w s 平台，是w i n d o w s w i n d o w s 方式的集成方案，c o r b a 是由中立组织o m g 制定具有独立于操作平台的特性。 1 2 6r ml 远程调用 s t u bs k e l e t o n m 协 lc o m j ， i r p c 图1 - 5 ：咪2 - _ 作原理 r m i n 羽( r e m o t em e t h o di n v o c a t i o n ，远程方法调用) 是j a v a 版的r p c 。r m i 是 j a v a - j a v a 的集成方案，客户程序与服务程序都必须使用j a v a 语言编写。r m i 的也是 s 使用s t u b 和s k e l e t o n 的代理方式，但就没有像c o r b a 和d c o m 那样有i d l ，r m i 是使 用j a v a 语言中的i n t e r f a c e 作为接口，服务程序必须实现这个接口。服务器程序负责 创建服务对象并将对象存放在3 n d i n 们( j a v an a m i n ga n dd i r e c t o r yi n t e r f a c e ，j a v a 命名和目录接口) 中，一个服务对象与一个名字关联。客户程序必须知道服务器的地址 和对象的名字，通过n a m i n g 1 0 0 k u p 0 方法查找服务对象。得到服务对象就可以使用对 象方法，就像本地调用一样。r m i 隐藏了远程调用的细节，它是使用j r m p ( j a v ar e m o t e m e t h o d sp r o t o c o l ，j a v a 远程方法协议) 进行通讯。 图1 - 6r m i 1 j 作原理 1 3 传统企业集成技术的局限性分析 1 c o r b a 和d c o m 都依赖于单一厂商的实现 尽管c o r b a 和d c o m 己经在各种平台上得到了实现，然而实际情况是建立在这些协议 之上的任何解决方案都依赖于单一厂商的实现。因此，如果要开发一个d c o m 应用程序， 分布式应用程序中所有参与的节点都必须以w i n d o w s 风格运行。c o r b a 虽然由中立组织 o m g 提出并制定了一套标准和规范，但在实际应用中，不同厂商的实现的标准并没有统 一。如果要开发c o r b a 应用程序，应用程序环境中的每个节点都要运行同一厂商生产的 o r b 产品。虽然现在也有来自不同厂商的c o r b a ，o r b 能够相互操作。但是那种互操作性 并不能扩展到像安全与事务管理那样的更高级别的服务中去。不仅如此所有特定于厂 商的优化在这种情况下将丢失殆尽n 引。 2 c o r b a ，d c o m 和r m i 存在着紧耦合 c o r b a ，d c o m 和r m i 在服务请求者( 客户端) 都需要一个s t u b 文件或是配置文件，也可 以是共享库。在服务提供者( 服务器端) 需要接口声明文件或服务器端的配置文件。这 就是说，服务器端和某个客户端的类型是唯一匹配的，进一步说只有拥有服务提供者 的s t u b 文件的客户才能与相应的服务提供者进行通讯。只要服务提供者的接口声明有 6 所调整，所有客户都必须升级到新的s t u b 。因此，如果服务提供者对接口做出的任何 修改都将使之前做的全部步骤作废，而且需要重编译、重新生成所有s t u b 和s k e l e t o n ， 并向所有己知的服务请求者重新进行分发。 3 d c o m 和r m i 与平台绑定 d c o m 是由m i c r o s o f t 提出并实现，是与w i n d o w s 平台紧密结合，它是更适合 w i n d o w s w i n d o w s 的企业内部集成。d c o m 目前为止还不适用于非w i n d o w s 平台。r m i 运行 在j v m 之上，j v m 屏蔽了底层操作系统的细节使r m i 能在各种主流操作系统中运行。但换 句话说，r m i 也只能在j a v a 平台中工作，客户端与服务器端都必须使用j a v a 语言，它在 j a v a j a v a 的集成模式中r m i 表现得非常好，但不能实现j a v a - - 非j a v a 的集成。 4 c o r b a ，d c o m 和r m i 之间的互操作难 c o r b a 使用h o p ，d c o m 使用o r p c ，r m i 使用j r m p 。c o r b a 对象不能与r m i 或d c o m 直接进 行通讯；跚i 则不能与d c o m 和c o r b a 实现会话；d c o m 也无法与r m i 或c o r b a 直接交互。如 果确实需要它们进行交互则需要另外的协议，如r m i i i o p 或c o r b a d o o m 桥。 1 4 本课题的主要研究工作 经过几十年的企业信息化建设，企业内已存在许多分散孤立的应用系统，随着业 务规模不断扩大，企业i t 架构环境中单个应用程序无法包容业务的各种需求，即使是 一个大型的e r p 解决方案，仍然不能满足不断膨胀的需求。对市场快速做出反应，商业 用户只能通过不断开发新应用系统、扩展现有应用程序来艰难地支撑其现有的业务需 求。企业信息系统的重用和集成已经成为当今企业的迫切要求。传统的e a i 解决方法包 括点对点集成和基于中间件的集成方法，它们都是面向接口的集成方式，对各个应用 系统的接口进行基于某些特定标准的处理，从而达到系统整合的目的。随着需要集成 的系统不断增多，系统的接口呈指数增长，这种情况下不但维护存在很大的难度，而 且当一个应用系统的接口发生改变时，连接到该系统的其它应用都要跟随改变。传统 的e a i 都使用了诸女h c o r b a ，d c o m ，r m i 等的分布式程序通讯技术，这些技术都缺少完全 开放的标准，它们的实现都与特定厂商的私有技术紧密绑定。 s o a ( s e r v i c eo r i e n t e da r c h i t e c t u r e ) 是一种组件模型思想，但它更强调的是 松散耦合和中立的接口定义。从s o a 的观点出发，企业内的各种信息系统应该是为企业 内外的用户提供全方位的信息服务，按照“软件就是服务”的观点n 引，企业内的信息 7 系统与信息系统之间也应该走向一种互为服务的关系。服务是从业务流程的视角来看 待技术的，这种视角同一般的由可用技术所驱动的商业视角是相反的。服务的优势是 它会同业务流程结合在一起，能够更加精确地表示业务模型，更好地支持业务流程。 按照s o a 的思想，企业的i t 系统应该是由各种各样的服务组成，服务的重用能力比以往 任何组件都要强，因为它是直接反映业务而不是技术。需要开发新的应用时，则可以 先考虑重用现有的服务，这样可以大大缩短开发周期和降低成本，使企业i t 系统更加 灵活。s o a 的一个中心思想就是让企业彻底摆脱面向技术的解决方案的束缚，轻松应对 企业商业服务变化、发展的需要。 s o a 技术及其应用是本文主要的研究对象，运用s o a 思想设计出灵活的基于标准的 以业务服务为中心的企业i t 架构是本文的研究目标。本文提出的是完全基于工业标准 ( 如：s c a ，s d o ，e s b ，w s - b p e l 等) 的企业i t 架构，利用s o a 的服务建模思想，将企业内 的信息系统分解成不同的服务和业务过程，形成抽象的服务层和业务层。服务层屏蔽 了提供服务的应用系统的实现技术和位置，应用系统的交互不再直接使用接口，而是 通过抽象的服务层间接实现，这样当一个应用系统的接口发生改变时，使用该系统提 供的服务的其它系统不需要做任何改变，从而增加企业i t 系统的灵活性。服务是使用 w s d l 进行描述，从而也增加了服务的重用能力，当开发新应用系统时可以更多地考虑 使用已有的服务。在业务层中，可以通过w s - b p e l 语言将服务进行灵活的组装和编排， 实现业务流程自动化。 1 5 论文内容安排 第一章：分析传统企业集成方法和技术的不足，提出基于s o a 的企业集成方案。 第二章：介绍s o a 的概念及相关技术。 第三章：提出基于s o a 的企业集成参考架构，并对实现s o a 的核心技术进行论述。 第四章：浙江移动c r m 的需求分析和总体设计。 第五章：浙江移动c r m 系统详细设计 8 2 1s o a 思想理论 第二章面向服务架构( s o a ) 基础 随着信息技术的发展，特别在计算机网络和i n t e r n e t 的时代出现了大量基于网络 的大型分布式应用系统。随着公司业务的不断发展，对资源、数据的集中，决策支持 统一的要求越来越急迫，需要将现有的多个应用系统进行集成和整合；另一方面随着 业务的快速变化，企业要应对竞争的新要求，需要不断更新业务流程和应用模式，建 设新的应用系统，从技术上要求新的应用系统能快速搭建并实施，需要能够做到“随 机应变”，由此面向服务的架构( s o a ) 应运而生。 2 2s o a 的概念 s o a n7 1 ( s e r v i c e - o r i e n t e da r c h i t e c t u r e ，面向服务的体系结构) 不是一个新的概 念，早在1 9 9 5 年，美国知名i t 市场调研顾问公司g a r t n e r 最早提出s o a 的预言，2 0 0 2 年 1 2 月，g a r t n e r 又提出了s o a 是“现代应用开发领域最重要的课题”n 8 1 ，并预计 ! w j 2 0 0 8 年，s o a 将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构 长达4 0 年的统治地位，主流企业现在就应该在理解和应用s o a 开发技能方面进行投资。 s o a 是一类分布式系统的体系结构。这类系统是将异构平台上应用程序的不同功能部件 ( 称为服务) 通过这些服务之间定义良好的接口和规范按松耦合方式整合在一起，即将 多个现有的应用软件通过网络将其整合成一个新系统。 2 3s o a 编程模型 s o a 编程模型如图2 1 所示，s o a 的一个重要思想就是尽量重用现有的服务，客户程 序使用了服务3 提供的服务，而服务3 重用了服务1 和服务2 提供的服务。服务的对外接 口都使用了开放的标准来定义女h x d l 或w s d l 。 翻2 - 1s o a 编程模型 9 如图2 - 2 所示，s o a 模型包含以下组成元素： 1 服务( s e r v i c e ) 服务是粗粒度的处理单元，通过传送基于消息的值对象来使用服务。它与面向对象 编程语言术语中的对象不同，相反，它可能更接近于业务事务的概念而非远程的c o r b a 对象的概念。服务又不同于软件组件，服务可以由一些组件组成一起工作，共同提供 服务所要求的业务功能。 圈2 2s o ai n g r e d i e n t s 因此，相比之下，组件比服务的粒度更细。另外，虽然服务映射到业务功能，但 是组件通常映射到业务实现体操作规则。服务是可以在没有外部行为的作用下自主运 行的，并能完成一套业务功能。图2 - 3 说明了服务一组件一对象的关系。 豳2 3 服务，组件、对缘的关系 服务拥有自己的状态，但它的状态非常简单只有两种：s t o p p e d ( 停止服务) 、 r u n n i n g ( 运行) 。它不像面向对象中的对象可以有多种状态，不同的状态影响着对象的 操作。服务应该有很强的并发处理能力，可以响应多个客户程序的同时使用。服务没 有实例化的概念，不像面向对象中的对象需要实例化后才能使用( 因为需要初始化对象 的状态) ，服务应该是一个静态的概念，只要它存在随时可以使用。 2 服务提供者( s e r v i c ep r o v i d e r ) 服务必须由至少一个服务提供者实现，服务提供者是实现服务内部复杂的业务逻辑 或业务流程的软件实体。服务提供者同样可以使用其它服务来实现业务流程。服务与 服务提供者是多对多的关系，一个服务可以由多个不同服务提供者实现，但在某一时 刻一个服务只有个服务提供者，服务的提供者可以根据不同的需求更换，一个服务 1 0 提供者也可以提供多个服务接口。 3 服务描述( s e r v i c ed e s c r i p ti o n ) 在s o a 中的服务是外部使用者使用服务的接口，且要用开放的标准工具所描述。用 于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。有了接口 描述和服务的封装性，服务的使用者就可以简单地把服务理解为一个逻辑实体，是一 个或多个已发布接口定义的契约，并不需要关心服务内部的细节。接口契约应该独立 于操作平台和编程语言，以至于所有想使用服务的消费者都能懂。女h w s d l ，i d l 等。 4 消息协议( m e s s a g ep r o t o c 0 1 ) 消息是服务与外部使用服务的消费者共同遵守的通讯信息格式，服务消费者使用消 息来请求服务，服务也用同样的消息格式作为返回内容。它也应该独立于操作平台和 编程语言。女, i j s o a p ，x m l 等。 5 传输协议( t r a n s p o r tp r o t o c 0 1 ) 在s o a 中服务与服务间的通讯应该遵守相同的传输协议，传输协议是在服消费者与 服务问传输消息的机制。通讯协议也应该独立于操作平台和编程语言。如h t t p ，s m t p n 引， j m s 乜等。 2 4s o a b 勺角色 s o a 有三个角色，服务使用者通过查询服务注册中心来查找需要的服务。如果服务 存在，注册中心就给使用者提供服务接口的描述文档和服务的端点地址。 1 服务消费者( s e r v i c ec o n s u m e r ) 服务消费者是一个应用程序、一个软件模块或s o a 系统中的一个服务。它发起对注 册中心中的服务查询，通过传输绑定服务，并且执行服务功能。服务消费者根据接口 描述文档来使用服务。 2 服务提供者( s e r v i c ep r o v i d e r ) 服务提供者是实现服务接口的一个软件实体并可通过网络寻址来查找该实体，它接 受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便 服务使用者可以发现和访问该服务。 3 服务注册中心( s e r v i c er e g i s t r y ) 服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴 趣的服务消费者查找服务并提供接口。 1 1 2 5s o a 与面向对象的关系 1 s o a 中的服务需要用面向对象技术实现 s o a 的基本组成元素是服务，服务的实现是需要用到面向对象分析( o o a ) 和面向对象 编程( o o p ) 技术瞳。s o a 思想并没有细到代码设计，它注重是企业i t 系统架构的全盘考 虑，和对变化着的需求灵活快速响应，因此在实现一个具体的服务时，还是应该使用 面向对象技术。 2 s o a 是面向对象的替代模型 虽然s o a 不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向 对象的模型是紧耦合的，己经存在二十多年了。虽然基于s o a 的系统并不排除使用面向 对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统 内的对象，所以虽然s o a 是基于对象的，但是作为一个整体，它却不是面向对象的乜3 l 。 不同之处在于边界，对象的边界是紧耦合的a p i ，而服务的边界是基于工业标准的松散 耦合的契约描述。 3 s o a 是面向对象的进一步封装 面向对象的中心思想是数据和操作的封装，而s o a 的思想则是任务或业务功能的封 装，一个服务可能包含了能实现服务功能的多个对象。所以s o a 适合规模更大的系统建 设，特别是企业级的i t 系统建设。 4 0 0 a d 是s o a d 的重要组成 s o a d 瞳3 1 ( s e r v i c e o r i e n t e da n a l y s i sa n dd e s i g n ，面向服务的分析与设计) 是 o o a d ( o b j e c t o r i e n t e da n a l y s i sa n dd e s i g n ，面向对象的分析与设计) 的有效补充。 s o a d 需要o o a d 但o o a d 不能完全满足s o a d 的需要，o o a d 与类和单独的对象实例这样的微 观层次的抽象有关，由于每个问题域常常都创建单独的用例模型，因此，这个企业的 大方向在许多情况下变得模糊。s o a d 着重于企业的整体架构和对业务流程的分析，把 握企业的发展大方向。 2 6s o a 带来的好处 迅速改变的能力和降低成本的要求是当今企业要面对的问题。为了保持竞争力，企 业必须快速地适应内部因素( 如兼并和重组) 或外部因素( 如竞争能力和顾客要求) 。需 要经济而灵活的i t 基础设施来支持企业。可以认识到，采用s o a 将带来几方面的好处， 有助于企业在今天这个动荡的商业环境中取得成功。 1 利用现有的资产 s o a 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在i t 方一面的投资， 方法是将这些现有的资产包装成企业功能的服务。企业可以继续从现有的资源中获取 价值，而不必重新从头开始构建。 2 更易于集成和管理复杂性 在s o a 中，集成点是规范而不是实现。提供了实现透明性，并将基础设施和实现发 生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有 资源和资产的服务规范，集成变得更加易于管理，因为复杂性是隔离的。当更多的企 业一起协作提供价值链时，这会变得更加重要。 3 更快的响应和上市速度 从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提 供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发生命周期( 包括 收集需求、进行设计、开发和测试) 所需的时间。这使得可以快速地开发新的业务服务， 并允许组织迅速地对改变做出响应和减少上市准备时间。 4 减少成本和增加重用 通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地使用和组 合服务。这意味资源浪费的减少、以及重用和降低成本的可能性的增加。 第三章企业s o a 服务集成总体架构设计及核心技术 31 概述 面向服务的集成( s e r v i c e o r i e n t e di n t e g r a t i o n ，s o i ) 使用了s o a 架构的思想， 它提供了一个抽象的接口，通过这些接口系统可以进行交互而不是使用低层的协议和 自定义的编程接口来规定系统如何与其它系统进行通讯。系统只需要以服务的形式出 现，选择与该系统交瓦的其它系统能够简单发现那些服务，并且在运行的时候或者是 设计的时候与这些服务绑定。i l | i 向服务的集成使得i t 机构能够在已有的应用中提供可 重用的服务的功能s o i 允许企业在其应用程序丌发过程中把精力集中于业务流程，而先 不去关注有关集成或应用程序底层实现问题。s o l 的中心思想是使得企业应用摆脱而向 技术解决方案的束缚，灵活的适应企业业务流程变化和发展的需要。通过将注意力放 在服务上，应用程序开发能够集中起来，提供更加丰富、目的性更强的业务流程，基 于s o l 的企业应用系统会更加真实地反映出与业务模型的结合。 3 2s o a 概念架构模式 蚓31s o a 的艋2 槊构粳止 如图3 - 1 服务组件层将以服务组件为单位提供单个服务的封装，对外隐藏了服务 的实现细节，s c a 规范可作为这一层等的实现技术惜。服务层则是单个的服务或是多个 服务组件的简瞥连接。这一层的服务多是单个服务组件或多个服务组件的简单组台 所提供的服务，用，可咀直接访问这一层而获取所需的服务。但是复杂胁务流程需 要对多个服务组件按照预定逻辑进行组织和编排，这就是业务过程层所起的作用。b p e l 规范是实现业务过程层的合适技术。因此，一般来说b p e l 流程位于s o a 的上层，是与 企业的业务逻辑关系最为密切的一层。 33s o a 实现的核心技术 s o a 的设计理念在于将企业的i t 架构建立在一系列执行业务功能的服务基础t ， i t 资产通过服务的形式得到重用。业务模式和流程也可以通过服务的重新组合变得更 加灵活。可见，要搭建一个灵活多变的架构，其中的几个关键的技术抉择在于： 服务：服务是标准化的，是可以自描述的，足可以组装的，并能够隔离业务功 能和具体实现。 数据消息模型：是服务的日的一准确、迅捷地传送数据。因此，一个好的数 据模型可以事半功倍。 服务编排和流程引擎：用来将已有的服务组装起来定义真正的业务流程。敏捷 是对服务编排的一个重要要求。服务编排同时要提供相应的事务管理、流程状 态管理、出错处理等支持功能。 以上的三个方面被称为s o a 编程模式的“铁三角”。 区 蚓3 - 2s o a 编雕模式的铁= m 34 服务 作为构建s o a 的一个基础组件，服务具有下面一些特征 服务是可以独立操作的。每一个服务都能够提供相应的操作，能够很容易地被 独立调用，其执行并不依赖于架构中的其他组件和服务。操作是通过标准方式 封装和发布的。 服务是自描述的。其使用标准的描述格式定义了服务提供的操作和消息格式， 无论调用者和被调用者都无需关心其他信息，如地址、实现技术等。 服务足松耦合和异构的。服务的使用者和提供者可以是分布部署的，可以位于 不同的系统平台上，可以使用不同的技术实现。 服务是可组合的。使用相应的服务组装技术，例如流程编排技术，可以将多个 简单的服务组装成一个更加复杂的服务。这一过程是可递归的。这一特性极大 地提高了服务的灵活度和计算能力。 服务是动态的。己发布的服务是可以被动态发现和绑定。 服务是标准和丌放的。h 有在标准的基础上，企业中不同部门或者不同供应商 的服务才能够动态地组织到一起提供业务流程。供应商的独立性和互通性是服 务的目标。这样才能真正实现理想的“天下大同”。 服务可以包装已有的应用或组件。这一特性使得服务的领域变得更加广泛，并 且可以使现有资产可被重用，保护已有i t 投资。 服务是有质量保障( 0 0 s ) 的。 一个描述服务的概念模型是如图3 - 3 ： 。；z 燃33 月k * 的溉念幢，d 可见，服务是可以自描述并独立注册发布的。在一个服务请求者需要使用某个特定 业务功能的服务时，可以先在服务管理者，即服务注册中心中发现符合要求的服务一一 可能得到一个服务列表，因为不同的供应商会提供同一服务( 这也是一种竞争) 。服 务请求者可以根据需要决定使用哪一个服务，也就是服务绑定，然后就理所应当地使 用选定的服务了。 w e b 服务是一个既有的成熟服务技术标准，甚至很多人在提到s o a 时就会将其自然 等同于w e b 服务及其相应的架构。的确，从历史而言，s o a 设计理念的确是在w e b 服务 技术产生和发展之后才逐渐形成的，也确实借鉴了w e b 服务技术的概念和开发模式， 但是s o a 的范畴要更加宽泛，解决更加深入的问题，并非仅仅是技术领域。w e b 服务理 所当然是s o a 服务实现技术的一个选择，但并非是唯一的选择哺1 。 3 4 1 服务组件架构( s e a ) 当前，在业界逐渐得到广泛认可的一个服务封装技术是服务组件架构( s e r v i c e c o m p o n e n th r c h i t e c t u r e ，s e a ) 。s e a 是一个跟实现语言无关的服务组件编程模型，可 以很好地处理服务网络的建构，因此提供了基于s o a 简化开发的解决方案。s c a 规范的 开发和发布由o p e ns o a 组织负责乜7 1 。o s o a 组织在世界范围内有广泛的支持者，其中不 乏i b m 、b e a 、o r a c l e 、s a p 、f f i e b e l 、s y b a s e 和x c a l i a 等著名厂商。 s e a 作为一种通用的面向业务服务的组件模型，它以业务为中心，使业务逻辑和实 现技术分离。s e a 支持导入和导出，使得s c a 组件和其他组件可以方便整合和访问。导 出s c a 组件使之能通过w e bs e r v i c e 或j m s 等协议访问：导入其他技术实现的组件， 如w e bs e r v i c e 或e i s 等，使之可以像s c a 组件一样被访问。 3 4 2s e a 基本概念 服务组件模型( s e a ) 中提出了一些新的概念，比如服务组件、模块、共享库、导 入和导出等。下面将分别解释这些服务组件中的基本概念。 3 4 2 1 服务组件 服务组件是s c a 中的基本组成