1、摘要I摘 要关键字： 摘要IIAbstractKeywords:目录III目 录摘 要 IAbstract.II第一章 引言 11.1 论文目的及方法 .11.2 研究背景 .11.3 国内外研究现状 .11.4 论文主要内容 .31.5 论文的组织安排 .3第二章 EJB 及 Web Service 概述 52.1 EJB 52.1.1 EJB 概述 52.1.2 BOAT 中为何要使用 EJB .52.1.3 BOAT 系统中的 EJB 组件 62.1.4 分布式计算技术的比较 72.1.5 对 BOAT 中 EJB 技术的思考 .82.2 Web Service 技术 .82.2.1 W
2、eb Service 概述 .82.2.2 Web Service 的访问 .92.2.3 Web Service 的创建 .92.2.3 Service Message 102.2.4 Web Service 在本项目中的应用 .112.3 本章小结 .12第三章 BOAT 系统 133.1 BOAT 系统介绍 .133.1.1 BOAT 系统从何而来 133.1.2 BOAT 系统架构 133.1.3 BOAT 开发平台及工具 153.2 APM 系统简介 .163.2.1 APM 简介以及与 BOAT 的关系 163.2.2 APM 主要开发技术与它的影响 163.2.3 BOAT 中调
3、用 Web Service .173.3 本章小结 .20第四章 数据库设计 214.1 BOAT 系统的数据库规范化设计 .214.1.1 数据库的规范化设计的原因 214.1.2 表设计中的第一范式（1NF） .214.1.3 表设计中的第二范式（2NF） .214.1.4 表设计中的第三范式（3NF） .224.1.5 Guid 与自增量 234.2 BOAT 数据库的存储过程（ Store Procedure） .234.2.1 为何 BOAT 采用存储过程 .234.2.2 BOAT 数据库中的触发器 244.3 BOAT 数据库中的视图（ View） 24目录IV4.3.1 创建视
4、图 254.3.2 视图的限制 254.4 BOAT 系统的 Audit Log 设计 264.4.1 Audit Log 的设计需求 .264.4.2 Audit Log 的数据获取 .264.4.3 Audit Log 的用户接口 .274.4.4 Audit Log 的用户显示层设计 .284.5 表结构设计 .294.5.1 辅助列的设计 304.5.2 起同步作用列的设计 304.6 本章小结 .31第五章 BOAT 系统主要功能的实现 325.1 BOAT 中的功能包 BackofficeJar325.1.1 BackofficeJar 中的主要功能 .325.1.2 Backof
5、ficeJar 中的邮件类 .325.2 用 JFreeChart 实现图形报表的功能 .325.2.1 JFreeChart 简介 .325.2.2 JFreeChart 应用举例 .335.2.3 HelperEJB 在生成图形中作用 345.3 邮件提醒机制的实现 .355.3.1 BOAT 中 CSR 工作分配邮件 355.3.2 BOAT 中信息提供和帮助邮件 355.4 Ant 编译 365.4.1. build.xml 中的元素 365.4.2. 经过 Ant 编译后 BOAT 的结构 .365.5 本章小结 .37第六章 总结 386.1 工作内容 .386.2 工作总结 .3
6、86.3 工作体会 .386.4 名词解释： .39参考文献 .40附录 Trigger 代码 .415第一章 引言1.1 论文目的及方法一个大型的Web应用系统可以拥有很多的组成部分，也可以涉及到很多的技术，根据需求开发人员可以套用或设计不同的模式将各个部分和技术组合起来，从而最终实现一个应用系统。本文的目的之一就是通过对BOAT系统全面的阐述，来说明一个新的 Web应用模式：利用Web Service来调用其它应用的数据服务。本文的目的之二就是说明数据库设计的重要性，因为所有的的应用的设计和实现都是基于数据的，所以成熟可靠的数据库表结构是非常重要的。本文阐述目的的方法是通过自己在BOAT
7、系统实际开发过程中参与设计的体会，以及对自己所做实际开发工作的经历的总结而完成的。1.2 研究背景自2000年以来，随着B/S架构被引入企业平台的开发， Java一直是平台开发的主流技术。随着时间的推移，J2EE的各种技术也是层出不穷，从EJB + Struts 到SpringHibernate，再到EJB3.0 的出现，各种第三方组件更是数不胜数。在J2EE的技术标准不断推出新的框架的同时，.Net技术由于它更低的开发难度以及前台界面控件的强大功能而受到开发者的青睐。由于这两种技术的并存，而且各有各的优点，由于J2EE对Request、Response和Session这样的对象的充分关注可以
8、让开发者很好的对整个系统的流程进行控制，从而更利于系统整体架构的良好设计，而.Net在这点上相对逊色。所以当不同部门之间的工具平台整合和互用的时候就会发现问题，两种技术的设计理念区别还是很大的，所以会有Web Service的出现用于不同系统之间的互用，在这个求同存异的世界，用哪种技术并不是最关键的，.NET和J2EE都是专注在企业级应用上，相反随着时间的推移如何保证一个平台数据的可用性和结合性才是最重要的。就本文中的BOAT系统来说，它存在于当地爱立信的客户支持部已经5年之久，它的前台界面一直有人负责更新和升级，甚至整个系统除数据库以外的架构都已经换过，所以数据库以上的更新是一直存在的，并且
9、这种更新与旧系统的运行是同时的，所以这次项目要保证在数据库现有数据结构不变得情况下更别的平台整合。而对于这个将要重用的新的系统(APM)，所要做的是设计它的数据库结构和它的访问层以便它不仅可以作为其本身的数据库系统，同时也很好的被BOAT 所使用 。在这一点上就可以把它看作一个小的分布式系统，项目中的一个重要任务就是通过对旧系统逻辑层和演示层以及新系统的数据层的设计和改进来达到跨平台业务逻辑的调用和不同系统的统一管理。综上所述，.NET和J2EE 在企业级应用上的地位已经不容置疑，这两种技术在一个企业内并存的现象也是不可避免。而如今在各个企业级平台之间的数据重用和逻辑重用的这种需求，特别在一个
10、企业内的相关平台之间，也已经越来越明显。虽然它们之间的关系谈不上分布式系统环境，但是在一定程度上已经有了互相协作，互相更新的行为，有了一定的依赖关系。而这种关系最关键的就是取决于数据库结构的设计。本文以BOAT为主要系统，以 EJB调用Web Service为技术基础，APM平台的数据库设计为底层支持，讲述了如何组建一个可协作可重用其他数据Web企业级管理系统，从而达到协作管理的效果。1.3 国内外研究现状现今，许多企业已经为他们的以存在的系统或者数据库投入了很多的资金和人力，因为更好的技术出现而舍弃旧的系统是不符合成本效益规则的，如何找到一条更符合成本效益的道路来优化企业的EIS(Enter
11、prise Infromation System 企业信息系统)，SOA(Service Oriented Architecture)的概念就成为了最好的解决方案。Web Service作为这个概念的一项技术，已经月来越成熟，它通过一些协议和已有的技术6(XML， Web Services Description Language (WSDL)， Simple Object Access Protocol (SOAP)， Universal Description， Discovery， Integration(UDDI)来实现SOA这个概念。它通过在旧系统上构建可供不同系统使用的web组件，
12、使旧系统的功能整合到如今的复杂多样化的计算环境中，你可以提供一个尽可能简单的服务，由订阅者去决定如何使用，这种方式非常符合成本效益的规则，用最低的成本来做到新旧的结合，而且已经被广泛使用 1。至于Web service未来会充当何种角色，也同样由它的特性所决定，云计算最近作为一个新名词进入大家的视野，微软和Google都推崇这种概念，虽然方式不一样，但是有一种未来大家是可见的，就是将来网上充斥的不再是信息，而是各种各样的服务。这种服务通过什么提供，就是存在于Internet上的各个网络单元通过Web Service提供的，它将成为未来的主流技术。不知道什么时候网上出现各种各样关于EJB性能差的
13、说法，虽然EJB 已经渐渐淡出历史舞台，但如果要使用J2EE提供一个成熟的解决方案，EJB将会一个选择，因为EJB 的容器( 如JBOSS) 自动提供了对象池和缓存池。如果你的解决方案需要承受大量的并发访问，没有缓存池更本不可能达到用户要求。所以一个无状态的Session Bean的性能肯定要强于一个框架中的普通Java Bean 。而随着EJB 技术进入3.0阶段，它在更框架相比在数据持久性上面的不足也得到了加强。EJB3.0的很多新特性是通过JAVA SE5.0 来实现的。这里就要谈到JAVA SE 5.0，它所提供的许多特性，其中最有趣的一点就是标注(Annotation)的功能。以前的
14、JAVA 语言都是命令格式的，比如a.b() ，表示让类a做事情b，但是很多时候只是需要对某个对象做一些注解，比如对某个类标记为可持续化的Serializable。这只是一个标记，为了以后的处理提供说明，本身不需要做任何操作。在Deploy 的时候， 提供了很多说明的XML 文件，比如部署描述文件，里面说明了引用的 EJB的名字，接口， 以及当前EJB的Transaction Type等等信息。所有这些信息都是说明性的，而不是命令性的。用来对某个对象的某个属性坐一段说明。因此，有一个非常有趣的想法，能不能通过对JAVA 语言的扩展，结合标注和命令这两者的优点?这也是有一个专家组在JCP的组织内
15、完成的，JSR规范的编号是JSR 175，为JAVA SE 5.0支持标注(Annotation)的功能。这个规范为 EJB3.0 的简化实现提供了一些基本的支持，也是最关键的支持。标注可以有自己的属性，也可以定义自己的持续时间，表示这段信息是否保存到源代码中，还是一直持续到Class中，或者一直保持到运行时间。标注有自己的缺省值。大多数情况下，无须说明就可以推算出来这个对象的行为。但是现在随着Swing框架的流行，统计数据显示，EJB的受欢迎程度在降低， EJB3.0也不可能完全抛弃EJB2.0 完全重新设计，它势必要达到对 EJB2.0的最大兼容。而且不管是 EJB2.0还是3.0，它们最
16、大的优势都是分布式部署，而J2EE的企业级应用向来关心的是数据本身，并不是分布式，或者说更本用不到分布式部署，在这一点上EJB就失去了它的效用，在 BOAT系统中继续使用EJB就相当于继续使用一个组件，因为先前建立的EJB已经建立了一个组件模型，如果再要实现什么新功能，只要依照原来的组件模型模仿就行了。如果要重新设计BOAT 系统，现存的组件模型的 EJB完全可以被Spring这个轻量级框架所取代 2。但是现阶段在这个项目中最重要的不是用更先进的技术重新实现BOAT，而是新增功能，并使BOAT 系统可以很好的使用外部数据库，所以EJB在BOAT中会继续存在。所以结合这两种技术，现在一个Web企
17、业级应用如果采用 J2EE作为解决方案，那么它的主流的架构将会是这样的，底层是由数据库存储实现的持久层，数据库之上是EJB的模型类包括所有的业务逻辑，在EJB类之上建立的是Web Service 层，在这层之上建立的框架动作层，它可以是 struts动作或者是spring动作，也就是通常所说的控制用于决定显示层的显示，再之上就是显示层，它们由JSP页面组成。这种架构中最主要的创新就是中间的Web Service层，它不但可以将自己系统本身由EJB组成的业务逻辑和数据库访问作为服务提供给控制层，而且同样可以把这种服务提供给外界的订阅者，而订阅者只要知道它们所需要的Web Service的WSDL
18、描述即可，同时 Web Service层还可以提供数据的验证、错误处理以及数据对象的缓存(Caching)，这种缓存是可以通过代码完全控制，缓存数据避免任何不必要的数据库访问，可以在本地缓存一个会话bean方法调用返回结果，这样就大大提高了数据访问的速率，从而提供系统的整体性能。在Web Service层的错误处理中隐藏了与EJB相关的系统异常。与 API相关的系统异常，比如RemoteException，EJBException都在WSManager 中被捕获然后作为一个非EJB 的相关异常( 比如一个自定7义的业务代理异常)通过Web服务端点重新抛出给客户端。应用级的异常仍然被传递给Web
19、 服务端点，然后由 Web服务端点通过SOAP消息发送给调用Web服务的客户端。Web Service层在提供服务的同时，当然也可以从其它的服务提供者(Service Provider)处获得服务。这样看来，新加入的这个层起到了内部以及外部通信的作用。在未来的面向服务的趋势中，这种结构将会越来越受到欢迎。1.4 论文主要内容论文所讨论的系统是在爱立信客户支持部内使用的工作平台，整个部门的运作也依赖于它，所以就此系统地位而言是相当重要的。虽然这个系统已经存在很长时间，但是随着客户需求的不断变化，开发技术的不断改进，需要的维护和功能加强和更新也越来越多。我在这个项目中的任务是对代码进行优化，必要时
20、重新开发，在这次开发过程中，也遇到了一些特殊的问题，如两个不同系统之间的交互等引起的问题。因此本文基于BOAT系统，就本人所参加的工作，结合各项工作所采用的技术和方法，从以下方面对BOAT系统和我所承担的开发工作进行了讨论：(1) 探讨了EJB以及Web Service在BOAT 系统中的重要作用EJB是JAVA 技术 中服务器端软件构件的技术规范和平台支持，这是站在软件组件的角度去看。在软件产业中，基于组件的技术是当前的热点，虽然这个管理系统并不是最新的管理系统，就EJB2.0来说，所采用的技术也不是非常先进，但是本文站在一个当时开发这个系统的角度解释为何采用EJB，这个技术对后续的二期开发
21、有何好处。另外，为了促进不同平台之间的合作以及数据重用（BOAT与APM） ，本文还详细讨论了BOAT系统中新引进的 Web Service技术，并且讨论了在Java 环境中调用远程Web Service的实际开发过程。(2) 探讨了数据库设计对于一个Web 管理系统的重要性及实现数据库在应用程序的重要位置是任何人无法否认的。数据库的设计也有数据库设计的规则，如常常所见的第一范式、第二范式、第三范式甚至于到第五范式。这些都属于理论上的内容，仅仅凭借一时的空想是完全不可能做到数据库的优良设计。在我们的项目中通过对需求的详细分析，在通过SQL 2000 DBMS最大程度的结合实际，结合用户的业务规
22、则来进行数据库的设计。但是在本文中强调的那些设计数据库的关键思想并不是光依赖于一个强大的DBMS，它提供的仅仅是一个平台，来辅助我们的设计，真正要让数据库中的数据很好的服务我们的系统还是取决于对项目的理解。本文中的这部分就从这方面出发讲述BOAT数据库的设计。(3) 利用JFreeChart技术创建报表以及BOAT 中邮件提醒等重要功能的设计与实现JFreeChart是一个纯Java类库，它可以让开发者很简单的得到具有专业质量的图形报表。因为BOAT是一个J2EE 的项目，所以采用了JFreeChart作为实现目的一个手段。作为与报表功能同级的邮件提醒功能，我也在本文中对于它的原理和思想以及实
23、现作了详细解释。本 论 文 中 描 述 的 系 统 是 作 者 在 实 习 公 司 参 加 的 实 际 项 目 ， 作 者 的 主 要 工 作 包 括 ： 参 与 了 整 个 管 理 系 统 的总 体 设 计 和 技 术 论 证 ； 开 发 和 实 现 了 BOAT管 理 系 统 中 的 报 表 、 记 录 搜 索 等 功 能 以 及 日 志 管 理 系 统 ； 管 理 系统 中 信 息 同 步 性 的 设 计 和 实 现 ； 以 及 修 改 了 部 分 客 户 端 代 码 。 作 者 的 主 要 贡 献 是 利 用 Web Service技 术 实 现 了对 不 同 系 统 的 数 据 库
24、中 的 数 据 进 行 重 用 。 1.5 论文的组织安排论文主要各章节摘要如下：第一章是论文的绪论。从选题背景开始，简述本项目所采用技术的研究现状，提出课题研究思路和论文的主要内容，概要枚举论文对企业级 Web 解决方案的研究成果，描述论文结构。第二章概述了 EJB 技术和 Web Service 技术。简要概括了 EJB 技术的组成部分以及各部分的功能，还有它的 Web 容器 JBoss，同时也简述了这项技术的优势和弱点。这一章中也分析了使用 Web Service 的具体优点，并且从项目角度出发讲解 Web Service 技术，使读者了解 Web Service 的优点如果体现，如果8
25、真正应用这项技术，不管是在 C#.Net 环境中还是在 JAVA 环境中。第三章主要讨论了本项目系统 BOAT。通过对 BOAT 系统架构的解析使读者更深入了解这个平台所做的工作，也更好地让读者了解各种技术在整个系统中扮演何种角色。为了能更好地阐述这个系统，本章也同时简要介绍了 APM 系统，包括它的用途和技术，技术主要从 Web Service 出发，目的是为了体现在 JAVA 和 C#环境中调用 Web Service 的不同情况。第四章只要从 APM 系统的底层数据库结构设计开始讲述如何设计数据库设计在整个系统中的重要性。在这一章也提到了本项目中，如何针对这个特定的数据库来设计直接架设在
26、数据库之上的 Web Service 层。第五章阐述了一些非主要技术整个系统中的作用，比如 JFreeChart 在图形报表方面的功能、使用 Ant编译和打包整个项目的功能以及在 BOAT 系统中十分重要的邮件提醒机制。第六章对论文的工作进行了总结。9第二章 EJB 及 Web Service 概述本章主要描述了在开发管理系统时用到的两大主要技术EJB和Web Service。在2.1节首先介绍了EJB 技术的相关概念，并分析和比较了现有的主要分布式计算技术。接着通过2.2节简单介绍了Web Service技术的内容，然后在2.3节分析了JMX的优势并说明了本管理系统采用JMX的理由，最后在2
27、.4节介绍了JMX技术。2.1 EJB2.1.1 EJB 概述EJB 是 JAVA 技术 中服务器端软件构件的技术规范和平台支持，这是站在软件组件的角度去看。在软件产业中，基于组件的技术是当前的热点。在面向对象的软件世界，基于组件的技术可以解决软件开发上的重复开发的问题。所以不同的厂商也相继推出他们的组件技术，形成了不同的派系，其中以微软为首的 DCOM/COM 阵营，从 DDE，OLE 到 ACTIVEX 等，提供了构件开发的基础。相对的，包括 SUN在内的对象管理组织 OMG，推出了跨语言的 CORBA，已逐渐成为业界的标准。而 EJB 是 OMG 成员之一的 SUN 推出的基于 JAVA
28、 的组件规范，自从随 J2EE 推出之后，广泛的得到了业界的支持，已经成为应用服务器的标准技术。从企业多层架构的角度，EJB 是业务逻辑的核心，与普通的 Java Bean 不同的是它提供了事务处理的能力。EJB 是利用 JTA 进行事务管理的，并不是 JDBC 里的 Connection，由于和数据存储层分离，所以EJB 的出现取代了存储进程的大部分地位 3。从分布式的角度看，EJB 和 CORBA，提供了分布式对象的基础，从而提供对象之间的通信机制。当然从最实际和最广泛的用途看，EJB 与 Servlet、Jsp 一起成为应用服务器的技术标准， EJB 中的 Session Bean 和
29、Entity Bean，前者维护会话，处理逻辑，后者处理事务。 Servlet 则负责与客户端通信，访问EJB，同时把结果传输给 Jsp 显示。2.1.2 BOAT 中为何要使用 EJBEJB 在 J2EE 的解决方案中并不是必须的，开发人员可以用一些简单的技术，比如 servlets， JSPs，同样可以建立用户想要的系统。就一般的程序开发经验来说，如果项目不大，也不要求很高的可扩展和可维护性，那么可以用普通的 J2EE 组建 servlets 加上直接的 JDBC 的连接去实现项目。 但是当需求复杂，同时要求的并发用户增多时，EJB 的使用就让分割和把握整个项目变得更容易，在这种情况下使用
30、 EJB就会给用户明显的优势。如今的软件开发趋势是让程序员从底层的架构还有中间层的通讯中脱离出来，让他们的重点放在业务逻辑的开发上，而采用 EJB 模型就很好的符合了这一点，因为 EJB 模型的目标之一就是尽可能的减少交互的复杂性，将重点放到每个 Session Bean 的业务逻辑中去。也就是说 BOAT 系统将重要的业务逻辑放到 EJB 中与显示层分开。另外 EJB 还能支持多用户接口，例如如果需要创建一个用户接口，它使用的是 Java Swing API，但是也有可能用户需要将这部分业务功能放到网络平台上，那么需要作的只是设计一个 servlet 的接口就行了，并不需要修改 EJB 中的
31、任何一行代码，图 2-1 就很好的解释了这一点：10图 2-1 EJB 组件的 UML 图并且 EJB 有特定的容器很好的管理它， Bean 的初始化、状态管理以及回收都是主动由容器负责，程序员不需要为此担心。所以说对于一个像 BOAT 这样较为复杂的系统来说，它的业务逻辑是最重要的，它一旦投入使用，只要爱立信存在，那它就一定会持续使用下去，技术在不断更新，如何保护和分离业务逻辑，以及重用业务逻辑才是最重要的，所以在 BOAT 项目一开始的时候， EJB 开发的业务逻辑部分就被作为这个项目的核心一直保留到现在。2.1.3 BOAT 系统中的 EJB 组件如之前所说的，BOAT 中的 EJB 组
32、件处理了系统中主要的业务逻辑，比如根据用户输入数据在数据库中组织查询得到想要的结果再传给显示层，又或在动态图表功能中访问 Web Service 从远程数据库中得到制图所需要的 DateSet。在 BOAT 中的 EJB 类有一个共同的特性：就是根据用户输入的数据，在类中附加业务逻辑后组织数据库查询，最终得到查询的数据结果后再应用到显示层上。以下介绍两个在 BOAT 系统中主要的 EJB 类。2.1.3.1 DBDataEJB在这个 EJB 当中很重要的一部分是要先建立数据库连接，由于本项目采用 JBOSS 作为 EJB 的容器，所以为了配合容器使用 MySQL，必须先在 Class Path
33、 内将 MySQL 的 JDBC 的驱动程序预先设置好，这样在每一个 DBDataEJB 的方法中只要得到容器中的初始环境（Initial Context） ，然后搜索 MySQL 中的连接池，最终获得连接。这样，可以在这个 EJB 中每一个方法都代表一段特定的业务逻辑，每一个方法都去寻找存在的数据库连接，各自独立。这个 EJB 是一个 StateLess Session Bean，说容器是不会保存这个 EJB 的状态的，也就是说当出现并发访问的时候，用户使用的是相同的 DBDataEJB 实例来满足他们的业务需求。使用 Stateless Session Bean的理由是因为 DBDataE
34、JB 中的方法都是公共方法，属于最基本的功能，任何一个用户都有权利调用其中的业务逻辑，所以不需要在其中保存一些用户信息，也不需要为每一个连接都建立一个实例（Instance） ，这样可以节省 Server 的存储空间。112.1.3.2 HelperEJB首先这个 EJB 更 DBDataEJB 一样是一个 StateLess Session Bean，可以说它们实现的功能是大致相同的。不同的是，HelperEJB 是为 BOAT 中的统计图形报表专门服务的，它其中的很多方法都直接调用Web Service 访问远程的数据库，再返回形成图形报表所需要的 DataSet，然后在利用 JFreeC
35、hart 包生成报表，其中也有一些是返回 JFreeChart 生成的报表路径名称，在页面上用标签直接引用。所以从本质上是与DBDataEJB 相同的。2.1.4 分布式计算技术的比较EJB属于中间件，它虽然也是分布式技术的一种，所谓分布式技术 4指通过网络互联，可协作执行某个任务的独立计算机集合。但是在语言支持方面就与最新的Web Service支持很多，不能很好的结合不同的开发平台，所以本项目引入了Web Service作为对BOAT项目新部分的技术支持。基于中间件分布式系统的体系结构与Web Service技术的体系结构与相比是非常相似的，可以把体系结构中的Web程序看作中间件。从结构上
36、来看，Web服务只是从侧面对中间件平台技术进行革新，虽然所有服务之间的通信都以XML格式的消息为基础，但调用服务的基本途径主要还是RPC ，而且具体实现并没有提供一种全新的编程模式。而移动Agent技术在实际的工程项目中应用不多，P2P技术也只应用在软件体系结构基于P2P的系统中。表2-1就基于Web Service 和中间件的分布式技术进行分析比较：表 2- 1 分布式计算技术的比较 5分布式技术 简述 网络通信 应用环境RPCRPC(Remote Procedure Call Protocol)是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 使得开发包括网
37、络分布式多程序在内的应用程序更加容易。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。在 Intenet 网络中，底层采用 TCP 和UDP 进行通信。RPC 技术是用来代替繁琐的基于 socket 的分布式编程，RPC 技术一般应用在面向过程的编程语言中RMIRMI 是 RPC 模型的面向对象实现。RMI 使用 Java 语言接口定义了远程对象，它集合了 Java 序列化和 Java 远程方法协议(Java Remote Method Protocol) 。JRMP（Java Remote Method Protocol）协议在纯 Java 开发的分布式系统中EJBEJB 是 su
38、n 的服务器端组件模型，最大的用处是部署分布式应用程序，类似微软的 COM 技术。凭借 Java 跨平台的优势，用 EJB 技术部署的分布式系统可以不限于特定的平台。采用 RMI 技术 主要应用在大型的基于 Java 技术开发的企业应用服务器端DCOMDCOM（ Distributed Component Object Model 分布式组件对象模型）是一系列微软的概念和程序接口，利用这个接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象 6。采用 RPC 技术 限用于微软开发技术和平台CORBACORBA（Common Object Request Broker Archi
39、tecture 公共对象请求代理体系结构）是由 OMG 组织制订的一种标准的面向对象应用程序体系规范。或者说 CORBA 体系结构是对象管理组织（OMG）为解决分布式处理环境GIOP/IIOP 协议 应用于需要跨平台和语言的分布式开发中12(DCE)中，硬件和软件系统的互连而提出的一种解决方案 7。Web ServiceWeb Service 的主要目标是实现跨平台的互操作，为了达到这一目标，Web Service 完全基于 XML、XSD 等独立于平台、独立于软件供应商的标准，它是创建可互操作的分布式应用程序的新平台。可以通过HTTP、FTP 、Email、MQ、IIOP 等协议传输主要应用
40、于 Web 开发中 2.1.5 对 BOAT 中 EJB 技术的思考随着技术的发展，不可否认得 EJB 技术已经淡出历史舞台，BOAT 平台的先期开发者基于 BOAT 系统复杂性、访问量大、时间上的局限性以及为了建立一个组件模型以便日后开发的需要而选择了 EJB2.0技术。时到今日如果完全重新设计 BOAT 系统，我认为它可以被其它更轻量级的框架所取代，因为 EJB 最大的用处是部署分布式应用程序，而企业级应用关心的只有数据，或者说隐藏在庞大数据中的信息。就像 BOAT 系统虽然现阶段它将用到两个数据库，但是两个数据库的核心是什么，还是数据，并不是分布式。关于 BOAT 系统的分布式问题，我们
41、已经通过 Web Service 技术解决了，所以虽然 BOAT 中还是使用了 EJB，但它并没有用到分布式的功能。 EJB 有两个模型，一个是组建模型，一个是远程访问模型，在BOAT 中使用的就是组件模型，并没有任何远程访问。所以就 BOAT 系统来说，它可以被取代，它可以被更轻量级、更易于开发的框架所取代，例如 Spring+ Hibernate。虽然随着 EJB3.0 的诞生，它也许十分优秀，但它的设计着眼点与 Spring+ Hibernate 这些轻量级框架的着眼点有很大的不同，因为 EJB3.0 不可能是一个全新的设计，它一定要在最大程度上与 EJB2.0 兼容，所以如果要重新设计
42、 BOAT 系统，我更倾向于采用 Spring 这个轻量级框架，而不是沿袭 EJB 的解决方案。2.2 Web Service 技术2.2.1 Web Service 概述Web Service 准确来说应该是一种分布式技术， 它的目标非常明确就是实现跨平台的互操作。所以为了达到这一目的，它是完全基于 XML， XSD 等标准，因为这些标准是完全独立于平台，独立于软件。这项技术主要应用于 Web 开发， 分布式之间的通信可以通过 HTTP、FTP、Email、MQ、IIOP 等协议传输。Web Service 技术的特点可以概括为以下几个方面：1. 松耦合2. 利用消息远程访问3. 可结合性就
43、是说可以用通过已存在的服务建立新的服务。4. 可发现性由于每一个 service 发布时，他的描述都是 WSDL 语言很好定义的，所以可以很容易的找到一个service。5. 还有就是每个订阅者如何使用这个 service，对于 service 提供者来说是保密的。也许大家对松耦合的概念并不是很清楚，下面通过它与紧耦合之间的比较来体现它在 web 应用中的优势。就通信方式来讲，紧耦合必须是同步的，而松耦合则是异步的；交互模式来讲，紧耦合是基于 OO方式访问的，而松耦合则是以数据为中心的，以消息来实现交互；紧耦合是静态发现和绑定服务的，而13松耦合则可以动态发现和绑定服务；还有就是依赖性，紧耦合
44、对平台和语言的依赖性很高，松耦合则相反，可以完全独立于平台和语言，换句话说就是一个系统的各个服务和模块可以建立在任何不同的平台，可以由不同的语言开发。虽然对于现代的企业级 web 系统来说，分布式的架构是很好的选择，松耦合的特性提供了很多优点，但是并不是说所有的功能模块都应该遵循这种特性，在系统设计的时候必须针对不同的模块在面向对象和以数据为中心之间做出正确的选择。比如说，如果一个公司要实现在他们的 web 平台上显示公司财报的功能，就这个功能而言是不适合 Web Service，因为它是一个显示的功能，并不包含业务逻辑，这种功能也不需要重用。比如在这个项目中适合 Web Service 的将
45、会是对数据库的各种组合访问的功能。2.2.2 Web Service 的访问当一个 Web Service 建立的时候，如何去访问它呢？下面是需要了解一些相关的概念：1. 提供者：创建可执行的服务，发布 Service Description。2. 请求者：寻找 Service Description，通过 Service Description 来绑定服务。3. 接口：服务提供者的公共接口，通过 WSDL 来发布和描述，主要起到隐藏内部执行细节的作用。以下通过一个股票信息的例子来具体阐述如何进行全程的 Web Service 调用（如图 2-2 所示） 。图 2- 2 通过 Proxy 的
46、Web Service 远程访问 8首先不管服务器端还是客户端，Service（SOAP）信息的创建和解析都是由各自的 Proxy 完成的。这里的 Proxy 可以说是一种设计模式，在 Client 端的 Proxy 代表向 Client 端提供的服务，而 Service Proxy 则是为了接受消息。而 Proxy 端的代码通常是自动生成的，比如在.Net 中 Client Proxy 就是 Web reference，而在 Java 中就是 proxy stub，在 Client 端如何生成 Proxy 对于 IDE 的用户是隐藏的，首先会获取 Web Service 的 WSDL，然后工
47、具内的 WSDL processor 会生成 Proxy，也就是说 Service 端的 Proxy 是按照WSDL 生成的。有了 Proxy，服务的提供者和消费者就被隔离了，它们只通过消息联系。而消费者使用服务时，就好像是本地方法一样直接调用，这种调用就变成一种请求，被序列化进 SOAP 消息，再在Service 端反序列化，而真正服务的请求和开发者并不需要直接创建或解释 SOAP 消息，这些都可以由Proxy 代劳。142.2.3 Web Service 的创建如何创建一个 Web Service 在工程中的意义比它的原理更重要，在开发过程中我们不需要知道 Web Service 的传输协
48、议，但一定要清楚如何应用和创建它。在当今的语言和平台环境下，创建 Web Service 可以说是相当简单的，如今最受欢迎的两个创建 Web Service 的环境就是 Microsoft .NET 和 Microsystems Java EE。创建一个 Web Service 的一项很重要的步骤就是搭建一个 Application Server，它是用来直接提供服务的，由它来完成以下的 4 个步骤，如图 2-3 所示。首先 Application Server 会把 HTTP 请求转化为数据对象，然后由 Web Service Toolkit（.Net SDK 或者两个标准的 JAVA AP
49、Is：JAX-RPC 或者 JAX-WS）调用Proxy 来传递消息数据 9，然后由 Proxy（这里的 Proxy 是一个 URL，用来指明 Web Service 的地址）调用Service Implementation 中的方法，最后由 Service Implementation 调用说需要的业务逻辑。图 2-3 Web Service 在 Application Server 中的运作在实际应用中，Application Server 因开发语言的不同而不同。有以下几种选择（如表 2-2 所示） 。表 2-2 Application servers 10.NET application serversInternet Information Server (IIS) 标准 Windows 组件Mono Application Server application serversOracle WebLogic IBM WebSphere Java System Application Server JBoss www.jboss.
