1、大型J2EE项目中异常处理机制的设计绪论随着计算机信息化技术在国内的doc大型J2EE项目中异常处理机制的设计绪 论随着计算机信息化技术在国内的普及，许许多多企业应用也如雨后春笋般的随之诞生。Sun的J2EE平台自诞生以来就着力于解决企业应用的各种复杂性，例如他提出了全局事务的概念解决了分布式数据库间的事务同步，JCA （Java Connection Adaptor）连接器的概念解决了异构系统如何使用J2EE容器提供的特性等功能，JMS（Java Messaging Service）用来处理Java平台之间消息发布，EJB的概念专注于架构基于分布式系统企业应用等。这些“重型武器”着重于解决了
2、系统架构级别的应用复杂度的同时，也留给了我们一个空白，那就是如何去解决业务逻辑带来的系统复杂问题，例如信息安全，系统性能，异常处理等。有些问题我们可以通过应用模式来处理，比如说Martin. Fowler的“企业应用架构模式”一书，其中就归纳了很多关于企业应用设计方面的设计模式，他把企业应用会遇到的问题归纳成各种模式例如“对象-关系行为模式”，“数据源架构模式”，“Web 表现模式”等。这些模式的提出有益于构建基于松散耦合同时易于扩展的应用系统，但有些问题是和系统业务复杂程度有关的比如说企业应用的异常处理。业务逻辑比较简单的系统不需要对异常做专门的架构设计，但是对于大型J2EE企业应用而言，由
3、于其自身业务的复杂，所连带产生的异常消息量也是十分巨大的，如何处理这些大量的异常消息，如何收集业务操作中所发生的所有异常情况，如何使得每一笔业务操作都有特定的异常处理机制 ，可以想象随着应用系统被用户的逐渐接受，解决这些问题将会变得越来越迫切。传统的处理异常的方法，无非就是增加大量的try catch块来捕获异常，这样做的缺点在于会使得代码迅速膨胀同时难以后期维护，而且异常的消息很难被收集起来统一显示给客户，实际上企业异常的处理所涉及到的不单单是异常的捕获和收集，还包括异常消息的国际化，异常的回滚和异常的分类等等，业内在这方面给我们提供了很好的平台和很多现成的工具，例如Spring的AOP的（
4、Aspect Oriented Programming）框架，AOP 是Aspect Oriented Programming 的简称，又名面向切面编程。它是软件工程发展到一定高度的一种对事物的抽象，也是对OOP的强力补充。它的作用就是对类实现非侵入性的增强。如果说OOP是提供了一种纵向继承结构的编程方式的话，AOP就是提供了一种横向切面方式的编程方法。目前在J2EE领域正在被广泛使用，例如事务，日志，权限验证等，其中比较有名的基于AOP的实现框架有Spring的声明式事务管理，和Spring-Acegi 对权限的验证。除了Spring提供了AOP的实现外,IBM的AspectJ 提供了一套面
5、向切面的编程语法，其他的例如Jboss公司和Oracle公司都分别在他们的应用服务器中集成了AOP功能，Sun的EJB3也提供了对AOP的支持，可以说随着时间的发展，基于AOP的应用将会越来越多的受到重视和发展。由于AOP天生就有在不改变原来的代码的前提下对类提供增强的特征，完全符合企业应用中对异常处理的需要。AOP框架虽然提供了一个很好的面向切面编程接口，但是需要实现一套基于大型J2EE系统的异常处理框架，还需要对企业异常处理的机制有深入的研究和了解。企业应用系统的设计需要考虑很多架构方面的问题，而异常处理往往容易被人忽视，人们普遍的都愿意关注业务的主要流程，而实际上业务的主要流程只占代码总
6、量的1/3，而其他2/3的代码往往都是处理校验，处理异常和处理分支代码，如果能够有一套框架能够把大部分的异常处理的代码从业务逻辑中提取出来，将能够大大的减少代码的总量，从而提交给客户更加优秀更加效率的系统。IEC (Interface of Error Collector) 是作者基于自己对企业异常的理解，利用Spring 的AOP实现的用来处理大型J2EE项目中异常情况的框架，它同时提供了对外的接口用来收集异常，而异常的捕获则全部交给框架来处理，她能够捕获并收集用户在执行一笔业务的过程中所发生的异常消息，同时提供国际化的支持，而且程序员不需要对原生的业务代码产生很大的改动，大大降低了代码之间
7、的耦合。虽然一个企业应用需要考虑的东西很多，但是前期任何一个方面的忽视都会导致后期大量的成本来弥补，异常处理往往就是一块容易被忽视的领域。作者实现的这套IEC的框架，是希望能够利用实际工作项目的机会同时结合自己对这个领域的思考做出一些贡献，同时起到一个抛砖引玉的作用。研究背景和意义目前国内外的所有J2EE的程序主要基于SSH(Struts+Spring+Hibernate)的三层框架，但是分层带来解耦特性的同时，也带来了传统开发中所没有面临过的问题，比如说层与层之间异常的收集和处理。传统的软件开发方式让程序员大量地关注业务的主要流程而忽视业务的出错流程，但是在大型的软件中我们不但需要处理大量的
8、异常，同时每一种类型的异常对主业务流程的影响也是不一样的。如果没有一套完整的异常处理体系的支持，不久系统就会陷入“异常“混乱的境地。由于对于如何处理企业异常很少有理论来指导这块领域，使得大部分的项目都有自己的一套处理方法，比如有些项目选择将异常信息用资源文件控制，然后通过一个抽象异常的接口对资源文件进行读取，这样做的好处是只解决了国际化的问题，但是并没有从实际上解决对异常的分类和分级，还有一些项目选择将异常保存到数据库，同时增加级别字段对异常进行处理，这样做的好处是程序的异常确实有了更加细致的描述，但是如何收集异常以及怎么处理不同种类的异常情况，各个项目没有形成一套可以相互参考和借鉴的理论和设
9、计体系。事实上一个基于一个J2EE的项目中异常可以分成以下几类： 用户输入异常 程序业务逻辑异常 模型校验异常而每一种类型的异常所处的层次都各不相同，比如用户输入类型的异常就处在J2EE模型的最高层（action level）,业务逻辑异常通常放在service层,而model层的模型校验异常就负责处理具体的持久化类型的异常情况，针对每一种不同类型的异常，程序都应该提供不同的处理机制。在J2EE项目中有很多的开源可以提供我们帮助，比如Spring的AOP框架，它就充分允许我们对J2EE容器中的业务对象作管理和拦截，利用拦截器的技术，我们可以充分的分析和处理异常，所以从理论上来讲一套基于拦截器的
10、异常处理框架是可行的，其次我们还有很多第三方的专门针对用户输入异常处理的框架比如说Apache的common-validation 包等。所以目前不管是从业务的需要还是从技术的角度来讲，都具备了提供一套比较完整的异常处理框架的条件。分析一下现代大型J2EE项目中在程序异常处理所普遍遇到的异常处理方面的问题和难点。拟解决以下几方面问题：1. 业务逻辑复杂，异常情况众多这个主要发生在大型的项目中，由于系统自身的复杂性往往一笔业务会牵涉到数十种出错的逻辑，而且在这样的项目中客户大都参与到实际的需求分析中。客户会和需求分析人员一起归纳出某一笔操作中可能出现的异常，以及他们根据业务情况所提出的解决放案。
11、2. 客户对异常有较严格的要求，希望对不同的异常有不同的处理所有的异常都是有级别的，比如某些一场属于输入类型的异常，某些异常输入业务逻辑的异常，某些异常属于模型自身的异常(不变量异常)，程序需要处理大量异常的同时，对异常作归类。3. 客户希望能够收集一笔业务操作中所有的异常，然后统一解决在大型的项目中，一笔业务操作往往涉及到很多模块的协同操作，而在这个过程中往往会发生很多的异常，有一些异常我们需要提示用户，而有一些异常则需要回滚整个业务操作，如果我们能提供一套完成的异常处理框架，我们就能够对用户在一次操作中所发生的异常做收集和展现，从而为用户节约了操作时间。 论文研究主要内容 本文是基于目前作
12、者主要从事的实际项目，总结和归纳出一套适应大型J2EE项目的异常处理框架。在本文中作者拟从以下几方面来进行研究：1. 企业异常的定义和分类。主要定义了异常在企业应用中的类型，哪些是属于业务异常，哪些是非受控型的异常（例如网络故障）。同时分析了异常在企业应用的不同层级中处理的方式也是不同的。2. 企业异常处理的需求。总结了大型业务系统中，业务员往往需要从异常反馈消息中获得的提示以及如何将客户和软件分析人员一起有效地参与到企业异常消息的定义中。3. 异常框架如何处理异常情况。定义了一个专门处理异常的框架有哪些地方是需要重点关注的，以及他需要满足的功能。4. 通过AOP的框架捕获异常。提出了基于AO
13、P的思想可以非侵入性的捕获企业的异常，同时做到对业务代码的侵入性降到最低。5. 异常消息的国际化支持。提出了利用资源文件的方式来处理国际化支持，这个主要针对大型的需要国际化支持的业务系统。6. 异常收集机制的设计以及线程安全的需要。提出了一套线程安全异常收集接口，它可以收集企业应用中各个层次发生的异常。论文的组织结构本文一共分为五章第一章 简要概述了论文的内容以及章节安排第二章 主要介绍了基于J2EE的MVC三层模型以及他的相关概念。分析了业内一些异常处理的方式，同时定义了企业异常的概念和异常处理框架需要满足的功能。第三章 提出了异常处理框架的概念以及框架需要实现的功能，同时针对每一种需求提出
14、了作者的设计思路。第四章 以作者目前从事的项目为基础，介绍了IEC（Interface of Error Collector）异常处理框架的总体设计和一些核型功能的详细设计机制。第五章 总结了研究内容和成果，定义了下一步的工作重点异常处理及传统J2EE体系结构分析J2EE（Java 2 Platform, Enterprise Edition）是Sun提出的一套应用开发技术架构 ，它在简化了传统企业应用开发的同时，规范了开发、部署的环节，进而缩短了开发的成本，提高了组件的再用性。由于它具有高可伸缩性、灵活性和易维护的特点，从一开始就受到了BEA、IBM以及Netscape Applicatio
15、n Server等业内知名IT供应商的支持。它的优势主要可以体现在：标准的设立：J2EE平台为许多的企业应用领域所关注的问题提供了标准，比如数据库连接，面向消息的组件，通信协议及互操作等。开发的高效：由于J2EE规范充分划分了开发的职责，开发人员只需要关注自己领域内的逻辑，而无需考虑诸如状态管理，事务连接和分布式应用等非常繁琐的问题，通过将这些问题留给每个中间件的供应商来解决，使得开发的效率大大提高，产品也更加具有质量。支持异构环境：基于分布式开发的J2EE完全不依赖于所在计算机的环境，由于Java天生的具有的跨平台的能力，J2EE可以部署在每一台装有Java虚拟机的电脑,同时J2EE的标准也
16、允许客户与J2EE兼容的第三方组件，极大地增加了现有IT环境的利用率。可伸缩性：未来软件的趋势是软件平台自身要满足客户不断增长的需求。J2EE平台能提供极佳的系统可伸缩性。它可以被部署到任意一台台式机中，例如大型应用系统基于稳定性的考虑，往往选择Linux与Unix等操作系统，而J2EE可以适应任何一种操作系统。同时由于支持J2EE中间件的供应商很多，在大型分布式的应用环境中，它能给客户提供更广泛的负载平衡策略，满足由于业务需要带来的性能问题。高稳定性和可用性：J2EE具有高度的平台稳定性，同时结合一些稳定的操作系统例如Sun Solaris、IBM OS/390可以实现每年只需5分钟的停机时
17、间，为企业应用的连续性和稳定性提供了强有力的保障。J2EE层次模型Sun为了解决当时C/S (client/server)二层模型难于升级和维护的缺点，采用分布式的概念，提出了四层模型，将各个组件按照他们所在的层分布在不同的计算机上，它们分别是： 客户层组件：J2EE的客户层组件包括用户访问J2EE平台的接口，可以通过Web的方式也可以通过Swing等非Web的方式去处理。 Web层组件包括JSP（Java Server Pages）和Servlets。 业务逻辑组件业务逻辑组建，主要服务于特定领域的商业应用，它是由EJB（Enterprise Java bean）组成的 EIS层组件由于商业
18、应用的需要，J2EE平台可以和异构的平台通信，用来做数据交换或者是满足特定业务逻辑的需要。下图描述了四层模型的基本关系：从上图看到J2EE的设计目标就是基于分布式的，这种设计模式带来了可移植性优势的同时也带来了复杂性的大幅度提高，由于层与层之间的通信协议都是延续了J2SE的RMI服务模型（Remote Method Invocation）单单处理RemoteException的代码就有和业务代码产生高度的偶合，同时强制企业应用分布式也是不合理得，因为大部分业务逻辑组件并不打算被分布，同时分布式组件还容易产生各种问题，例如网络问题引发的系统异常，等,这些复杂性的引入实际是增加了系统的不稳定性。事
19、实上业内的J2EE开发很少采用这种模型，由于近几年轻量级容器（Spring）的大面积推广，使得在不损失传统架构优势的前提下，J2EE的开发模型已经更加趋向于向敏捷和易扩展转化。基于轻量级容器架构的J2EE模型 由于传统的架构有很多缺点，业内普遍采用以下的架构，作者称之为“基于轻量级容器的J2EE架构”MVC ArchitectureWeb BrowserSwing ClientJSP/ServletEIS系统DB1EIS层业务逻辑层Web 层客户 层轻量级容器Service LayerORM Layer这种基于这种架构的企业应用把业务逻辑层和Web层合并在一个JVM中，web层通过一个MVC的
20、框架和业务层的门面代理去访问业务逻辑层，两层合并的优势在于大大的简化了企业应用的开发，同时由于一些轻量级容器的成熟，比如Spring 和PicoContainer 等，业务逻辑的代理可以很方便的被web层调用到，而不需要依赖具体的实现，同时从性能角度讲，这种架构更加易于扩展和集群。企业异常的分布基于轻量级的架构是目前比较流行的一种J2EE架构，基于这种架构的企业应用异常也主要分布在客户层，web层，业务逻辑层以及EIS层。客户层的异常通常指客户端的校验逻辑异常，比如在提交一笔业务之前客户端需要满足的提交前校验，值空，大于0 小于0 等，一般情况下这种异常的处理都比较迅速而且不需要通过服务器，例
21、如很多企业应用都利用JavaScript去做客户端的校验，这样做的好处是用户无需等待服务端的响应来判断这次操作是否正确，缺点是很多客户端的校验是不安全的，虽然他能够减轻服务器的校验负荷，但是我们可以通过修改客户端的校验逻辑来强制信息提交到服务器，所以这个时候如果服务器没有相应的校验的话，这个校验判断就被忽略了，这是一种非常危险的操作，也不被提倡，特别是对于企业应用这样一个对安全和稳定信性要求很高的商业系统来说，任何绕过校验的方法都应该在一开始设计的时候被考虑和屏蔽掉。对于非Web的J2EE应用，绕过客户端异常的校验也是十分简单的，只需要反编译相应的源代码，然后编写自己相应的校验逻辑，然后替换原
22、来的校验就可以了，由于相同名字空间的类JVM只允许有一个存在，所以自己编写的校验逻辑很容易覆盖掉原来的校验逻辑，总而言之把关键的校验逻辑放在客户端是十分不安全的一种解决办法。Web层的异常实际上是客户层的异常在服务器的实现，这样做的好处是异常的处理更加安全，也可以支持复杂的表现层校验逻辑，由于是用JAVA编写的校验逻辑，所以校验逻辑更加容易被重用，而且目前很多的第三方的开源软件都支持web层的校验，比如说common-validation，struts的DynaValidatorForm。实际上有过J2EE开发经验的人都知道任何的异常都是数据流造成的，而从客户层到web层的数据结构是DTO（D
23、ata Transaction Object）数据传输层，Web层的校验主要是对数据传输层做校验。如图所示：从上图可以看到，客户层和Web层之间的交互需要通过一层DTO来包装，关于如何校验DTO，可以参考异常处理的第三方支持一节。业务层的异常包括很多，在JAVA的领域里面异常被分为受控异常以及非受控异常，所谓的受控异常是指和业务有相关性的异常，例如数据不存在，格式不正确或者数据不合法等，客户层可以根据从业务层返回的异常中得到明确的异常提示然后做合理的后续操作，这种类型的异常时受控异常，也是本文要重点关注的一种类型的异常。非受控异常时指在实际操作中由于各种非受控的外界因素导致的异常，例如网络故障
24、又比如在EJB的环境中，要求客户处理的RemoteException这中类型的异常，如果从后台抛出的话，客户是无法从中得到任何的有价值的信息的。所以就要求在web层有一个前段的控制器负责处理所有从也业务层返回的异常，前段控制器的作用除了负责展示异常的消息之外，还需要负责异常的页面控制跳转。业务层需要处理一次业务操作中的所有发生的异常，同时返回异常的类型，为了让前段的控制器能够有效的识别异常的类别和异常消息，针对大型的J2EE系统来说，往往就需要设计一个类型很庞大的异常类结构来满足复杂的业务需求。别且由于还混合了一些非受控的异常类型，使得从业务层到web层的异常返回情况变的十分的复杂和不确定。受
25、控异常从业务逻辑层的校验层中抛出，非受控异常则可以从任何的业务代码中抛出，前段控制器很难区分那种类型属于受控，哪种类型属于非受控的。这就需要有一种框架来专门包装这两种类型的异常，同时又不损失异常的语义。 EIS层包括异构企业信息系统也包括数据库。EIS层的异常主要是也是由受控异常和非受控异常组成的，比如业务层需要通过web服务去访问另一个系统的对象，从而执行一些业务操作，在这个过程中远程接口有可能声明抛出受控异常，也有可能由于底层的复杂性，远程接口直接抛出了RemoteException也是很有可能的。但是这里的异常的处理有个特殊的地方就是事务，如果通过JCA(J2EE Connector A
26、rchitecture)的连接方式的话，事务是可以传播到异构系统中的，但是这个也要特定于具体的连接器，如果通过Web服务方式的话，事务是没有办法传播的，如果通过JMS的方式的话，事务的传播只是局限于消息如列之前，消息进入消息中间件之后的事务是不受权全局事务控制的，这就给开发人员出了一个难题，就是如果在消息发送之后，程序出现了异常，怎么去处理后续的异常恢复。如下图简述了业务层和EIS层的异常交互。传统异常处理的机制 传统的异常处理都是基于“抛出”，“捕获”来实现的。抛出异常是在类签名的时候声明的，这种类型的异常是受控异常（checked），同时由于Java语言也支持类在没有签名的时候也能抛出异常
27、，这种异常叫非受控异常（uncheck）。例如业务系统中需要定义一个接口ParcelService用来保存Parcel对象。而在保存之前我们需要查看对象是否已经存在，这里的已经存在不单单是数据库记录的重复，而是含有一定的业务逻辑，比如说Parcel的所占用的pipeline是否已经被其他的parcel所使用，如果是的话接口就会抛出UnAvailablePipelineException，这个时候的异常就是受控异常，受控异常是业务用户可以弥补或者修复的异常。如下代码段：ParcelDao是ParcelService关联的一个数据库操作的代理类，在执行保存parcel的动作之前需要做一些业务逻辑的
28、校验，如果业务逻辑不满足校验条件的话就抛出异常，大部分的企业应用都是采用这样的逻辑。ParcelDao的save方法也会抛出异常，例如数据库连接过期，或者网络断开等，这种类型的异常就是非受控异常。这个例子展现了web层的前段控制器如果需要关联这些业务层的方法的话就必须去捕获这些异常，同时还必须区分哪个异常代表哪种类型的错误和哪些异常是受控的而哪些是非受控的。异常类型的划分 从业务的角度来看，所有客户无法恢复的异常都属于非受控异常。比如前面讲到的ParcelDao的save方法有可能抛出底层的通信协议类的异常，客户往往对此束手无策，所以传统的异常处理机制需要明确在一个应用系统什么类型的异常时客户
29、无法恢复而需要交给框架处理的。比较合理的一种划分如下：受控异常： 客户的业务逻辑异常 业务对象的校验异常 应用系统安全检查异常非受控异常： 远程方法调用异常 系统异常前段控制器的设计 前面介绍了，轻量级J2EE架构的核心是一个MVC框架和一个业务层的容器，如果业务层向web层又能抛出受控又能抛出非受控异常的话，web层是如何处理的？web层通常都有一个前段控制器，前段控制器的作用就是捕获异常，分析异常消息，页面派发。如果从业务层抛出的是受控异常的话，前台就会把这个受控异常泡状包装成消息的形式发给页面，这种流程可以参考 Struts的页面派发和异常处理流程。但是这里就引入了一个问题，如何区分受控
30、和非受控的异常？回答就是MVC框架无法区分，因为框架没办法确定哪些异常对客户有用的，哪些是没有用的，所以一个设计良好的异常体系就至关重要。有了异常体系，前段控制器可以只关注和其相关的异常类型，而把非受控的异常类交给更高层的控制器处理。这样前端控制器的体系结构应该是这样的：（参考Template 设计模式）一个Baseaction MVC前段控制器的基类，从基类派生的子类AbstractAction处理和业务无关的，但是特定于框架的一些工作例如非受控异常的处理，前面已经介绍过了，非受控异常的发生，客户往往无法恢复，必须联系系统的管理员，而这个AbstractAction就负责处理非受控的异常。而
31、特定于具体业务的具体前段控制器，可以处理业务异常，就好比前面介绍的UnAvailablePipelineException,由于这些都是在声明抛出的，所以前段控制区需要手动的写捕获的逻辑，就是Java里面最让人头疼的try+catch 处理块。那前面的ParcelService声明抛出的UnAvailablePipelineException为例，前段控制器必须有如下代码：code ：前段控制器异常捕获1tryParcelService.save(p);catch(UnAvailablePipelineException e)/执行错误分析和页面派发 从上面的代码段可以看出如果一个大型的企业应
32、用逻辑复杂的话，前段控制器的代码将会迅速的被大量的异常捕获代码所侵占掉，针对这种情况，可以通过合理的异常体系结构来解决。异常体系结构的设计 异常体系结构的设计的原则就是区分受控和非受控异常，然后包装成基本异常体系结构中的基类。前面讲到了，业务层可以向web层放回两种类型的异常，根据这个特点企业应用的异常体系结构可以设计成如下：受控异常：非受控异常： 程序如果有特定的业务异常比如UnAvailablePipelineException可以完全继承自BusinessCheckException。基于这样的异常结构前段控制器的捕获代码将被大大的减少，通常只需要一个try+catch块就可以完成。code ：前段控制器异常捕获2tryParcelService.save(p);catch(BaseAppException e)/执行错误分析和页面派发 程序只需要捕获一个BaseAppException就可以了，因为程序的异常体
