（计算机软件与理论专业论文）基于web服务的soa应用研究.pdf

基于w e b 服务的s o a 应用研究 摘要 随着信息化水平的提高，对软件的要求也越来越高。早期软件( 计算机) 的应用主要 是代替人工的计算，计算一些简单而又重复的工作，渐渐发展到对信息的处理成为主要内 容，信息化深入到各个领域。信息化给企业带来了很大的方便，各个部门开始利用网络进 行信息的公开并且实现了办公自动化，这样对软件的要求也越来越高，于是就出现了新的 问题：一是部门之间的信息共享的问题，这就需要采用基于相同的通信协议，使得信息更 为流畅；二是如何实现企业的随需而变的问题。在这样的前提下w e b 服务应运而生，w e b 服务很好的解决了信息的共享的问题；但是在解决企业的随需而变的问题中，w e b 服务就 显得不够有效。结合这时提出的面向服务的体系架构才能很好的解决了这个问题，因此基 于w e b 服务的s o a 应用研究就显得极为重要。 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 应用研究 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fi n f o r m a t i o nt e c h n o l o g y , t h er e q u e s to fs o f t w a r et e c h n o l o g y m u s tb ei m p r o v e d t h ee a r l ys o f t w a r e ( c o m p u t e r ) m a i n l yh e l p sp e o p l ed os o m er e p e a t e da n d s i m p l ew o r k s ，l i t t l eb yl i t t l e ，i tp l a y st h er o l eo f i n f o r m a t i o np r o c e s s i n ga n dg o e sd e e pi n t om a n y f i e l d s d e p a r t m e n t si ne n t e r p r i s ep u b l i s hi n f o r m a t i o na n dh o l do as y s t e mb a s e do nc o m p u t e r n e t w o r k p e o p l ed ot h i sf o ri t sc o n v e n i e n c e m o r ed e m a n d sa r ep u tf o r w a r d ，s o f t w a r ef a c e sn e w c h a l l e n g e f i r s th o ws h a r ei n f o r m a t i o na m o n gd e p a r t m e n t so re n t e r p r i s e s p e o p l ep r o v i d et h e s a m ec o m m u n i c a t i o np r o t o c o ls ot h a ti n f o r m a t i o nf l o wi sl i q u i d i t y s e c o n de n t e r p r i s ec h a n g e s t h ea p p l i c a t i o n sa c c o r d i n ga si t sd e v e l o p m e n t t om e e tt h ec h a n g e ss o f t w a r em u s tb ea g i l i t y t h r o u g hl i t t l em a i n t e n a n c ec o s t t h ec o n c e p t i o no fw e bs e r v i c ei sa d v a n c e d w e bs e r v i c e r e s o l v et h ep r o b l e mo fs h a r i n gi n f o r m a t i o n b u tw e bs e r v i c ec a n n o tr e s o l v et h ep r o b l e mo f c h a n g i n go nd e m a n d ，t h ec o n c e p t i o no fs e 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 ) i sa d v a n c e d ，a n d s e ac a nr e s o l v et h ep r o b l e mo fc h a n g i n go nd e m a n d s ow e bs e r v i c ea n ds e ac o m b i n et o s o l v et h ec u r r e n tp r o b l e m s ，w h i c hi se f f i c i e n c yi nf a c tt h ea p p l i c a t i o nr e s e a r c ho fs o ab a s e do n w e bs e r v i c eb e c o m em o r ep o p u l a r s e ad e s c r i b ea ne x c e l l e n tp e r s p e c t i v e ，b u tm a n yn e wp r o b l e m sa r ep r o d u c e dw h e nw e i m p l e m e n tt h ea p p l i c a t i o nb a s e do ns e a r e c e n t l ym a n ys o f t w a r ec o m p a n i e sa n ds t u d y i n s t i t u t e sf o c u so ns o a ，a n dp r o v i d em a n ys o l u t i o n sb a s e ds e a t h es t u d yw o r ka r ed e v e l o p i n g i nt h i sp a p e rt h ea p p l i c a t i o nr e s e a r c hb a s e do ns e ai sd e v e l o p i n ga sf o l l o w ： f i r s t l y , 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 ( s o a d ) i sd i s c u s s e d t h r o u g hc o m p a r i n g t e c t m o l o g i e s o fs o f t w a r ed e v e l o p m e n t ，w ec o n c l u d et h a tm a n yt e c h n o l o g i e sc o m b i n et or e s o l v e t h es 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 s e c o n d l y , t h r o u g hc o m p a r i n gt h es o l u t i o n so ft h ea p p l i c a t i o nr e s e a r c ho ns e a b a s e do n w e bs e r v i c e ，w ed i s c u s sas o l u t i o nb a s e do no p e ns o u r c es o f t w a r e t h i r d l y , a p r o t o t y p eo f t h es c h o o li n f o r m a t i o nm a n a g es y s t e mi si m p l e m e n t e d f r o mt h a tw e c a l lp r o v ei t sa v a i l a b i l i t y , a n dd e s c r i b et h em e t h o do fs e a d e v e l o p m e n t k e yw o r d s ：s o f t w a r ea r c h i t e c t u r 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 e a ) 。s e r v i c e - o r i e n t e d a n a l y s i sa n dd e s i g n ( s o a d ) ，w e bs e r v i c e i i 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得审侉殳太房或其他教育 机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何 贡献均已在论文中作了明确的说明并表示谢意。 学位论文作者签名：沙勘起 签字日期： ) ”7年午月以哥 学位论文版权使用授权书 本学位论文作者完全了解毒数九号有关保留、使用学位论文的规定， 有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅 和借间。本人授权序馋婶以将学位论文的全部或部分内容编入有关数据库 进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名：沙移越 签字日期：? 1 年牛月； ( 习喜 毒 + _ 。o 晒? 囝 l 薹。一 莲 勰鬻辫w # 啦科轻蹴喇褊蝴鲫h 雄k ， 嚣 。节”凰冒龋圈l 蔓 图2 1s o a 的基本架构 展现层( p r e s e n t a t i o n ) ：图2 1 中5 区，通过p o r t a l 等技术建立展现平台，方便用户 在这个界面上提出服务请求。 业务处理建模( b u s i n e s sp r o c e s sm o d e l i n g ) ：图2 1 中的4 区，s o a 元模型从m d a 中继承了平台无关模型来对业务处理过程建模。这一部分独立于服务设计和部署层。模型 驱动架构m d a ( m o d e ld r i v e n a r c h i t e c t u r e ) 的主要缺陷是在模型设计阶段就对需求有完整 的描述，而且没有需求变更的反馈机制。s o a 通过添加敏捷方法a m 来应对需求变更的情 况。 服务层( s e r v i c e s ) ：图2 1 中的3 区，整个s o a 的核心层，它承上启下，对上响应业 务模型，对下调用相关组件群完成业务需求，形成“业务驱动服务、服务驱动技术”的s o a 事务处理格局。服务可以根据粒度分层。虽然细粒度提供了更多的灵活性，但同时也意味 着交互的模式可能更为复杂。粗粒度降低了交互复杂性，但敏捷性却下降。 基于w e b 服务的s o a 应用研究 企业组件层( e n t c r p d s ec o m p o n e n t s ) ：图2 1 中的2 区，这里是相关组件发挥作用的 场所。这些组件是平台相关的。因为到了这层，许多底层软硬件平台的特性已经不再透 明了。 系统软件层( o p e r a t i o n a ls y s t e m ) ： 羽2 1 中的l 区，这一层包括操作系统、数据库管 理系统、c r m 、e r p 、商业智能( b i ) 等异构系统，是一个集成的平台。 除此之外，诸如q o s 、安全性等( 图2 1 中7 区) 也是s o a 架构的组成部分。 ( 2 ) s o a 的体系结构 s o a 的体系结构包括三个部分： 是服务提供者，一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将 自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。 服务使用者，一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对 注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口 契约来执行服务。 服务注册中心，服务发现的支持者：它包含一个可用服务的存储库，并允许感兴趣的 服务使用者查找服务提供者接口。 三者之间关系可以通过图2 2 来说明： 图2 2s o a 体系结构 8 第二章面向服务的体系架构( s o a ) 2 2 基于w e b 服务的s o a 应用基本协议 w e b 服务是建立可以互操作的分布式应用程序的平台，同时也是一套标准，定义了基 于w e b 的互操作的规范。根据这个规范，可以使用任何你习惯的语言，可以在你习惯的任 何平台上，只要基于w e bs e r v i c e 标准，就可以实现互操作。从表面上看，w e bs e r v i c e 就 是一个应用程序，它向外界暴露出可以调用的a p i 接口，而其他的应用程序可以远程调用 这个接口，我们称提供接口的一端为服务端，而调用接口的一端成为客户端。从这个意义 上说，w e b 服务不过是通过提供调用标准，实现了接口的远程调用。但是实际情况并非如 此简单理解，首先提供了分布式调用后，可以分离出服务提供方和服务消费方，这样便于 开发的时间实现协作，而且彼此松散耦合，给开发带来了方便；第二正是因为服务提供方 和消费方的分离，这样恰恰符合s o a 的理念，因此是实现s o a 的一个比较好的技术；第 三由于要实现远程调用那么面l 临新的问题，就是网络通信毕竟不能和本地调用一样，存在 网络调用中出现调用失败的问题，同时也决定了不能频繁的调用，那么这样就出现了如何 划分服务粒度的问题，这些问题又恰恰需要利用s o a 的思想进行解决。 尽管w e bs e r v i c e 是一种比较好的s o a 实现，但是s o a 和w e bs e r v i c e 之间有着根本 的区别。首先s o a 是一个体系架构，强调系统的逻辑层面的设计，而w e bs e r v i c e 则是一 种实现方法，属于技术层面的内容；其次基于s o a 思想的实现未必只有w e bs e r v i c e ，同 样基于w e bs e r v i c e 实现的应用也未必符合s o a 思想。但是目前它们的结合则具有广阔的 应用前景，因此这个部分具有重要的意义。下面从开发的角度来认识w e bs e r v i c e 的基本 协议。 2 2 1x m l x m l 即为可扩展的标记语言( e x t e n s i b l em a r k u pl a n g u a g e ) ，x m l 是一套定义语义标 记的规则，这些标记将文档分成许多部件并对这些部件加以标识。 x m l 是标记语言。理解x m l ，首先要理解标记，可以从熟悉的h t m l 的标记( m a r k u p ) 来讨论，通俗地讲，它就是一种用来给文本添加标记的语言。在h t m l 里每个标志都是有 确切含义的。例如，在h t m l 中，标签( b ) 的含义是要求h t m l 浏览器将段文本加 粗表示，而标签( c e n t e r ) 的含义是告诉浏览器将这段文本在一行的中间显示。而x m l 并非象h t m l 那样，提供了一组事先已经定义好了的标签，而是提供了一个标准，利用这 9 基于w e b 服务的s o a 应用研究 个标准，你可以根据实际需要定义自己的新的置标语言，并为你的这个置标语言规定它特 有的一套标签。准确的说，x m l 是一种源置标语言，它允许你根据它所提供的规则，制定 各种各样的置标语言。从这个意义上说x m l 是比h t m l 更抽象的一个语言，利用x m l 可以定义出类似h t m l 一样的语言来，所要做的工作就是对x m l 的部分进行定义。 x m l 具有如下的优点： ( 1 ) x m l 允许各种不同的专业( 如音乐、化学、数学等) 开发与自己的特定领域有 关的标记语言。比较早而且比较典型的是下面两个实例：化学置标语言c m l ( c h e m i s t r y m a r k u pl a n g u a g e ) 、数学置标语言m a t h m l ( m a t h e m a t i c a lm a r k u pl a n g u a g e ) 。这就使得 该领域中的人们可以交换笔记、数据和信息，而不用担心接收端的人是否有特定的软件来 创建数据。 ( 2 ) x m l 具有较好的保值性过去4 0 年来的大多数计算机数据都丢失了，不是因为 自然损害或是备份介质的磨损，而只是因为没有人来写出如何读取这些数据介质和格式的 文档。以不常用的格式保存的二进制数据，数据也许会永远地消失了。x m l 在基本水平上 使用的是非常简单的数据格式。可以用1 0 0 的纯a s c i i 文本来书写，也可以用几种其他 定义好的格式来书写。 ( 3 ) 应用间交换数据由于x m l 是非专有的并易于阅读和编写，就使得它成为在不同 的应用间交换数据的理想格式x m l 使用的是非专有的格式，不受版权、专利、商业秘密 或是其他种类的知识产权的限制。x m l 的功能是非常强大的，同时对于人类或是计算机程 序来说，都容易阅读和编写。因而成为交换语言的首选。 ( 4 ) x m l 还具备简单数据库的功能，可以用来保存和检索数据，可以作为一个小型 的数据库使用，这个可以说超出了一般语言的范畴。 x m l 文件的整体结构。x m l 文件包括三部分：x m l 声明、处理指示( 可选) 、x m l 元素。x m l 文档的一个基本要求是形式良好的( w e l lf o r m e d ) ，一个形式良好的x m l 文档 要包含这三个部分。一个完整的x m l 文件如下： 0 第二章面向服务的体系架构( s o a ) 其中 对此文件进行了声明，说明了属于x m l 文件，同时告诉了编码格式。 则是处理 指示，告诉了本文件的类型，从而便于告诉处理器处理本文件实用哪个程序。接下来的则 是元素。从这个例子中，可以简单体现如下内容：一是可以存储数据，事实上这个文件就 储存了有意义的数据：二是经过转换又可以被浏览器通过不同的形式实现显示；三是内容 便于阅读，也就是说就算没有了处理程序，甚至这个文件出现了损坏，仍然从中可以理解 这个文件所要表达的内容。正因为如此x m l 作为w 曲s e r v i c e 的交换基础，可以便于交换 的规范性，便于广泛的应用。 2 2 2s o a p s o a p ( s i m p l e o b j e c t a c c e s sp r o t o c 0 1 ) 简单对象访问协议是在分散或分布式的环境中 交换信息的简单的协议，是一个基于x m l 的协议【7 1 。它包括四个部分： s o a p 封装( e n v e l o p ) ；封装定义了一个描述消息中的内容是什么，是谁发送的，谁应 当接受并处理以及如何处理它们的框架。 s o a p 编码规则( e n c o d i n g m l e s ) ：用于表示应用程序需要使用的数据类型的实例。 s o a pr p c 表示( r p cr e p r e s e n t a t i o n ) ：表示远程过程调用和应答的协定。 s o a p 绑定( b i n d i n g ) ：使用底层协议交换信息。 s o a p 采用了已经广泛使用的两个协议：h t t p 和x m l 。其中h t t p 用于实现s o a p 的r p c 风格的传输，而x m l 是它的编码模式，一个s o a p 请求实际上就是一个h t t p p o s t 请求。其消息格式如图2 3 所示。 基于w e b 服务的s o a 应用研究 2 2 3w s d l 图2 3s o a p 消息格式 已经有了s o a p 协议，就解决了如何进行通信的问题。因此下一步就是要解决通信内 容的问题，其实也就是如何描述w e b 服务，这就是w s d l ( w e bs e r v i c e sd e s c r i p t i o n l a n g u a g e ) ，包括参数的传递和结果的返回等内容，而它本身是由x m l 定义的，是一种 x m l 文件。目前w s d l 2 0 已经成为标准，并获得了广泛的支持。i s w s d l 就是描述w e b 服务的标准x m l 格式，它用一种和具体语言无关的抽象方式定 义了给定w e b 服务收发的有关操作和消息。为更好理解w s d l 是如何工作的，首先描述 s o a p 和h t t p 是如何使用w s d l 工作的。w s d l 的用途是“描述”w 西服务。业务 之间将通过交换w s d l 文件来理解对方的服务，可以将服务看作是通过s 0 a p 访问的对 象。 w s d l 文档将服务定义为网络端点或端口的集合。在w s d l 中，由于端点和消息的 抽象定义已从具体的网络部署或数据格式绑定中分离出来，因此可以对抽象定义进行再次 使用：消息，指对交换数据的抽象描述；而端口类型，指操作的抽象集合。用于特定端口 类型的具体协议和数据格式规范构成了可以再次使用的绑定。将网络地址与可再次使用的 绑定相关联，可以定义一个端口，雨端口的集合则定义为服务。因此，w s d l 文档在网络 服务的定义中使用下列元素： t y p e s 一数据类型定义的容器，它使用某种类型系统( 如x s d ) 。 m e s s a g e 一通信数据的抽象类型化定义。 第二章面向服务的体系架构( s o a ) o p e r a t i o n ，对服务所支持的操作的抽象描述。 p o r t t y p e 操作的抽象集合，这些操作由一个或多个端点支持。 b i n d i n g 特定端口类型的具体协议和数据格式规范。 p o r t 定义为绑定和网络地址组合的单个端点。 s e r v i c e 相关端点的集合。 可以说w e b 服务的开发就是围绕w s d l 进行的，因此充分理解和使用w s d l 是进行 w e b 服务开发的基础。而编写w s d l 的过程就是填写以上六个部分。 应该注意的是，w s d l 并没有引入新的类型定义语言。虽然w s d l 知道，要描述消 息格式需要丰富的类型系统，并且它也支持“x m l 架构规范( x s d ) ”作为其标准类型系 统，但是，由于不可能只用一种类型系统语法来描述现在和将来的所有消息格式，因此 w s d l 允许通过扩展来使用其它类型定义语言。 此外w s d l 还定义了通用的绑定机制。通过该机制可使特定的协议、数据格式或结 构与抽象的消息、操作或端点相关联。该机制还允许对抽象定义进行再次使用。虽然本文 档定义了上述语言扩展，但这些扩展均位于核心服务定义框架的上部，所以能将w s d l 与 其它绑定扩展一起使用。 2 2 4u d d i 统一描述、发现和集成协议( u d d i ，u n i v e r s a ld 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 e b 的、分布式的、为w e b 服务提供的信息注册中心的实现标准规范，同时也包 含一组使企业能将自身提供的w e b 服务注册以使得别的企业能够发现的访问协议的实现 标准。 9 , 1 0 , 1 1 】 u d d i 解决了企业遇到的大量问题。首先，它能帮助拓展商家到商家( b 2 b ) 交互的 范围并能简化交互的过程。对于那些需要与不同顾客建立许多种关系的厂家来说，每家都 有自己的一套标准与协议，u d d l 支持一种适应性极强的服务描述，几乎可以使用任何接 口。规范允许企业在注册中心中发布它所提供的服务，这样发现企业及服务就变得高效而 且简单了。对于b 2 b 交易场所提供者，他们需要获得这一行业内的供应商的分类数据， 以及它们与计费服务、包装商、运输商、保险公司等之间的关系，u d d i 允许动态发现相 关的w e b 服务并将其集成到聚合的业务过程中。u d d t 提供一站式搜索有关企业和电子 化服务的信息。在u d d i 中发布企业与服务信息使其它企业能大范围的访问到这些信息。 基于w e b 服务的s o a 应用研究 u d d i 包含于完整的w e b 服务协议栈之内，而且是协议栈基础的主要部件之一，支 持创建、说明、发现和调用w e b 服务。u d d i 构建于网络传输层和基于s o a p 的x m l 消息传输层之上。诸如w e b 服务描述语言提供了统一的x m l 词汇，供描述w e b 服务 及其接口使用。如图2 4 所示。 w s f 屯 图2 4u d d i 的分层w e b 服务协议栈 u d d i 服务器产品。j u d d i 是一个开放的基于j a v a 的u d d ! 实现，它包括如下特征： 开源产品；平台的独立；支持j d k l 3 1 以后的产品；支持u d d l v 2 ；可以用任何关系数据 库，如m y s q l ，d b 2 ，s y b a s e ，j d a t a s t o r e ，h s q l d b 等；可以部署在任何基于j a 、，a 的应用 服务器上，如j a k a r t at o m c a t , j o n a s ，w e b s p h e r e ，w e b l o g i e ，b o r l a n de n t e r p r i s es e r v e r , j r u n 等；支持集群构造；很容易和已存在认证系统交互，目前已经发展到0 9 r e 4 版。 u d d i 服务器的建立。u d d i 服务器本质上就是一个简单的数据库，其中存放着w s d l 文件的相关内容。u d d i 服务器在w i n 2 0 0 3 中默认安装，因此可以说建立此类服务器是很 容易的事情，j u d d i 是服务器的实现，参考h t t p ：w s a p a c h e o r g j u d d i ，其服务器设置步骤 主要是：首先安装数据库，然后创建相关表即可。j u d d i 下载后，包括s q l 目录，按照对 应的数据库，其中包括了建立数据库的s q l 文件，通过此文件可以建立数据库，然后通过 其目录下的j u d d i w w 文件直接拷贝至l j w e b a p p s 下即可使用，通过 h t t p ：l o c a l h o s t ：8 0 8 0 j u d d i 可以进行访问和管理。 4 第二章面向服务的体系架构( s o a ) 2 2 5e s b 企业服务总线e s b ( e n t e r p r i s es e r v i c eb u s ) 是s o a 架构的一个支柱技术。作为一种 消息代理架构它提供消息队列系统，使用诸如s o a p 或j m s ( j a v am e s s a g es e i c c 、等标准 技术来实现。e s b 的主要功能有：通信和消息处理、服务交互和安全性控制、服务质量和 服务级别管理、建模、管理和自治、基础架构智能等。如图2 5 所示： 图2 5 e s b 基本架构 e s b 的体系结构。e s b 主要由服务网关( s e r v i c e ga t e w a y ) 、服务适配器( s e i c e a d a p t o r ) ， 服务目录( s e r v i c er e g i s t e r ) 等三个主要部分组成： 1 ) 服务网关是e s b 中的核心组件，它的主要职责是负责服务的路由和交互。 2 ) 服务适配器是e s b 的重要组成部分，它担负着服务和消息的协议转换工作，以实现 不同协议格式的服务间的交互。 3 ) e s b 还需要某种形式的服务目录来为服务路由提供帮助。然而，s o a 可能还有单独 的业务服务目录，其最基本的形式可能是设计时的服务目录，用于在组织的整个开发活动 中实现服务的重用。w e b 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 u d d i 目录，从而可以动态发现和调用服务，这样的目录可以视为e s b 的一部分。 e s b 的主要应用模式分别是： 1 ) 协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情 形 2 ) 消息广播模式，用于事件驱动多个动作或者消息广播的情形 3 ) 服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容， 基于w e b 服务的s o a 应用研究 或负载情况，或服务级别约定，来为服务请求者选择合适的服务。 目前e s b 方面也有了丰富的开源产品，例如：m u l e e s b 、o p e n e s b 以及a p a c h e c x f 等。但是现在e s b 也面临一些问题，随着s o a 应用规模的增长，一个大企业的s e r v i c e 几十甚至成百上千，不同s e r v i c e 可能部署到不同厂商的c o n t a i n e r ( e s b ) ，安装在不同的地 点( 如北京和纽约，或北京上海) ，不同s e r v i c e 有不同的访问权限，不同的s e r v i c e 有不同 的p o l i c y ( 日志级别，安全，权限，传输和协议) ，怎样管理s e r v i c e 及其属性，怎样方便的 查找和发现s e r v i c e 等等，这些问题就浮出水面，迫在眉睫。这催化了s o a 治理、策略 ( p o l i c y ) 和s o a n e t w o r k 、s o a r e p o s i t o r y 的兴起，这时提出了s o a 治理的概念，就是说 一个服务的创建到废弃，都需要责任管理，否则就会出现一个服务已经不再使用了，而此 时调用者还不知道。【1 3 1 2 2 6b p e l w e b 服务的业务流程执行语言( b u s i n e s sp r o c e s se x e c u t i o nl a n g u a g ef o r w e bs e r v i c e s ， b p e l 4 w s ) 规范，其定位是成为整合方面的w e b 服务标准。b p e l a w s 支持两种截然不 同的使用情形：实现可执行的业务流程，描述不可执行的抽象流程。作为可执行流程的实 现语言，b p e l 4 w s 的作用是将一组现有的服务整合起来，从而定义一个新的w e b 服务。 b p e i a w s 基本上是一种实现这样的整合的语言。与其它任何w e b 服务一样，整合服务 的接口也被描述为w s d lp o r t t y p e 的集合。整合( 称为流程) 指明了服务接口与整合的 总体执行的配合情况。图2 6 说明了从外部看到的b p e i a w s 流程的上述情况。b p e i a w s 中出现的整合原语主要来自于工作流和业务流程集成方面多年的经验，b p e i a w s 的定位 是成为一种业务流程整合语言。因此就涉及如下几方面内容： 一是实现服务。不同于用传统的编程语言来实现w s d l 服务，每个p o r t t y p e 的每项 操作并不映射成b p e l 4 w s 中的一个独立的逻辑块。服务的整个类型( 即该服务的 p o r t t y p e 集合) 由单个b p e l 4 w s 流程实现。 二是伙伴。作为一种用来将一组服务组合在一起以形成一个新的服务的语言， b p e i a w s 流程由向其它服务提出调用或接收来自客户机的调用组成。前者通过使用 活动来做到，后者则通过使用 和 活动来做到。b p e i a w s 把 与流程交互的其它服务称伙伴( p a r t n e r ) 。这样，伙伴或者是流程将其作为算法的一个主要 部分进行调用的服务( 被调用的伙伴) ，或者是那些调用流程的服务( 客户机伙伴) 。 第= 章面向服务的体系架构( s o a ) 图2 6b p e l 4 w s 流程实现的w e b 服务的视图 三是服务引用。伙伴在运行时是的工作。为了能够在运行时工作，伙伴必须解析成实 际的w e b 服务。这样，伙伴实际上最后就是一个有类型的服务引用而已，其类型信息来 自服务链接类型和角色。b p e i a w s 流程本身不指定伙伴如何绑定到特定服务；人们认为 这是一个部署时或运行时的绑定步骤，这个绑定步骤必须被b p e l 4 w s 实现支持。 四是服务的生命周期。与传统的分布式对象系统不同，b p e l 4 w s 实例不是通过工厂 模式创建的。相反b p e l 4 w s 中的实例是在服务的消息到达时隐式地创建的。 业务流程可以特定于某个领域或行业，如保险索赔流程。行业联盟定义行业业务流程。 例如，电信管理论坛( t e l e m a n a g e m e n t f o r u m ) 为电信行业定义增强的电信运营图( t e l e c o m o p e r a t i o n sm a p ，e t o m ) 。从这个意义上讲业务流程的制定，其逻辑部分主要来自所在行 业的领域专家。由于业务流程很好的对行业进行了业务概括，在这样的前提下可以理解为 成熟的业务流程相当于咨询公司的模版。【1 4 ，嘲 2 3 本章小结 本章主要站在开发的角度介绍了s o a 和w e b 服务的相关概念，同时重点介绍了w e b 服务的基本协议，包括x m l 、s o a p 、w s d l 、u d d i 、e s b 、b p e l 。这个部分是基于w e b 服务的s o a 应用的基础：一方面便于对s o a 框架的理解，另一方面为进步的开发奠定 基础。 基于w e b 服务的s o a 应用研究 第三章基于s o a 应用的解决方案 3 1 软件开发方法的演化 软件开发方法( s o f t w a r ed e v e l o p m e n tm e t h o d ) 是指软件开发过程所遵循的办法和步骤。 软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档， 并且满足有关的质量要求。软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是 软件开发方法学，指的是规则、方法和工具的集成，既支持开发，也支持以后的演变过程 ( 交付运行后，系统还会变化，或是为了改错，或是为了功能的增减) 。典型地都包含了以 下的过程或活动：分析、设计、实现、确认( 测试验收) 、演化( 维护) 。 有些软件开发方法是专门针对某一开发阶段的，属于局部性的软件开发方法。特别是 软件开发的实践表明，在开发的早期阶段多做努力，在后来的测试和维护阶段就会使费用 较大地得以缩减。因此，针对分析和设计阶段的软件开发方法特别受到重视。其它阶段的 方法，从程序设计发展的初期起就是研究的重点，已经发展得比较成熟。除了分阶段的局 部性软件开发方法之外，还有覆盖开发全过程的全局性方法，同样是软件开发方法学的重 点。 在六十年代末期提出了软件危机的概念，并因此提出了非常有纪律性的方法即软件工 程学，试图从电子工程学、技术工程学提炼出一些东西来用于软件工程学，他们想从中提 炼出一种方法，使得软件开发的流程更有预测性，这种工程学的方法一直为大家普遍使用。 但软件业的人在做软件的过程中发现这些方法并没有减少软件开发过程中遇到的问题，对 于这种现象有很多解释。近年来有人发现软件工程学里一些基本的假设是不正确的，并提 出了一些新的开发方法，统称为敏捷式开发。 敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方法。敏捷式开发 是以人为主的，而传统的工程学是以过程为主的。0 7 1 适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学 里，核心的概念就是把设计和构建这两个过程分开进行。最开始一个阶段叫设计阶段，在 这个阶段所有和软件设计相关的重要决定就已做出了，而且以完整的形式描述出来。这项 工作通常是由专业人员来做，而且所花的时间和精力在整个项目中占着很小的一部分。这 第三章基于s o a 应用的解决方案 项工作完成以后，这些设计的结果，从建筑学的角度就被“建筑公司”拿去，按照设计的 结果一步步构建。在描述清晰的设计图纸的基础上，你就可以据此对构建过程进行详细的 规划，并进行成本的预测。 在软件开发的过程中，需要把设计和编程完全区分过来。软件工程学领域，所有在这 里从事工作的人员，都把设计的过程想象成用图表、图象的方式来描述结果的过程。很多 人都有这样的经验，没有经过编程而是直接想象出的设计，在进入编程阶段有很多地方是 错误的，需要改正。还有一个更重要的问题就是，软件本身的需求是在变化的。一个项目 在开发过程中需求会出现变化，需求的变化从根本上推翻了工程学方法所建立的一个基 础。而敏捷式开发方法则能达到比较好的效果。 3 2 常用开发技术 3 2 1m v c m v c ( m o d e l v i e w - c o n t r o l l e r ) 是一种目前广泛流行的软件设计模式，即把一个应用 的输入、处理、输出流程按照m o d e l 、v i e w 、c o n t r o l l e r 的方式进行分离，这样一个应用被 分成三个层模型层、视图层、控制层。 视图( e w ) 代表用户交互界面，对于w e b 应用来说，可以概括为h t m l 界面，但有可 能为x h t m l 、x m l 和a p p l e t 。随着应用的复杂性和规模性，界面的处理也变得具有挑战 性。一个应用可能有很多不同的视图，m v c 设计模式对于视图的处理仅限于视图上数据 的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理 由模型( m o d e l ) 处理。 模型( m o d e l ) ：就是业务流程状态的处理以及业务规则的制定。业务流程的处理过程 对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型 的设计可以说是m v c 最主要的核心。目前流行的e j b 模型就是一个典型的应用例子，它 从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作 为应用设计模型的框架，它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减 少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。m v c 设计模式 告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人 员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。m v c 并没有提供模型 1 9 基于w e b 服务的s o a 应用研究 的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。 业务模型还有个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保 存( 持续化) 。比如将张订单保存到数据库，从数据库获取订单。我们可以将这个模型 单独列出，所有有关数据库的操作只限制在该模型中。 控制( c o n t r o l l e r ) 可以理解为从用户接收请求，将模型与视图匹配在一起，共同完成用 户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么 样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处 理。例如，用户点击一个连接，控制层接受请求后，并不处理业务信息，它只把用户的信 息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能 对应多个视图，一个视图可能对应多个模型。 其优点表现为：分层的思想实现了松散耦合，有利于开发中的分工，有利于组件的重 用。 3 2 2i o c 控制反转模式( i n v e r s i o no f c o n t r o l l 意味着将设计好的类交给系统去控制，而不是在类 内部控制。这个概念的似乎让人难以理解，但是这个概念的本身内涵并不新鲜，因为操作 系统从文字界面到图形界面，就出现了控制权交给框架管理，而不是程序内部类自己管理 了，例如我们的鼠标和键盘以及其他事件，都对应着各自的操作，从这个意义上讲基于事 件触发的就具备了控制反转的内涵。但是控制反转真正引起重视则是在结合了j a v a 中的工 厂这个概念后。可以把i o c 模式看做是工厂模式的升华，可以把i o c 看作是一个大工厂， 只不过这个大工厂里要生成的对象都是在x m l 文件中给出定义的，然后利用j a v a 的“反 射”编程，根据x m l 中给出的类名生成相应的对象。从实现来看，l o c 是把以前在工厂方 法里固定的对象生成代码，改变为由x m