（机械设计及理论专业论文）基于j2ee架构的数据交换中心系统的设计与实现.pdf

摘要 随着社会信息化步伐的加快，企业之间迫切需要在更大范围内实现资源共享与数据 交换，因而实现数据交换处理中心系统具有重要的现实意义。 论文叙述了多层分布式数据交换中心系统的总体设计方案及该系统用于诊疗资料 的远程交换作业的实现方法，结合分布式、e b 服务器端组件、x m l 、r m i 远程通讯、 面向对象、数据库等技术的运用，讨论了该系统中数据层、业务层、w e b 表示层、应用 客户端的具体实现，着重论述了业务数据的对象化封装、信息处理效率的提高及业务处 理的安全性保证等关键问题的解决方法。 该系统的主要功能已实现，其雏形在诊疗行业进行了初步的测试，运行结果表明采 用的技术路线正确，设计的方案合理且可行。 关键字：数据交换：分布式：e j b ；j 2 e e w i t ht h er a p i dd e v e l o p m e n to fs o c i a li n f o r m a t i o n e n t e r p r i s e sa r ee a g e rt or e a l i z e r e s o u r c es h a r ea n dd a t ae x c h a n g ei nm u c hm o r eg r e a t $ c 0 p c ，s ot h ed a t ae x c h a n g ec e n t e ro f e n t e r p r i s e sh a sw i d ea p p l i c a t i o nf o r e g r o u n d t h ep a p e ri n t r o d u c e sag e n e r a ld e s i g np a t t e r no fm u l t i l a y e rd i s t r i b u t e dp l a t f o r mo f d y n a m i cd a t ae x c h a n g e i ta l s od i s c u s s e st h em e t h o d si nf u l f i l l i n gr e m o t ed a t ae x c h a n g eo f m e d i c a lt r e a t m e n t i td i s c u s s e st h er e a l i z a t i o no fd a t al a y e lb u s i n e s sl a y e r , w e bl a y e ra n d a p p l i c a t i o nc l i e n to f t h es y s t e m b a s e do nd i s t r i b u t e dt a l c u l a t i o n e n t e r p r i s ej a v a b e a n s ，x m l ， r m ir e m o t ec o m m u n i c a t i o n o b j e c t o r i e n t e d ，d a t a b a s e t h es o l u t i o no fk e yp r o b l e m sa s f o l l o w si s e m p h a s i z e d ：t h ee n c a p s u l a t i o no fb u s i n e s sl o g i c ，o p t i m i z i n g t h ee f f i c i e n c yo f i n 士o n n a t i o nd i s p o s a la n dh o wt oe n s u r et h es e c u r i t ya n di n t e g r i t yo f d a t aa c c e s s t h em a i nf u n c t i o no ft h es y s t e mh a sb e e na c c o m p l i s h e d t h ee l e m e n t a r ya p p l i c a t i o nh a s b e e na p p l i e dt om e d i c a lt r e a t m e n t t h er e s u l ts h o w st h a tt h et e c h n i c a lr o u t ei sr e a s o n a b l ea n d t h es c h e m ei sr a t i o n a la n df e a s i b l e k e yw o r d s ：d a t ae x c h a n g e ；d i s t r i b u t e d ；e n t e r p r i s ej a v a b e a n s ；j 2 e e 基于1 2 e e 挺构的数据交换中心系统的设计与实现 1 绪论 2 0 世纪9 0 年代以来，计算机技术和网络技术迅速发展，其影响已经涉及到社会的 各领域。将各种行业应用扩展到局域网、广域网甚至i n t e r n e t 上已成为用户的普遍需 求，分稚式计算成为热点。另一方面，数据库技术也日趋成熟，不管是小型数据库，还 是大型的服务器数据库，乃至分布式数据库到数据仓库技术都有很大的发展，这样使得 海量数据的有效存储成为可能。、 在传统的渗疗领域中，病人的诊疗资料一般是以文字病例或电子文档的形式在各诊 疗单位存储，没有得到统一的管理，这些诊疗记录在不同的单位之间的交换通常是采用 信件、传真、电子邮件等低效的方式完成，在一定程度上影响了诊疗资料的共享。由于 缺乏完整的诊疗资料和用来将这些资料分发到诊疗单位的有效工具而导致很多事故地 发生，因此开发一套以病人为主体的诊疗数据交换中心系统成为必要。 本论文就是基于这样的背景，在对分布式计算和可重用组件开发技术进行研究的基 础上，完成了诊疗数据交换中心系统的设计与实现，提出了一个能同时为多种类型远程 客户端( w e b 客户端和应用程序客户端) 提供远程数据交换服务的数据交换中心系统的解 决方案。 1 1 技术背景 1 1 1 多层分布式系统简介 长期以柬，“客户n 务器”两层结构模式占据着大部分的应用领域，即客户端提供 用户界面、运行逻辑处理应用，中央服务器接收客户端的请求与数据库进行交互，然后 返回处理结果。两层的结构系统给用户带来相当大的灵活性，但随着处理业务对系统提 出更高的要求后，这种架构逐渐暴露出客户端庞大和服务器端负载过重的弊端。 为了解决两层结构中存在的问题以及满足i n t e r n e t i n t r a n e t 的兴起对于企业运作 模式转变的需要，业界提出了三层的结构模型【1 1 。典型的三层结构计算模式如图卜l 所 不。 ! 堡，? 群衩! 壁，洋衩颦兰 圈卜l 兰层结构系统模型( f i g u r e 卜tm o d e la ft h r e e t i e ra r c h i t e c t u r e ) 在三层体系结构中，客户层提供应用用户界面，它根据用户的操作调用相应的业务 逻辑，不直接访问后台的数据库；业务逻辑层是应用系统的关键所在，它负责处理所有 的用户请求，并把处理结果返回客户层：数据层封装数据逻辑，提供数据支持，也称为 壮于j 2 e e 架构的数据交换中心系统的设计与实现 服务层。 构建于三层结构上的应用系统，必须提供三个层次的服务： - 用户服务：包括提供信息和功能，保持用户界面的一致性和完整性。它提供一个 可视化的接口，用来表示和收集数据，同时确保业务服务能够提供所需的业务处 理能力，并且使用户与应用系统紧密地结合起来，以处理各项业务。 业务服务：它是联系用户服务和数据服务的桥梁，影响用户的请求，执行某种业 务规则，为具体应用提供事务处理、安全控制以及满足不同数量用户的请求而进 行性能调整。 - 数据服务：包括数据的定义、维护、访问和更新，以及影响业务服务的数据请求。 1 1 2j 2 e e 企业计算平台 j 2 e e 平台1 4 , 5 1 是为了满足目前企业应用系统的需要，由s u n 公司发布的企业计算平 台规范。它的主要技术目标可以概括为：为企业应用系统提供一个具有高度的可移植性 和兼容性的平台。j 2 e e 平台提供了多层的分布式应用模型、组件重用、一致性的安全模 型以及灵活的事务控制。在这个平台上可以容易、快速地建立融合i n t e r n e t 技术，尤 其是基于w e b 技术的多层结构的分布式企业应用。为此，j 2 e e 平台采用了基于j a v a 技 术的分布式组件技术。图卜2 示意了j 2 e e 平台的基本体系结构。 客户层 业务层数据层 l _ h t t p h t t p s2 - r m i i i o p ( 远程方法调用)3 - j d b c ( j a v a 数据库连接)a c a p p l e t 容器 a c c a p pli c a ti o nc li e n tc o n t a i n e r ( 应用程序客户端容器) 图卜2j 2 e e 平台基本体系结构( f i g u r el 一2b a s i ca r c h i t e c t u r eo fj 2 e ep l a t f o r m ) 由图可以看出，j 2 e e 平台包括四个方面：j a v a 技术、组件技术、服务和通讯。j z e e 平台规范为分布式系统搭建了一个高度灵活的基础平台。这种灵活性将使企业的应用系 统能够不断的适应快速变化的市场需求和层出不穷的新技术，j 2 e e 技术已经获得了各大 开发平台提供商的支持，成为企业应用开发的主流平台。 基于j 2 e e 柴构的数据交换中心系统的设计与实现 1 2 选题背景 1 2 1 课题所属的研究领域 本课题属于计算机信息管理与交换研究领域，是在大连理工大学c a d 研究所和厂商 合作丌发的以病人为主体的诊疗数据交换中心系统的基础上提出的。 1 2 2 课题的现实价值 在本课题的设计与实现过程中提出了一个用于解决数掘共享和在异地数据库之问 进行数据交换的方案，并应用于以病人为主体的诊疗数据交换中心系统的开发中。系统 用户( 渗疗数据交换中心系统中指病人和经病人授权的医生) 可以把自己的诊疗资料通 过网络上传到数据中心，并自主管理自己的诊疗资料，从而实现了数据收集和统一管理。 对于那些经过病人授权的医疗单位，通过系统提供的软件工具可以实现本地数据库和远 程数据中心之问的双向数据交换。通过这两种方式，来自不同数据源的数据得到了有效 的收集与存储。医疗单位就可以及时得到病人最新的、完整的数搌已录，降低由于缺乏 完整的诊疗记录而引发医疗事故的概率，具有实际的社会价值。 1 2 3 数据中心系统的发展状况 计算机技术和网络技术的迅速发展，使得把企业应用扩展到i n t r a n e t i n t e r n e t 成 为可能，从而实现了资源在较大范围内的共享。以提供信息服务为主要目的的数据中心 系统就是这种发展趋势的必然产物。 现阶段，数据中心系统在各行业内得到广泛的应用。这些数据中心存储相关行业的 海量数据信息，并对数据进行管理和处理。用户可以根据自己的需求，通过网络访问相 关的数据中心，检索需要的信息。大部分的数据中心系统只为一种类型的客户端服务， 也就是基于w e b 浏览器的用户。在数据中心的内部，系统负责人员通过应用程序界面， 对数据中心进行管理。人们希望获得更大范围内的资源共享，不仅可以从外界获取丰富 的信息，还能够与数据中心之间动态的交互。能同时为多种类型的客户端提供服务的数 据交换中心系统成为当前的发展趋势。 1 3 课题的研究内容 1 3 1 课题的特色 数据交换中心系统在实现上采用了分布式、可复用组件模型，可以部署在任何支 持j 2 e e 规范的应用服务器环境中，易于实现系统的迁移，使得系统具有较强的可扩展 雉于j 2 e e 架构的数据交换中心系统的世计与实现 性。表示逻辑与业务逻辑、业务逻辑与数据逻辑、表示逻辑和数据逻辑之间严格分开， 降低了整个系统各部分之间的耦合程度。当系统发生错误时，仅停留在某一层而不会导 致整个系统的崩溃。系统的资源通过应用服务器被有效地池化，从而降低了资源访问的 代价。能够同时为w e b 浏览器的用户和使用应用程序的用户提供服务，实现了数据中 心与异地数据库之间的数据交换。 1 3 2 研究内容和要解决的问题 数据交换中心系统基于j 2 e e 架构平台，通过企业j a v a b e a n s 服务器端组件技术实 现系统的业务服务，为使用w e b 浏览器的用户和使用应用程序的用户提供服务。该课 题的主要研究内容如下： - 在数据层实现数据库结构的设计与构建：合理设计数据库结构以提升数据访问与 处理的效率，并保证数据完整性。 业务层的设计与实现：运用企业j a v a b e a n s 组件技术和x m l 技术实现系统业务层， 包括数据检索、数据交换、用户管理和交互式数据更新，提高信息的处理效率。 应用客户端表现层的设计与实现：针对适用于中小型诊所的诊疗信息系统 ( p r o v i d e r s m a r t ) 的需求，设计一个专用的软件系统，用于实现其远程数据交换 的目的，通过此软件系统的实际开发工作，阐述了应用客户端表现层的设计与实 现过程。 w e b 表现层的设计与实现：针对使用浏览器进行远程数据处理的用户，设计并实 现w e b 表现层的逻辑，并以文字和图形相结合的信息表现形式提供给w e b 用户。 结合上面的工作，本课题重点要解决如下问题： l 、数据层的设计：合理选用数据库模型对系统的数据结构进行分析设计。 2 、业务层的设计。 1 ) 合理划分业务层的业务逻辑。 2 ) 进行组件化的设计。 3 ) 提供完整性和安全性的控制。 4 ) 优化系统的性能，提高信息处理效率，降低系统负载。 3 、表现层的设计。 1 ) 支持多种客户端。 2 ) 提供友好的用户界面，实现本地数据库与数据中心之间的数据交换。 1 3 3 预计达到的效果 本课题预计达到的效果如下： - 使诊疗数据得到有效的收集和管理，保证数据的完整性和实时性；数据的使用者 能从数据中心下载最新的数据到本地，数据的下载方式包括把数据追加到本地数 据库、保存为数据文件和报表输出等三种方式。 - 实现数据中心和异地数据库之间的数据交换，实现大范围的信息共享。 4 基于j 2 e e 架构的数据交换中心系统的设计与实耳| 5 2 系统的总体设计方案 2 1 需求分析 通过第一章的论述可以看出以病人为主体的诊疗数据交换中心系统将主要解决两 个问题：1 ) 实现数据的有效收集与存储，并对数据进行统一的管理；2 ) 实现数据中心 和诊疗单位本地数据库的之间的远程数据交换。在现阶段，诊疗单位主要是指安装了 p r o v i d e r s m a r t 软件的诊所和医院，在这些用户的本地系统中维护着用来保存病人信息 的数据库。 为解决这两个问题，系统应提供对w e b 客户端和应用程序客户端的支持。这样，用 户就可以通过网络及时地把自己的诊疗信息上传到数据中心，并可以随时检索和修改自 己的信息；拥有本地数据库的诊所等单位则可以通过运行在本地的应用程序实现本地数 据库和数据中心之间的数据交换。 若按照传统的客户n 务器模式实现异地数据库之间的数据交换，即在客户端提供 用户界面、运行业务逻辑，并对远程数据库进行访问，随着业务的增多势必导致客户端 逐渐庞大和系统服务器负载过重等问题。需要进行数据交换业务处理的用户分散在网络 中的各处，在交换的过程中必须要和数据中心之间建立并保持远程连接，远程连接建立 的代价非常昂贵，并且要在i n t e r n e t 上维持这种连接是不现实的。数据在网络中通过 远程连接进行传输的稳定性、安全性和准确性也难以得到保证。另外随着远程连接数量 的增加，系统数据库将出现负担过重的现象，随时可能崩溃，影响整个系统的正常运行。 本系统既要解决上述问题，又要满足对多种类型远程客户端的支持和把敏感的业务 处理同面向外界的i n t e r n e t 相隔离的需求。同时考虑系统的可扩展性、易维护性和可 移植性等因素，数据交换中心系统应当由传统两层模式转移到多层分布式模式。 2 2 系统的总体架构 作为一个多层分布式的系统，数据交换中心系统的设计关键在于应用服务器端的程 序设计。它一方面为客户端的请求提供服务；另一方面也进行数据库物理位置定位，提 供数据库的透明访问、进行性能调整等。 2 2 1 应用服务器端组件模型方案的确定 目前，应用服务器端组件开发主要有三种标准：0 m g 组织推出的公共对象请求代理 结构c o r b a ：微软公司的分布式组件对象模型c o m d c o m ：s u n 公司的企业j a v a b e a n s 。 方案一：c o r b a c o r b a 2 】是o m g 在o m a ( 对象管理体系结构) 基础上定义的对象请求代理 ( o r b ) 的公共结构。c o r b a 为分布式对象的平台中立和语言中立的计算环境奠定了基 础。在c o r b a 的环境中，功能驻留在对象之中，而客户机可以通过对象请求代理o r b 基于j 2 e e i 巴构的数据交换中心系统的垃汁与实现 访问这些对象。实现基本o r b 功能的软件成为o r b 核心。o r b 是一种对象式中间件， 它有效地隔离了互操作的双方：客户对象与服务器对象只需遵循守由i d l ( 接口对象语 言) 定义的共同接口，则客户对象即可以透明地激活一个远地服务器对象，就象是激活 本地的对象一样，而不必关心对象的位罱、使用的编程语言、具体的操作系统、或者其 它与对象接口无关的信息。基于c o r b a 的分布式体系结构是将一个分布式异构系统作 为相互作用的对象集合即将分布式系统中各成员系统的资源模型转化为构件，成为可 以直接插在c o r b a 软件总线上的对象。 方案二：d c o m d c o m 是微软提出的构件标准及实现【3 】，它使开发人员可以利用c o m 的通讯机制 组装不同开发商提供的构件。d c o m 的核心是一组应用程序调用接口，该接口提供了创 建构件、组装构件的方法。d c o m 是微软为支持网络环境而对c o m 进行扩充的结果。 它的目标与c o r b a 类似，都是为了支持不同结点上、不同操作系统、由不同语言实现 的对象进行互操作。和c o r b a 一样，d c o m 中的接口和实现是分开的。但和c o r b a 的o r b 不同的是，d c o m 的底层机制仅在客户建立请求关系阶段发挥作用、帮助定位 服务器对象之间直接进行连接。目前，微软的分布式构件对象模型d c o m 仅运行于两 种操作系统之上：w i n d o w s9 x 和w i n d o w sn t 4 。 方案三：企业j a v a b e a n s e j b 是一种面向企业应用、基于j a 、德平台的服务器端标准的构件体系结构( 6 , 7 8 1 用于使用j a v a 程序设计语言建立平台无关的、分布式对象及面向事务的业务应用系统。 它有如下优点： 层次结构清晰：企业j a v a b e a n s 在应用系统业务逻辑和系统功能之间定义了清晰 的分界，应用系统开发者只需要关注应用系统本身的业务逻辑，而复杂的低层事务 处理、对象持久性、多线程、安全性、资源缓冲池和其它复杂的低层a p i 的详细信 息及远程通讯等的管理则交由应用服务器来管理。 平台独立：只要开发一次，就可在多个平台上运行。 三种方案的比较如表2 1 性能c o r b ad c o me j b ，r 台无关性与平台无关基丁微软的平台 与平台无关 语言独立性语言独立语言独立j a v a 语言 容错性 一般一般较强 安全性较好一般 较好 可扩展性较好一般较好 表2 一l 三种服务器端组件模型的比较 ( t a b l e2 - lc o m p a r i s o no ft h r e es e r v e r s i d ec o m p o n e n tm o d e l s ) 出于对系统可扩展性、可移植性和平台无关性的角度考虑，数据交换中心系统采用 j 2 e e 的e j b 作为服务器端的组件开发模型。 基于j 2 e e 架构的数据交换中心系统的醍汁与实现 2 2 2 数据交换中心系统的总体架构 基于j 2 e e 架构，采用多层结构设计的系统构架如图2 1 所示： 客户端表现层业务崖数据层 w e b 测览器 一服务器端表示页砥 总业务 n v u “。 控功能实体 制会话组件 组纽件集合 s q l 2 0 0 0 数据 件集合 库 客户端应用程序 1 2 e e 服务 b e aw e b l o g ic 6 1 j 2 s e 图2 - 1 数据交换中心系统总体架构 ( f i g u r e2 - it h ea r c h i t e c t u r eo fd a t a - e x c h a n g ec e f l t e rs y s t e m ) 数据交换中心系统基于j 2 e e 多层分布式架构，建立在w i n d o w s 2 0 0 0 系统之上。采 用s q ls e r v e r 2 0 0 0 为数据库平台，以b e aw e b l o g i c 6 1 为j z e e 应用服务器，以a p a c h e t o m c a t 4 0 为w e b 服务器，支持w e b 客户端和应用客户端，具有良好的可扩展性、可伸 缩性，易于维护。 应用客户端和应用服务器之间采用标准的分布式计算协议r m i i i o p ，而应用服务器 和数据库服务器访问采用标准的数据库访问标准( j d b c ) 。如果客户端使用浏览器，系统 通过浏览器和应用服务器之间的w e b 服务器接受客户端请求并且将应用服务器的结果返 还给客户端。浏览器和w e b 服务器之间的通讯主要采用h t t p 协议，而w e b 服务器和应 用服务器之间的通讯也是采用r m i i i o p 来完成，使 ! 导两种访问方式得到了最大限度的 统一。 2 3 系统的组成部分简介 为了实现数据的有效收集和完成异地数据库与数据中心之间的数据交换，本系统 为两种类型的客户端提供服务：基于w e b 浏览器的客户端和应用程序客户端。w e b 浏览 器的客户端主要是病人和经其授权的医生，用户可以通过网络把最新的数据上传到数据 中心，修改与浏览信息，并对相关数据进行图形化分析，从丽更加直观地反映病人当前 的健康状况。应用程序客户端主要是经过病人授权的医疗单位，通过客户端应用程序， 医疗单位可以浏览病人的相关数据，从远程数据中心下载最新数据，实现本地数据库和 远程数据中心之间的动态交互。 数据交换中心系统按照逻辑化分为三层：数据层、业务层、表现层，其中表现层又 可分为w e b 表现层和应用客户端表现层。下面对各层进行简单的介绍： 接于j 2 e e 架构的数据交换中心系统的i 驶计与实现 数据层：数据层负责存储和管理用户的诊疗资料。 业务层：业务层是整个系统的关键所在。业务层处理系统的全部业务逻辑并负责与 数据层之间的交互，主要包括数据检索、数据交换、用户检测、交互式数据更新、实现 接口定义与控制等功能。 w e b 表现层：为使用浏览器的客户端提供表现服务。接收柬自客户端的请求，把请 求委托给业务层相应业务组件处理，并把处理结果以h t m l 文件的形式返回客户端。 应用客户端表现层：是一个独立的j a v a 2 应用程序，运行在医疗单位的系统上，为 用户提供交互界面。通过浚软件，用户可以访问数据中心，检索特定病人的诊疗信息； 上传数据到数据中心实现数据中心的更新：从数据中心下载数据，实现本地数据库的更 新。 2 4 数据层的设计 本系统的数据层指的是数据中心数据库，存储和管理病人的相关诊疗信息，包括： 病人的人口统计资料、家族病历、诊疗病史资料等。根据这些信息的相关程度，可以把 病人的珍疗记录分为三大类：基本信息、诊疗病史和护理项目。 采用关系型数据设计原理对数据中心的结构进行了分析与设计，具体数据库结构见 表2 - 2 。 系统数据库结构设计表 类别表名说明 p a t i e n t用户的基本信息( 姓名、年龄、住址、身份汪、生日等) 基p a t i e n t i n s 病人的保险信息 太 p h y s i c i a n s 家庭医生的基本信息 信 g u a r a n t o r担保人的基本信息 息g u a r d i a n 监护人的基本信息 e m e r c o n t紧急情况联系人信息 护i t e m s护理项甘信息( 项目名称、单位代号、数据类型等) 理u n i t项目单位 项 i t e m v a l u e s病人的护理项目检测信息( 检测值、检测时问等) 目 r e f r a n g e护理项甘参考标准值 l i f e s t y l e病人的生活方式( 吸烟、酗酒、饮食等) v i s i t病人每次看病的基本信息记录 d r u g 病人目前用药情况( 药品、用药日期、剂最、用药效果等) d r u g h i s t o r y病人的用药历史记录( 药品名称、开始日期、结束日期) d i e a s e 目前的病情( 疾病名称、患病日期等) 医 d i e a s e h i s t o r y 历史病情( 曾患病症、起始日期、结束日期等) 疗 h o s p i t a li z a t i o n 住院历史纪录( 住院日期、原因、出院状况等) 病 a il e r g e n s过敏反应 接于j 2 e e 架构的数据交换中心系统的l 世汁与实现 史 f a m i l y h is t o r y家族病史( 家庭成员的病史) 3 u r g e r l e s外科手术 i m m u n i z a t i o n s 免疫情况 i n f e c t i o u s d i e a s e 传染病 辅u s e r i n f o用户帐号( 用户名、密码等) 助d o c t o r 医生基本信息 表 p a t i e n t g r a n t 管理医生和病人关系 表2 ：- 2 系统数据库结构 ( t a b l e2 - 2 s t r u c t u r eo fs y s t e md a t a b a s e ) 2 5 系统的运行环境和开发工具 2 5 1 系统运行环境的选择 本系统采用j 2 e e 三层式架构模型，运行在基于t c p i p 协议的广域网上。系统选 用s q ls e r v e r 2 0 0 0 数据库，提高了数据的存储容量和访问效率；应用服务器端软件部 署在b e a 公司的w e b l o g i c 6 1 应用服务器上；w e b 服务器端的软件部署在a p a c h et o m c a t 服务器上；应用客户端软件系统的运行环境可以是当前流行的大多数操作系统，如 w i n d o w s 、l i f l u x 等。 2 5 2e j b 应用服务器的选择 应用服务器是本系统业务层e j b 组件部署和运行的平台，管理着e j b 容器并为e j b 组件提供系统级的服务。因此，合理的选择e j b 应用服务器对整个系统的性能十分关键。 目前主流的应用服务器主要有：b e aw e b l o g i c 应用服务器，i b mw e b s p h e r e 应用服 务器，o r a c l e 应用服务器和b o r l a n d 应用服务器。 考虑到b e aw e b l o g i c 是用于集成、开发、部署和管理大型分布式w e b 应用和网络 服务器应用的应用服务器，能将j a v a 的动态功能和企业j a v a b e a n s 标准的高效性和安 全性引入了大型w e b 应用的集成和开发之中，代表了新一代w e b 应用服务器的发展方向。 并且，w e b l o g i c 应用服务器以完全实现j 2 e e 应用程序接口：全面实现e j b 2 0 技术，为 e j b 组件的创建和管理提供辅助工具，能够允许定制业务组件；方便地与业界领先的数 据库协同工作：支持主流系统等优势而成为应用服务器中的佼佼者。 所以，本系统选择b e aw e b l o g i c 作为系统的应用服务器。 2 5 ，3 系统的开发工具的选择 在系统架构已经确定的情况下，开发工具的选取将会对整个系统的开发效率和周期 非常重要，合理选择开发工具，将会提高开发效率，降低开发成本，提高系统的稳定性， 9 接于j 2 e e 架构的数据交换中心系统的啦计与实现 同时使系统的维护更加容易。数据交换中心系统是一个复杂的大型系统，为了方便系统 的开发与维护，整个系统以b o r l a n d 公司的j b u i l d e r 6 为开发工具，很好地实现了应 用服务器、数据库与开发工具之间地整合。 26 系统应用的主要技术 数据交换中心系统采用j 2 e e 架构开发平台，以e j b 作为服务器端组件丌发模型 在系统的设计阶段和开发阶段，涉及到的主要技术包括：e j b 技术：x m l 等。 2 6 1e j b 技术 e j b 是一种基于构件的开发技术【5 6 】，用于创建可伸缩、多层次、分布式应用，并且 可创建具有动态扩展性的服务器端应用。在e j b 中，通过j a v a 语言可以方便的创建分 布式的面向对象商业应用，此种模型以j a v a b e a n s 作为构件基础，与以往的j a v a b e a n 对 象主要用于客户端开发不同，e j b 主要用于服务器端，为客户端提供服务。 e j b 的基本思想是为组件开发提供一个框架，满足规范的构件可以方便、灵活的放 在服务器端的e j b 容器内，扩展服务器的功能，而不需考虑移植等细节，类似于硬件的 即插即用。此种技术建立在j a v a 语言的基础上，因此具有“一次编写，到处运行”的特 点：由于利用框架的设计思路，使得开发者可以方便的使用分布式对象的特点。 2 6 2x m l 技术 x m l ( e x t e n s i b l em a r k u pl a u g u a g e ) 是一种可扩展的标记语言【1 4 ，l “，集s g m l 和 h t m l 的优势于一体，其设计的目的是为了克服h t m l 的缺陷，将网络上传输的文档 规范化，并赋予标记一定的含义。x m l 的应用可分为三大类：简单数据的表示和交换； 面向消息的计算：表示相关的上下文。 在数据交换中心系统中，x m l 主要用于数据的表示。业务层e j b 组件在部署的时 候，要提供部署描述文件，该文件的目的是要获取为使用者所准备的声明性信息，e j b 的容器根据该文件提供的信息来管理和部署e j b 组件。同样的情况，表现层的w e b 组 件也需要类似部署描述文件。 2 7 技术路线 系统开发的技术路线如图2 - 2 所示： o 基十j 2 e e 架构的数姑交换中心系统的设计与实现 连用天糸掣数稻l 库原理对数据库卜叫数据层 结构进行分析 技术、命名和甘卜一业务层 图2 - 2 技术路线( f i g u r e2 - 2t e c h n i c a lr o u t e ) 其中： 数据层：是指系统数据库。 业务层：是通过应用服务器端的e j b 组件处理系统的业务逻辑。 w e b 表示层：向w e b 用户提供和展示相关信息。 应用客户端表示层：为客户端提供与系统业务层交互的图形界面。 甚于j 2 e e 巢构的数姑交换中心系统的设计与蜜观 3 业务层的设计与实现 3 1 需求分析和设计模型 3 1 1 需求分析 业务层实现的业务逻辑是基于j 2 e e 架构的数据交换中心系统的核心所在。业务层 负责接收来自w e b 表现层和应用客户端表现层的操作请求，对客户端提出的请求进行处 理，通过与数据层的交互，把处理结果反馈给相应的用户。业务层需要满足如下的需求： 1 用户的有效性检测。 2 ) 根据用户的提出的检索条件访问数据层，返回检索结果。 3 ) 实现数据中心和异地数据库之间的数据交换。 4 ) 保证数据在操作过程中的完整性和安全性。 5 ) 有效应对大量用户同时访问数据中心的问题。 3 ，1 2 设计模型 结合以上的需求分析，为了向客户端提供统一的操作接口，对业务层进行了进一步 的划分，分为数据存储层、业务功能层和总控制层。由上述分析提出了业务层的设计模 型，见图3 一l 。 数据存储层：用实体组件封装数据中心存储的诊疗记录，其中基本信息复合实体管 理包含了护理医生、监护人、担保人、紧急情况联系人、傈险信息等基本信息对应的实 体对象，诊疗病史复合实体包含了病人就诊记录、用药信息、疾病信息、住院历史、家 族病历、过敏反应等诊疗病史信息对应的实体对象。 业务功能层：用会话组件实现系统的主要功能，主要实现四个功能，即： 1 ) 用户检测对登陆系统用户的合法性进行检查，对于以医生身份登陆的用户， 同时返回给该医生授权的所有病人的基本信息列表； 2 ) 数据检索根据来自表现层检索条件对封装业务数据的实体组件进行访问，把 查询到的诊疗信息返还给客户端： 3 ) 数据交换接收来自应用客户端的数据交换请求，把客户端上传的诊疗数据同 数据中。1 5 相应的记录进行比对，实现数据中心某个病人诊疗信息的更新，同时返回数 据中心对应的珍疗数据，在客户端实现异地数据库的更新，从而间接地实现了数据中心 和异地数据库之闻的数据交换。 4 ) 交互式的数据更新通过网页，用户可以向数据中心内逐条添加新的记录或者 对某条特定的记录进行修改和删除的操作，这些操作都是由交互式的数据更新业务组件 处理的。 总控制层：用会话组件作为总控制组件，充当客户端和业务层交互的界面。控制组 件接收客户端的请求，对用户输入的数掘进行检查，转化为适合于各业务组件使用的形 2 罐十j 2 e e 架构的数据交换中心系统的设计1 j 实现 式，调用相应业务业务组件的方法完成操作。通过总控制组件，向客户端提供了统一的 操作接口。 总控制层 i 业务功能层 j 数据存储层 胆粤趣净 一业务层控削眵篇颡搿 组件 险 图3 - i 业务层设计模型 ( f i g u r e3 - 1a r c h i t e c t u r eo fb u s i n e s st i e r ) 3 1 3 企业j a v a b e a n s 组件框架剖析 e j b 是一种客户服务器结构7 j ，提供服务的方法运行在服务器端，根据客户端的 请求调用相应的方法，客户端和服务器端遵循同样的调用规则，建立在提供服务的基础 上而不是数据库中的表和列。另外e j b 在客户服务器结构引入了面向对象和分布式技 术，其基本结构如图3 - 2 。从图可以看出，e j b 的主要构成部分包括：e j b 组件、e j b 容 器、e j b 服务器、远程接口、e j bh o m e 对象。 e j b 组件：e j b 组件可分为会话组件和实体组件两大类。会话组件代理客户端对服 器的请求，它实现了业务逻辑的处理流程。会话组件的生命周期与客户端的会话持续时 间相同，它代表与客户程序的一次短暂会话。实体组件用来处理持久化的数据，而不是 处理业务逻辑，它代表实际的数据对象及作用于该数据对象的方法。 e j b 容器：e j b 容器管理部署在容器中的e j b 组件，是e j b 组件的执行环境，为e j b 缀件提供服务器端的系统级服务，包括线程管理、状态管理、交易管理、安全属性、资 源共享等。 远程接口( e j b 对象) ：远程接口，也称e j b 对象，由e j b 容器创建，代表e j b 组 件的一个客户视图。e j b 对象向客户端暴露所有与应用有关的接口。 h o m e 接口：h o m e 接口由e j b 容器创建，用户可通过命名与目录服务柬得到每个组 毕于j 2 e e 榘掏酌数据交换中心系统的殴计与实现 件相应的h o m e 接口，通过此h o m e 接口来创建、删除、查找e j b 对象及相应的信息。 黔： 崎羲岩e j b 容器 、i 服务 l 处理| l 化 。l 系统环境服务 i 图3 - 2e j b 组件框架 ( f i g u r e3 - 2a r c h i t e c t u r eo fe j bc o m p o n e n t ) 3 2 数据存储层的设计 3 2 1 数据的对象化封装 1 设计思想 系统数据库存储着大量的业务数据，在传统的模式下，客户端要想访问这些数据， 首先要和数据库建立连接，然后提出查询条件，得到返回结果。在访问量较少的情况下， 这种模式可能运行较好。但随着客户访问量的增加，系统的性能明显下降。并且，数据 交换中心系统的主要业务是要在数据中心和异地数据库之间进行数据交换，远程的数据 库连接代价非常的昂贵，如果同时出现大量的远程连接，整个系统可能会崩溃。另夕 ， 通过远程数据库连接在i n t e r n e t 上传输数据的完整性和安全性也不能得到很好地保证。 出于这些因素的考虑，本系统采用实体组件实现数据中心业务数据的封装以应对大量 用户对系统进行同时访问。 实体组件是存储在关系型数据库中的数据模型，代表了数据库中业务数据的对象视 图，并提供了访问和操作数据的对象封装。实体组件具有持久性，支持多用户的共享访 问。持久性是指实体组件的状态不依赖于应用服务器两存在。因为实体组件是底层数据 库已录的映像，它的状态和数据库记录保持一致，即使应用服务器崩溃或停止运行，实 体组件的状态仍然保存在数据库中，不会丢失。 按照持久化的实现方式，把实体组件划分为：组件管理的持久化( 以下简称b m p ) 和 容器管理的持久化( 以下简称为c m p ) 。前者由组件自身管理到数据库记录的映射，后者 则由容器负责把实体组件的对象实例映射到底层数据库的调用。这两种持久化方式的优 缺点如表3 一l 所示： 4 堆于j 2 e e 禁构的数据交换中心系统的设计与实现 持久化方式优点缺点 b m p 支持组件到数据库的复杂映射编码复杂、在数据模式改变时需要 重新部署、影响系统的可移植性 c m p 对象持久化逻辑由容器供应商解不能反应复杂的数据关系 决、可以在部署描述符中进行改 变、可移植性好、数据库无关性 表3 - 1b m p 与c m p 的比较 ( t a b l e3 - 1c o m p a r i s o n sb e t w e e nb m p a n dc m p ) 由于本系统数据库的结构清晰，数据表之间的关系明了，为了满足以后系统数据库 平台迁移的需求，在业务层的实现中采用了c m p 的方式，把实体组件向数据库的映射交 给容器来处理。 2 具体实现 使用实体组件作为数据中心业务数据的对象视图，客户端可以通过实体组件提供的 接口间接地实现对数据库业务数据的访问与操作。容器管理持久化的实体组件在部署到 容器时，由容器提供的持久化工具根据该部署描述符和实体组件的持久化域实现容器管 理实体组件到数据库的映射。、 每个实体组件的实现都包括三个部分：e j b 对象、e j bh o m e 接口、实体组件类和主 键。在数据交换中心系统中所有对实体组件的访问都是通过会话组件来封装，每个实体 组件只提供本地接口和本地h o m e 接口，防止了远程客户端对实体组件对象的直接访问， 保证了数据的安全性。 下面以系统用户信息实体组件为例，说明每个实体组件的丌发。在系统的数据库中， 系统用户信息表( u s e r i n f o ) 保存着系统的用户信息，该表定义了：用户名( u s e r _ n a m e ) 、 用户密码( p a s s w d ) 、身份证号码( s s n ) 、用户索引( u i d ) 等字段。与浚数据表相对应的实 体组件为u s e r i n f o b e a n ，该实体组件的本地接口和本地h o m e 接口分别为：u s e r i n f o 和 u s e r i n f o h o m e 。 本地接口( u s e r i n f o ) 的定义：本地接口定义了提供给客户端调用的一组方法。通过 方法调用，完成相应的逻辑运算。用户信息实体组件所提供的业务方法主要是对数据项 进行读写操作，因此在用户信息实体组件的本地接口中声明了对应于数据表u s e r i n f o 中所有字段的读写方法。本地接口继承了j a v a x e j b e j b l o c a l o b j e c t 接口。 p u b l i ci n t e r f a c eu s e r i n f oe x t e n d sj a v a x e j b e j b l o c a l o b j e c t 【 p u b l i cj a v a 1 a n g s t r i n gg e t u s e r n a m e0 ： 读取用户名称属性 p u b l i cv o i ds e t u s e r n a m e ( j a v a i a n g s t r i n gu s e r n a m e ) ：修改用户名称属性 ) 本地h o m e 接口( u s e r i n f o h o m e ) 的定义：u s e r i n f o h o m e 接口定义了管理用户信息 实体组件生命周期的方法：创建、删除、查找。在系统用户登陆时要对该用户输入的姓 名和密码进行验证，因此在用户信息的本地h o m e 接口中声明了根据用户名和密码查找 赫于j 2 e e 架构的数据交换中心系统的砹计与实现 用户信息实体对象方法，并在部署描述符内使用e j b - q l 语言对查找方法进行描述。 p u b l i ci n t e r f a c eu s e r i n f o h o m ee x t e n d sj a v a x e j b e j b l o