浅析基于JavaEE的数据库管理的架构、设计与实现
时间：2022-05-28 01:16:29
【摘 要】作为Java语言的缔造者，Sun公司在1999年底了企业级Java平台J2EE——Java 2 Enterise Edition。随着J2EE 1.5标准的，Sun将J2EE正式更名为JavaEE。JavaEE并非是一个产品，而是一系列技术和标准的集合。具体JavaEE平台下的产品由各厂商实现，并遵循同一个标准。本文描述了一款基于GEF和EMF技术的javaee应用快速开发工具——jStudio，它可以快速、高效地自动生成基于Struts+Spring+Hibernate的JavaEE应用。该工具可以大幅度减少程序开发人员编写重复性代码的工作量，同时可提高代码的质量，进而可缩短开发周期和降低开发成本。
JavaEE是Sun公司提出的多层(multi-diered)，分布式(distributed)，基于组件(component-base)的企业级应用模型(enterpriese application model).在这样的一个应用系统中，可按照功能划分为不同的组件，这些组件又可在不同计算机上，并且处于相应的层次(tier)中。所属层次包括客户层(clietn tier)组件，web层和组件，Business层和组件，企业信息系统(EIS)层。JavaEE是建立在Java平台上的企业级应用的解决方案，它极大的简化了企业级解决方案的开发、部署和管理等复杂的问题。同时，它也为企业级应用提供事务、安全性、命名、持久性和资源管理等服务，这些服务使得JavaEE应用开发人员能够专注于开发商业逻辑而不必考虑底层的细节。
一、JavaEE开发平台简介
JavaEE包括Faculies for develops JavaEE Apps，Runtime Environment，Docs&Samples。
JavaEE核心就是来解决分布式应用（见图1）。
Java EE一般分为4层：
（1）客户端
（2）web层
（3）业务逻辑层
（4）企业信息层（EIS：Enterprise Information System）
JavaEE Containers
Containers are the interface between a component and the low-levelplatform-specific functionality that supports the component. Before aweb，enterprise bean，or application client component can be executed，it must be assembled into a Java EE module and deployedinto its container。e.g.Entity Bean Container(Jboss).
是用来管理组件行为的一个集合工具。
组件：本意是指可以重用的代码单元，一般代表着一个或者一组可以独立出来的功能模块，在J2ee中组件的种类有很多种，比较常见的是EJB组件、DAO组件、客户端组件或者应用程序组件等，它们有个共同特点是分别会打包成.war，.jar，.jar，.ear，每个组件由特定格式的xml描述符文件进行描述，而且服务器端的组件都需要被部署到应用服务器上面才能够被使用。
JavaEE Container Type
JavaEE Application Server
The runtime portion of a JavaEE product. A JavaEE server provides EJBand web containers.Enterprise JavaBeans (EJB) Container
Manages the execution of enterprise beans for JavaEE applications.
Enterprise beans and their container run on the JavaEE server.
JavaBeans™ 架构基于一种组件模型，此模型允许开发人员创建组件软件单元。组件是功能完备且可重用的软件单元。可以使用可视化应用程序构建工具将组件集成到复合组件、applet 程序、应用程序和 servlet 中。JavaBean 组件也称作 beans。
Web Container（Tomcat、apache）
Manages the execution of JSP page and servlet components for JavaEEapplications.
Web components and their container run on the JavaEE server.
Application client container
Manages the execution of application clientcomponents.
Application clients and their container run on theclient.
Applet container
Manages the execution of applets.
Consists of a web browser and Java Plugin runningon the client together.
二、JavaEE体系架构
JavaEE体系架构采用传统的MVC设计模式，分为Model、View、Controller三层，其中：Model即模型层，定义数据模型和业务逻辑。为了将数据访问与业务逻辑分离，提高业务精度，降低代码之间的耦合，模型层又细分为DAO层与业务层，DAO全称为Data Access Object（数据访问对象），将数据库访问代码封闭起来，Hibernate API也在此封装，不再出现在其他层或向其他层暴露；业务层是整个系统最核心也最具价值的一层，该层封装应用程序的业务逻辑，处理数据，关注客户需求，在业务处理过程中会访问原始数据或产生新数据，或者需要持久化数据，DAO层提供的DAO类能很好地帮助业务层完成数据处理，业务层本身则侧重于对客户需求的理解和业务规则的适应，自然也包括大部分的计算，总体说来，DAO不处理业务逻辑，只为业务层提供辅助，获取原始数据或持久化数据等操作。View即视图层，为最终用户提供一个友好的交互界面，用户可以查看请求结果，也可以通过表单等交互手段实现数据录入。Controller层即控制器，控制器是Model与View的桥梁，将二者很好的衔接，通过View接收用户数据，Controller将数据传输给Model，Model对数据进行处理；或者Model读取数据后，Controller将数据传递给View，View向用户展示数据。一来一往，Controller成了Model与View之间的快乐使者。
三、JavaEE数据管理系统的设计与实现
(一)元数据管理系统的设计
使用本系统的各部门实际情况不同，系统可能被部署到不同的平台上，而且需要对该系统进行一定的扩展和改进。所以在系统设计上，需要充分考虑到系统的可移植性和可扩展性。
1.系统设计
本系统基于J2EE平台，是一个浏览器/服务器（B/S）结构的系统，具有J2EE平台可以跨系统使用的特性，采用MVC（Model－View－Controller）应用框架。MVC设计框架的内部原理比较复杂，将MVC运用到应用程序中会带来大量的额外工作，增加应用的复杂性。但是MVC可以轻松地实现程序代码与HTML的分离，而且MVC的三个模块相互独立，可以构造良好的松耦合构件，提高应用系统的可维护性、可扩展性、可移植性和可复用性。从长远的应用考虑，应使用ＭＶＣ设计框架。
本系统在传统的B/S三层结构上作了一定的改进。
(1)表现层。在该层使用Struts框架。Struts是一个MVC模式的表现层应用框架。浏览器向Web服务器提出请求后，Web服务器会把请求交给控制器处理。ActionServlet控制器根据请求的不同，将它们转发给不同的Action实例。Action实例在这里充当了用户请求与业务处理逻辑之间的适配器，它只负责控制整个程序的流程，不关心具体业务的实现，实现了请求与业务逻辑的分开。本系统使用一个高效的Action类——DispatchAction类。只要继承该类，就可以在一个Action中集成多个业务方法，有利于系统的维护。在视图显示方面，其大量使用了Struts标签，用来控制显示的逻辑和内容。由于不同平台采取的编码方式不同，在进行系统移植时很容易出现中文乱码问题。在这里使用一个可插拔式的过滤器，实现对请求和响应的预处理及后处理，很好地解决了字符编码问题，使系统可以在不同的平台上进行移植。
(2)业务层。它处理用户请求和应用逻辑。在处理之前，将所有涉及到表现层的数据结构替换成更加通用的数据结构类型；使用通用的、与表现层无关的数据结构在这两层之间传递参数。表现层方法提交的参数类型主要是HttpServletRequest和HttpServletResponse；使用这样的参数会增加系统的耦合性，不利于代码的重用，所以要将它们处理成通用的数据类型，如数组。这一过程在Action适配器进行转发之前完成，提供给业务层的参数是通用的数据类型。业务层方法之间的通信也通过通用的参数类型进行，使得每个业务方法均独立存在于系统之中，在很大程度上减少了系统的耦合，提高了可复用性。
(3)数据层。为了实现数据库访问细节与业务层的分离，引入持久化层。
为了使系统具有较好的可维护性、可移植性和可复用性，采用以上的设计思想，以搭建一个逻辑清楚、功能明确、模块化程度高的元数据管理系统。
2.工作流程
用户通过浏览器（IE/Netscape）向服务器提交请求，请求经过过滤器处理后再提交给控制器ActionServlet；控制器根据请求的类别将它们转发给不同的DispatchAction类。该类中的方法对参数进行处理后调用不同的业务逻辑对请求进行分析处理，处理后得到的信息通过视图显示在用户浏览器上。
(二)基于J2EE的元数据管理系统的实现
一个元数据管理系统——基于J2EE的小城镇元数据管理平台。本实例以J2EE平台为基础，Tomcat 5.0为服务器，可以使用Oracle 9i、SQL Server 2000、MySQL数据库，使用了ORM（Object－Relation Mapping）模式的持久化层中间件Hibernate，以Eclipse 3.0为开发平台。在系统实现过程中，使用了以J2EE平台为基础的各项技术，遵循Java2标准平台的编码标准，注重系统的可扩展性和可维护性。系统的XML引擎采用了DOM（Document Object Model）和SAX（Simple API for XML）。DOM负责XML文档的生成和修改；SAX对XML进行解析。
四、JavaEE应用程序在Glassfish上的性能调优案例分析
Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题。特别是企业级的应用，并发用户多，数据传输量大，业务逻辑复杂，占用系统资源多，因此性能问题在企业级应用变得至关重要，它和系统的稳定性有着直接的联系。更加重要的是，性能好的应用在完成相同任务的条件下，能够占用更少的资源，获得更好的用户体验，换句话说，就是能够节省费用和消耗，获得更高的利润。JavaEE应用性能调优不仅仅和Glassfish有关，Java语言有关，还要和操作系统以及硬件都有关系，需要调优者有综合的知识和技能。这些不同层面的方法需要综合纵效，结合在一起灵活使用，才能快速有效的定位性能瓶颈。下面是一些具体的案例分析：
(一)内存泄漏问题
某个JavaEE应用运行在8颗CPU的服务器上。上线运行发现性能不稳定。性能随着时间的增加而越来越慢。通过操作系统的工具（mpstat），发现在系统很慢的时候，只有一颗CPU很忙，其他的CPU都很空闲。因此怀疑是Java虚拟机经常进行内存回收，因为虚拟机在内存回收的时候，有的回收算法通常只能运行在一个CPU上。通过Java虚拟机的工具“jstat”可以清楚的看到，Java虚拟机进行内存回收的频率非常高，几乎每5秒中就有一次，每次回收的时间为2秒钟。另外，通过“jstat”的输出还发现每次回收释放的内存非常有限，大多数对象都无法回收。这种现象很大程度上暗示着内存泄漏。使用 Java虚拟机的工具“jmap”来获得当前的一个内存映象。发现有很多（超过10000）个的session对象。这是不正常的一个现象。一般来说， session对应于一个用户的多次访问，当用户退出的时候，session就应该失效，对象应该被回收。当我们和这个系统的开发工程师了解有关 session的设置，发现当他们部署应用的时候，竟然将session的timeout时间设置为50分钟，并且没有提供logout的接口。这样的设置下，每个session的数据都会保存50分钟才会被回收。根据我们的建议，系统提供了logout的链接，并且告诉用户如果退出应用，应该点击这个 logout的链接；并且将session的timeout时间修改为5分钟。通过几天的测试，证明泄漏的问题得到解决。
(二)数据库连接池问题
某财务应用运行在JavaEE服务器上，后台连接Oracle数据库。并发用户数量超过100人左右的时候系统停止响应。通过操作系统层面的进程监控工具发现进程并没有被杀死或挂起，而CPU使用率几乎为零。那么是什么原因导致系统停止响应用户请求呢？我们利用Java虚拟机的工具（kill -3 pid）将当前的所有线程状态DUMP出来，发现JavaEE服务器的大部分处理线程都在等待数据库连接池的连接，而那些已经获得数据库连接的线程却处于阻塞状态。数据库管理员应要求检查了数据库的状态，发现所有的连接的session都处于死锁状态。显然，这是因为数据库端出现了死锁的操作，阻塞了那些有数据库操作的请求，占用了所有数据库连接池中的连接。后续的请求如果还要从连接池中获取连接，就会阻塞在连接池上。当解决数据库死锁的问题之后，性能问题迎刃而解。
(三)大对象缓存问题
电信应用运行在64位Java虚拟机上，系统运行得很不稳定，系统经常停止响应。使用进程工具查看，发现进程并没有被杀死或挂起。利用Java虚拟机的工具发现系统在长时间的进行内存回收，内存回收的时间长达15分钟，整个系统在内存回收的时候就像挂起一样。另外还观察到系统使用了12G的内存（因为是 64位虚拟机所以突破了4G内存的限制）。从开发人员那里了解到，这个应用为了提高性能，大量使用了对象缓存，但是事与愿违，在Java中使用过多的内存，虽然在正常运行的时候能够获得很好的性能，但是会大大增加内存回收的时间。特别是对象缓存，本系统使用了8G的缓存空间，共缓存了6000多万个对象，对这些对象的遍历导致了长时间的内存回收。根据我们的建议，将缓存空间减少到1G，并调整回收算法（使用增量回收的算法），使得系统由于内存回收而造成的最大停顿时间减少到4秒，基本满足用户的需求。
(四)外部命令问题
数字校园应用运行在4CPU的Solaris10服务器上，中间件为JavaEE服务器。系统在做大并发压力测试的时候，请求响应时间比较慢，通过操作系统的工具（mpstat）发现CPU使用率比较高。并且系统占用绝大多数的CPU资源而不是应用本身。这是个不正常的现象，通常情况下用户应用的CPU占用率应该占主要地位，才能说明系统是正常工作。通过Solaris 10的Dtrace脚本，我们查看当前情况下哪些系统调用花费了最多的CPU资源，竟然发现最花费CPU的系统调用是“fork”。众所周知， “fork”系统调用是用来产生新的进程，在Java虚拟机中只有线程的概念，绝不会有进程的产生。这是个非常异常的现象。通过本系统的开发人员，我们找到了答案：每个用户请求的处理都包含执行一个外部shell脚本，来获得系统的一些信息。这是通过Java的“Runtime.getRuntime ().exec”来完成的，但是这种方法在Java中非常消耗资源。Java虚拟机执行这个命令的方式是：首先克隆一个和当前虚拟机一样的进程，再用这个新的进程去执行外部命令，最后再退出这个进程。如果频繁执行这个操作，系统的消耗会很大，不仅在CPU，内存操作也很重。用户根据建议去掉这个shell 脚本执行的语句，系统立刻回复了正常。
基于J2EE的元数据管理平台，具有良好的跨平台特性；解决了多源异构数据的融合、遥感数据的存储、数据持久化和用户控制访问问题；在设计和实现过程中遵循J2EE的设计模式，具有良好的扩展性和维护性；功能模块具有低耦合的特点，极大地提高了代码的可复用性；可对元数据进行有效管理，实现信息的共享，广泛地应用在各个领域。在如何提高系统的安全性方面还有待于对其进行进一步的研究。
参考文献：
[1]杨浮群,邹利艳,徐丽.JavaEE开发环境下Sql Serve数据库优化[J].电脑知识与技术,2011,31.
[2]JavaEE应用系统设计与开发课程培训.2011,11.
[3]刘世贵,郭文龙,姜惠娟.基于Java EE架构的多层软件的测试研究与实现[J].电脑知识与技术,2010,17.
