（系统分析与集成专业论文）基于soa的企业系统解决方案的框架研究.pdf

南京信息工程大学理学硕士论文基于s o a 的企业系统解决方案框架研究 摘要 随着英特网的飞速发展，企业系统正处于新、旧模式交替的阶段，目前占主 导的仍然是传统的c s 和b s 架构的系统，但是目前正在日益兴起的s o a 解决 方案正在颠覆传统架构的地位。由于一个大型的企业部门众多，而由于业务的 不断发展，所以需要不断开发一些复杂而庞大的系统，造成了自动化成本的迅 速提高，由于系统有不断升级的需求，所以传统的企业系统解决方案都有复杂 性高和缺乏灵活性的缺陷。第二就是企业内部部门问和与企业外部的合作伙伴 间缺乏互操作性，由于以独立的系统的形式存在，所以企业内部的数据流断裂。 只有拥有完整的业务链才能保证企业对市场作出及时的反应，系统间如果实现 真正意义上的集成则需要更多持续的投资，这两个因素大大制约了企业系统的 发展。所以以往占主导的c s 和b s 架构逐渐不再适应需求j s o a ( 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 ，面向服务的体系结构) 最近几年才提出， 并迅速成为企业集成应用领域的一个趋势，它是一种抽象的模式，代表了一种 不涉及具体实现的软件基础架构，基于面向服务的原理，可以实现一种类似服 务组件群落的系统解决方案。本文论述了一种基于面向服务架构的分布式解决 方案框架，该框架命名为面向服务的分布式企业解决方案框架( s o ab a s e d d i s t r i b u t e de n t e r p r i s es o l u t i o nf r a m e w o r k ) 。提供了一个使用w e b 服务来实现的 拥有开放、可扩展、敏捷等多重优点的解决方案，该方案不仅提供了一个实体 模型，还提供了一个成熟的开发过程模型，该模型包含了规划、设计、开发和 部署在内的构建环节。该方案通过使用w e b 服务技术，从而得到了提高系统、 平台兼容性和系统可扩展性的茸的。 关键词：w e b 服务，面向服务架构，服务总线，技术框架 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 a b s t r a c t w i t h 曲峙g r e a td e v e l o l r m c n to f i n t e m e t , e n t e r p r i s es y s t e m i sa tas t a g eo f t m i n g t on e wp a t t e m c sa n db $ 辩a l s od o m a i na r c h i t e c t u r et o d a y , b u ts o aw t f i e l a p r o g r e s s e sq u i c k l y i sc h a n g et l a ew h o l es o t l w a r ea r e h l t e e t u r ef i e l d f o rl a r g e c o m p a n i e sh a v ean u m b e ro fd c p 缸m l 艇t ，t h e ya l w a y sn e e ds o m ec o m p l i c a t e da n d h u g es y s t e m s t h ec o s to f a u t o m a t i o np r o g r e s s e s f a s tf o re n d l e s sr e q u i r e m e n to f u p 船a d i n g , s o s o l u t i o n so f 匝h a v ed e f e c t so fc o m p l i c a t e 锄di l f f l e x i b i l i t y d e p a r t m e n t sa n dc o m p a n i e sl a c ko fi n t e r o p e r a t i o nf o rt h e ya i n d e p e n d e n ts y s t e m s 耽ed a t as t l 洽a l ni sb r o k e ni nt h ec o l p o t a t i o ns ot h a tm a r k e tc a l ln o ti m p a c ti n c o m p a n ya c t i v i t yi n 妇i n t h eo l dp a t t e r n , t h er e a li n t e g r i t yn e e d sm o l ec o n t i n u o u s i n v e s t m e n t t h e s et w ol e a 如n sr e s t r a i n tt h ed e v e l o p m e n to f e n t 盯p r i s es y s t e m $ o ai sa 岫di nt h ef i e l do fe n t e r p r i s es y s t e mi n t e g r i t y m a j o rv e n d o r s i n t r o d u c e dt h e i rs o as o l u t i o n sa n ds u p p o r tn i l ! wt c e l m o l o g i e sa n ds t a n d a r d s a c c o m p l i s h e dw i t hs o a s e r v i c e - o r i e n t e da r e t a i t e e t u r ec a m eo u tj l l s taf e wy e a r s a g o ，b u ti th a si m p r o v e dt ob et r e n do f 既岫印r i 辩s o l u t i o nf i e l d s o ai saa b s t r a c t p a t t e r n i tr e p r e s e n t s as o t t w a r eb a s i sf r a m e w o r ke x e l u d i a gs p e c i f i ci m p l e m e n t b a s e do nt h ep r i n c i p l eo fs e r v i c e - o r i e n t e d , w ec l l nr e a l i z eas y s t e ms o l u t i o n j u s tl i k e s e r v i c o m p o n e n t s t h ep a p e r d i s e m s e da $ o ab a s e dd i s t r i b u t e ds o l u t i o n f r a m e w o r k t h i sf i - a m 洲o r km a yn a m e ds o ab a s e dd i s t r i b u t e de n t e 删s es o l u t i o n f r a m e w o r k i tp r o v i d e sas o l u t i o nb a s e d0 1 1w e bs e l v i c i ：a n dh a sf e a t u r e so fo p e n , e x t e n s i b l ea n ds n l f l l t i t sn o to n l yd e m o n s t r a t e dam o d e lo rap r i a e i ! o l e 。b u ta l s o p r o v i d e sas e r i a lo fp l a n n i n g ，d e s i g n i n g , d e v e l o p i n ga n dd e p l o y m e n to fe n t i r e e n t e r o r i s o l u t i o n t h es o l u t i o nc i t l li m p r o v es y s t e me x t e m i b i l i t ya n dc o m p a t i b i l i t y o f s y s t e ma n dp l a t f o r mf o rb a s i n g0 1 1w e bs c r v i c i ，t e e l m o l o g y k e yw o r d l s sw e bl l e f y i c e 。s e r v i c e - o r i e n t e da r e t a i t e e t u r e ，s e r v i c eb u s ，t e e l m i e a l a r e l a i t e e t u r o 学位论文独创性声明 本人郑重声明t 1 、坚持以。求实、创新”的科学精神从事研究工作 2 、本论文是我个人在导师指导下进行的研究工作和取得的研究成果 3 、本论文中除引文外，所有实验、数据和有关材料均是真实的 4 、本论文中除引文和致谢的内容外，不包含其他人或其它机构已经 发表或撰写过的研究成果 5 ，其他同志对本研究所傲的贡献均已在论文中作了声明并表示了谢 意 作糍名；讧：亟 日 期：z 1 3 ：! ：生 学位论文使用授权声明 本人完全了解南京信息工程大学有关保留、使用学位论文的规 定，学校有权保留学位论文并向国家主管部门或其指定机构送交论 文的电子版和纸质版；有权将学位论文用于非赢利目的的少量复制 并允许论文进入学校图书馆被查阅；有权将学位论文的内容编入有 关数据库进行检索；有权将学位论文的标题和摘要汇编出版保密 的学位论文在解密后适用本规定 、 作者签名：丛塑塾 日期；丝固：竺 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 第一章概述 1 1 引言 目前在企业系统领域中已经有了很多成功的方案，在解决大型系统问题时有一个重要 的原则就是将系统分解为相对较小的子系统和相对独立的功能模块，分而治之，得到一个 个的系统片段，每个片段都关注于系统中某个具体的功能点，这样整个系统也更加易于分 析和实现。 但是同时会出现的问题就是在邦署一个完整的系统时，会发现并不是真正意义上盼相 互独立的分布式部署，而是将功能模块的物理载体程序集在物理e 进行分布式部署。 这是技术框架上实现的一种粗糙的物理部署，如果从业务框架上来说，完全不是一个真正 意义上的分布式计算，当维护阶段需要进行系统升级时会出现一个类似c o m 组件部署的 部署陷阱( d e p l o y m e m l - i e u ) ，这是因为被更新的业务逻辑元素必需寄生在各个相关系统中， 那么每个相关系统都必须升级。 随着s o a 架构的出现，系统能够实现功能内聚和子系统松散耦合这两个特点，不会出 现上面提到的“部署陷阱”问题。大型的系统供应商都提供了自己的s o a 方案，但是标准 和规范还没有达到统一 本文以面向服务架构为原始出发点，结合企业系统的特点，构建一个s o a 解决方案的 框架，并实现一个实体的开发平台 1 2 背景 1 2 1 企业系统面临的向量。 目前大型企业中普遍面临着的问题不是构建而是发展，系统一旦构建，缺乏扩展性。 业务自动化随着网络时代的到来已经成为了一个不可逆转的趋势，但系统构建后，传统方 案存在着不能与时俱进的缺陷。系统中最重要就是系统中的信息，如果这些信息维护在不 同的系统中，那么就无法实现实时的信息共享。企业如果希望在系统问同步信息就需要更 多的投入，开发成本也就相应提高。 然而还有一个更为严重的问题就是当系统需要升级或者某些独立的系统需要与现存系 统集成肿。就对开发工作提出了更大的挑战，我们面临的闯题是摒弃现存的系统或是在以 前系统的基础上进行改造。然而在传统的软件架构中加入新的功能，就类似于在一个大厦 下修建一个停车场一样困难，需要我们从头修改需求、设计、实现和部署方案，更大的苦 恼是我们得担心新的改动是否对系统带来破坏。 这也跟企业系统发展的历史有关，在发展的初级阶段，往往企业使用的是特定的产品， 比如财务管理软件或者人事管理软件，或者是实施了某些功能模块的e r p ( 企业资源管理 l 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 系统) 和o a ( 办公管理系统) ，但是随着企业信息化的不断发展，我们又引进了一些更新 的系统，比如c r m ( 客户资源管理系统) 和b p m ( 企业流程管理系统) 。希望利用这些系 统提高公司的办公效率，因而不断发展我们的企业系统，这在我们的市场经济环境下的优 势是可想而知的 上文中我们提到了企业自动化的种种优点，但我们可以轻易的发现所有的系统都是相 对孤立的，这就造成了信息流的断裂，信息不能同步，而且实现同步的难度也很大，需要 做一些进行辅助数据同步的软件，这将提高开发成本，而我们所得到的也不是真正的信息 同步。而是一种伪同步，系统仍然是孤立的。 由此我们获知传统的方案缺乏足够的灵活性，且没有基于特定的标准和协议，随着系 统需求的不断发展，带来的更多的将是负面的影响。系统难以维护，各个事业部门也难以 使用，最终使得企业的业务退步。 1 2 2s o a 方案的引入和现状 我们实施s o a 方案的初衷是为了实现企业系统内、系统闻的应用整合，它是下一代企 业解决方案的基础架构。s o a 是一场平台的革命，应用程序的业务逻辑及特定的功能以服 务的形式提供给客户端( 相对于服务提供者) 。 将业务逻辑分离为独立模块并不是新的思路，但是与传统的逻辑分离不一样的是，s o a 可以实现一种真正的内聚和松散耦合，相比之下，从技术和业务框架的角度来观察传统的 方式都是强依赖的，所以抑制了系统业务逻辑和功能模块的发展潜能 通过严格的遵守s o a 的开发原则，我们可以实现服务组件内部逻辑的高度聚合，从外 观来看该服务的紧密聚合是有利的，因为服务作为组件是一个包含有序操作的功能块，所 以调用方不用了解内部逻辑，只需要知道调用的接口即可。当然强聚合也会带来一些缺点， 操作以特定形式存在，灵活性就明显降低了，我们应该做的就是控制服务的粒度，这样就 可以避免这种极端状况的出现。 当组件密切依赖于外部组件实现自身的功能时，我们就可以称之为紧密耦合。开发人 员应减少组件问的相互依赖，因为如果依赖性太强，未来系统升级时会发生一系列事故， 避免这些事故将需要更高的成本 从s o a 的原则出发，就可以成功避免这两个问题，这也恰好符合了软件工程的思想。 在实现前，我们花费时间抽象企业的业务服务，如果抽象的程度越高，就可以得到更符合 松散耦合原则的系统，从而使得该系统具有更健壮的架构 s o a 发展面临的另一个问题是目前广泛存在的误解。预想中s o a 的多变特性引起了 系统供应商的注意，从理论上来说s o a 可以改变整个企业系统环境，但是很多观点认为采 2 南京信息工程大学理学硕士论文 基于$ o a 的企业系统解决方案的框架研究 用$ o a 就是采用w e b 服务，对现有软件架构进行异构使之应用w e b 服务技术就能够实现 多变、敏捷、扩展性强的特点，然而这恰恰忽略了s o a 的实质。我们实施s o a 是追求一 种潜在效益，必须按照s o a 架构的基本原则进行系统构建。而w e b 服务融入s o a 的重要 前提是：我们必须对系统需要的技术和业务进行详尽的分析，并封装业务逻辑，构建开放 的服务层。所以s o a 是一个与实际如何实现无关的概念，它与w e b 服务并不相互依赖。 1 3 解决方案框架研究的意义 首先对企业系统的特点进行分析，由于认识到企业系统多变的需求并且包含众多的子 系统，比如，由于某些业务的特殊性，需求变化时，某些模块就需要作相应的变化，所以 我认为讨论具体的需求不能带来广泛的借鉴价值，在论述过程中也将尽量避免过于具体。 在分析了系统特点后，我对系统进行了抽象，这个过程从最基本的需求分析和框架定 义出发。通过框架定义了软件的每一个逻辑层之间的依赖关系，在建立了这样的一个框架 之后，我就按照最基本的需求构建了一个原型平台，这样的一个原型平台的价值在于，一、 它的实现过程也是未来每个子系统实现所要经历的，有借鉴意义，二、它是最基本的需要， 将作为组件被集成到其他的独立系统中。 总体设计之后，首先提出一个符合s o a 特点的企业系统的开发过程模型，随后逐个完 成模型中所定义的环节。整个设计、实现的过程是个迭代的过程，通过坚持遵循基于组件 的开发原则，实现系统的每个功能块只依赖于框架而不依赖于其他部分。通过对最基本的 需求和最朴实的原则进行遵守，方案实现了一种基于服务契约的最小依赖，并达到松散耦 合的目的。 本文的目的和意义在于： 定义一个典型的企业s o a 解决方案，并实现这种解决方案的个开发平台。 利用s o a 的固有特点，使得企业系统具有松散耦合的架构。 通过详细设计，特别是关于服务层选择的讨论，使每个功能点都具有内聚的特点。 提供一个相对成熟的企业分布式系统的开发过程的模型，定义开发过程中的每个 实施步骤。 1 4 本文的结构 本文首先介绍基本理论知识，介绍w e b 服务的原理和展望最终带出s o a 的概念和s o a 将为我们带来的新思路。介绍多层架构及其特点，然后根据软件工程的思路，对每一个环 节进行分析，论文主要分为以下几章。 第一章、阐述目前企业系统面临的问题和引入s o a 的初衷，并对s o a 的现状进行阐 述，进而讨论本文的意义。 第二章、介绍论文中将引到的基本理论知识，主要对w e b 服务、多层槊构体系和s o a 进行介绍。 第三章、分析目前企业系统的需求和特点，并作出总体设计。 第四章、描述一个为s o a 解决方案度身定做的开发过程模型，并对开发过程中可始存 在的风险进行分析。 第五章、详细设计框架和平台。 第六章、简略介绍开发平台的实现，着重强调了实现过程中必须遵循的原理和原则 3 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 最后提供了一个符合s o a 解决方案特点的部署方案。 第七章、分析论文的成果和仍然存在的不足，及在企业系统领域中本方案的发展前景 1 5 本章小结 本章对目前企业应用系统作了一个概括，分析了目前企业系统构建中存在的问题，并 对其发展前景作了预测，从而引出了这篇论文研究的意义最后介绍本文的结构，说明了 文章的主要研究内容和层次结构。 4 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 第二章基本知识 自从1 9 9 6 年，g a r t n e r 首先提出s o a ，面向服务架构逐渐被公认为系统集成领域的下 一代架构。各个大型的系统供应商如b e a 、m m 都已纷纷建立自己的s o a 应用方案，$ o a 的目标在于让r r 方案有更大的弹性，以适应不断进步的业务需求。 在解决方案的构想阶段，需要项目组与客户进行业务需求和目标的讨论，但是在做需 求调研之前我们必须首先对面向服务体系架构的理论进行分析，因为面向服务的抽象性， 所以我们并需要讨论相关的技术。 下文中，我将首先分析此案例所依赖的x m l 和w e b 服务技术，在设计阶段我们还会 将多层架构桥接到我们的s o a 方案中，所以还会介绍软件的多层架构知识 2 1w e b 服务 w e b 服务( w e bs e r v i c e ) 是一种应用程序的组件w e b 服务只是应用程序的局部，能 够独立为基于不同程序平台和开发语言开发的程序提供服务。因为w e b 服务基于不依赖某 个平台的h t t p 、x m l 、s o a p ( s i m p l e o b j e c t a c c e s s p r o t o c 0 1 ) 、u d d i ( u n i v e r s a l d e s c r i p t i o n , d i s c o v e r ya n di n t e g r a t i o n ) 和w s d l ( w e bs e r v i c ev e s c r i p d o nl a n g u a g e ) 技术，所以w 曲 服务有先天的超平台性，因为核心的s o a p 和w s d l 技术又都是基于x m l ，所以w e b 服 务往往被称为x m lw e b 服务同时作为一种组件，w e d 服务可以得到基于组件开发能够 得到的可伸缩性和松散耦合性 2 1 1w e b 服务原理 w e b 服务以x m l 为信息的格式来与调用方交换数据，所以可以实现与不同平台、不 同编程语言的客户端( 相对而言) 基于共同标准开发分布式程序，所以基于w e b 服务技术， 部署在不同平台上的应用程序也可以进行集成。w e b 服务另一个基本特性就是客户端与服 务端之间互相不知道对方如何实现，而仅仅需要知道w e b 服务的描述，即知道如何调用该 服务即可。w e b 服务就是通过这样的一种松散的耦合得到开放、可扩展的和易用的服务框 架。 请求，响应的方式主要是客户端程序。阅读”w s d l 文档后，通过发送方法调用和调用 参数这些数据来调用服务中的方法，数据使用以x m l 格式并符合s o a p 协议的信息通过 h t r p 传输发送到w e b 服务提供方，服务提供方也将按照w s d l 文档的规定返回方法的调 用结果。因为双方是基于协议，通过i n t e m e t 和i n t r a n e t 来进行分布式集成，在开发过程中， 当开发某一个功能模块时，我们需要构想建立于网络上的开放组件，它可能调用服务，同 时又作为服务器端为其他系统提供服务。这样做可以避免其他系统构建时，如果开发相同 功能，需要耗费作同样多的精力，也就可以实现软件工程理论希望帮助我们实现的开发过 程的复用( r e u s e ) 。 客户端与w e b 服务之间的请求，响应方式与r p c ( r e m o t ep r o c e d u r ec a l l ) 相似，类似 于其他的分布式计算方式，比如与n e tr e m o 衄( n e t 远程处理) 相似的方式，客户端 建立一个代理对象并类似于调用本地对象一样进行调用，与n e tr e m o t i n g 不一样的就 是n e tp e m o t i n s 使得远程对象的生存周期更长，而w e b 服务却是没有状态的。 南京信息工曩大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 s o a p 妇l e 嘶l s e a l i z e d e s e a 结 ，t 姆魄p y d e s e r i a l le $ a - i a l i 卅 f 乏 。 纰一 圈2 1 舶b 服务调用过程 按照图中所示，响应过程包括以下几个步骤。 客户端创建w e b 服务代理对象。 利用代理对象调用服务方法。 方法和参数信息序列化为s o a p 信息包，发送给w e b 服务端。 服务器端反序列化s o a p 信息包，将其“翻译”为适应本地平台的版本 服务器端执行相应任务。 服务器端序列化结果信息，并将响应发还给客户端。 ，客户端反序列化调用结果，并按照既定流程继续向下执行 2 1 2 w e b 服务平台的基础构架 w e b 服务之所以能够独立于编程语言并独立于特定开发平台，原因是基于开放协议的 x m l 技术，x m l 简单并且平台独立。首先得提到x m l 的先天优势，x m l 发明的目的就 是为了描述数据；第二用户可以自己定制x m l 的架构，所以它本身又具有扩展性；第三 点是x m l 以文本形式存在，所以它又是超平台的，只要一个系统中有咀。的解析器，就 可以“读懂”x m l 。s o a p 就是以x m l 文本作为传输信息介质的协议，而更高级的网络 服务是一种基于s o a p 协议的技术。由于它的通信协议s o a p 和其通信载体x m l 文本具 有以上优点，所以网络服务是一种中立技术，利用n e t 和j a v a 等语言并且基于不同的操 作系统都可以创建w e b 服务，遥过将方法暴露给其他语言进行调用，从而实现数据通信乃 6 南京信息工程大学理学硕士论文基于s o a 的企业系统解决方案的框架研究 至互操作 w e b 服务主要有以下几个组件。 s o a p ，报文格式协议。报文以x l v l l 文档的格式存在，与一般的x m l 文档不同 的是s o a p 报文有着特定的语法定义，如它的每个元素都用s o a p ：i d 属性标记以区 别于其他元素。整个s o a p 文档类似于封信件，有信封、信头和信件主题。s o a p 是一种被类型化的序列化格式，它使用h t t p 作为通信协议，可以与j a v a 、c 、 c + + 、c # 和v b 等语言编写的程序互操作。 s o a p 协议包含四部分，第一是信息的封套，第二部分定义了编码规则，第三部分定 义了交换信息的请捌响应模式，第四部分定义了s o a p 协议与通信协议的绑定，这部分为 可选项。 n lv e r s i o n = “1 o ”? 2 0 0 u 】m 啪郾l i o e d n o w s d l ，提供信息以供客户了解如何调用w e b 服务，定义了调用w e b 服务时发送 的x m l 文档的格式，描述文档会定义w e b 服务客户端和服务器端之间传输的 s o a p 信息的架构。 u d d i ，实现发布了的服务的目录存储和查询工作，用来搜索所需要的w e b 服务 和相关的信息。统一描述、发现和集成规范了w e b 服务的发布规则，本质上就是 一个服务信息的数据库。 7 南京信息工程大学理学硕士论文基于s o a 的企业系统解决方案的框架研究 田2 2u i 带来的新型的w e b 钿r v i c e s 榘掏 如图，u d d i 可以使得我们的服务形成一个服务群落，不再是单独的w e b 服务个体， 而是w e b 服务的复数( w e bs e r v i c e s ) 。基于这些组件，我们能够得到一个w e b 服务技术框 架，客户端通过u d d i 查找相应的w e b 服务，根据结果得到w e b 服务描述文档w s d l 的 u r l ，我们就可以将相应的服务纳入到我们的程序中，根据文档并利用工具得到生成代理 类，这样也就可以根据w s d l 所定义的方式进行相应的编程 2 1 3w e b 服务小结 当我们需要建立超平台、松散耦合并且可伸缩性强的系统时我们可以选择w e b 服务作 为组件。创建w e b 服务之后，任何有权限的用户女阿以访问该服务，可以使用直观的w e b 接口或者编程方式都可以使用该服务。 w e b 服务的发现机制可以建立一种以w e b 服务为基础的服务平台，客户端通过查询可 以得到w e b 服务描述文档，用户得到w s d l 文档后，根据其定义的w e b 服务位置和访问 方式等信息进行调用。 w e 服务可以使用v i s u a ls t u d i o n e t 的集成开发环境进行开发和创建，v m n l s t u d i o n e t 简化了w e b 服务的开发。 由于w e b 服务是无状态的，客户端通过创建一个咀w e b 服务代理类的对象并对代 理类方法进行调用。客户端将调用和参数序列化为s o a p 格式并发送给服务器端，s 作为 宿主侦听到请求并将信息反序列化，创建服务器对象并根据信息调用服务的实体方法，服 务组件将调用结果返回给寄宿程序，寄宿程序将结果序列化为s o a p 信息，并发送回客户 端。客户端代理根据反序列化后的结果模拟为客户端调用的返回值，程序往下继续执行 8 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 在通信的两端都有相应格式化器和反格式化器。 目前w e b 服务被公认为一种s o a 实施方案的基础设施，w e b 服务与s o a 关系密切， 但是目前仍然很多人对s o a 和w e b 服务之间的关系有误解，s o a 本质上不是w e b 服务最 终实施的平台，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 。这样的观点只是表象，如果我们没有依照s o a 的原则进行软件 的构架，那么就得不到最终的s o a 。 s o a 能得到一种强大的、潜在效益，依照面向服务原则进行w e b 服务的设计和实现才 是真正s o a ，因为目前存在的完美方案只存在于构想中作为抽象模型的s o a 方案中，w e b 服务是一种将之实体化的方式，并不是唯一途径，w e b 服务是将s o a 由抽象模型转变为实 体的一种捷径而已。 s o a 广泛传播还因为市场的要求。使用了s o a 这个字眼项目也就处在一个比较高的 层次，但是这往往只是“w e b 服务实现”的概念上的变种，而没有抓住实质，人们在利用 $ o a 这个概念进行市场的炒作和推动。 当然w e b 服务和s o a 在目前这个阶段还是相辅相成、互相推动的，也正是第二代的 w e b 规范使得s o a 进入了发展的快车道，成为r r 架构中潜在的主流。如果我们退到一定 的位置会发现s o a 与w e b 服务是方案的两面，它们决不冲突，w e b 服务是一种特定的技 术。为我们提供了一种分布式系统的解决手段，基于它，我们可以构建一个分布式系统的 技术平台。s o a 则侧重于业务架构，所以刨建s o a 架构还需要具备业务分析经验，架构 师根据特定情形对业务逻辑进行封装并将构建服务层将之发布，所以s o a 超越了技术的范 畴，它构造了系统的业务平台。 2 2 s o a 面向服务的体系结构( s e r v i c eo r i e n t e d a r c h i t e c t m e ，s o a ) 是为了建立一种基于i n t e r n e t 的业务集成平台，通过将各个独立的逻辑单元分离，各个独立的单元构成整个自动化逻辑 的一部分，每个单元自治而互不孤立，这个系统就实现了一种s o a 软件架构，而这些逻辑 单元则是一个个的服务来实现。s o a 是一种组件模型，通过严格定义、友善的协议从而将 服务间联系起来。s o a 的核心价值来自于接口中立从而使得软件体系可以独立于编程语言、 操作系统和硬件平台 2 2 1 基本s o a s o a 的严格定义是：一个开放的、敏捷的、可扩展的、可联合的、可组合的架构，包 含了自治的、高服务质量的、厂家多样性的、可互操作的和潜在可复用的服务。 s o a 的定义根抽象，目前是基于x l v i l ，并且使用w e b 服务实现的，但是它并不依赖 于w e b 服务，它是一种抽象，可以通过将各种可用技术纳入软件体系中以获得实施s o a 方案的核心价值，也就可以说我们实施s o a ，不在于使用哪种技术实现。 s o a 是一种平台的进化，成功实旅它往往通过对传统框架进行成功的变异，通过保留 传统框架的成功特性，并且引入能够获得自治、开放，敏捷和扩展性这些新特性的元素。 所以我们可以说s o a 是一种遵守面向对象原则的架构体系，它是一种意识形态，能够对我 们的组件的设计和开发起一种指导作用，它对我们的方案施加了一种潜在的影响。 因为$ o a 实现的标准在于能够支持大量的异构系统，这就决定我们必须使用文本而不 9 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框桨研究 能使用二进制的信息来传输数据。这就不同于传统的d c o m 和c o r b a 或者现在比较流行 的n e t 远程处理，这些技术都使用二进制信息作为传输对象，当然n e t 远程处理可以选 择传输对象的编码规则( 也可以选择线性化为s o a p 或x m l 格式信息) ，但是都不能真正 的独立于平台，比如n e t 远程处理就不可以脱离w m d o w s 平台。与这些技术相比使用文 本作为传输对象将使得我们的系统损失一定的性能，但是却可以得到最大的兼容性。 目前s o a 普遍的通信媒介是) 西也格式，在i n t e r n e t 环境下，不同开发语言，不同平 台对x m l 都能够解析，这就避免了因为基本数据类型不同而带来的对象识别问题，s o a 架构下各个模块之间通过文本进行通信。服务器端发送数据无须考虑客户端是否能够兼容， 因为x m l 是如此的简单，以至于每一种高级语言都有了相应的类库。 关注s o a 我们首先就得提到s o a 的特点：松散耦合、适当功能粒度。松散耦合是通 过设计使得我们的组件的外观给用户( 客户端) 友善的感觉，避免了当一个组件更改时对 其他系统组件带来恶意的、联动的影响，提高服务的质量。 适当功能粒度则是在回应对功能粒度分割的各种误区，目前不少观点觉得s o a 的基本 原则就是粗粒度，但是这个原则太过于绝对。s o a 的出发点就是保证服务的独立性，失去 独立性，s o a 也将丧失了其他的优点，比如敏捷、可组合，独立性的要求与我们的功能粒 度的选择其实是共通的，我们实现了前者也就自然得到了后者。在s o a 实施前期，我们对 功能分割为各个功能颗粒时。我们需要在特定的语境下进行逻辑的封装，因为每个系统客 观条件上的特殊性，特定语境也就特定于一个独特的业务活动。 目前很多观点都孤立的讨论服务的粒度，讨论我们分割为大、小或者中等的颗粒，而 脱离了特定的业务环境。 田2 3 服务粒度对比 如上图，随着业务环境、对象和场景的不同，服务的范围和规模都是可变的，诚然分 割为小的粒度适合开发者的观点，他们具体的完成各个模块，所以希望清晰的知道每个模 1 0 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 块中的每个单元，但是这是不可能的，因为如果不是一个熟悉的领域，分析师得到的不会 是确定的需求，需求随着客户对系统的认知而不断变化。如果站在需求分析师的角度，只 能看到了一个个独立的大功能，分析师可能会说我们提供了查询功能或其他笼统韵功能， 但是没有经过更具体的分析，我们不知道什么样的规格符合一个独立的服务的要求，这对 我们的功能粒度分割也没有益处。 从开发者的角度，我们得到的会是一种细粒度的服务，这些服务不可以为终端直接可 用，而且数量比较多，因此对安全的控制也会成为我们开发的负担，租粒度来自子分析师 特定的功能其实包含了多个细粒度规格的服务，往往规格太大，接口变更时也需要更大的 成本。所以不论我们总是站在开发者的角度还是总是站在分析师的角度，都对我们的功能 分割产生负作用。分割为很小的颗粒，中间调用带来的拇题过多，从而使得系统难以管理 而分割为粗颗粒，使得系统失去了灵活性。 我们可以将系统分析师得到的成果进行进一步的详细分析，将各个独立的功能一个个 从笼统“打磨”到很精细，比如一个银行系统对身份信息进行验证，这就是一个相对独立 而且具有相当复用可能性的功能，我们可以将它提取出来，并为之定义严格的接口契约。 这是一种对开发过程的升级 功能粒度分割的工作我们可以放在分析师完成工作后，在确切知道用户需要什么样的 系统后，在设计师具体的设计每个功能模块前。我们就应该将功能按照合适的粒度进行粗 略分割，这也可以对我们排定开发日程提供指导意义。 这个步骤在这个s o a 方案中看似非常重要，但其实在普通的非s 0 a 系统开发过程也 可以引入这个环节，它可以成为我们系统设计提供蓝本。 2 2 2s o a 基本原则 s o a 的强大在于它的灵活性可以给企业带来巨大的好处，帮助公司将系统架构抽象， 每个服务都渣晰，并且企业系统可以以较低的成本进行重组，但是更大的好处不在于耳前 的系统能够提供给我们的，而在于未来的技术优势，s o a 可以实现业务敏捷性，创建一个 面向未知需求的架构。 提到企业业务系统，我们必须首先讨论企业的系统和企业系统领域的两个重要平台， 技术平台和业务平台，企业系统的发展来至于两个平台的积累。 技术平台项目比较清晰，就是企业的系统基于何种开发平台，如n e t 或j 2 e e 和数据 管理和访问策略，作为必须，各类企业都差不多，没有必要为了一个新的系统而重新考虑 重构技术平台。因为企业需要的是成功、安全的实现而不在于如何实现 业务平台才是一个系统的灵魂所在，也是企业系统的核心竞争力。成功的企业系统首 先需要业务领域知识的积累，也就是企业内解决方案的不断积累和升级，成功地把握需求。 但是一个系统是否成功还在于开发完成后系统的生命力，如果企业的i t 部门每天都在应付 项目的维护，那么这种情况就将导致一种恶性循环。因为企业内部对于系统的需求是不断 的。老的问题没有解决。新的问题又出现，那么将导致i t 部门效率低下，项目难以维护， 甚至公司里所有人( 开发人员和使用者) 都焦头烂额。那么我们就意识到系统在构架阶段 就出了问题，这是因为我们的开发没有依照正确的原则。 其实正如旬绕口令“原则的真正原则在于它的核心原则”，s o a 开发的核心原则在 于以业务为核心，正如我前面提到的目前有不少对s o a 的误解，w e b 服务的出现或多或少 南京信息工程大学理学硕士论文 基于s o a 的企业系统解决方案的框架研究 的降低了实习s o a 的难度，我们可以以更小的代价达成我们的需求但是如果开发者忽略 面向服务的业务建模，那么我们所实现的系统仍然跟传统的软件一样，得不到s o a 的优点， 就像我们使用面向对象的语言编写面向过程的程序，我们使用的工具并不能使的我们获得 我们所期望的潜在价值，而这样的潜在价值才是我们孜孜不倦的追求。 当以业务为核心构建s o a 平台时，我们设计的系统才可以对系统设计的变更作出敏捷 的响应。系统就拥有一个灵敏的环境，通过对业务流程以及技术架构进行升级，就可以有 效地对系统进行业务领域的变更如果我们没有从业务出发，我们没有得到这样的抽象高 度，我们就不可以得到这样的优势。 当然我们还需要从以下几个基本的出发点来讨论面向服务的一般原则。 复用性 面向服务鼓励服务的复用性，复用( r 目) 思想也是现代软件工程所竭力倡导的中心 思想，一段代码、个方法、一个类型、一个模块甚至一个系统，现代的软件公司都希望 可以构建无限复用的软件。对于开发者来说复用性越高，开发过程也越成熟，系统开发在 不断的积累过程中，并且传统开发中成功的特性将保留，并成为公司开发平台的核心部分， 开发的产品基于的架构也更加健壮。 保证复用性我们就必须保证以下几点，首先是原子性，如果一个功能的实现与其他功 能耦合太紧密，那么也就不大可能实现复用性，因为将它从现有的功能模块中提取出来就 需要很大的精力其次是封装，减少暴露服务的实现，而只暴露服务的外观，可以实现更 大的复用性。 这个原则是延伸的，无限的，作为开发者我们希望所有的功能都有共通的特质，这样 可以使得开发效率更高，开发过程也更加成熟。但是从实质上说这种复用性不可以从开发 者角度出发并获得，我们需要从设计环节，建立设计、开发标准，从业务角度分割功能颗 粒，这样才可以增强独立功能模块，独立服务的可复用性。 松散耦合 松散耦合使得服务获知并调用另外一个服务的同时保证二者的独立性，相互之间实现 相对独立而且接口稳定，应用面向服务的前提就是设计时注意松散耦合，这样才可以得到 敏捷的特点。 第二带着发展的观点看问题，当系统升级，我们的系统希望移植到新的平台或者我们 希望使用新的、功能更加强大的中问件时，我们可以最大限度在不影响现有的架构的情况 下以最低的成本实现这一切。 封装 封装可以得到s o a 的另外一个优点就是自治，自治需要服务暴露的逻辑在一个界限之 内，服务可以处理自我的信息。这样这个系统变动时也不依赖于其他系统。将约束条件降 到最低。封装能够使得这一个服务有独立的自主权，执行时，逻辑全都在控制范围之内， 当然这个概念不是说底层逻辑完全被该服务所拥有，因为底层逻辑可能是与其他模块公用 的，这个服务没有完全的处理权，绝对的封装和绝对的松散耦合是冲突的，所以我们应当 遵守服务层面上的自治。 接口，岁 观严格定义 设计阶段严格定义了服务的外观可以使得我们的系统处于一个相对稳定的环境。否则 南京信息工程大学理学硕士论文基于s o a 的企业系统解决方案的框架研究 后期开发都是为设计阶段的不谨慎交学费。这个契约是服务之问共享的，所以从这个层面 上我们可以说，开发小组闯相互的依赖是契约层面的，因为他们之间本不知道对方开发的 状态也不知道对方如何实现。这与面向对象中的基于接口的开发有异曲同工之妙接口的 定义是其他原则的前提，实现友善的接口才能实现s o a 无状态 服务应当保证尽量少的状态信息原因有二，第一如果保存状态，那么将加重系统的 负荷，服务器的缓存中需要保存这些信息，可能会成为系统的瓶颈，这种情况在b s ( 浏 览器朋幢务器) 架构中也会发生，a p p l i c a t i o n ( 全局变量) 和s e s s i o n ( 对象) 需要尽量少用， 或者只保存少量有用的信息，而且不该用于保存如d a t a s e t ( 数据集) 这样的重量级对象。 第二就是如果有状态，那么将会有一个对象持久化的问题，服务器和客户端需要同样 的线性化和反线性化对象的机制，否则不仅不能保证对象持久化还将引入不兼容这样的问 题。我们希望响应客户之后保存某些信息，我们也可以设计相应的机制。 当然此方案中基于w e b 服务技术，w e b 服务天性就是无状态的，我们也就避免了保证 无状态方案选择带来的苦恼。 遵守以上的几点原则，我们可以得到足够好的s