（计算机软件与理论专业论文）基于中间件的分布式应用系统开发.pdf

西北工业大学硕士学位论文 摘要 构架设计是从问题空间向软件解空间过渡的第一个活动，以构件关系模型 为基础，在考虑系统实现环境( 如操作系统、数据库、通信机制、中间件等) 和应遵循的标准等因素的情况下，形成针对特定系统或领域的软件构架，中间件 作为分布体系应用的关键技术，以其独特的优势为各种分布式应用的开发注入 了强大动力，极大地推动了分布式应用系统的研究和设计。 本文结合某某人寿的保险业务组件开发平台项目的开发，对分布式应用系 统的架构设计进行了深入的研究。本文首先研究了分布式软件体系结构，说明 了分布式软件开发的基本原理，然后详细阐述了保险业务开发平台的设计思路 与相关技术，对分布式软件开发提出了自己的观点。文中重点介绍保险业务开 发平台的架构，提出了基于m s m q 的分布式软件架构模型，探讨了该模型在 保险业务开发平台的应用。同时使用u m l 对开发平台的重要部件进行建模和 深入的阐述。对于企业数据集成与交互，给出了基于x m l 的数据集成服务 作为为开发平台的数据服务的增强。文章最后结合分布式容错技术的发展，提 出了针对服务级对象容错模型，由于服务是大颗粒对象( 组件或者应用程序) 又是i n t e m e t 分布式计算环境中软件开发的重要概念，该模型从服务级容错这 个新视角对容错的复制管理、失效检测、失效恢复技术及其算法进行了深入的 探讨，从而使保险业务组件提供高可用的分布式应用。 关键词分布式软件体系结构中间件n e t x m l容错 西北工业大学硕士学位论文 a b s t r a c t a r c h i t e c t u r ei st h ef i r s ts t e pt ot h es o l u t i o no ft h es o f t w a r e t h i n k i n ga b o u t t h es y s t e me n v i r o n m e n t ( s u c ha so p e r a t i o ns y s t e m 、d a t a b a s e 、c o m m u n i c a t i o n 、 m i d d l e w a r e ) a n dt h es t a n d a r d , w ef o r mt h es o f t w a r ea r c h i t e c t u r ef o rs p e c i a l d o m a i n m i d d i e w a r ei st h ek e yt e c h n o l o g yf o rt h ed i s t r i b u t e ds o f t w a r es y s t e m a tt h es a i n et i r n et h em i d d l e w a r eh a sa d v a n t a g ef o rt h ed i s t r i b u t e ds o f t w a r e d e v e l o p t h i sa r t i c l er e s e a r c ht h ed i s t r i b u t e da p p l i c a t i o ns o f t w a r ea r c h i t e c t u r eb y i m p l e m e n t e dt h ep r o j e c t o fa ni n s u r a n c eb u s i n e 蟠c o m p o n e n td e v e l o p m e n t p l a t f o r m a tf i r s t , w er e s e a r c h t h ed i s t r i b u t e ds o f t w a r ea r c h i t e c t u r et e c h n o l o g y a n d d e v e l o p m e t h o d , t h e nd e s i g n t h ei n s u r a n c eb u s i n e s s c o m p o n e n t d e v e l o p m e n tp l a t f o r mb yg i v e n s o m ec r e a t i v ei d e a sf o rt h es y s t e m t h et h e s i s f o c u so nt h ep l a t f o r m s o f t w a r ea r c h i t e c t u r e a n dr e s e a r c h e dm s m q - b a s e d d i s t r i b u t e da p p l i c a t i o na r c h i t e c t u r ew i t hd i s c u s s e d i t sf e a s i b i l i t ya n d a d v a n t a g e a tt h es a r n et i m ea n a l y s i sa n dd e s i g n t h e c o m p o n e n t s o ft h es y s t e m u s i n g u m l a c c o r d i n gt o t h ed a t ai n t e g r i t yf o rt h ec o p a r t n e r , g i v et h ex m l - b a s e dd a t a i n t e g n t y a r c h i t e c t u r e a tt h e l a s t c h a p t e r , w e d i s c u s st h ef a u l t - t o l e r a n t t e c h n o l o g ya n dp r o p o s et h em o d d ( f t - m r s ) i nt h en e w f i e l d - a sw ek n o w s e r v i c ec o n c e p ti sa ni m p o r t a n tc o n c e p tf o rd i s t r i b u t e dc o m p u t i n g , t h ef a u l t t o l e r a n tm o d e lb u i l do nt h el e v e lo ft h es e r v i c e ( c o m p o n e n t a p p l i c a t i o n ) w e a p p l i e d t h ef a u l tt o l e r a n ti nt h ei n s u r a n c es y s t e m t h ef t - m r s m o d e lr e s e a r c h t h e r e p l i c am a n a g e m e n t 、f a u l td e t e c t 、l o g g i n g a n dr e c o v e r ya n dt h e i r a l g o r i t h m s k e y w o r d s d i s t r i b u t e ds o f t w a r ea r c h i t e c t u r e m i d d l e w a r e n e t x m l f a u l tt o l e r a n t i i 西北工业大学硕士学位论文 1 1 选题背景及意义 第一章绪论 传统的应用系统模式是“客户机j l 务器”，客户机服务器系统( c l i e n t s e r v e r s y s t e m ) 的结构是指把一个大型的计算机应用系统变为多个能互为独立的子系 统，而服务器便是整个应用系统资源的存储与管理中心，多台客户机则各自处 理相应的功能，共同实现完整的应用。随着i n t e m e t 的发展壮大，特别是企业 信息化过程的加快，对大流量、实时性特点的要求需要系统具有实时响应、交 互动作异步非耦合、高可用性、高可得到性等特征。这些传统模式已经不自适 应新的环境，于是就产生了新的分布式应用系统，即所谓的“浏览器朋匣务器”结 构、“瘦客户机”模式。 在c l i e n t s e r v e r 结构模式中，客户端直接连接到数据库服务器，由二者分 担业务处理，这样体系有以下的缺点： l 、c l i e n t 与s e r v e r 直接连接，安全性低。非法用户容易通过c l i e n t 直接闯 入中心数据库，造成数据损失； 2 、c l i e n t 程序肥大，并且随着业务规则的变化，需要随时更新，或者重新 部署c l i e n t 端程序，大大增加维护量，造成维护工作困难； 3 、每个c l i e n t 都要直接连到数据库服务器，使服务器为每个c l i e n t 建立连 接而消耗大量本就紧张的服务器资源； 4 、大量的数据直接c l i e n t s e r v e r 传送，在业务高峰期容易造成网络流量剧 增，网络阻塞。 c l i e n t s e r v e r 模式的这些先天不足，随着业务量的变化，出现越来越多的问 题，我们有必要对这种两层体系进行改革。随着中间件与w e b 技术的发展三 层或多层分布式应用体系越来越流行，从而借助中间件可以将业务处理与客户 交互分开来，实现瘦客户，业务服务数据服务的分布式应用体系结构。 在基于中间件的分布式体系结构中，客户机只存放表示层软件，应用逻辑 包括事务处理、监控、信息排队、w e b 服务等采用专门的中间件服务器，后台 是数据库。在多层分布式体系中，系统资源被统一管理和使用，用户可以通过 网格门户( p o r t a l ) 透明地使用整个网络资源。 1 2 国内外发展现状 当前分布式对象技术主要有三种架构标准：c o m c o m + 、j a v a 和c o r b a ， 西北工业大学硕士学位论文 这些标准极大地促进了对象中间件技术的发展。随着面向对象应用系统的逐渐 增长，对象中间件的需求也在逐年加大。对象技术的优势和对象中间件的标准 化，促使对象中间件的功能将最终涵盖其它几类中间件的功能而成为主流。国 际上中间件的开发技术是分别建立在以上三种架构规范上的。我国的中间件开 发商也在向这个方向发展。例如，金蝶开发的a p u s i c 应用服务器是完全支持 j 2 e e 规范的应用服务器。 多层分布式分布式体系结构如下：瘦客户：提供简洁的人机交互界面，完 成数据的输入，输出：业务服务：完成业务逻辑，实现客户与数据库对话的桥梁。 同时，在这一层中，还应实现分布式管理、负载均衡、f a i l r e c o v e r 、安全隔离 等；数据服务：提供数据的存储服务。一般就是数据库系统。这种体系结构的 特点是：安全性：中间层隔离了客户直接对数据服务器的访问，保护了数据库 的安全；稳定性：对于要求2 4 * 7 工作的业务系统，多层分布式体系提供了更 可靠的稳定性：1 、中间层缓冲c l i e n t 与数据库的实际连接，使数据库的实际连 接数量远小于c l i e n t 应用数量。当然，连接数越少，我们的数据库系统就越稳 定。2 、f a i l r e c o v e r 机制能够在一台服务器当机的情况下，透明地把客户端工 作转移到其他具有同样业务功能的服务上。易维护：由于业务逻辑在中间服务 器，当业务规则变化后，客户端程序基本不做改动：快速响应：通过负载均衡 以及中间层缓存数据能力，可以提高对客户端的响应速度；系统扩展灵活：基 于多层分布体系，当业务增大时，可以在中间层部署更多的应用服务器，提高 对客户端的响应，而所有变化对客户端透明。 1 3 课题内容及本人所作工作 一、课题内容 论文结合某某人寿保险公司的寿险业务系统的开发，针对保险行业信息化 业务复杂、数据量大的特点，采用了基于中间件技术的分布式应用解决方案。 整个业务系统分成如下三层：基础平台层：负责数据类访问逻辑，同时提供客 户端对服务端的对象引用以及在引用上的操作，相关的对象查找( 定位) 、分布 事务管理、安全机制等内容。保险业务逻辑层：一般保险行业的需求有关的设 施、部件，使平台能适应更多的保险行业。东方寿险业务层：与东方寿险的具 体业务相关的部分，这是该软件系统中的真正的应用层。同时东方寿险业务系 统使用了应用服务器。应用服务器提供一些安全、事务处理，管理机制。同时针 对保险应用对高可用服务的要求，结合f t - c o r b a 规范给出了一个保险业务组 件运行容错模型。使保险业务组件的应用服务器端服务提供容错，同时给出了 相应的容错算法，并对该容错模型进行了设计与实现。 西北工业大学硕士学位论文 二、本人所作的工作 论文研究重点如下： 研究了分层的分布式软件体系结构，在n e t 平台下给出保险业务组件开 发平台的架构方案 基于x m l 的数据集成应用，增强保险业务平台的数据服务 参考f t - c o r b a 规范提出了保险业务组件的运行容错模型 1 4 论文组织 全文组织为：第一章为绪论部分、第二章至第五章为主体部分、结束语。 第一章绪论 综述本文的选题背景、研究内容和整体组织。 第二章分布式软件体系结构 本章介绍了分布式系统的定义，中间件对于分布式应用开发的增 强，简要介绍了中间件的分类、特点并重点介绍了消息中间件的 模型。研究了面向模式的分布式架构技术，介绍了分层的软件体 系结构在分布式软件中的应用。 第三章保险业务组件开发平台 本章是本文的重要部分，也是作者完成的主要工作之一。首先讨 论保险业务组件开发平台的指标，然后给出了应用服务器端基于 消息中间件m s m q 架构设计，同时给出了x m l 的数据集成应用， 从整体上阐述了保险业务组件开发平台的软件体系结构。 第四章保险业务组件运行容错模型 本章是本文的重要部分，针对保险应用对高可用服务的要求，结 合f t - c o r b a 规范给出了一个保险业务组件运行容错模型，使保 险业务组件的服务器端服务提供容错服务，同时给出了相应的容 错算法，并对该容错模型进行了设计与实现。 结束语本章对本文进行了总结，并指出了需要进一步完善的工作。 西北工业大学硕士学位论文 第二章分布式软件体系结构 软件体系结构和设计模式( p a t t e r n ) 是近年软件工程领域的新的研究课题 之一，人们为一些软件寻找并确定其实现模式，以实现在软件结构一级的重用。 软件体系结构的形成借鉴了计算机体系结构，网络体系结构，分布式计算等各 学科的思想和方法，主要内容涉及软件体系结构的描述，软件体系结构风格， 软件体系结构的设计，软件体系结构模式，软件体系结构的评估和软件体系结 构的重用等。同时随着设计模式对重用组件、中间件设计的优化与增强，分布 式软件体系结构的研究逐步走向成熟，本节将对分布式软件体系结构进行介绍 与研究。 2 1 中间件对分布式系统的增强 随着以网络计算为中心的应用系统规模的扩大和软硬件结构的日趋复杂多 样。客户端和服务器端的负担也日益繁重并且传统软件的移植性、互操作性和 重用性也都不能满足现在的性能需求，为此人们提出一中间件( m i d d l e w a r e ) 。 中间件处于操作系统软件与用户的应用软件的中间，在操作系统、网络和数据 库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与 开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。 中间件具有如下特点：1 ) 易于集成：中间件能无缝地连入应用开发环境中， 应用程序可以很容易地定位和共享中间件提供的应用逻辑和数据。2 ) 易于移植： 中间件使与平台有关的细节对于应用程序来说是透明的，可以在不改变应用程 序的情况下改换计算机底层硬件、操作系统或通信协议等。3 ) 易于维护： 中 间件实现的功能对应用程序来说是透明的，因此对局部进行改进而不会影响到 系统的其它部分。4 ) 高可靠性：中间件保证事务及关键性业务不被丢失。5 ) 易于使用：中间件能和同构或异构环境下的多种数据源通信，同时它能管理数 据问的公共逻辑约束，它将用户从复杂的平台、网络、数据库选择中解放出来。 中间件通常分为五类：1 ) 远程过程调用中间件：远程过程调用中间件r p c m ( r e m o t ep r o c e d u r ec a l lm i d d l e w a r e ) 是使客户端的应用调用一个位于远端平台 的进程或服务。2 ) 消息中间件：消息中间件m o m ( m e s s a g e o r i e n t e dm i d d l e w a r e ) 利用高效可靠的消息传递机制实现异构平台之间的通讯。3 ) 数据库访问中间件： 数据库访问中间件d a m ( d a t a b a s ea c c e s sm i d d l e w a r e ) 实现对来自不同厂商数 据库的访问。它提供了一系列应用编程接口( a p i ) ，通过中间件而不考虑操作 系统及网络来访问数据库。o d b c 、j d b c 都是数据库中间件的标准。4 ) 对象 中间件：对象中间件也称为请求代理o r b ( o b j e c tr e q u e s tb r o k e r ) 。o r b 提供 西北工业大学硕士学位论文 一种通信机制，透明地在异构的通信环境中传递对象请求，这些对象可以位于 本地或远程机器，且对象之间的客户机服务器的角色是可以互换的。5 ) 交易 中间件：交易中间件也称为分布式事务处理中间件d t p m ( d i s t r i b u t e d t r a n s a c t i o np r o c e s s i n gm i d d l e w a r e ) 。它提供了重要的分布式应用服务。通过事 务处理监控有效的平衡网络负载和主机服务，从而减轻了阻塞，提高了系统性 能。 在分布式应用软件的开发过程中，中间件技术得到了更为广泛的重视，因 为中间件平台提供的平台透明性、通信协议透明性、硬件无关性，可以有效的 降低分布式软件开发的复杂性及成本，提高软件的复用率，特别是对服务端应 用服务器的设计与实现，可以使开发工作集中于业务组件，实现开发平台的透 明性。 本文对于中间件的应用集中于消息中间件。一般而言，一组中间件总是集 成在一起构成开发和运行平台。这组中间件中必须有一个用于通信的中间件， 这个能在分布式系统各部分之间相互通信、实现高效可靠的跨平台数据传输的 中间件称为消息中间件。目前比较成熟的中间件产品有微软的m s m q 、i b m 的 m q s e r i e s 、t o n g l i n k 、b e a e l i n k 等。消息中间件的功能是控制和管理一个集 成的系统，使得组成这个系统的分支应用或各部件之间通过消息完成整个工作 流程。典型的消息中间件结构如图2 1 所示。它由消自, ( m e s s a g e ) 、队y l j ( q u e u e ) 和队列管理器( q u e u em a n a g e r ) 组成。 图2 一l 消息中问件结构图 消息中间件有如下几个特点：1 ) 异步通信机制一这是消息中间件的核心 性质。“异步”不要求通信的双方必须同时在场。当网络出现某种故障使不同部 西北工业大学硕士学位论文 分间无法相互连接时，或当通信的一方在等待另一方的响应过程中耗费了很多 的时间和网络资源时，“异步”都为我们提供了解决的方法。这种机制保证在通 信一方不存在的情况下，业务得以继续进行，而且一旦通信双方的连接恢复后， 因中断而积累的消息会快速地传递到通信的另一方，不会丢失。2 ) 队列化消息 传递一“队列化”其实是实现“异步通信”核心本质手段。当通信双方不能 同步交互消息时，要传递的消息必须以某种数据结构方式暂时保存下来，通常 采用的数据结构就是“队列”，消息通过队列来进行存储转发的机制就是“队列 化消息传递”。也就是说，消息的发送者和接收者通过“队列”中间媒介进行交 互。3 ) 消息的传递可靠、安全、有效一消息安全及时的到达、不丢失、不重 复对通信双方是非常重要的，这是对分布式应用数据完整性的保证。 2 2 面向模式的分布式架构技术 构架设计是从问题空间向软件解空间过渡的第一个活动，以构件关系模型 为基础，在考虑系统实现环境( 如操作系统、数据库、通信机制、中间件等) 和应遵循的标准等因素的情况下，形成针对特定系统或领域的软件构架。构架 是系统实现的蓝图，在后续开发活动中的作用包括以下两个方面：1 规定了构 件接口和规约，有助于构件获取( 例如，定制或发现相关的构件) ：2 为系统 集成提供框架，有助于符合规定接口的构件集成。软件采取的模型是整个架构 设计的理论基础，模式是整个架构得以实现的方法论。以模型为基础，以模式 为方法，以相关技术为手段去构建一个可行、可靠、可重用的平台架构。基于 模型的框架可以定义为以下五元组： b m f = s o f t w a r ea r c h i t e c t u r e ，f r a m e w o r kc o m p o n e n t s ，c o n n e c t i o n s ，c o n s t r a i n s ， d e s i g np a t t e r n s ) 其定义如下： 定义1 s o f t w a r ea r c h i t e c t u r e 一描述了软件的成分及系统框架、软件成分的 选择，各成分之间的相互作用和系统的功能、性能、设计以及多种方案及选项 中进行选择的决策。比较典型的有管道一过滤器模式、基于事件的隐式调用模 式、基于消息广播并面向图形用户界面的c h r i o n 模式、分层模式、知识库模式、 解释器模式等，每种模式都有其优点和缺点，适用于不同的应用设计； 定义2 f r a m e w o r kc o m p o n e n t s 一实现了领域共性，而在框架外部的、出 用户定制的、待组装的构件称为应用构件( a p p l i c a t i o nc o m p o n e n t s ) ，它体现 了具体应用系统的特征，即领域变化性； 定义3 c o n n e c t i o n s 一实现了构件之间的交互动作和交互规则，是软件体系 结构的基础块，在系统实现时不一定具有对应的实现单元，如：不同设备( 子 6 西北工业大学硕士学位论文 系统) 问相互交流的消息、共享变量、缓冲区、管道、数据库与应用程序间s q l 连接等； 定义4 c o n s t r a i n s 一描述框架内部的控制流程、构件和连接器的依赖关系、 构件之间的协作关系以及框架对于扩展的限定等，这些约束往往与领域有关； 定义5 d e s i g np a t t e r n s 一设计模式：面向对象设计模式可分为类模式和对象 模式。其中类模式处理类和子类之间的关系，这些关系通过继承而建立，是静 态的，并且在编译时刻就已经确定下来：而对象模式则用于处理对象间的关系， 这些关系在运行时刻是可以变化的，更具有动态性。由于构件难以实现继承关 系，因此，只能使用类似于对象模式的模式。这些模式( 除了s i n g l e t o n ，f a c a d e ， f l y w e i g h t ，m e m e n t o 模式以外) 都提供了对于设计中某种变化性的解决方案， 可以用于处理构件层次不同类型的变化性： 在分布式软件的架构设计中我们必须考虑的模型如下：远程、分布式组件 模型、数据模型、业务模型、安全模型：这些模型的建立也就意味着软件是多 层、分布式的。中间件作为分布体系应用的关键技术，以其独特的优势为各种 分布式应用的开发注入了强大动力，极大地推动了分布式应用系统的发展。跨 平台的基于中间件的分布式应用，常见的分层软件体系结构模型如图2 2 所 示： 图2 - - 2 分层软件体系结构模型囤 该模型与基于客户服务器的机制不同，将业务的表现与实现逻辑分开，这 样更与现实世界的业务处理相同。因为前台的操作人员不需要对业务逻辑进行 控制，而业务逻辑是由管理人员确定的，操作人员仅面向人机交互。其中包括 三个层次： 西北工业大学硕士学位论文 表示层：该层为用户提供人机交互界面，所有的数据录入，显示操作都在 此完成。表示层的数据交互通过业务逻辑层提供的接口进行访问，实现了真正 意义上的瘦客户。 业务逻辑层：该层负责对输入输出的数据按照业务逻辑进行加工处理， 该层由构建构成，它们是独立的功能单元，实现一定的商业逻辑。构件是对象 概念的延伸和发展，通常认为构件的粒度比对象的粒度更大，在实现上可以是 一组协作的对象集合，典型的构件如c o r b a 构件、d c o m 构件、e j b 构件等。 对象具有小粒度、大数量的特点。相对而言，构件系统中的构件具有大粒度和 小数量的特点。数据库服务接口用以实现对后台数据库的无关访闯，为不同的 数据库提供了相同的接口引擎，屏蔽了与数据库相关的细节。也就是说，当后 台数据库发生了变化，由于系统是通过数据库服务接口进行数据库访问，因而 我们的应用程序不需要做任何变动。例如，我们现在的寿险业务平台系统使用 的是s q ls e r v e r 大型数据库，以后随着业务的扩展需求，我们可能把寿险中财 务数据库单列出来，放到其他的数据库服务器中，以降低中心数据库服务器的 负载。这时，从成本角度考虑，我们可能选用其他数据库，但我们不需要再投 资购买应用软件的相应数据库版本。 数据层：即实际意义上的r d b m s 。 采用以上的技术，我们就解决了客户朋艮务器模式中面临的最严峻问题：客 户机增多一 数据库连接增多 服务器不断扩容 当机。在多层体系中，由于 客户机不是直接访问数据库，而是通过业务逻辑服务层，因此我们可通过业务 层有效的实现公用数据库连接。也就是说，1 0 0 个客户端同时在线，我们可能 到数据库只有1 0 个实际连接。 2 2 1 软件构件 构件是一种可复用的软件单元，是对系统中相对稳定的实体的抽象。构件 具有以下性质：1 ) 相对独立性。构件相对独立于其他构件，构件之间的关系是 松散连接。2 ) 封装性。构件封装了内部设计和实现细节，外部只能通过接口访 问构件。3 ) 可组装性。构件可以与其他构件组合构成更大的构件。4 ) 完成一 个清晰、明确的功能。5 ) 遵循一套接口标准。6 ) 构件必须为复用者提供关于 自身的信息。构件的描述有：7 ) 属性。是指构件可以由外部直接操作的特性， 属性值可读，也可写。8 ) 功能接口。构件向外输出的可操作方法，也是对构件 功能和活动的一种定义。9 ) 依赖关系。指出当该构件被实例化时所依赖的构件 或接口，这是构件完成其功能所必需的部分。 关于构件的描述通常被称为构件的元数据( m e t a - d a t a ) ，构件必须是可以浏 览的，即可以由工具将各个可复用构件的元数据列出来，使复用者能够了解到 西北工业大学硕士学位论文 关于构件的必要信息。构件的设计应该遵循以下原则：1 ) 构件根据子系统或子 功能来划分，使构件与实体相对应。2 ) 构件粒度不宜过大，实现的功能尽量单 一，以方便复用。3 ) 接口设计要友好规范，既要满足信息隐藏的要求，还应该 符合互操作的要求，以便使用。4 ) 扩展性和兼容性，因此设计中的关键是定义 构件应该对外暴露哪些接口以及内部相应的应该实现哪些功能。 对构件进行复用的目的在于使用可获得的构件构造出可运行的应用程序或 者更大的构件。构件组装过程即是把现有构件加入到一个框架中，然后将所加 入的构件利用事件迸行连接的过程。对于源码型构件，相互之间的连接方式相 对简单，只需首先对源码进行必要的分析，然后在调用者代码中适当的位置加 入对被调用者的调用语句即可。采用这种方式，一旦建立起连接关系后就很难 再进行调整，因为连接关系信息被编译在目标码中，如果要对其进行调整，必 须修改源码，并重新编译。分布式构件采用构件接口引用( r e f e r e n c e ) 机制来实 现构件连接。解决了在不改变目标码的前提下加入连接信息的问题。这种连接 方式很灵活，增强了动态配置的功能，使系统可以在运行过程中增加新的构件 或替换旧的构件，并且不影响系统的正常运行。 2 2 2 软件框架 随着应用领域的发展和完善，某些带有整体应用性的结构被逐步“固定”下 来，形成了特定的系统结构，它包括系统的基本构成单元和关系，这就是框架 的原始形成。在基于过程的应用程序开发中包括大量相互调用的过程，这些过 程通常是粗颗粒对象，因此不能在别的应用程序中重用。更进一步将这些过程 拼装在起，形成一个应用程序所需的逻辑关系被分散到应用程序的各个部分， 不能由任一函数或过程所把握。面向对象的应用程序用细粒度的对象取代了粗 粒度的过程，用方法调用取代了过程调用。这些对象由于呈现小粒度特征可 以在别的应用程序中得到广泛重用。面向对象技术在实现信息隐藏和数据抽象 方面是相当成功的，对于可复用设计单元包括具体的类和抽象类，其实例化方 式主要通过子类化抽象类以及对现有具体类方法的调用，确实类和类库实现了 细粒度的对象，它们能被各种程序分享。但是这种细粒度的对象只占全部应用 程序的部分。它们完全不能把握将这些对象拼装在一起所需的逻辑联系，即 完全不能把握软件的体系结构或框架。 随着o o 框架的开发和使用，许多学者意识到了面向对象框架的不足，主 要集中于以下三点：首先是框架的一过度增殖问题”，也就是将变化性“硬变化” 到框架中，这就造成了框架的大量“增殖”：其次是“脆弱的基类问题”，也就 是用户进行扩展而修改基类时，造成对继承类的损害；最后是“隐式的体系结 构问题”，也就是用户需要了解具体的、在代码层次复用的具体类，这样框架体 9 西北工业大学硕士学位论文 系结构被淹没在类的具体实现细节中。 框架更多的是关于应用领域问题己建立的体系结构，所以也称作应用框架。 从设计模型的角度看，应用框架是一个给定应用领域中的完全的软件系统模式， 是大粒度的可复用构件。框架的功能在于：把握许多相似应用程序的结构，为 运行一批对象提供一个有组织的环境。构件不再相互调用方法，而是通过框架 调用方法。不仅构件可以与别的应用程序分享，而且框架本身也可以被其他应 用程序所分享。 从组成上看，框架是一个等待实例化的完整的系统，它定义了一个软件系 统的族和关系，并提供t g j 建它们的基本构件模块。框架也定义了设置功能更 改的插件位置。本质上，框架对相似问题集提供了一种统一的解决方案。这一 层次上的代码重用远超出了基于被动的类库的代码重用。框架的最终目的是能 动态地组装构件，实现软件的即插即用。 框架表示应用程序的一部分，这部分由领域内的专家设计并编码和调试， 开发者只需在框架上再添加上附加值的代码即可。这些附加代码占整个应用的 2 0 ，而框架占8 0 。框架很像类，只能设计和测试一次，开发者通过向框架 中添加区别于其它相似程序所需的动作来建立特定的应用程序。 2 2 3 软件总线 软件总线的概念则把构件和框架的能力扩展到了开发基于网络的应用。它 使数百万独立的软件单元在异构环境下达到无缝的交互操作。对象总线最著名 的是0 m g 的o r b 和微软的d c o m 。 两个相互通信的对象并不需要相互理解对方的语言。对它们来说，只要能 够理解一种共同的语言即可。在软件构件结构中，这种公共语言是一种对象总 线语言。对象总线为所有对象提供了一种向总线描述自己的机制，这种机制通 过一种说明性的、与实现无关的接e l 语言( i d l ) 提供。任何应用程序、软件 系统和工具只要符合i d l 标准规范的接口定义，就可以被方便地集成到分布式 系统中。 2 3 n e t 平台分布式架构 n e t 是m i c r o s o r 提出的新的分布式计算平台，它包含了操作系统上软件 开发的所有层，它提供了任何平台上所见的组件技术、呈现技术和数据技术 的最丰富的集成级别，整个体系结构( 如图2 - - 3 所示) 已经被创建为易于 在高度分布式i n t e r a c t 环境中的应用程序开发，就像进行传统的桌面系统开 发一样。n e t 有以下目标： 望韭三些垄兰堡主兰堡垒圭 1 ) 提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执 行，还是在本地执行但是在i n t e m e t 上发布，或者是远程执行。 2 ) 提供一个将软件部署和版本控制冲突最小化的代码执行环境。 3 ) 提供一个保证代码( 包括所有未知的或不完全受信任的第三方创建的代码) 完全执行的代码执行环境。 4 ) 提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。 5 ) 使开发人员的经验在面对类型大不相同的应用程序( 如基于w i n d o w s 应用 程序和w e b 的应用程序) 时保持一致。 6 ) 按照工业标准生成所有通信，以确保基于n e t 框架的代码可与任何其它代码 集成。 一母_ 田_ 图2 - - 3 n e t 体系结构 n e t 框架具有两个主要部分：公共语言运行时( c l r ) 和框架类库 ( f c l ) 。n e t 框架现实了代码重用、代码规范化、资源管理、多语言开发、安 全、部署和管理。 公共语言运行时：是n e t 框架的基础，将运行时看作一个在执行时管理代码的 代理，它提供核心服务( 如内存管理、线程管理和远程代理) ，而且还强制实施 严格的类型安全以及可确保的安全性、可靠性的其它形式的代码准确性。事实 上，代码管理的概念是运行时的基本原则。 框架类库： a s p n e t ：w e b 应用程序的新一代a s p ( a c t i v es e r v e rp a g e s ) 技术。这种新技 西北工业大学硕士学位论文 术的一个关键功能是强力支持“开发和使用w e bs e r v i c e s ”的应用程序。 a d o n e t ：新一代a d o ( a c t i v e xd a t ao b j e c t s ) 技术，用以访问存储在d b m s s 里的数据，或是以其他格式存在的数据。 w i n d o w sf o r m s ：一套用以开发w i n d o w sg u i s 的标准c l a s s e s ，可用于任何n e t 框架编程语言。 e n t e r p r i s es e r v i c e s ：一套标准c l a s s e s ，用以访问事务和对象池之类的c o m 十服 务。 典型的n e t 分布式计算模型由以下部件组成，如图2 4 所示：从体系结构 图中，我们可以看出作为系统组件包括安全、操作管理、通讯、工作流、商业 组件、数据访问逻辑、以及系统访问外部服务所需的服务代理部件。对于数据 表示层的用户接口可以使用w i n d o wf o r m s 或者w e b f o r m s 的形式，而对于复杂的用户接口，可以提供一个 用户处理组件，对数据进行预处理，同时对用户 的交互进行相应的控制和必要的处理。业务逻辑 层是应用程序的核心部件。体现商业软件的各种 功能。一个商业逻辑是一个完整的业务功能。业 务逻辑可以直接供表示层调用也可以使用服务 的形式提供给表示层。当商业逻辑需要外部的服 务时，可以使用服务代理来对外部功能进行访问。 工作流是对整个业务流程进行控制的部件。工作 流干预工程、业务程序的自动化处理，文档、信 息或者任务，并且按照定义好的规则在参与者之 图2 - 4 n e t 企业应用计算模型图 间传递，来完成整个业务目标或者对整个业务目 标的完成做贡献，例如：利用b i z t a l ks e r v e r 对业务逻辑进行工作流定义，或 者使用第三方的工作流控制软件来完成业务的自动化处理，此时与其它部件的 通讯需要一个松耦合的架构，可以使用m s m q 这样的消息队列机制，或者是 基于a g e n t 的服务机制，从而保持程序的健壮性，并且易于维护。因此对于安 全、事务管理、工作流等内部服务的构件可以使用c o m + w e bs e r v i c e 的形式 来提供服务。 西北工业大学硕士学位论文 第三章保险业务组件开发平台 近年随着经济的迅速发展，保险公司的业务种类和规模在不断地增加，因 此随着保险公司业务量的急剧的膨胀，保险作业系统信息化越来越成为保险公 司的核心竞争力，与此同时企业为了提高相互之间的合作程度以及自身的竞争 力，常常需要将企业内部或者企业之间的应用系统进行集成。本章结合某某人 寿作业系统的开发给出了个保险业务组件开发平台，并且提出了基于x m l 技术的数据整合与交换框架。该保险业务组件开发平台支撑寿险作业流程( 新 契约、销售管理、计划书、保全等) 以任务驱动，结合工作流实现作业部署与 管理，同时辅以影像作业使保险作业流程制度化、透明化、全国服务一体化， 系统开发基于d a t a c l a s sf r a m e w o r k ，提供可重用的保险业务组件，代码实现 配置化开发模式。 3 1 保险业务组件开发平台 在n e t 分布式计算环境中通常采用分层的软件体系结构。表示层：用户接 口可以使用w i n d o w f o r m s 或者w e bf o r m s 的形式，而对于复杂的用户接口， 可以在表示层提供一个用户处理组件，对数据进行预处理，同时对用户的交互 进行控制和必要的处理。例如：可以使用脚本对数据输入规则的进行校验。业 务逻辑层：是应用程序的核心部件：体现商业软件的各种功能。一个商业逻辑 是一个完整的业务功能。业务逻辑可以直接供表示层调用，也可以使用服务的 形式提供给表示层。当商业逻辑需要外部的服务程序时，可以使用服务代理来 对外部功能进行访问。工作流是对整个业务流程进行控制的部件。例如：利用 b i z t a l ks e r v e r 对业务逻辑进行工作流定义，或者使用第三方的工作流控制软件 来完成业务的自动化处理。数据层：d a l c ( 数据访问逻辑组件) 可以实现对 后台数据库的无关访问，为不同的数据库提供了相同的接口引擎，屏蔽了与数 据库相关的细节。东方人寿保险作业系统借助当前的n e t 分布式计算环境，应 用服务器采用基于中间件技术的分布式架构方案。整个业务系统分成如下三层： 基础平台层：负责数据类访问逻辑，同时提供客户端对服务端的对象引用以及 在引用上的操作，相关的对象查找( 定位) 、分布事务管理、安全机制等内容。 保险业务逻辑层：一般保险行业的需求有关的设施、部件，使平台能适应更多 的保险行业。东方寿险业务层：与东方寿险的具体业务相关的部分，这是该软 件系统中的真正的应用层。同时东方寿险业务系统使用了应用服务器，一些安 全、事务处理管理机制由该应用服务器完成。 西北工业大学硕士学位论文 基于以上思想，整个东方保险业务组件开发平台包括以下重要的功能组 件：d a t a c l a s sf r a m e w o r k ，通讯部件，工作流引擎与服务，界面重用组件， 以及消息中间件m s m q 。d a t a c l a s s 、类行为、界面重用组件等通过框架提供 的工具进行配置化开发，以提升开发速度。其东方业务组件开发平台部署如图 3 1 所示。后续将简要介绍这些重要组件的功能及含义。 图3 1 东方业务组件部署图 3 1 1 d a t a c l a s sf r a m e w o r k d a t a c l a s sf r a m e w o r k 一保险业务开发平台框架的核心组件，主要功能 为对数据的持久化操作( o - r m a p p i n g ) ，实现o b j e c t 到数据库记录的映射，为 保险业务中的业务逻辑提供数据入口。同时该框架用行为类a c t i o n c l a s s 对业务 行为进行封装，该行为类通过框架配置工具建立与数据类的关联，这样就完整 的表达了业务对象( 业务数据+ 业务逻辑) 。由于数据类与行为类的分离，从而 将针对数据操作的行为及业务逻辑集中在应用服务器进行，实现分层处理。该 框架如图3 2 所示： 4 西北工业大学硕士学位论文 图3 2 d a t a c l sf r a m e w o r k 图 d a t a c l a s s 数据功能：从数据抽象的角度看，数据类是一个类似于视图的概 念，它抽取了若干表中的若干字段通过连接形成一个逻辑表，在此基础上来完 成数据的查询和更新操作，完成数据库的记录到对象的映射。每个d a t a c l a s s 均有唯一的i d - - c l a s si d 用来识别各个数据类，然后每个数据类实例化后使用 唯一的i d o b j e c ti d 来标识。数据类通过框架工具进行配置化开发，配置完 成后这些数据类的元数据( m e t a d a t a ) 存放于数据库中，当实例化一个数据类 时，通过定义于数据库的元数据来动态生成内存对象，从而完成业务数据的存 取操作。d a t a c l a s s 的生命期均被分割成两部分：创建期和行为期。d a t a c l a s s 在创建期专门从事c r u d ( 新增、读取、修改、删除) 行为，负责所有与数据 交互有关的工作，包括从数据库中提取记录填充类的属性，将类的数据修改结 果保存到数据库等工作，同时包括读取创建期脚本并执行；在数据类封装的体 系中，主要涉及到这样的几个类： 1 ) d a t a c l a s s ：提供数据类的实现。包含的主要的数据属性有：用于唯一的标志 了该数据类的i d ，用于记录父数据类的i d ，用于存储一条记录的数据行。 数据类提供了新建，读取，删除，保存，执行创建期交互等几个主要的方法 供业务对象操作。 2 ) d a t a c l a s s f r a m c ：用于构造数据类的对象结构，通过向数据服务发送数据请 求，并以x m l 格式字符串返回数据类定义信息，并根据这些信息构造数据 类的所有数据属性，所有创建期交互，以及数据类的所有子类管理器。 3 ) d a t a c l a s s c h i l d m g r ：予数据类管理器用于管理子数据类对象。 4 ) d a t a c l