（电工理论与新技术专业论文）基于web+service的eai框架研究.pdf

硕士毕业论文 a b s t r a c t b a s e do n a l y s i n go ft h ed e m a n do ft h ee n t e r p r i s ef o ri n f o r m a t i o ns y s t e mi n t e g r a t i o n t h i s p a p e rb u i l d s a ne a if r a m e w o r kb a s e do nw e bs e r v i c et e c h n o l o g y , w h i c hi n d u c tt oal o o s e c o u p l i n gs y s t e mw h i c h i sb u i l do nq u e r y i n g ，b i n d i n ga n di n v o k i n gm e c h a n i s m e n t e r p r i s e sc a n s e t u pt h e i ri n t e g r a t e da p p l i c a t i o n se a s i l yi ns u c haf r a m e w o r k ，w h i c ha l s op r o v i d e sas i m p l ea n d e a s ym e a n s t ob u i l dt h ed y n a m i cs u p p l y - c h a i na n dv i r t u a le n t e r p r i s ea p p l i c a t i o n s i ta l s od i s c u s s e st h a tt h em o d e lo f e n t e r p r i s ei n t e g r a t ea p p l i c a t i o na n di m p l e m e n to fl e g a c y s y s t e mw r a p a f t e ra n a l y s i n gt h ej o bc o u r s eo fe a i sf r a m e w o r k ，i ti sc o n d u c e dt h a tt h ec o r eo f s u c haf r a m e w o r ki st h e d a t a - e x c h a g es u b s y s t e m a n dw o r k f l o w s y s t e m i na d d i t i o n ，a f t e r a n a l y z i n gt h ep u r p o s eo fd a t a - e x c h a g es u b s y s t e ma n dw o r k f l o ws y s t e m ，t h i sp a p e r a l s og i v e st h e m o d e l sa n d s a m p l ec o d e so f t h et w os y s t e m sm e n t i o n e da b o v e k e y w o r d s ：w e bs e r v i c e ，e a i ，s o a p ，w s d l ，u d d i ，x m l ，s u p p l yc h a i n ，v i r t u a le n t e r p r i s e w o r k f l o w 学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得东南大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 签 艘 关于学位论文使用授权的说明 东南大学、中国科学技术信息研究所、国家图书馆有权保留本人所送交学位 论文的复印件和电子文档，可以采用影印、缩印或其他复制手段保存论文。本人 电子文档的内容和纸质论文的内容相一致。除在保密期内的保密论文外，允许论 文被查阅和借阅，可以公布( 包括刊登) 论文的全部或部分内容。论文的公布( 包 括刊登) 授权东南大学研究生院办理。 级季、哆日 硕士毕业论文 第一章课题背景 伴随着经济全球化的发展企业需要在全球范围内展开竞争与合作。企业已经不满足 于信息系统仅仅能提供局部业务的计算机化处理。企业需要在更大的范围内( 艇个企业内 部其至整个供应链) 实现信息的共享，以提高企业的丁作效率，提升自己的竞争优势。显 而易见，企业不可能完全抛弃现有应用，这种付出是昂贵且带有极大风险的。因此如果能 够利用现有的集成设施和应用进行信息系统的改造和集成将是至关重要的。另外，山于优 化资源配置等目的，企业不可避免的需要进行并购、重组，如何使原来孤立的系统协同工 作也是一个重要问题。 在上述情况下，企业应用集成( e n t e r p r i s e a p p l i c a t i o ni n t e g r a t i o n ) 呈现出重要的作用。 e a i 使得企业将现有应用和建立在新技术基础上的应用融为一体，还能使企业的业务处理 过程模型化和自动化【1 】。 1 1 企业应用集成的目标 企业应用集成对于不同的企业角色有着不同的含义，当然从他们的角度也有不同的目 标但是企业的各个运行( 生产) 环节不可分割，应该作为一个整体考虑。 从企业的最高层来看，绝大多数企业进行企业应用集成的战略目标都是降低成本、提 高效率并可以对市场和机遇作出快速反应。为了达到这个目标，在进行企业应用集成时， 必须首先着眼于欧期的效益分析企业的应用集成目的。从技术的角度，企业应用集成的设 计目标有以下几个【1 】： 1 适应性的系统和过程。由于技术变革、全球化等因素，导致了企业所面临的环境 是快速变化的且面临着激烈的竞争或者由于重组等导致企业自身产生变化，所 以企业的应用系统和过程必须能够适应这种变化。而且在很多的企业中，应用系 统是和企业的业务过程紧密结合的，一旦企业的业务流程发生变化，相应的计算 机系统也必须发生变化。这同样要求系统和过程的再开发。从长远来看，变化是 必然的，如果企业应用系统不能适应这种变化，那么就必将遭到淘汰。从这一点 来说，系统和过程的可适应性是e a i 的最主要设计目标2 2 】。 2 有效的信息管理。企业的信息来源是广泛的，而且是多种多样的。信息反映着企 业内部和外部的变化，反映着企业物流和资金流的情况，企业的运行需要信息的 指导，同时也为控制质量和成本提供了依据。所以企业应用系统必须能够保证： 数据的一致性、及时准确性、可访阃性( 共享) 、规则一致性、处理( 过程) 一致 性，同时必须能够提供异常报告和对历史数据的分析。 3 对电子商务的支持。i n t e r n e t 的快速发展使得电子商务成为企业集成中的重要方 面。电子商务使得企业的信息系统得以延伸至上下游企业和最终消费者。电子商 务的无论采用什么样的形式，它必须在i n t e r a c t 上进行，这是对电子商务的一个 重要的外部约束。从消息的角度看，电子商务可以看作是数据的交换过程，当然 这种数据交换需要一系列的规则来约束 2 3 1 。 4 一体化的安全性。基于i n t e r n e t 的数据流动带来了新的安全问题，由于w e b 服务 器连接在i n t e r n e t 上并可以被任何人访问，而且为了在企业之间更方便地进行协 作，企业的业务系统也需要提供远程调用的能力，这带来了更多的危险。所以安 全性必须作为一个整体性的要求提出。安全性的要求必须具备以下的一些要素： 硕士毕业论文 验证、授权、完整性、保密性和不可否认性 7 】。 5 开放的标准化。由于应用系统是处于变化的环境中，随着环境的改变系统也需要 变化。在系统的重新构建( 或再开发) 的时刻，标准化是最为重要的需求之一。 在这一点上，无论是理论研究和工程实践的过程中都是有着深刻体会的。另外从 软件的发展趋势看，从蘸结构化到结构化再到面向对象的设计方法都是在使用黑 箱的系统描述方式，接下来必然是从面向对象向对象的协作发展，分布式的组件 技术就是一个明显的证明，而本文中e a i 框架的基础w e bs e r v i c e 更是表明了这 种趋势所以软件的开放性也非常重要。 当然作为软件系统的一些其他必备的特性或者设计目标也是必须的，如可靠性、可恢 复性、高效等要求。 1 2 企业应用集成的层次需求 从管理的角度，企业的集成可以分为若干个层次参见图t - 1 。 图卜l 从管理角度的企业集成的层次 无需多言，当今的软件系统的最大特征就是面向对象技术的应用，面向对象的实际表 现就是组件技术。在图l - l 中，应用组件组成了业务应用。它是整个企业系统的基础，同 时它在企业内部是分布式计算的基础。这样的组件可以使用不同的语言实现。目前实现分 布式组件有三个主要的规范【3 】：e j b ( e n t e r p r i s ej a v ab e a n ) 、c o r b a ( c o m m o no b j e c t r e q u e s t b r o k e r a r c h i t e c t u r e ) 和c o m i d c o m ( c o m p o n e n t o b j e c t m o d e l d i s t r i b u t e d c o m ) 。 以后还会谈到，对于早期的遗留系统( l e g a c y ) ，我们可以采用封装或者适配器的模式形成 这种组件。业务应用完成了某个特定的业务段，如确认订单这一动作。应用一套业务流程 逻辑就可以将业务应用组成一个完整的业务流程，如客户提交订单一订单确认一付款、出 票一发货。同时，业务应用也组成了企业的业务系统域内的应用，在整个业务系统域内需 要达到一个基本的信息共享并且必须在这个域内管理业务进程来达到特定域的需要，如 财务部。一个企业显然内部包含了很多的业务域，也包含了很多的业务进程。一个业务系 统域可以调用其他业务系统域内的业务应用，这样才实现了企业的正常业务流转，如客户 的订单需要在销售部门确认。而付款、出票的工作是在财务部实现的。这种相互的调用表 现了业务的逻辑，在已往的应用系统中业务逻辑往往是由程序所确定的，现在也可以使用 2 硕士毕业论文 工作流系统来实现，关于工作流请参见第四章。若干个企业出于商业目的的需要，要求组 成虚拟企业，或者说企业要求和其他社会资源相互整合，形成优势互补实现资源的合理 配置。但是就实际的系统集成来说，企业内部已经形成了单个的系统，企业必须保护自身 的系统和信息以防【上来自外部的不利操作造成的损害，同时利t ； j 虚拟企业内的灵活性加强 联系【1 0 】。 图1 1 的这种层次的划分表示了企业信息系统的作用范围，而作用范围是和这个范围 内的目标相联系的。这种划分的方法更容易被企业内部人员接受。 1 3 企业应用集成的总体特征 以上两节分析了从技术角度进行企业应用集成的设计目标、从管理角度给出了企业对 丁- 应用集成的层次需求。下面根据上述的设计目标和层次需求具体分析企业应用集成应该 具有的特征。 1 分布式计算。由于集成在企业内部及虚拟企业的范围内进行，不可避免地需要支 持分布式的计算模式。大中型企业可能更需要分布式计算的环境。分布式计算的 优点是可扩展、适应企业的地区性要求 6 】。 2 跨平台。由于企业的遗留系统可能建立在各种各样的平台之上，所以跨平台也是 进行企业应用集成的必然要求。所谓的平台包括：网络系统、操作系统、数据库 系统。由于t c p i p 协议早已成为互联网的标准所以网络平台的差异几乎可以忽 略。但其前提条件是系统必须建立在t c p n p 协议上，具体采用何种应用层协议 ( h t t p 、s m t p 、f t p 等) 可视具体要求而定。由于h t t p 协议的良好穿透网络 的能力和x m l 对于h t t p 的支持，可以将h r r p 协议作为标准。由于x m l 本身 具有的跨平台能力和各种主流数据库系统对x m l 的支持，x m l 可以作为跨平台 的实现手段。 3 基于组件。基于组件意味着可以通过结合可替换、可共享的模块来构造和修改应 用程序。这是快速适应变化环境的必然要求。 4 事件驱动。虽然事件驱动已经成为面向对象设计方法的基本要义，但还有必要强 调一f 事件驱动在业务流程中的作用。事件提供了这样的一种机制：在满足条件 的情况下，可以迅速地处理。例如当客户_ f 达订单时，待处理的订单应马上由某 种方式通知相关人员进行处理，而不是等待相关人员查询未处理的订单，这样提 高了企业的响应速度【2 l 】。 5 松耦合。松耦合是指在通信异步的条件下处理业务流程并连接应用程序，即服务 请求不是马上处理并返回结果的。由于网络的复杂性和有限的资源，在分布式的 计算模式下各种调用必须是松耦合的。事实上，由于t c p i p 协议本身是无连接且 异步的，所以严格意义的同步在企业的网络环境中根本就不存在。已往应用中所 谓的建立连接只不过是服务器端指定了若干资源为某个客户端服务，而客户端在 等待服务的结果。这种连接耗费了服务器和客户端的资源，在复杂的企业环境中， 这造成了对服务器资源的巨大需求，而且是几乎不可能实现的。在松耦合的情况 下为了处理大量的服务请求，对丁：任务队列的管理是必须的。 6 基于工作流机制。工作流机制( 系统) 实现了业务过程的自动流转。而且可以轻 松地适应企业外部或内部的变化。提高了企业的响应速度。另外，工作流使得所 有的工作都是可管理的，若系统的状态发生变化可以很快适应。 硕士毕业论文 上述的分析并不是所有的企业应用集成的特征，但是可以得出两点肯定的结论 1 企业应用集成应该建立在基于x m l 的数据交换基础上。 2 企业应用集成同时应有，l ：作流系统管理企业的业务流程。 这两点的具体实现将在第五章中具体讨论。 4 硕：毕业论文 第二章w e bs e r v ic e 体系结构与相关技术 2 1w e bs e r v i c e 概述 根据w 3 c 的定义，所谓的w e bs e r v i c e 就是指支持网络上计算机之间互操作的软件系 统。这种软件系统有个可以由计算机识别的接u ( 即使用w s d l 描述的) 。其他的系统l w e bs e r v i c e 使用s o a p 消息中描述的方式进行互动，这些s o a p 消息在使用其他相关w e b 标准进行x m l 串行化之后一般通过h t t p 协议在网络r 传输。 w e bs e r v i c e 体系结构基于i 种角色( 服务提供者p r o v i d e r 、服务注册中心r e g i s t e r 和服 务请求者r e q u e s t o r ) 之问的交互。交互涉及发布、查找和绑定操作 8 。 - 服务提供者。从企、眦的角度看，这是服务的所有者。从体系结构的角度看，这是托 管问服务的平台。 _ 服务请求肴。从食业的角度看，这是要求满足特定功能的企业。从体系结构的角度 看，这是寻找并调用服务，或启动与服务的交互的应用程序。服务请求者角色叫以 由浏览器来担当，由人或无用广界面的程序( 例如，另外一个w e bs e r v i c e ) 来控 制它。 一 服务注册中心。这是可搜索的服务描述注册中心，服务提供老在此发布他们的服务 描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑 定信息( 在服务描述中) 。对于静态绑定的服务请求者，服务注册中心是体系结构 中的可选角色，因为服务提供者町以把描述直接发送给服务请求者。同样，服务请 求者可以从服务注册中心以外的其它来源得到服务描述，例如本地文件、f t p 站点、 w e b 站点等。 在典型情况下，服务请求者使用查找操作从服务注册中心检索服务描述，然后使用服务 描述与服务提供者进行绑定并调用w e bs e r v i c e 实现或同它交互。图2 ，1 表示了这三种角色 和。b s 4 f 之问的交互过程。 图2 - 1w e bs e r v i c e 的角色和它们之问的交互 如图2 - 1 中所示，w e bs e r v i c e 的构件包括服务和服务描述。 8 一 服务。在这里，w e bs e r v i c e 是一个南服务描述来描述的接l ，服务描述的实现就 是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问 硕士毕业论文 的平台上。服务存在就是要被服务请求者调用或者同服务请求者交互。当服务的实 现中利用剑其它的w e bs e r v i c e 时，它也可以作为请求者。 服务描述。服务描述包含服务的接口和实现的细节。其中包括服务的数据类型、操 作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其 它元数据。服务描述可以被发布给服务请求者或服务注册中心。 w e bs e r v i c e 的概念协议栈可以用图2 - 2 米描述【9 。 图2 - 2f e bs e r v i c e 的概念协议栈 w e bs e r v i c e 的应用在底层使用h t t p 、f t p 等己普遍使用的协议，这些协议可以轻松穿 越网络上的防火墙。另外，采用这些协议使得i n l r a n e t 和i n t e m e t 的服务开发可以使用统一 的编程模型，网络协议和技术的选择对于开发者来说是透明的。 在网络层之上w e bs e r v i c e 使用基于x m l 的消息协议s o a p ( s i m p l eo b j e c ta c c e s s p r o t o c 0 1 ) 。s o a p 由三部分组成：一个使用x m l 信封来描述消息内容的机制、一组编码各 种类型数据的编序规则和一个提供远程过程调用( r p c ) 和响应的机制。 w s d l ( w e bs e r v i c ed e s e r i p tl a n g u a g e ) 也是基于x m l 的，它描述了服务的实现和接 口。在服务发现、集成层次上使用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 ) 进行描述。u d d i 提供了一种发布和查找服务描述的方法。u d d i 数据实体提供对定义业务 和服务信息的支持。w s d l 中定义的服务描述信息是u d d l 注册中心信息的补充。 w s f l ( w e bs e r v i c ef l o w l a n g u a g e ) 是协议栈顶层的服务工作流( 它是i b m 公司所制 定的一个规范，目前已提交w 3 c ，但尚未成为标准) ，w s f l 针对商务流程建模和：作流描 述了w e bs e r v i c e 在工作流中如何相互作用以及它们如何处理服务的协同和通信的问题 9 】。 另外，由于w e bs e r v i c e 应用不需要建立任何固定或虚拟连接，所以基于w e bs e r v i c e 的应用是松散耦合的。为了保证在松散耦合的条件f 的对象访问，必须使用其他的方式来管 理服务的过程、保证服务质量并且确保安全性和事务性1 9 1 。 从图2 - 2 中可以看出w e bs e r v i c e 是由一组脱离应用平台的协议定义的。这种平台无关 性为基于w e bs e r v i c e 上企业应用集成的最大优势，在进行e a i 的过程中无需再为各种平台 ( 操作系统、数据库管理系统等) 编写各种各样的接e l ；另外，这种平台无关性同时为在进 行企业应用集成时的平台选择提供了很大的灵活性。其次，w e bs e r v i c e 是基于x m l 的， x m l 的晟大优势在于x m l 的文档是自描述的跨平台的文档。这使得无论在任何平台上解 析x m l 文档时，格式的定义是简单而严格的。 6 硕士毕业论文 2 2s o a p 2 2 1s o a p 简介 s o a p ( s i m p l eo b j e c ta c e sp r o t o c 0 1 ) 简单对象访问协议是在分散或分布式的环境中 交换信息的简单的协议，是一个基于x m l 的协议，它为在一个松散的、分布的环境中使用 x m l 对等地交换结构化的和类型化的信息提供了一个简单的轻量级机伟l j 2 0 。s o a p 本身并 不定义任何应用语义，如编程模型或特定语义实现，它只是定义了一种简单的机制，通过一 个模块化的包装模型和对模块中特定格式编码的数据重编码机制来表示应用语义。s o a p 的 这项能力使得它可被很多类型的系统用于从消息系统到r p c ( r e m o t ep r o c e d u r ec a l l ) 的延 伸。 s o a p 规范主要由三部分组成： s o a p 信封( e n v e l o p ) ，它构造定义了一个整体的s o a p 消息表示框架可用于表示消 息中的内容是什么，是谁发送的，谁应当接受并处理它，以及这些处理操作是可选的还是必 须的等。 s o a p 编码规则( e n c o d i n gr u l e s ) ，定义了一个数据的编码机制，通过这样一个编码机 制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所 衍生的实例。例如可能应订单服务的需要，使用s o a p 编码规则定义了订单的数据类型，井 可以在订单生成的客户端与订单服务之间交换订单实例。 s o a pr p c 表示( r p cr e p r e s e n t a t i o n ) ，定义了一个用于表示远端过程调用和响应的约 定，例如如何使用h t t p 或s m t p 协议与s o a p 绑定，如何传输过程调用，在具体传输协 议的哪个部分传输过程响应，如我们可以在h t t p 的响应的时候传递过程响应。 虽然这三部分是作为s o a p 的不同部分作为一个整体定义的，但他们在功能上是正交 的、彼此独立的。特别的，信封和编码规则是被定义在不同的x m l 命名空间( n a m e s p a e e ) 中，这样有利于通过模块化获得定义和实现的简明性。 s o a p 的主要设计目标是简明性和可扩展性。这就意味着有一些传统消息系统或分布式 对象系统中的特性将不包含在s o a p 的核心规范中。这些特性包括：分布式垃圾收集 ( d i s t r i b u t e d g a r b a g ec o l l e c t i o n ) 、成批消息传输，处理( b o x c a r r i n g o r b a t c h i n go f m e s s a g e s ) 、 对象引用( o b j e c t s b y - r e f e r e n c e ) 、对象激活( a c t i v a t i o n ) 等等。 f 面给出了一个使用s o a p 调用b 2 b 服务的一个简单例子： 在这个例子中，将向产品报价( p r o d u c t q u o t e ) 服务提交一个获取最新交易价格 ( g e t l a s t p r o d u c t p r i c e ) 的s o a p 请求。请求将包含一个字串型的参数，指明需要报价的产 品代号，而在s o a p 响应中则包食一个实数的价格。s o a p 信封元素是表示s o a p 消息的 x m l 文档的根元素。x m l 命名空问则用来消除s o a p 标识符与应用定义的标识符之间可能 存在的理解歧义。s o a p 总是绑定在某种协议上进行传输，这个例子使用了s o a p 的h r r p b i n d i n g s 。 p o s t p r o d u c t q u o t eh r r p 1 1 h e s t ：e b i z c o m c o n t e n t - t y p e ：t e x t x m l ；c h a r s e t = “u f f - 8 c o n t e n t l e n g t h ：i 1 1 1 1 1 1 s o a p a c t i o n ：“s o m e u r i ” 7 硕士毕业论文 e b i z ：g e t l a s t p r o d u c t p r i c ex m l n s ：e b i z = “s o m e u r i ) j a g u m 玉：腿p e r e f e r e n c e l d ) 上面的s o a p 消息是调用请求，下面的s o a p 消息是调用响应： h t t p 1 12 0 0o k c o n t e n t - t y p e ：t e x t x m l ；c h a r s e t = “u t f - 8 ” c o n t e n t - l e n g t h ：n n n n e b i z ：g e t l a s t p r o d u c t p r i e e r e s p o n s e x m l n s ：e b i z = - s o m e - u r i ， 2 4 3 9 0 0 0 0 s o a p 消息可以看作是从发送方到接受方的一釉传输方法。但s o a p 消息一般会和实现 模式结合，例如请求，响应( 参见下一节) 。s o a p 的实现可以为特殊网络系统的特有特征来 优化。例如，通过h t t pb i n d i n g 将s o a p 响应消息通过h 1 f i p 响应来传输，请求和响应使 用同一连接。无论s o a p 是与哪种协议绑定，消息都可以通过消息路径( m e s s a g ep a t h ) 来 指定路线发送。消息路径机制使消息在到达最终目的地之前可以在一个或多个中间件上处 理。例如一个申请订单的消息可以首先到达认证服务( a u t i l e m i c m i o ns e r v i c e ) 确认身份获 取权限，然后到达产品查询服务( p r o d u c t q u o t es e r v i c e ) 获得所需产品的最新价格，然后进 入订单服务( p u r c h a s e o r d e rs e r v i c e ) 根据所得的最新价格产生订单并响应调用者。通过这 样一种机制可以实现基于模块化服务设计基础的商务流程实现，通过低耦合模块的统一集成 获得良好的系统体系和功能实现。消息路径的示例参见图2 3 。 图2 3 消息路径机制 通常，一个收到s o a p 消息的s o a p 应用程序必须按照以下规范、通过执行r 面这些 8 硕上毕业论文 动作来处理这个s o a p 消息： 找到并标识该s o a p 消息中所有为该应用程序设置的部分。例如，在前面的例子中，认 证服务就需要找到并标识消息中的帐户信息。 校验该消息在前一步中获得的被标识的部分中所有的必须处理的部分( 在s o a p 消息规 范中支持强制处理部分和可选处理部分，这一功能的实现是通过对文档片断加以属性修饰而 实现的) ，并处理这些部分。如果这部分的内容不符合双方约定的默认定义，则丢弃该消息。 处理器可以忽略在第一步中获得的被标识的部分中的可选部分，如果这些可选部分不会影响 处理的结果。例如上面的例子中，第一步完成帐户校验后，在消息中删除a c c o u n t i n f o ，生 成一个会话i d ，加入该s o a p 消息，同时向产品查询服务转发该消息。 如果该s o a p 应用程序不是该消息的最终目的地，则在该消息中删除所有在第一步中标 识的部分，如果有必要的话，附加上处理的结果部分，并转发该消息。 为了处理一条消息或消息的部分，s o a p 处理器需要理解；使用的交换方式( 包括单向。 请求响应，广播等) 、该方式中消息接受者的角色、r p c 机制的使用方法( 如果有的话) 、 消息中数据的编码或表示方式以及对丁正确处理所必须了解的另一些语义。 以上的介绍可以认为是s o a p 技术在一个通用开放和广泛的环境下如何协同工作及相 互集成的机制。 2 2 2s o a p 的应用模式 s o a p 的应用模式包括以下几种，每种模式对应着不同的应用场合，以下对这些模式做 些简单的介绍。 请求响应模式 所谓的请求响应模式是指发送方发送一个s o a p 消息之后接收方在对这个s o a p 消 息处理之后再向发送方发出一个响应的消息。例如发送方发送一个订单请求，接收方给出了 一个订单确认的响应。 请求响应模式需要“请求响应”的消息特性来实现。无论成功或失败，s o a p 发送者 都被告知了请求消息的状态( 拒绝请求、处理失败等) 。上一节的例子就是个请求响应的 应用模式。 如果底层传输协议直接支持请求及其响应的关联性( 即底层协议支持请求相应机制) ， 那么具体的实现机制如图2 4 所示。同步h t f pp o s t 是这样一个底层传输协议的例子。这 样一种实现机制将使用某种s o a p 绑定，例如s o a p h r r p 绑定。由s o a p 发送者发送的作 为请求的商业文档将被插入到请求消息中，成为请求消息的有效负载( 消息体) 。而当接收 到该请求后，处理应用将产生一个将作为响应消息的有效负载并将被返回的文档，同时在响 应消息中会包含合适的状态码。无论因为何种原因，如果请求消息没有被接收到，或者没有 被期望的商业应用所处理，那么同样，合适的状态消息也将被底层传输层所生成并报告给 s o a p 发送者。 9 硕士毕业论文 催毫惑訾喾”作驾嚣鬻瓣 8 0 p 茬逸誊s 0 p 接蝗者 s o p 癌用 g m 斑月 掌a p 演襄摇烃 i s o ” ll l 一髓羞 一煳| k 一。舭梦单遣嘲垫。 r 一j l 图2 4 使用底层传输的请求响应模式 如果底层传输协议不支持请求，响应模型，那么按照如图2 5 所示的机制将是一个合适 的解决方案。这种底层传输协议的一个例子是单向的队列中间件。在这种情况下，消息标识 和消息关联是通过s o a ph e a d e r 来提供的。在生成请求s o a p 消息时，消息标识处理器需 要生成一个唯一的消息标识，并将它插入到一个s o a ph e a d e r 中。这个消息标识作为s o a p 请求消息的一个组成部分由s o a p 应用a 发送，并被s o a p 应用b 接收。请求消息被商业 应用处理，同时该商业应用装配了响应消息。响应消息中同样包含了一个特别的s o a p h e a d e r ，这个s o a p h e a d e r 是由消息关联性处理器生成的，它负责将响应消息与其相关的请 求消息设置连接语义。 ”i i ：2 ：i 卷，”l ：5 嚣；警擎“i ：；：紫”嘉：；譬” s o p 摧牧s 0 p 遗蠢 3 0 p 底用$ 0 舻赢用 蔽：l 目1 焖 璃皂燕臻健 隐l1 黪i| ； - _ ! 繁；| ；1 蝴a r l r 。1厂l l 8 0 p * m _ i -，l s o 艚蛀硅_ l l8 一。 l s a 雌镕 |i ll t 上j 醐一建 卿一蹙j 图2 - 5 使用s o a ph e a d e r 的请求响应模式 1 0 硕士毕业论文 f i r e - a n d f o r g e t 模式 “f i r e a n d f o r g e t ”来源于军事术语，其含义是“发射后不管”。而在s o a p 消息的应用 模式中，它指发出s o a p 消息，然后不需要再去处理与该消息相关的操作。在这种模式下， 接受者可能是一个也有可能是多个。消息的接收者不需要特别在意以前的消息也不需要对消 息作出回应：而且s o a p 发送者并不需要了解任何的消息状态信息，包括消息是否已经被发 送，或是消息是否已经被接收者接收到等。一个典型的“f i r e a n d - f o r g e t ”模式的应用是每 隔几分钟更新一次股票价格消息。底层传输协议也许实现了一个响应机制，然而描述消息是 否被成功发送的状态信息将不会被返回给发送s o a p 消息的s o a p 处理器。 第三方中介模式 所谓第三方中介模式是来源于这样一种应用：自主竞价交易市场( m a r k e t p l a c e ) 。这是 一个在买家和供应商之间的代理桥梁。买家将他们的需求提交给交易中心，交易中心会将这 些需求信息广播给多个供应商。供应商收到求购信息之后，将向买家发出求购响应，求购晌 虑是通过交易中心被传输给最终买家的，同时在交易中心将记录下这些响应。 第三方中介模式也可以被认为是订阅，分发模式，即应用程序向一个事件源( e v e n t s o b r c e ) 订阅了一些具有明确名称的事件( e v e n t ) 的事件通知。当被订阅的事件发生后，如 果通知是被发送给最初的发出订阅请求的应用程序的话，那么称为单方订阅，如果通知是被 发送给其他应用程序的话，那么称为第三方订阅。例如，一个应用程序可以向打印机驱动程 序发出关于打印机状态变化( 例如，缺纸、缺墨等) 的事件订阅请求，而这些事件的通知可 以发送给另一个系统管理程序。订阅内容的分发可以是“f i r e - a n d - f o r g e t ”模式也可以使用 请求响应模式实现。 传舟橱嫱雹琏蠢的靠为蠢播攮赣蠢韵撵为 s o a p m 点嗣甜p 站赢 s i 8 泔发遵t9 瑚控s d s c 岛m p 由用 9 噼斑自 ，一 9 瀚基 蝴蹲l- 一_ l li 匡 ls q p 鳗理s b o 整缨皂 3 一麟| i 鑫脚窟陲攀 酗警蠛0 。一 ；- 白- | i 尚f l j | l 一；- 一 i、 !b 岬 h _ c 蛔i 图2 - 6 交易市场中介 图2 - 6 展示了一个基于s o a p 的消息基础架构，该基础架构用于支持作为买家和卖家之 间的中介的第三方交易市场的实现。对于交易市场这样的商业模式而言，首先它会尽力召集 多个商业和服务的供应商，然后买家连入交易市场，同时使用交易市场提供的服务。交易市 场是作为在买家和其所挑选的卖家之间完成商业事务所需要的第三方通道而工作的交易市 硕士毕业论文 场既能为b 2 b 事务提供服务，也能为b 2 c 事务提供服务。 在这种模式下，买家可能使用非常简单的客户应用，比如浏览器，也可能使用复杂的应 用，比如采购系统。当交易市场接收到买家的订单之后，它会联系一组合适的卖家，这些卖 家将针对这个定单进行反向竞标。交易市场将从中挑选出最有竞争力的标，然后将其作为竞 标的赢家交互给买家。然后，一个采购流程将被初始化，而交易市场则作为这个事务的中介 进行工作。 从s o a p 消息传输的角度来看，图2 - 6 所展示的模式中，对于买家登录订单的过程，是 在买家和交易市场间发生了一组请求，响应消息的交换。当交易市场接收到订单之后，交易 市场同样通过一组请求响应消息与一组挑选山的卖家进行交互。在交易市场与卖家之间， 将会就消息交换的特性有一些先决的协约，比如可靠性、安全性以及消息结构等等。这些特 性将定义在交易市场和卖家之间需要哪些额外的s o a p 处理模块米支持这一消息交换模式。 在经由多个中介的通讯模式中，中介将代理初始发送者的消息交换，将来自初始发送者 的消息转发给最终的接收者。初始发送者希望能够加强消息路由的不可抵赖性。在对消息提 供路由服务的过程中，所有的中介消息服务处理器必须将路由消息头信息记录到日志中。当 消息即将被转发给最终消息接收者时，此时承担转发任务的消息处理器必须将被签名的路由 消息头以及消息的接收者写入日志，以保证消息接收的不可抵赖性。 在经由多个中介的通讯模式下，需要在初始生成消息的s o a p 发送者与最终s o a p 接 收者之间可创建一个审计链。其中消息要送达最终s o a p 接收者，要经过一些s o a p 中介 审计链要包含所有出现的s o a p 中介。在消息路径中的每一个s o a p 结点都维护了一个持 久化信息库( 典型的是数据库) ，这个数据库被用丁：存储对于每条消息的审计记录。而这每 个s o a p 结点中的路由日志处理器都有责任将每条消息的日志记录在持久化信息库中。而对 于这些路由日志处理器而言，它在将消息转发给消息路径的下一个结点之前，需要对路由信 息消息头实施签名。而对于消息签名而言是必须得一些机制包括对数字证书的支持，以及一 些相关的配套机制等。 基于会话的消息交换模式 在基于会话的消息交换模式下，两个会话的参与者将进行一个长时间的会话进程，其中 将包含多次消息交换。这种进程的例子可以是复杂的供应链管理、动态的制造日程安排或是 信息修复等。在相同的两个参与者之间，可能会有同一个进程的多个实例存在。 在商业伙伴之间的交互经常是远远比一个简单的请求，响应消息交换要复杂地多。举例 来说，一个长时间运行的消息交换可能是用于实现诸如商品和服务的采购这样商业交互。在 这种情况下，将多个个体形式出现的消息组成一个长时间的消息交换集可以带来很多实现上 的好处。这样一种多次的消息交换的形式就是我们所熟知的会话。会话可以在一对交易伙伴 之间长时间地继续。一个会话实例可能需要几天、几周甚至几个月来才能完成。 在两个交易伙伴之间的会话可以被类似e b x m l 交易伙伴协定( t r a d i n gp a r t n e r a g r e e m e n t ，t p a ) 这样的共享的构造信息来定义。一个交易伙伴协定( t p a ) 所包含的信 息有诸如期望的响应次数、每个交易方承诺完成的商务流程的动作、安全信息以及消息内容 结构等。在一个采购进程中，一个会话过程可以是： 1 一个买家向卖家发出对一些商品的报价请求，卖家响应了商品报价； 2 买家发出了一个采购订单，卖家接收了这个订单； 3 卖家通知买家交货的日期，而买家接收了这个通知； 4 买家确认了商品已经送达，卖家收到了这一确认： 5 买家提供对商品的支付，卖家发出收据响应。 所有的这些消息交换的例子都是与t p a 的实例相关的，这个t p a 是在这两个参与者之 间达成的。如果一个消息需要合法地作为约定规则的一部分那么每一个参与方都需要去检 硕士毕业论文 验当前的消息是否是在t p a 范围内合法。 每个参与者的s o a p 处理器都能够访问一个按照t p a 协定而配置的数据库，t p c 协定 是在两个参与者之间达成的。s o a p 发送者中的会话状态处理模块负责处理的s o a ph e a d e r 条目中包含的信息，能够表示该条目所在的消息是会话实例的一部分。而对等的s o a p 接收 者的相应的会话状态处理模块则使用发送者提供的信息来测试收到的消息是否是遵照t p a 的规则的。该测试过程具体的是通过检查它自己的规则数据库来实现的，这个数据库里保存 着每个当前活跃的会话实例的状态信息。如果当前消息违背了t p a 的规则，那么应用程序 可以产生一个错误。 异步消息模式 在异步消息模式下，发送者以异步方式将消息发往接收者，同时期望在一段时间之后获 取一些响应。其中，发送者为请求分配了一个标识，并标注了这个请求，这样之后的响应就 可以使_ i = | j 这个标识与初始请求进行关联。同时，发送者也可以为请求分配了属于其他服务的 一个标识，而这个服务将作为最终的响应的接收者，也就是说，响应并不一定会发同给发送 者。 异步消息模式的实现与请求响应模式基本上是相同的。其唯一的不同点，是请求消息 与响应消息在发生时间上是分离的，并且是以两个单向消息来实现的。其中，s o a p 发送方 的应用程序在发送完s o a p 消息之后并不会等待响应消息的返回。当最终的响应消息的接收 者( 不一定是初始的消息发送者，这我们一开始就指出了这一点) 收到响应消息后，s o a p 发送方的应用程序将会通知初始的s o a p 发送应用程序。然后它就可以使用接收到的消息中 的关联信息与之前发送的某个s o a p 消息达成关联。 其实由t - s o a p 消息往往与h t t p 、f t p 等上层通信协议绑定，而这些协议又往往无 固定连接、无统一时钟，所以从严格意义说，所有的消息传输都是异步的。而这里所谓的异 步只不过是发送方无需等待响应而己。 多消息异步响应模式 多消息异步响应模式是异步消息模式的一个扩展。在多消息异步响应模式f ，应用程序 向服务器以异步方式请求信息，依请求而给出的返回结果将在段时间之后以多个响应消息 的形式返回。这样的应用模式常常发生在被请求的信息无法一次被完整提供而又需要保证较 好的系统性能的场合下，比如象分布式w e b 搜索这样的应用。多消息异步响应模式的实现 基本架构与异步消息模式中是基本一致的，他们使用了相同的消息关联机制来关联请求消息 和响应消息。而为了实现多消息响应，我们可以通过使用一个称为序列化处理器的模块来支 持这一特性。序列化处理器确保在每一个响应消息中插入一个唯一的序列号。如果负责返回 响应消息的应用程序预先就知道将会生成多少响应消息的话，那么序列化处理器可以使用 “no f m ”的格式( 例如lo f 3 ，3o f 3 等) 来指明有多少响应消息将被返回，以及当前的 消息是处于序列中的哪个位置。 s o a p 消息的增量解析和处理模式 在s o a p 消息的增量解析和处理模式下，s o a p 发送者可能生成了一个非常冗长的 s o a p 消息，由于等到完整接收这个冗长的s o a p 消息后再处理会造成大量的技术时间的浪 费，并且将延迟响应速度，因此就需要发送者具备增