企业自动化管理框架的设计与实现——硕士学位论文

摘要摘 要 关键字： AbstractKeywords:48目录目 录摘 要IAbstractII第一章 引言11.1论文目的及方法11.2研究背景11.3国内外研究现状11.4论文主要内容31.5论文的组织安排3第二章 EJB及Web Service概述52.1 EJB52.1.1 EJB概述52.1.2 BOAT中为何要使用EJB52.1.3 BOAT系统中的EJB组件62.1.4分布式计算技术的比较72.1.5 对BOAT中EJB技术的思考82.2 Web Service技术82.2.1 Web Service概述82.2.2 Web Service的访问92.2.3 Web Service的创建92.2.3 Service Message102.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中调用Web Service173.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）244.3.1创建视图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 BackofficeJar中的邮件类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工作总结386.3工作体会386.4 名词解释：39参考文献40附录 Trigger代码41 第一章 引言1.1论文目的及方法一个大型的Web应用系统可以拥有很多的组成部分，也可以涉及到很多的技术，根据需求开发人员可以套用或设计不同的模式将各个部分和技术组合起来，从而最终实现一个应用系统。本文的目的之一就是通过对BOAT系统全面的阐述，来说明一个新的Web应用模式：利用Web Service来调用其它应用的数据服务。本文的目的之二就是说明数据库设计的重要性，因为所有的的应用的设计和实现都是基于数据的，所以成熟可靠的数据库表结构是非常重要的。本文阐述目的的方法是通过自己在BOAT系统实际开发过程中参与设计的体会，以及对自己所做实际开发工作的经历的总结而完成的。1.2研究背景自2000年以来，随着B/S架构被引入企业平台的开发，Java一直是平台开发的主流技术。随着时间的推移，J2EE的各种技术也是层出不穷，从EJB + Struts到SpringHibernate，再到EJB3.0的出现，各种第三方组件更是数不胜数。在J2EE的技术标准不断推出新的框架的同时，.Net技术由于它更低的开发难度以及前台界面控件的强大功能而受到开发者的青睐。由于这两种技术的并存，而且各有各的优点，由于J2EE对Request、Response和Session这样的对象的充分关注可以让开发者很好的对整个系统的流程进行控制，从而更利于系统整体架构的良好设计，而.Net在这点上相对逊色。所以当不同部门之间的工具平台整合和互用的时候就会发现问题，两种技术的设计理念区别还是很大的，所以会有Web Service的出现用于不同系统之间的互用，在这个求同存异的世界，用哪种技术并不是最关键的，.NET和J2EE都是专注在企业级应用上，相反随着时间的推移如何保证一个平台数据的可用性和结合性才是最重要的。就本文中的BOAT系统来说，它存在于当地爱立信的客户支持部已经5年之久，它的前台界面一直有人负责更新和升级，甚至整个系统除数据库以外的架构都已经换过，所以数据库以上的更新是一直存在的，并且这种更新与旧系统的运行是同时的，所以这次项目要保证在数据库现有数据结构不变得情况下更别的平台整合。而对于这个将要重用的新的系统(APM)，所要做的是设计它的数据库结构和它的访问层以便它不仅可以作为其本身的数据库系统，同时也很好的被BOAT所使用。在这一点上就可以把它看作一个小的分布式系统，项目中的一个重要任务就是通过对旧系统逻辑层和演示层以及新系统的数据层的设计和改进来达到跨平台业务逻辑的调用和不同系统的统一管理。综上所述，.NET和J2EE在企业级应用上的地位已经不容置疑，这两种技术在一个企业内并存的现象也是不可避免。而如今在各个企业级平台之间的数据重用和逻辑重用的这种需求，特别在一个企业内的相关平台之间，也已经越来越明显。虽然它们之间的关系谈不上分布式系统环境，但是在一定程度上已经有了互相协作，互相更新的行为，有了一定的依赖关系。而这种关系最关键的就是取决于数据库结构的设计。本文以BOAT为主要系统，以EJB调用Web Service为技术基础，APM平台的数据库设计为底层支持，讲述了如何组建一个可协作可重用其他数据Web企业级管理系统，从而达到协作管理的效果。1.3国内外研究现状现今，许多企业已经为他们的以存在的系统或者数据库投入了很多的资金和人力，因为更好的技术出现而舍弃旧的系统是不符合成本效益规则的，如何找到一条更符合成本效益的道路来优化企业的EIS(Enterprise Infromation System 企业信息系统)，SOA(Service Oriented Architecture)的概念就成为了最好的解决方案。Web Service作为这个概念的一项技术，已经月来越成熟，它通过一些协议和已有的技术(XML， Web Services Description Language (WSDL)， Simple Object Access Protocol (SOAP)， Universal Description， Discovery， Integration(UDDI)来实现SOA这个概念。它通过在旧系统上构建可供不同系统使用的web组件，使旧系统的功能整合到如今的复杂多样化的计算环境中，你可以提供一个尽可能简单的服务，由订阅者去决定如何使用，这种方式非常符合成本效益的规则，用最低的成本来做到新旧的结合，而且已经被广泛使用1。至于Web service未来会充当何种角色，也同样由它的特性所决定，云计算最近作为一个新名词进入大家的视野，微软和Google都推崇这种概念，虽然方式不一样，但是有一种未来大家是可见的，就是将来网上充斥的不再是信息，而是各种各样的服务。这种服务通过什么提供，就是存在于Internet上的各个网络单元通过Web Service提供的，它将成为未来的主流技术。不知道什么时候网上出现各种各样关于EJB性能差的说法，虽然EJB已经渐渐淡出历史舞台，但如果要使用J2EE提供一个成熟的解决方案，EJB将会一个选择，因为EJB的容器(如JBOSS)自动提供了对象池和缓存池。如果你的解决方案需要承受大量的并发访问，没有缓存池更本不可能达到用户要求。所以一个无状态的Session Bean的性能肯定要强于一个框架中的普通Java Bean。而随着EJB技术进入3.0阶段，它在更框架相比在数据持久性上面的不足也得到了加强。EJB3.0的很多新特性是通过JAVA SE5.0来实现的。这里就要谈到JAVA SE 5.0，它所提供的许多特性，其中最有趣的一点就是标注(Annotation)的功能。以前的JAVA语言都是命令格式的，比如a.b()，表示让类a做事情b，但是很多时候只是需要对某个对象做一些注解，比如对某个类标记为可持续化的Serializable。这只是一个标记，为了以后的处理提供说明，本身不需要做任何操作。 在Deploy 的时候， 提供了很多说明的XML文件，比如部署描述文件，里面说明了引用的EJB的名字，接口， 以及当前EJB的Transaction Type等等信息。所有这些信息都是说明性的，而不是命令性的。用来对某个对象的某个属性坐一段说明。因此，有一个非常有趣的想法，能不能通过对JAVA语言的扩展，结合标注和命令这两者的优点? 这也是有一个专家组在JCP的组织内完成的，JSR规范的编号是JSR 175，为JAVA SE 5.0支持标注(Annotation)的功能。这个规范为EJB3.0 的简化实现提供了一些基本的支持，也是最关键的支持。标注可以有自己的属性，也可以定义自己的持续时间，表示这段信息是否保存到源代码中，还是一直持续到Class中，或者一直保持到运行时间。标注有自己的缺省值。大多数情况下，无须说明就可以推算出来这个对象的行为。但是现在随着Swing框架的流行，统计数据显示，EJB的受欢迎程度在降低，EJB3.0也不可能完全抛弃EJB2.0完全重新设计，它势必要达到对EJB2.0的最大兼容。而且不管是EJB2.0还是3.0，它们最大的优势都是分布式部署，而J2EE的企业级应用向来关心的是数据本身，并不是分布式，或者说更本用不到分布式部署，在这一点上EJB就失去了它的效用，在BOAT系统中继续使用EJB就相当于继续使用一个组件，因为先前建立的EJB已经建立了一个组件模型，如果再要实现什么新功能，只要依照原来的组件模型模仿就行了。如果要重新设计BOAT系统，现存的组件模型的EJB完全可以被Spring这个轻量级框架所取代2。但是现阶段在这个项目中最重要的不是用更先进的技术重新实现BOAT，而是新增功能，并使BOAT系统可以很好的使用外部数据库，所以EJB在BOAT中会继续存在。所以结合这两种技术，现在一个Web企业级应用如果采用J2EE作为解决方案，那么它的主流的架构将会是这样的，底层是由数据库存储实现的持久层，数据库之上是EJB的模型类包括所有的业务逻辑，在EJB类之上建立的是Web Service层，在这层之上建立的框架动作层，它可以是struts动作或者是spring动作，也就是通常所说的控制用于决定显示层的显示，再之上就是显示层，它们由JSP页面组成。这种架构中最主要的创新就是中间的Web Service层，它不但可以将自己系统本身由EJB组成的业务逻辑和数据库访问作为服务提供给控制层，而且同样可以把这种服务提供给外界的订阅者，而订阅者只要知道它们所需要的Web Service的WSDL描述即可，同时Web Service层还可以提供数据的验证、错误处理以及数据对象的缓存(Caching)，这种缓存是可以通过代码完全控制，缓存数据避免任何不必要的数据库访问，可以在本地缓存一个会话bean方法调用返回结果，这样就大大提高了数据访问的速率，从而提供系统的整体性能。在Web Service层的错误处理中隐藏了与EJB相关的系统异常。与API相关的系统异常，比如RemoteException，EJBException都在WSManager中被捕获然后作为一个非EJB的相关异常(比如一个自定义的业务代理异常)通过Web服务端点重新抛出给客户端。应用级的异常仍然被传递给Web服务端点，然后由 Web服务端点通过SOAP消息发送给调用Web服务的客户端。Web Service层在提供服务的同时，当然也可以从其它的服务提供者(Service Provider)处获得服务。这样看来，新加入的这个层起到了内部以及外部通信的作用。在未来的面向服务的趋势中，这种结构将会越来越受到欢迎。1.4论文主要内容论文所讨论的系统是在爱立信客户支持部内使用的工作平台，整个部门的运作也依赖于它，所以就此系统地位而言是相当重要的。虽然这个系统已经存在很长时间，但是随着客户需求的不断变化，开发技术的不断改进，需要的维护和功能加强和更新也越来越多。我在这个项目中的任务是对代码进行优化，必要时重新开发，在这次开发过程中，也遇到了一些特殊的问题，如两个不同系统之间的交互等引起的问题。因此本文基于BOAT系统，就本人所参加的工作，结合各项工作所采用的技术和方法，从以下方面对BOAT系统和我所承担的开发工作进行了讨论： (1) 探讨了EJB以及Web Service在BOAT系统中的重要作用EJB是JAVA技术中服务器端软件构件的技术规范和平台支持，这是站在软件组件的角度去看。在软件产业中，基于组件的技术是当前的热点，虽然这个管理系统并不是最新的管理系统，就EJB2.0来说，所采用的技术也不是非常先进，但是本文站在一个当时开发这个系统的角度解释为何采用EJB，这个技术对后续的二期开发有何好处。另外，为了促进不同平台之间的合作以及数据重用（BOAT与APM），本文还详细讨论了BOAT系统中新引进的Web Service技术，并且讨论了在Java环境中调用远程Web Service的实际开发过程。(2) 探讨了数据库设计对于一个Web管理系统的重要性及实现数据库在应用程序的重要位置是任何人无法否认的。数据库的设计也有数据库设计的规则，如常常所见的第一范式、第二范式、第三范式甚至于到第五范式。这些都属于理论上的内容，仅仅凭借一时的空想是完全不可能做到数据库的优良设计。在我们的项目中通过对需求的详细分析，在通过SQL 2000 DBMS最大程度的结合实际，结合用户的业务规则来进行数据库的设计。但是在本文中强调的那些设计数据库的关键思想并不是光依赖于一个强大的DBMS，它提供的仅仅是一个平台，来辅助我们的设计，真正要让数据库中的数据很好的服务我们的系统还是取决于对项目的理解。本文中的这部分就从这方面出发讲述BOAT数据库的设计。(3) 利用JFreeChart技术创建报表以及BOAT中邮件提醒等重要功能的设计与实现JFreeChart是一个纯Java类库，它可以让开发者很简单的得到具有专业质量的图形报表。因为BOAT是一个J2EE的项目，所以采用了JFreeChart作为实现目的一个手段。作为与报表功能同级的邮件提醒功能，我也在本文中对于它的原理和思想以及实现作了详细解释。本论文中描述的系统是作者在实习公司参加的实际项目，作者的主要工作包括：参与了整个管理系统的总体设计和技术论证；开发和实现了BOAT管理系统中的报表、记录搜索等功能以及日志管理系统；管理系统中信息同步性的设计和实现；以及修改了部分客户端代码 。作者的主要贡献是利用Web Service技术实现了对不同系统的数据库中的数据进行重用。 1.5论文的组织安排论文主要各章节摘要如下：第一章是论文的绪论。从选题背景开始，简述本项目所采用技术的研究现状，提出课题研究思路和论文的主要内容，概要枚举论文对企业级Web解决方案的研究成果，描述论文结构。第二章概述了EJB技术和Web Service技术。简要概括了EJB技术的组成部分以及各部分的功能，还有它的Web容器JBoss，同时也简述了这项技术的优势和弱点。这一章中也分析了使用Web Service的具体优点，并且从项目角度出发讲解Web Service技术，使读者了解Web Service的优点如果体现，如果真正应用这项技术，不管是在C#.Net环境中还是在JAVA环境中。第三章主要讨论了本项目系统BOAT。通过对BOAT系统架构的解析使读者更深入了解这个平台所做的工作，也更好地让读者了解各种技术在整个系统中扮演何种角色。为了能更好地阐述这个系统，本章也同时简要介绍了APM系统，包括它的用途和技术，技术主要从Web Service出发，目的是为了体现在JAVA和C#环境中调用Web Service的不同情况。第四章只要从APM系统的底层数据库结构设计开始讲述如何设计数据库设计在整个系统中的重要性。在这一章也提到了本项目中，如何针对这个特定的数据库来设计直接架设在数据库之上的Web Service层。第五章阐述了一些非主要技术整个系统中的作用，比如JFreeChart在图形报表方面的功能、使用Ant编译和打包整个项目的功能以及在BOAT系统中十分重要的邮件提醒机制。第六章对论文的工作进行了总结。第二章 EJB及Web Service概述本章主要描述了在开发管理系统时用到的两大主要技术EJB和Web Service。在2.1节首先介绍了EJB技术的相关概念，并分析和比较了现有的主要分布式计算技术。接着通过2.2节简单介绍了Web Service技术的内容，然后在2.3节分析了JMX的优势并说明了本管理系统采用JMX的理由，最后在2.4节介绍了JMX技术。2.1 EJB2.1.1 EJB概述EJB是JAVA技术中服务器端软件构件的技术规范和平台支持，这是站在软件组件的角度去看。在软件产业中，基于组件的技术是当前的热点。在面向对象的软件世界，基于组件的技术可以解决软件开发上的重复开发的问题。所以不同的厂商也相继推出他们的组件技术，形成了不同的派系，其中以微软为首的DCOM/COM阵营，从DDE，OLE 到ACTIVEX等，提供了构件开发的基础。相对的，包括SUN在内的对象管理组织OMG，推出了跨语言的CORBA，已逐渐成为业界的标准。而EJB是OMG成员之一的SUN推出的基于JAVA的组件规范，自从随J2EE推出之后，广泛的得到了业界的支持，已经成为应用服务器的标准技术。从企业多层架构的角度，EJB是业务逻辑的核心，与普通的Java Bean不同的是它提供了事务处理的能力。EJB是利用JTA进行事务管理的，并不是JDBC里的Connection，由于和数据存储层分离，所以EJB的出现取代了存储进程的大部分地位3。从分布式的角度看，EJB和CORBA，提供了分布式对象的基础，从而提供对象之间的通信机制。当然从最实际和最广泛的用途看，EJB与Servlet、Jsp一起成为应用服务器的技术标准，EJB中的Session Bean和Entity Bean，前者维护会话，处理逻辑，后者处理事务。Servlet则负责与客户端通信，访问EJB，同时把结果传输给Jsp显示。2.1.2 BOAT中为何要使用EJBEJB在J2EE的解决方案中并不是必须的，开发人员可以用一些简单的技术，比如servlets， JSPs，同样可以建立用户想要的系统。就一般的程序开发经验来说，如果项目不大，也不要求很高的可扩展和可维护性，那么可以用普通的J2EE组建servlets加上直接的JDBC的连接去实现项目。 但是当需求复杂，同时要求的并发用户增多时，EJB的使用就让分割和把握整个项目变得更容易，在这种情况下使用EJB就会给用户明显的优势。如今的软件开发趋势是让程序员从底层的架构还有中间层的通讯中脱离出来，让他们的重点放在业务逻辑的开发上，而采用EJB模型就很好的符合了这一点，因为EJB模型的目标之一就是尽可能的减少交互的复杂性，将重点放到每个Session Bean的业务逻辑中去。也就是说BOAT系统将重要的业务逻辑放到EJB中与显示层分开。另外EJB还能支持多用户接口，例如如果需要创建一个用户接口，它使用的是Java Swing API，但是也有可能用户需要将这部分业务功能放到网络平台上，那么需要作的只是设计一个servlet的接口就行了，并不需要修改EJB中的任何一行代码，图2-1就很好的解释了这一点：图 2-1 EJB组件的UML图并且EJB有特定的容器很好的管理它，Bean的初始化、状态管理以及回收都是主动由容器负责，程序员不需要为此担心。所以说对于一个像BOAT这样较为复杂的系统来说，它的业务逻辑是最重要的，它一旦投入使用，只要爱立信存在，那它就一定会持续使用下去，技术在不断更新，如何保护和分离业务逻辑，以及重用业务逻辑才是最重要的，所以在BOAT项目一开始的时候，EJB开发的业务逻辑部分就被作为这个项目的核心一直保留到现在。2.1.3 BOAT系统中的EJB组件如之前所说的，BOAT中的EJB组件处理了系统中主要的业务逻辑，比如根据用户输入数据在数据库中组织查询得到想要的结果再传给显示层，又或在动态图表功能中访问Web Service从远程数据库中得到制图所需要的DateSet。在BOAT中的EJB类有一个共同的特性：就是根据用户输入的数据，在类中附加业务逻辑后组织数据库查询，最终得到查询的数据结果后再应用到显示层上。以下介绍两个在BOAT系统中主要的EJB类。 DBDataEJB在这个EJB当中很重要的一部分是要先建立数据库连接，由于本项目采用JBOSS作为EJB的容器，所以为了配合容器使用MySQL，必须先在Class Path内将MySQL的JDBC的驱动程序预先设置好，这样在每一个DBDataEJB的方法中只要得到容器中的初始环境（Initial Context），然后搜索MySQL中的连接池，最终获得连接。这样，可以在这个EJB中每一个方法都代表一段特定的业务逻辑，每一个方法都去寻找存在的数据库连接，各自独立。这个EJB是一个StateLess Session Bean，说容器是不会保存这个EJB的状态的，也就是说当出现并发访问的时候，用户使用的是相同的DBDataEJB实例来满足他们的业务需求。使用Stateless Session Bean的理由是因为DBDataEJB中的方法都是公共方法，属于最基本的功能，任何一个用户都有权利调用其中的业务逻辑，所以不需要在其中保存一些用户信息，也不需要为每一个连接都建立一个实例（Instance），这样可以节省Server的存储空间。 HelperEJB首先这个EJB更DBDataEJB一样是一个StateLess Session Bean，可以说它们实现的功能是大致相同的。不同的是，HelperEJB是为BOAT中的统计图形报表专门服务的，它其中的很多方法都直接调用Web Service访问远程的数据库，再返回形成图形报表所需要的DataSet，然后在利用JFreeChart包生成报表，其中也有一些是返回JFreeChart生成的报表路径名称，在页面上用标签直接引用。所以从本质上是与DBDataEJB相同的。2.1.4分布式计算技术的比较EJB属于中间件，它虽然也是分布式技术的一种，所谓分布式技术4指通过网络互联，可协作执行某个任务的独立计算机集合。但是在语言支持方面就与最新的Web Service支持很多，不能很好的结合不同的开发平台，所以本项目引入了Web Service作为对BOAT项目新部分的技术支持。基于中间件分布式系统的体系结构与Web Service技术的体系结构与相比是非常相似的，可以把体系结构中的Web程序看作中间件。从结构上来看，Web服务只是从侧面对中间件平台技术进行革新，虽然所有服务之间的通信都以XML格式的消息为基础，但调用服务的基本途径主要还是RPC，而且具体实现并没有提供一种全新的编程模式。而移动Agent技术在实际的工程项目中应用不多，P2P技术也只应用在软件体系结构基于P2P的系统中。表2-1就基于Web Service和中间件的分布式技术进行分析比较：表 21 分布式计算技术的比较5分布式技术简述网络通信应用环境RPCRPC(Remote Procedure Call Protocol)是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。在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是sun的服务器端组件模型，最大的用处是部署分布式应用程序，类似微软的COM技术。凭借Java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。采用RMI技术主要应用在大型的基于Java技术开发的企业应用服务器端DCOMDCOM（Distributed Component Object Model分布式组件对象模型）是一系列微软的概念和程序接口，利用这个接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象6。采用RPC技术限用于微软开发技术和平台CORBACORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）是由OMG组织制订的一种标准的面向对象应用程序体系规范。或者说 CORBA体系结构是对象管理组织（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案7。GIOP/IIOP协议应用于需要跨平台和语言的分布式开发中Web ServiceWeb Service的主要目标是实现跨平台的互操作，为了达到这一目标，Web Service完全基于XML、XSD等独立于平台、独立于软件供应商的标准，它是创建可互操作的分布式应用程序的新平台。可以通过HTTP、FTP、Email、MQ、IIOP等协议传输主要应用于Web开发中 2.1.5 对BOAT中EJB技术的思考随着技术的发展，不可否认得EJB技术已经淡出历史舞台，BOAT平台的先期开发者基于BOAT系统复杂性、访问量大、时间上的局限性以及为了建立一个组件模型以便日后开发的需要而选择了EJB2.0技术。时到今日如果完全重新设计BOAT系统，我认为它可以被其它更轻量级的框架所取代，因为EJB最大的用处是部署分布式应用程序，而企业级应用关心的只有数据，或者说隐藏在庞大数据中的信息。就像BOAT系统虽然现阶段它将用到两个数据库，但是两个数据库的核心是什么，还是数据，并不是分布式。关于BOAT系统的分布式问题，我们已经通过Web Service技术解决了，所以虽然BOAT中还是使用了EJB，但它并没有用到分布式的功能。EJB有两个模型，一个是组建模型，一个是远程访问模型，在BOAT中使用的就是组件模型，并没有任何远程访问。所以就BOAT系统来说，它可以被取代，它可以被更轻量级、更易于开发的框架所取代，例如Spring+ Hibernate。虽然随着EJB3.0的诞生，它也许十分优秀，但它的设计着眼点与Spring+ Hibernate这些轻量级框架的着眼点有很大的不同，因为EJB3.0不可能是一个全新的设计，它一定要在最大程度上与EJB2.0兼容，所以如果要重新设计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. 可结合性就是说可以用通过已存在的服务建立新的服务。4. 可发现性由于每一个service发布时，他的描述都是WSDL语言很好定义的，所以可以很容易的找到一个service。5. 还有就是每个订阅者如何使用这个service，对于service提供者来说是保密的。也许大家对松耦合的概念并不是很清楚，下面通过它与紧耦合之间的比较来体现它在web应用中的优势。就通信方式来讲，紧耦合必须是同步的，而松耦合则是异步的；交互模式来讲，紧耦合是基于OO方式访问的，而松耦合则是以数据为中心的，以消息来实现交互；紧耦合是静态发现和绑定服务的，而松耦合则可以动态发现和绑定服务；还有就是依赖性，紧耦合对平台和语言的依赖性很高，松耦合则相反，可以完全独立于平台和语言，换句话说就是一个系统的各个服务和模块可以建立在任何不同的平台，可以由不同的语言开发。虽然对于现代的企业级web系统来说，分布式的架构是很好的选择，松耦合的特性提供了很多优点，但是并不是说所有的功能模块都应该遵循这种特性，在系统设计的时候必须针对不同的模块在面向对象和以数据为中心之间做出正确的选择。比如说，如果一个公司要实现在他们的web平台上显示公司财报的功能，就这个功能而言是不适合Web Service，因为它是一个显示的功能，并不包含业务逻辑，这种功能也不需要重用。比如在这个项目中适合Web Service的将会是对数据库的各种组合访问的功能。2.2.2 Web Service的访问当一个Web Service建立的时候，如何去访问它呢？下面是需要了解一些相关的概念：1. 提供者：创建可执行的服务，发布Service Description。2. 请求者：寻找Service Description，通过Service Description来绑定服务。3. 接口：服务提供者的公共接口，通过WSDL来发布和描述，主要起到隐藏内部执行细节的作用。以下通过一个股票信息的例子来具体阐述如何进行全程的Web Service调用（如图2-2所示）。图 22 通过Proxy的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，然后工具内的WSDL processor会生成Proxy，也就是说Service端的Proxy是按照WSDL生成的。有了Proxy，服务的提供者和消费者就被隔离了，它们只通过消息联系。而消费者使用服务时，就好像是本地方法一样直接调用，这种调用就变成一种请求，被序列化进SOAP消息，再在Service端反序列化，而真正服务的请求和开发者并不需要直接创建或解释SOAP消息，这些都可以由Proxy代劳。2.2.3 Web Service的创建如何创建一个Web Service在工程中的意义比它的原理更重要，在开发过程中我们不需要知道Web Service的传输协议，但一定要清楚如何应用和创建它。在当今的语言和平台环境下，创建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 APIs：JAX-RPC或者JAX-WS）调用Proxy来传递消息数据9，然后由Proxy（这里的Proxy是一个URL，用来指明Web Service的地址）调用Service Implementation中的方法，最后由Service Implementation调用说需要的业务逻辑。图 23 Web Service在Application Server中的运作在实际应用中，Application Server因开发语言的不同而不同。有以下几种选择（如表2-2所示）。表 22 Application servers10.NET application serversInternet Information Server (IIS)标准Windows组件Mono Application S/appserver/Java application serversOracle WebLIBM WebS/software/webshpere/Sun Java System Application SJBApache Tomcat在部署到Application Server之前，首先要创建一个Web Service，在本项目中用的是.NET，这儿也用一个.NET的例子说明。在Visual Studio中创建一个Web site，直接选择ASP.NET Web Service的模板，然后设置Web Service的URL路径，在生成的文件中写一个方法，在方法前加“WebMethod”的关键字，在编译后，proxy和WSDL会自动生成，这样就完成了最简单的创建。当然在定义方法的时候通过属性还可以定义这个服务的一个唯一标识符，即WebService(Namespace = “/getstock”)。2.2.3 Service Message服务创建者和订购者之间的通信通过的是SOAP消息，而SOAP消息又是通过XML来表示的，SOAP消息的结构如图2-4所示：图 24 SOAP消息的组成由图可见，SOAP消息由header和body组成，其中header主要用于Service的元数据（Metadata，表示Service数据的属性），路由信息（Routing），安全信息（Security），相关性信息（Correlation）等等；body主要包括方法参数和方法返回值。2.2.4 Web Service在本项目中的应用本项目中，Web Service是建立在数据库层面上，也可以把它看作数据层，更普通数据层不同的是这个数据层可以同时给几个不同系统提供服务。在构建这个数据库的Web Service的时候，将它的整体功能分为3类：DataAccess Provider；Exception Provider；Security Provider。Data Access Provider主要提供常规的数据查询和修改（C、R、U、I），Exception Provider主要提供用户操作所产生的逻辑异常信息（逻辑异常指用户的又违业务逻辑的异常，不是程序执行异常），Security Provider主要提供用户的验证信息，以及在系统中各个模块中不同权限的信息。在层次上，分为两层，底层是普通类，直接更数据库连接，对数据库进行操作，上层是Web Service类，调用底层的类对数据库从而达到对数据库操作的目的。所以底层类只能由Web Service调用，对外是私有的，而Web Service对外是公有的，底层类更确切地说是Web Service更数据库之间的接口，它们之间的结构如图2-5所示。图 25 APM Web Service类结构图黄线以上的部分为3个Web Service类，黄线以下是为Web Service提供接口的类，上层的类调用下层的类。这里主要拿DataAccessProviderWebService为例，这个Service是整个APM Service的核心，它的方法中包括了所有对数据库表的操作方法，有特定的，也有泛型的，所有对数据库的操作，包括（C、R、U、I）都由这个Web Service完成，在每一个方法中最后的数据库执行操作的部份都是通过对DataAccessProviderInterface中方法的调用完成。这样就完成了一个数据层的分层，Web Service层包含少许的业务逻辑可以根据需求变动，而DataAccessProviderInterface则纯粹的完成C、R、U、I的工作，不需要进行改动。由于所有的Interface（黄线以下）对外都是私有的，而只有它们拥有对数据库操作的权利，所以虽然本项目的Web Service层对外公布，但通过Web Service必须遵循一定的业务逻辑，再加上Security Web Service的用户验证，我们就可以很有效的保护数据库。2.3本章小结 本章首先介绍了EJB技术，包括其他各种分布式技术的比较。接着在此基础上简单介绍了EJB技术在本项目中的应用，然后简要介绍了Web Service技术的优势和本管理系统采用Web Service的理由，最后对Web Service在本项目中的架构作了简单的介绍。 当今Java已经被广泛地应用在企业开发的方方面面，.NET框架也很受开发者的欢迎，它们各有个的优点，在各种各样分布式技术流行的今天，平台之间的互相协作和应用成了很关键的问题，Web Service作为解决这个问题的关键技术起着越来越重要的作用，它们为数据提供了远程的查询手段，使数据发挥更大的作用。 第三章 BOAT系统本章主要讨论了BOAT系统在爱立信中担当的角色和用途，以及它作为一个自动化管理系统的特点。在这一章主体部分主要从技术角度出发，讲述如何设计BOAT系统来实现它的特点。为了更好的阐述BOAT系统的报表功能，同时也简单介绍了APM系统（BOAT系统需要用到APM的数据）。3.1 BOAT系统介绍3.1.1 BOAT系统从何而来BOAT（Back Office Administrator Tool）是爱尔兰爱立信Back Office部门的主要工作平台，而Back Office部门从事的主要工作就是作为爱立信全球客户所用的OSS（Operations Support Systems）软件的第三层技术支持。也就是说当全球任何一个移动运营商的OSS软件出现问题的时候，他们就可以咨询这个部门，来寻求解决之道。客户的咨询都是以Email的形式到达（必须从爱立信内部网站上按照特定的格式来完成一个CSR（Customer Service Request）邮件）。因为是第三层技术支持，也就是说处理的都是第一第二层不能处理的问题，所以邮件都是来自爱立信内部的Maketing Unit、GSDC等部门。当邮件慢慢增加，问题种类（也可能会有TR产生）越来越多的时候，所有的数据就变得难以处理，也难以重用。这样BOAT系统就应运而生了，他主要负责自动解析进入该部门的工作邮件，将它们转化为数据库中的一个CSR或者TR，然后生成内部邮件提醒员工有新的案子进入该部门，员工接到通知后就可以登录该平台队新案子进行操作给出回答，再回复给第一第二层的技术支持或直接回给客户。当然因为此系统可以很好的管理历史数据，所以很多其它的功能也集成在这个平台上，如报表功能，历史问题和答案的查询功能以及一些辅助信息的提醒机制（将会在本章中做详细介绍）。以下列出了BOAT平台的四个主要功能11：1. 用户在BOAT系统中可以跟踪一个CSR从一个CSR的创建开始到结束，CSR总是存在于BOAT系统中，用户可以很方便的查询它的状态和详细信息。2. 管理CSR使它符合WLA（Working Level Agreement）为了让客户满意爱立信对它们的支持，所以针对不同的客户和CSR，必须为每一个CSR设定一个目标时间，必须在规定时间内给出答案，所以每个CSR都有一个计时器，会倒计时，员工要即时给出答案来符合WLA。3. 创建一个CSR答案的数据库很多CSR都具有共同点，在给出了一个CSR的解决方案以后，BOAT数据库就有必要很好的记录这个解决方案，以供以后更有效的给以客户支持。4. 生成统计数据图形报表为了很好的统计支持的工作和反应客户的状态，生成统计图形报表是最简单和直接的方法，这样不光可以给爱立信一个历史工作的总结以及各个客户的状态，更可以给自己的产品所存在的问题给出很好的定位。3.1.2 B