（计算机系统结构专业论文）基于mda架构的民生银行客户交流系统的设计与实现.pdf

摘要 信息技术的飞速发展给人们的生活方式带来了巨大的变化，其中 一个重要的变化即反映在人们交流方式的改变上，因此对于商业银 行来说传统的柜台坐席式的服务模式已经不能够满足时代发展的需 求。同时在中国已经加入w t o 组织这个大背景下商业银行将来势必 还要面临着跨国银行的挑战，因此如何能够给客户提供更快捷和更 高质量的服务成为了商业银行的一个重要难题。 本文通过对当今主流交流方式的研究并结合银行客户的需求，研 究和设计了一个基于电话、手机短信和邮件等交流方式的新型银行客 户交流系统。同时鉴于传统软件开发的各种弊端，本文还对o m g 组 织提出的m d a ( m o d e ld r i v e na r c h i t e c t u r e ) 架构思想进行了详细的分 析和研究，并在此基础上提出了一套自己的解决方案去构建和实现银 行客户交流系统。 在具体系统开发过程中鉴于面向对象开发与传统关系数据库的 矛盾，本文还对对象持久化技术进行了研究和分析，并提出和实现了 一套自己的持久化解决方案。最后针对开发过程中的遇到的那些“长 事务业务逻辑，论文还对工作流技术进行了研究。并利用开源工 作流引擎s h a r k 在系统中给出了相应的实现。 本文实现的民生银行客户交流系统界面友好，功能完善。同时针 对未来电信运营商有可能开通3 g 服务和i p t v 服务的情况，本系统 还给未来的视频交流留出了扩展接口。系统上线运行之后受到了客户 和银行机构的广泛好评。 关键词m d a ，对象持久化，工作流，s h a r k a bs t r a c t t 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 yh a sb r o u g h tg r e a t c h a n g e si np e o p l e sd a i l yl i f e ，e s p e c i a l l yo nt h ew a yo fc o m m u n i c a t i o n t oc o m m e r c i a lb a n k t h et r a d i t i o n a ls e r v i c eo fs i t t i n gi nt h ec o u n t e rc a l l n o tm e e tt h ep r e s e n tn e e d sa n ym o r e m e a n w h i l ec o m m e r c i a lb a n ks h o u l d f a c et h ec h a l l e n g e sf r o mm u l t i n a t i o n a l b a n ks i n c ec h i n ah a sa l r e a d yb e e n am e m b e ro f 呵o t h u st oo f f e ram o r ec o n v e n i e n ta n db e t t e rs e r v i c et o c u s t o m e r si sb e c o m i n gam a j o rd i f f i c u l tt a s ka tp r e s e n t t h i st h e s i sm a k e sar e s e a r c ha n dd e s i g no fn e wc u s t o m e r c o m m u n i c a t i o ns y s t e mb a s e do nt e l e p h o n e ，m o b i l em e s s a g ea n de - m a i l b yi n v e s t i g a t i n gc u r r e n tp o p u l a rw a y so fc o m m u n i c a t i o n sa n dc o m b i n i n g t h en e e d so fb a n kc u s t o m e r s m e a n w h i l ec o n s i d e r i n gt h es h o r t c o m i n g so f t r a d i t i o n a ls o f t w a r ed e v e l o p m e n t ，t h i st h e s i sa l s oc o v e r st h ed e e pa n a l y s i s a n dr e s e a r c ho fm o d e ld r i v e na r c h i t e c t u r ew h i c hp r o p o s e db y0 m g o r g a n i z a t i o n m o r e o v e rt h i st h e s i sp r o p o s e sas o l u t i o nt od e s i g na n d i m p l e m e n tt h ec u s t o m e rc o m m u n i c a t i o ns y s t e m c o n c e r n i n go ft h ec o n f i c tb e t w e e nt h eo b j e c t o r i e n t e dd e v e l o p m e n t a n dt r a d i t i o n a lr d b m s t h i st h e s i sf o c u s e so nt h er e s e a r c ha n da n a l y s i s o fo b j e c tp e r s i s t e n c et e c h n o l o g ya n da l s op r o p o s eas o l u t i o no fo b j e c t p e r s i s t e n c ef o rt h ec o m m u n i c a t i o ns y s t e m a tl a s ti no r d e rt om a k et h i s s y s t e md e a lw i t hc o m p l e xt r a n s a c t i o n s t h i st h e s i sa l s om a k e sr e s e a r c ho n w o r k f l o wt e c h n o l o g y , b yu s i n gao p e n s o u r c ew o r k f l o we n g i n e - s h a r ki n s y s t e ma n di m p l e m e n t i t t h ec u s t o m e rc o m m u n i c a t i o ns y s t e mi nm i n s h e n gb a n ks t a t e di n t h i st h e s i sh a saf r i e n d l yi n t e r f a c ea n dw e l lf u n c t i o n s r e g a r d i n gt e l e c o m m a n a g e m e n tw i l lp r o v i d e3ga n d 口t vs e r v i c e ，t h i ss y s t e ml e a v ea e x t e n d e di n t e r f a c ef o rv i d e oc o m m u n i c a t i o ni nt h ef u t u r e i tg o tav e r y g o o df e e d b a c kf r o mc u s t o m e r sa n db a n ka f t e ru s i n g k e yw o r d sm d a ，o b j e c tp e r s i s t e n c et e c h n o l o g y ，w o r k f l o w , s h a r k l i 原创性声明 本人声明，所呈交的学位论文是本人在导师指导下进行的研究 工作及取得的研究成果。尽我所知，除了论文中特别加以标注和致谢 的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不 包含为获得中南大学或其他单位的学位或证书而使用过的材料。与我 共同工作的同志对本研究所作的贡献均己在论文中作了明确的说明。 作者签名： 丛生：盛 日期：! ! 年月尘日 学位论文版权使用授权书 本人了解中南大学有关保留、使用学位论文的规定，即：学校 有权保留学位论文并根据国家或湖南省有关部门规定送交学位论文， 允许学位论文被查阅和借阅；学校可以公布学位论文的全部或部分内 容，可以采用复印、缩印或其它手段保存学位论文。同时授权中国科 学技术信息研究所将本学位论文收录到中国学位论文全文数据库， 并通过网络向社会公众提供信息服务。 储签名：鲥址导师签名主烨日期业月笙日 硕士学位论文 第一章绪论 1 1 课题的研究背景与来源 第一章绪论 信息技术的飞速发展给人们生活带来了巨大的变化，很多传统的信息交流方 式已经不能再满足时代发展的要求。在银行机构中，传统的人工柜台式客户服务 系统已经被采用和实行了几十年，然而这种客户与银行服务人员之问面对面的服 务方式需要大量的人力资源。对于商业银行来说，尤其是在中国已经加入w t o 组 织这个大背景下，将来势必会面临着国外跨国大银行的挑战，如何能够更高效率 和更高质量的满足自己的客户成为了必须解决的首要问题。同时随着i n t e r n e t 技 术的发展和个人手机的普及，相对于过去那种主动上门投诉和寻求服务的方式， 人们更愿意能够足不出户的得到各种服务。因此设计和实现一个基于新型交流方 式的银行客户交流信息系统成为了银行机构面临的一个重要课题。 同时由于传统的软件产业本身也存在着许多问题。其表现为开发效率不高， 常常会因为各种问题而使项目超期，经过长时间开发出来的信息系统也存在的质 量问题，通常需要耗费大量的人力去进行后期的维护。由于这些原因所以软件开 发成本也往往是大大超出预期，很多情况下公司不得不放弃那些最终成本代价过 高的项目，或者是减弱其原先设计的功能来节约成本。虽然目前软件业经过几次 软件危机之后，先后提出了基于软件工程的开发方法和许多被验证为成功的设计 模式和框架。然而这些并没有从根本上解决现今软件业面临的问题。 模型驱动架构( m o d e ld r i v e na r c h i t e c t u r e ) 就是在这样的大背景下被提出的 一种新型软件开发方法。2 0 0 2 年国际对象管理组织( o m g ) 提出了m d a 这个新型概 念，震惊业界。人们从o m g 组织的关于m d a 描述中似乎看到了未来软件开发的 美好情景。那就是不只是现在传统意义的程序员能够参与软件和系统的开发，连 不懂代码开发的业务人员和客户也可以参与其中，只要他们熟悉如何去给业务建 模【l 。3 】。而学习和掌握建模技术比起学习复杂的计算机编程语言和各种开发平台 要来得简单很多，同时一旦客户和业务人员能够参与到系统的开发工作，那么就 能够很大程度的减少因为传统代码开发人员与业务人员之间因为需求理解的偏 差而造成的系统开发时间的浪费。同时在模型驱动架构思想中软件开发将会以模 型为中心而展开，大部分的框架代码将会由系统根据模型自动生成【2 圳。这同时 也能解决传统开发过程中的代码冗余和重复利用问题。 本课题是在我的导师的安排和指导下，通过项目研究和合作的方式与北京长 信通信息技术有限公司一起合作开发和实现了一个基于m d a 架构的新型客户交 硕士学位论文 第一章绪论 流系统。 1 2 课题的研究现状 目前各大银行和企业基本上都有了自己的一套交流信息系统。但是系统具有 的功能复杂程度不一，大多数只是简单的短信平台，实现了用短信的方式与客户 进行交流。而基于模型驱动架构思想进行开发的交流平台如今市场了基本上还没 有成功的案例。这和模型驱动架构本身也是有很大的关系。 模型驱动架构的基本方法其实已经被使用了很多年，早在“m d a 这个词 出现之前它就已经应用于嵌入式和实时系统。基于s c h l a e r - m e l l o r 的系统用于为 多种电子设备生成嵌入式代码，从对象模型产生数百万行c c + + 代码来完成复杂 的电信交换。目前m d a 的应用已经进入众多i t 组织中，在全球1 0 0 0 家i t 组 织中许多企业级的m d a 工程正在开展。然而m d a 毕竟还处于起步阶段，它的 成长中仍然存在很多问题。我们知道模型驱动的方法作为下一代软件开发的方 法，核心应该是工具的发展，而不仅仅是方法和理论的发展【5 7 】。现有的工具如 a n d r o m d a 、a r c s t y l e r 和o p t i m a l 这些工具都声称可以生成遵循m d a 的设计方 法，但其实大多只用于数据库应用程序，这些应用的特征是a c i d 事务，处理对 象是大量的数据，但是在数据上只进行相对简单的计算【8 1 0 】。有一些工具则可以 用在企业应用中，从业务逻辑建立模型，然后可以把绝大多数的业务逻辑转换为 实体类的规则。另有些工具只产生结构代码，作为常规的操作都被包含在实体模 型中，但是对于商务逻辑的事务操作，这些工具只产生空的方法体。因此就目前 来看，基于m d a 架构的应用还只停留在某些特殊领域的应用上【1 1 j4 1 。由于m d a 工具发展的局限以及作为一种新型软件开发方法所带来的风险影响所致，目前完 整的基于m d a 架构的商业级应用还非常少，其中就包括一些开源研发组织研究 和实现的轻量级商业应用。目前最出色的应用就是德国开源组织研发的基于开源 m d a 平台- - o p e n m d x 平台的c r m 应用o p e n c r x 。 1 3 课题的研究目标和意义 目前商业银行的交流平台基本上都是采用传统开发方法进行开发和实现。功 能单一，扩展性较差，同时维护成本也比较大。这很大程度的原因是由基于传统 软件方法开发的系统自身特点所致。由于传统方法开发的系统是基于代码为核心 的。而像银行交流平台这样的系统通常会在线运行很多年，随着项目组人员的更 替，在日后的日常需求更新和维护工作中，不可避免的要发生许多因为开发人员 没有完全理解先前项目组成员的代码或者是先前代码本身就有问题的情况而导 2 硕士学位论文 第一章绪论 致的生产事故或者系统维护问题。同时在系统维护工作中，还有可能存在客户或 者业务人员在与代码开发人员之间的沟通和交流问题。而这些问题是基于传统开 发方法的系统本身所无法克服的。本课题研究的目标是采用先进的m d a 思想去 重新实现一个银行客户交流系统。由于在基于m d a 架构的系统中，模型将会取 代代码成为系统的核心，而相对于繁琐的代码模型更加容易被理解和实现。而通 过对建模技术的学习，业务人员也可参与到系统的开发和维护中。从而能够提高 系统的质量，减轻系统维护的工作量。 1 4 论文组织 全文共分为六章，内容组织如下： 第一章主要介绍本课题基于m d a 架构的客户交流平台的研究背景、现 状和意义。 第二章介绍了基于m d a 思想的软件开发以及与传统开发的区别。同时还 介绍了基于m d a 思想的软件开发的具体实现方式。 第三章通过对基于m d a 架构的软件开发思想研究的基础上，在本章中对 客户交流系统进行架构和功能模块的详细设计。 第四章通过前面对系统的架构和功能上的详细设计，本章将结合o p e n m d x 平台对系统的重要功能模块进行p i m 模型的设计，同时对o p e n m d x 平台的模型 映射机制进行了研究和探讨，最后给出了系统的实现。 第五章在本章中将对客户交流系统开发过程中遇到的各个难题进行了分析 和探讨，并相应的给出了在客户交流系统中的具体解决方案。 第六章对本文研究工作取得的成果进行了描述和总结，并对本课题的研究 工作中存在的不足进行了分析，并在此基础上提出了未来研究工作中仍需解决的 问题。 硕士学位论文 第二章基于m d a 的软件开发技术探讨 第二章基于m d a 的软件开发技术探讨 2 1 什么是m d a m d a 即模型驱动架构( m o d e ld r i v e na r c h i t e c t u r e ) ，是对象管理组织( o m g ) 于2 0 0 2 提出的一种对业务逻辑建立抽象模型，然后从抽象模型自动产生最终的 完备的应用程序的新型软件开发方法学【1 5 1 8 】。它是一种基于u m l 和其他工业标 准的框架，支持软件设计和模型的可视化、存储和交换。和u m l 相比，m d a 能够创建机器可读和高度抽象的模型，这些模型以独立于实现的技术开发，以标 准化的方式存储。因此，这些模型可以被重复访问，并被自动转换为纲要 ( s c h e m a ) 、代码框架( c o d es k e l e t o n ) 、测试工具( t e s th a r n e s s ) 、集成化代码以 及各种平台的部署描述。m d a 把建模语言当作一种编程语言而不仅仅是一种设 计语言。m d a 致力于提高软件开发行为的抽象级别，倡导将业务逻辑定义为精 确的高层抽象模型，让软件开发人员从繁琐的重复的低级劳动中解脱出来去更多 地关注业务逻辑层面【1 9 2 2 】。它代表了o m g 组织定义的互操作性规范的一个革命 性进步。 m d a 将软件系统的模型分为平台无关模型p i m ( p l a t f o r m - i n d e p e n d e n t - m o d e l ) 和平台相关模型p s m ( p l a t f o r m - s p e c i f i c - - m o d e l ) ，同时又能通过转换规 则将它们统一起来，以这样的方式来解决需求变更所带来的问题【2 3 2 5 1 。平台无关 模型p i m 是对工作流程的高层次抽象，其中不包括与实现技术相关的信息。平 台相关模型p s m 是跟特定平台相关的模型，在需求分析阶段要使用平台无关的 建模语言，来针对业务过程搭建平台无关模型p i m 。然后，在低层设计阶段p i m 将被转换为一个或多个平台相关模型( p s m ) ，这个翻译的过程一般是自动实现 的，它将用到这种技术所提供的种种架构，比如e j b 、数据库模型、c o m 组件 等等。之后，在编码和测试阶段根据特定平台和实现语言的映射规则，自动生成 应用程序代码和测试框架。m d a 被面向对象技术界预言为未来两年里最重要的 方法学，它以一种全新的方式将i t 技术的一系列新的趋势性技术整合到一起。 这些技术包括基于组件的开发( c o m p o n e n t - b a s e dd e v e l o p m e n t ) 、设计模式 ( d e s i g n p a t t e r n )、中间件( m i d d l e 2 w a r e )、说明性规约( d e c l a r a t i v e s p e c i f i c a t i o n ) 、抽象( a b s t r a c t i o n ) 、多层系统( m u l t i t i o - e ds y s t e m ) 企业应用 整合( 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 ) 以及契约式设计( d e s i g nb yc o n t r a e t ) 【2 睨引。m d a 的出现，为提高软件开发效率，增强软件的可移植性、协同 工作能力和可维护性，以及文档编制的便利性指明了解决之道。 4 硕士学位论文第二章基于m d a 的软件开发技术探讨 m d a 有如下特点： ( 1 ) 模型驱动。m d a 认为一切都是模型。 ( 2 ) 业务导向无关性。业务导向是指m d a 基于企业工程理论和企业参考模 型，为软件设计和开发提供有效的导向和依据，帮助开发者全面、正确和迅速地 实现管理者的管理和业务要求，大幅度地提升管理软件的开发、发布和维护的效 率及质量，并在业务持续完善的过程中实现快速调整。 ( 3 ) m d a 是一个开发的、中立于软件商的架构，能支持异构系统之间的互操 作。它从系统模型层次上来解决互操作性的问题，互操作性能够实现的一个重 要原因就是设立了元模型的规则，元模型在规范中、建模技术中和元数据中都是 主要的活跃因素。互操作性最终都是通过共享的元数据理解元数据的策略来实现 的。 ( 4 ) 独立于程序设计语言和平台。m d a 通过运行平台直接执行企业的业务， 实现业务模型和系统实现技术的分离，使应用系统可以在各类主流和标准的基础 平台上运行，并可以顺利地迁移到未来的实现技术上。 ( 5 ) m d a 意味着更多的“组装 而不是“开发 。在为一个应用建立p i m 的时候，基本上没有技术上的周旋空间。 2 2 基于m d a 的软件开发过程 ( 1 ) m d a 的两个重要模型 m d a 的关键之处是，模型在软件开发过程中扮演了非常重要的角色。在 m d a 中，软件开发过程是由软件系统的建模行为驱动的。下面将介绍m d a 中的 两个重要模型。 平台独立模型( p l a t f o r mi n d e p e n d e n tm o d e l ) ：m d a 定义的第一模型是具 有高抽象层次、独立于任何实现技术的模型。我们把这类模型叫做平台独立模型， p i m 描述支撑某些业务的软件系统。在p i m 中，对系统的建模视角是“系统如 何才能最好的支撑业务。至于系统是用大型机上的关系数据库实现，还是用 e j b 应用服务器实现，则不是p i m 关心的内容。 平台相关模型( p l a t f o r ms p e c i f i cm o d e l ) ：平台相关模型是为某种特定实现 技术量身定做的，在p s m 中你使用这种技术中可用的实现构造来描术系统。例 如，e j bp s m 是用e j b 结构表述的系统模型。它通常会包含e j b 特有的术语， 比如“h o m ei n t e r f a c e ”、“e n t i t yb e a n ”、“s e s s i o nb e a n ”等等。关系数据库p s m 则包含“表”、“列 、“外键 等术语。p s m 只对了解相应平台的开发者有意 义。 ( 2 ) 与传统开发方式的比较 硕士学位论文第二章基于m d a 的软件开发技术探讨 从m d a 开发生命周期来看，似乎和传统的开发没有太大的不同。但是实际 上二者有一个关键的不同点。那就是在传统开发中，从模型到模型的变换，或者 从模型到代码的变换，主要是通过手工来完成的。许多工具可以从模型生成一部 分代码，但是往往止步于生成一些模板代码，大部分工作还是需要手动完成。而 且在传统的软件开发中，模型通常只是作为项目开发过程中的一个图示参考而 已。比如说各种u m l 类型图或者是手工绘制的图的创建通常只是在项目初期或 者是一个新的案例需求提出时为了项目组中的成员更好的沟通和理解而由有经 验的人创建，这个人通常是项目组经理。而创建后的u m l 模型图在项目组真正 进行开发的时候通常会被摒弃，而不会继续在项目中发挥作用。而m d a 则不同， 在基于m d a 架构的系统开发中，模型将始终会作为一个核心概念在项目开发中 发挥作用。同时区别与传统的软件开发在m d a 中模型变换将总是由工具来执行， 许多基于m d a 思想的工具可以把通过模型转换而来的具体平台的模型p s m 直接 转换成代码。m d a 的创新之处还在于把p i m 到p s m 的变换也自动化了。因此， 在m d a 中，开发者的焦点转移到了p i m 的开发。所需的p s m 是通过变换自动 从p r i m 生成的。当然，需要有人来确切定义这个变换，这是件困难的专门任务。 但是这样的变换只需要被定义一次，然后我们就可以在开发系统时多次应用这个 变换了。这种工作一般是有丰富经验的专家来完成。传统的软件开发过程如图 2 一l 所示。 图2 - 1 传统的软件开发流程 6 硕士学位论文第二章基于m d a 的软件开发技术探讨 下面我们将通过一个图示来了解m d a 的系统架构，如图2 2 所示我们看到 在m d a 架构的顶层是元语言，在m d a 架构中将采用o m g 组织提出的 m o f ( m e t a - o b j e c tf a c i l i t y ) 规范对元语言进行描述和解释。在下一节中我们将具 体描述m d a 的几个重要规范。 图2 2m d a 应用系统架构图 2 3m d a 的四个核心规范 m d a 架构的思想其实在很早的时候就已经被提出，然而却一直没有应用于 实际的软件开发过程中，这主要是因为没有相应的规范和标准的支持。国际对象 管理组织o m g 不仅明确的提出了m d a 架构思想，同时也建立了一系列的规范和 标准，它们使得m d a 技术的实现成为可能，其中m d a 中最重要的四个规范分别 是u m l 、m o f 、c w m 和x m i t 2 9 】。 ( 1 ) u m l ：u m l 是m d a 存在的基础，使用m d a 技术创建的所有应用程序都 基于标准化的、平台独立的u m l 模型。u m l 被m d a 用来描述各种模型。它并不 是为m d a 而生，但是作为目前最为风行的建模语言，u m l 已经占据了全球建模语 言领域9 0 的市场份额，成为了建模语言事实上的标准。它是m d a 的基础，也是 m d a 最有力的武器。 ( 2 ) m o f ：m o f ( m e t a o b j e c tf a c i l i t y 元对象机制) 是比u m l 更高层次的抽 7 硕士学位论文 第二章基于m d a 的软件开发技术探讨 象，它的目的是为了描述u m l 的扩展或者其它未来可能出现的类u m l 的建模语 ( 3 ) x m i ：x m i ( x m l b a s e dm e t a d a t ai n t e r c h a n g e ) 是基于x m l 的元数据交 换。它通过标准化的x m l 文档格式和d t d ( d o c u m e n t t y p ed e f i n i t i o n s ) 为各种模 定义了一种基于x m l 的数据交换格式。这使得作为最终产品的模型可以在各种 不的工具中传递，保证了m d a 不会在打破了一种束缚之后再被加上一层新的束 缚。x m i 规范支持任何可以用m o f 表示的元数据( 包括模型和元模型) 的数据转 换。规范同时支持完整的模型或是一个模型的片断到x m l 的转换。 ( 4 ) c w m ：c w m ( c o m m o nw a r e h o u s em e t a m o d e l 公共仓库元模型) 提供了 一种数据格式变换的技术，在任意级别的模型上都可以使用c w m 来描述两种数 据模型之间的映射规则，比如将数据实体从关系数据库变换为x m l 格式。在 m o f 的框架下，c w m 使得通用的数据模型变换引擎成为可能。 2 4m d a 的实现 2 4 1m d a 的实现方法 我们知道m d a 只是国际对象管理组织o m g 提出的一种新型软件开发思想 和架构。就像j 2 e e 平台一样，m d a 也只是一个规范和标准，并不是一个具体的 实现。就目前而言，m d a 的实现方法主要有两种。 ( 1 ) 直接使用模型去驱动应用程序的开发。模型包括平台无关模型和具体平 台相关模型。 ( 2 ) 用模型去驱动m d a 运行时系统。在该方法中，模型并不直接去驱动应 用程序的开发，而去直接作用于一个实现m d a 架构的运行时系统，再由运行时 系统去完成和实现具体的应用。 像目前市场上大部分的支持从u m l 模型转换的代码生成工具都可以归入第 一种实现方式。其中比较典型的代表工具是a n d r o m d a 。 而第二种实现方式的典型代表则是o p e n m d x ，它是一个开源的m d a 运行时 系统，客户交流平台的m d a 实现正是基于该运行时系统的。 2 4 20 p e n m d x o p e n m d x 是一个开源的m d a 运行时系统。他实现了o m g 坌 h 织提出的m o f 、 x m i 、j m i 、u m l 等标准同时也从其他标准中继承了很多的概念和模式，比如说 j d o ( j a v ad a t ao b j e c t s ) 。o p e n m d x 最早的框架版本是用作m o f 标准的c o r b a 接 硕士学位论文第二章基于m d a 的软件开发技术探讨 口库的实现的而后通过不断的功能扩展，如今已经完全有能力承载和运行一个 复杂的商业应用3 0 - 3 1 1 。 2 4 3o p e n m d x 与其他m d a 工具间的比较 下面我们将通过和传统的m d a 开发工具之间的对比来了解o p e n m d x 平台 的工作原理。传统的m d a 开发过程如图2 3 所示。 g e n e r a t i v em d ad e v e l o p m e n tp r o c e s s m o d e l c h a n g e p i m 托n o w - | h o w e j b n 幽f 鼍瞄 _g = oo 团v目日 图2 - 3 传统的m d a 开发过程 我们可以看到传统的m d a 开发过程主要分为以下几个步骤 ( 1 ) 平台无关模型的建模阶段。首先将根据业务逻辑生成遵循m o f 规范的 平台无关模型。这里的平台无关模型通常是指用o m g 组织的统一标准建模语言 u m l 所生成的模型。在m d a 的思想中只要是与具体平台无关的业务模型都属 于兼容的p i m ，将来也许有新的建模标准语言出现，m d a 的m o f 规范使得m d a 能够支持这种扩展。 ( 2 ) 具体平台模型的建模阶段。在这一步中将根据第一步建模阶段生成的 p i m 模型结合具体平台的相关信息，从而生成具体平台的p s m 模型。在m d a 中p i m 到p s m 模型的转换过程是通过具体的工具来实现的。像目前市场上的 i b m 公司的r a t i o n a ls o f t w a r ed e v e l o p m e n t 等工具都可以实现这两种模型之间的 转换功能。 ( 3 ) 开发阶段。在这一步中将把建模阶段生成的p s m 模型作为输入参数，通 过代码生成工具，生成具体平台的代码。同时也将根据业务逻辑手工写一些代码 进行必要的补充。如图2 3 所示，其中的g 表示由m d a 工具自动生成的，而m 则表示手工修改的。手写的和通过工具自动生成的代码将会被打包成具体平台的 组件。我们可以看到在这一步的具体平台模型到代码的转换过程也是通过工具来 硕七学位论文第r 二章基丁m d a 的软件开发技术探讨 实现的，像目前市场上比较流行的a n d r o m d a 就是这种能够实现模型到代码映射 转换的工具。 ( 4 ) 部署阶段。我们在前面的开发和建模阶段已经得到了具体平台的代码， 同时也完成了对这些资源的打包工作。在这一步中我们将前面生成的东西以组件 的形式部署到具体平台中。 o p e n m d xm d ad e v e l o p m e n tp r o c e s s k n m * - | h o w 图2 4 基于o p e n m d x 的软件开发过程 ，女镕德i r p l a t f o r m c h a n g e j b p b t ，* m 懵 我们可以看到基于o p e n m d x 平台的m d a 丌发过程也是分为建模、开发和 部署三个阶段。但是每个阶段的具体工作有别于传统的m d a 开发过程。主要由 以下几个步骤组成。 ( 1 ) 首先与一般的m d a 开发方法一样在建模阶段先根据应用逻辑建立平台 无关模型。 ( 2 ) 在开发阶段，将m o f 映射j m i ( j a v a b a s e dm e t a d a t ai n t e r c h a n g e ) 矛i x m i ( x m l b a s e dm e t a d a t ai n t e r c h a n g e ) 作用于建模阶段产生的p i m 模型。由于j m i 的接口和实现中只包含最普通的j a v a 对象，而不含任何与具体平台相关的类和 接口。因此在这一步的映射过程中不需要任何与具体平台相关的信息。相应的应 用逻辑，客，、端和服务器端都要分别实现j m i 接口。 ( 3 ) 在部署阶段。我们将产生的m o f 映射，应用逻辑，m d x 平台以及具体 平台的相关配置信息打包到一个组件中。在这一步中j 将p i m 模型与具体平台 挂钩。 我们可以看到相对于传统的m d a 丌发过程，基于o p e n m d x 平台的m d a 丌 发省去了将p i m 模型扩充成具体平台相关模型这个步骤。同时直到最后部署阶 段才将p i m 模型与具体平台进行绑定。这样做将会有以下几点好处。 茹嗍 硕士学位论文第二章基于m d a 的软件开发技术探讨 ( 1 ) p i m 模型不需要被扩充成p s m 。这使得模型变得很轻便。 ( 2 ) p s m 建模使得建模变得复杂，同时容易出错。m d x 使得建模人员不需要 去考虑太多平台相关的信息。 ( 3 ) 应用逻辑是平台无关的。因此他实现了j m i 接口，而j m i 中是不带任何 与具体平台相关的信息的。因此使得代码看起来很轻便，因此代码中不包含与任 何平台相关编码。 ( 4 ) 由于传统的m d a 开发方法中会有一个p s m 到具体平台代码的独立实现 过程。因此同时也会产生代码维护问题。因为每次的p s m 到代码映射过程都会 产生新的代码而这将有可能覆盖前面产生的一些代码。因此也增加了开发和维护 的工作量。而o p e n m d x 平台并没有p s m 模型到具体代码的映射过程，因此也就 不存在这种维护问题，从而能够较大程度的提高工作效率。 ( 5 ) 由于最后阶段系统维护资源中只包括p i m 模型和o p e n m d x 平台相关的 插件，因此也使得资源简洁且容易维护。 2 5 本章小结 在本章中本文对o m g 的m d a 架构思想进行了详细的描述和研究，并对当 下m d a 的实现方式进行了各种探讨和比较。最后对客户交流系统的m d a 解决 方案o p e n m d x 运行时系统进行了详细的描述和研究。 硕士学位论文第三章客户交流系统的总体设计 第三章客户交流系统的总体设计 3 1 客户交流系统的需求分析 随着信息技术的发展，人们的生活也同时发生了巨大的变化。其中很重要的 一点就反映在人们的通讯手段上。现今的i n t e r n e t 、手机短信等己渐渐成为了人 们生活中主要的通讯方式。中国民生银行北京总行根据自身发展的需要提出实现 一个能够利用电话、短信、邮件等信息交流手段与客户进行信息交流的一个新型 平台。它需要具备以下特点： ( 1 ) 必须保证信息交流的及时、可靠。交流平台作为民生银行和客户交流的 中间信息平台，首先要保证交流的实时性和信息的可靠性。 ( 2 ) 支持多种信息交流的载体。同时能够给未来的其他信息交流手段留出扩 展接口，比如说将来电信运营商开通3 g 和i p t v 服务后能够无缝的支持视频交流。 ( 3 ) 可实现信息互动交流。比如短信交流方式，交流平台不但需要能够支持 民生银行通过短信方式给客户提供各种服务，也需支持客户可以通过短信方式向 银行定制各种服务和提出建议和投诉。 ( 4 ) 系统必须容易维护。因为作为银行的交流系统来说，实时性能是一个重 要指标，交流平台必须要能保证上线之后容易维护。 ( 5 ) 系统可根据需要进行扩展。交流平台必须能给未来因为民生银行的业务 新需求所带来的功能扩展留出接口。 ( 6 ) 交流平台必须具备对交流信息和交流行为进行管理及统计分析。为民生 银行未来制定新策略提供各种数据参考。 3 2 客户交流系统的功能模块分析 客户交流系统从功能上可分为以下几个模块。 ( 1 ) 管理中心 管理中心对客户交流的操作进行管理；对系统的重要数据进行配置；同时运 营管理机构的用户可使用浏览器登录到客户交流系统的管理中心，对系统进行维 护；营业网点的用户可使用浏览器登录到客户交流系统的管理中心生成信息发送 任务。 ( 2 ) 交流中心 交流中心是整个客户交流系统的核心，它控制银行系统与客户之间信息交流 1 2 硕士学位论文第三章客户交流系统的总体设计 的过程。由应用网关、业务处理平台、信息发送处理交易和信息发送队列处理程 序几部分组成，其中各组成部分的功能如下： 应用网关在交流中心起着中间桥梁的作用，对请求报文进行认证、根据路 由配置对于各种业务请求进行协议转换、报文的转发和报文转换。 业务处理平台完成应用协议的转换、调度交易业务流程、管理交易的事务 等功能。 信息发送处理交易完成信息发送数据的检查，登记、转发及缓存。 信息发送队列处理程序负责将信息发送数据组成发送报文，并发送给客 户。 ( 3 ) 开发中心 主要为客户交流定制个性化的信息模板，同时为了和客户应用系统进行良好 的集成提供相应的应用程序接口。开发中心包括： 信息分类管理 标准域管理 信息模板管理 ( 4 ) 信息发送a p i 是客户交流系统和银行业务系统结合的部分。信息发送a p i 完成以下功能： 根据用户系统的信息发送数据生成信息发送报文。 将信息发送报文发送到客户交流系统的应用网关。 交流平台的功能模块图和系统结构图分别如图3 1 和图3 2 所示 图3 1 交流平台的功能模块图 硕士学位论文 第三章客户交流系统的总体设计 图3 - 2 客户交流系统的系统结构图 3 3 客户交流系统的系统架构设计 本交流平台底层技术架构是基于j 2 e e 技术、采用w o r k f l o w 和最先进的m d a ( 模型驱动架构) 技术的企业应用系统架构。图3 3 所示的是客户交流平台的系 统架构图 - b bc 口n t - j n r “ j x _ l 滋戮溺溺缫麟ii 萋。：，。 b 熟r o w s e r 一鍪董疆鬻- i ：= 二二尊誊 褰；去l 鬻卜芑：世鼍粤_ a d p li “c a t io ，n ，二 l f j a v a c n e t )1 瓣懑嘲鬣黪 鲻黼羡黼黼 图3 - 3 民生银行客户交流系统的系统架构图 lu m 一x _ ； ，j |l j 呻 z 硕士学位论文第三章客户交流系统的总体设计 在上述体系架构中m d a 管理了业务对象生命周期( 创建、存储、修改、删 除) 和对象间的关系( 依赖、继承、关联、聚合等) 。 w o r k f l o w 技术则实现了业务流程。用图形化的设计工具可设计出各种复杂 的业务流程，包括顺序、分支、跳转、回退、条件判断、事件触发等，定义了参 与者( 人、应用程序) 等。流程以x m l 形式存储，运行时由工作流引擎解释执行， 并管理其生命周期。w o r k f l o w 的引入使应对需求的变更轻而易举，繁琐的代码 编写大为减少，业务组件复用性极大的提高。 g a t e w a ys e r v e r 解决了本系统与其他外系统交互的难题，充当了各系统间翻 译和向导的角色。 交流平台技术架构包含下列子系统： ( 1 ) o b j e c ti n s p e c t o r ：对象观察器。 以w 曲方式提供展现和操作对象的用户接口。部署于w e bc o n t a i n e r 中。对 象的展现外观由u i 配置文件( x m l 格式) 定义，包括可显示的属性、属性标题、 提示信息、显示的属性的排列布局、校验约束、关联对象容器等。支持多国语言。 对象操作的请求，如新建、提取、查询、修改、删除等，由o b j e c ti n s p e c t o r 采 用r m i i i o p 协议派发到e j bc o n t a i n e r 中的b u s i n e s sd e l e g a t o re j b 。 ( 2 ) g a t e w a ys e r v e r ：网关服务器。 有两大作用，一是作为交流平台的一种对外服务接口，接受t c p i p 协议x m l 格式的请求；二是作为交流平台调用外部服务系统，如运营商或s p 的服务器， 的代理。网关服务器采用j a v a 多线程和x m l 技术实现，性能优良。网关将客户 端的请求转发到交流平台后台业务系统有两种通讯方式，一是以r m i 远程调用 b u s i n e s s d e l e g a t o re j b ，二是利用j m s 发送异步消息。 ( 3 ) b u s i n e s s d e l e g a t o re j b ( s l s b m d b ) ：业务代理。 b u s i n e s s d e l e g a t o re j b 是交流平台后台业务处理系统的门户，有s l s b ( 无 状态的s e s s i o n b e a n ) 和m d b ( 消息驱动b e a n ) 两种形式。它的功能只是接入 并识别各种业务请求，根据服务配置，调用工作流引擎用合适的工作流去处理即 可。 ( 4 ) w o r k f l o we n g i n e ：工作流引擎。 实现w f m c 规范的工作流引擎，解释并执行x p d l 格式( x m l ) 的流程定 义文件，管理流程实例的生命周期，提