J2EE应用框架设计白皮书.doc

J2EE应用框架设计白皮书Ver 0.1上海华腾软件系统有限公司2005-101前言12J2EE平台架构概述22.1以WEB为中心的应用模式32.2多层应用模式42.3选择J2EE平台应用模式43J2EE应用框架设计63.1应用框架设计目标和总体设计原则63.2应用框架设计73.2.1纵向分层(Multi-layer)平台层基础层应用层业务层153.2.2应用层的水平分层(Multi-tier)交互层(表现层)业务逻辑层集成层与Tuxedo Service的集成204应用框架定制方案214.1简单WEB应用架构214.1.1应用需求214.1.2案例224.1.3架构224.2以业务处理为中心的应用架构234.2.1轻量级J2EE应用架构需求案例应用架构244.2.2基于EJB的应用架构2需求2案例银联差错系统2应用架构275实现产品选择295.1容器295.1.1Tomcat295.1.2BEA Weblogic305.1.3IBM Websphere315.1.4Spring325.2Web应用框架345.2.1Struts345.2.2JSF实现产品355.2.3Portal365.3持久化框架365.3.1Hibernate365.3.2iBatis385.3.3Entity Bean395.4第三方组件406开发工具406.1Eclipse wtp406.2Exadel416.3锐道Dorado427J2EE实际项目应用架构调研447.1上海付费通447.2银联后线子系统457.2.1后线子系统总体逻辑架构457.2.2后线子系统水平分层结构4表示层4业务处理层4服务集成层527.3浦发个贷53611 前言企业级应用的主流技术框架逐渐形成了以Microsoft倡导的.NET框架和以IBM、Sun等公司所领导的J2EE框架并存的局面。在国外，金融领域的前端应用(Front Office)已经在迅速地向这两种技术框架迁移。随着国内商业银行网上服务应用的发展，国内金融领域的应用技术框架也逐渐体现出这种趋势。在金融行业内，由于IBM、BEA、Oracle等传统软件提供商的支持，J2EE技术框架是具有压倒性优势的技术框架。公司早在2000年左右就已开始了Java技术的储备和Java应用领域的开发，先后实施了和讯、邮政一期和二期支付网关、花旗等银行的网上银行、银联后线、付费通等项目，目前正在建设IndoPay电子钱包及网上汇款系统、银联商务综合POS系统，通过这些项目的实施与建设，积累了一定的开发与系统集成经验，取得了一些值得关注的技术成果（如：方便数据库操作的EasyDB、基于XML配置的报表呈现、简化页面制作的WebTag、通用查询处理、统一异常处理等等），初步建立了一支Java应用开发队伍。基于上述需求，公司管理层经过周密的调查和深入的研究，启动了公司层面的“J2EE架构研发项目第一阶段”。J2EE架构研发项目第一阶段的目的，是集中公司J2EE具有丰富设计经验的资源，结合业界发展的和公司应用特点，定制出几种应用架构，能覆盖公司80%项目设计需求，提高公司在J2EE技术框架下的应用架构的规范程度，提高设计质量和设计可重性，缩短设计周期，降低系统架构设计风险。根据第一阶段的研发工作的成果，编写本应用框架设计白皮书。2 J2EE平台架构概述J2EE平台是一个标准化的平台，支撑J2EE应用的运行。J2EE平台的具体表现形式是一组API，规范和策略的组合。下图展示了完整的J2EE 1.4平台所包含的完整内容。在J2EE平台中，将组成平台的实体分为容器(Container)和构件(Component)两大类。容器为构件提供运行期间的支持服务：生命周期管理、配置和部署、安全机制等。构件是在容器之中运行的软件单元，除了J2SE标准的Java Bean以外，J2EE容器支持下列特有的J2EE构件：Applet、Application Client、EJB、Web Components(Servlet/JSP、Taglib、Interceptor)。J2EE平台是一个多层、分布式的平台，针对不同的应用类型，可以对上述平台进行裁减和扩充，以适应具体应用的需求。下面展示了几种典型的J2EE平台应用模式。2.1 以WEB为中心的应用模式在这种典型应用模式下，J2EE的EJB容器被裁减。相应地，实现应用功能的所有构件都在Web 容器中运行。优点： 这种应用模式在应用架构上较为简洁，容易掌握； 相对后面将要介绍的多层应用模式而言开发维护和测试都比较简单； 在同样的单机处理能力下能够提供更好的性能； 只需要Web container的支撑，不需要全功能的J2EE Application Server，降低应用系统造价。缺点： 牺牲了Application Server所提供的复杂的分布式基于异构EIS资源的交易管理； 业务逻辑构件提供的功能不支持基于RMI/IIOP的远程分布式调用，难以支持除Browser和Web Service Client以外的其他远程客户端。2.2 多层应用模式在这种典型应用场景下，以Web容器为宿主的Web构件仅仅负责应用的表现逻辑。以EJB容器为宿主的业务逻辑构件负责处理来自Web层的请求，并存取EIS资源。通过将业务逻辑和EIS资源存取从表示逻辑中分离出来，并以EJB构件的形式封装起来，业务逻辑和表示逻辑无论在物理层面还是逻辑层面都是分离的。这种应用模式需要完整的J2EE Application Server实现容器(如BEA Weblogic、IBM Websphere、JBoss+Tomcat等)的支撑，其优缺点与前面介绍的以WEB为中心的应用模式相反，在此不再赘述。2.3 选择J2EE平台应用模式建议根据具体的应用需求来选择J2EE平台应用模式。首先澄清几种对J2EE Application Server或者EJB Container的几种误解。下列需求都不是决定采用何种J2EE应用模式的决定因素： 采用EJB能够提高应用系统的可维护性和业务逻辑构件的可重用性就提高可维护性和可重用性而言，物理层面的分离并不会比逻辑层面的分离起到更多的作用。即使采用以WEB为中心的J2EE应用模式，虽然在物理上组成应用的所有功能构件都是在Web Container中运行，仍旧可以通过应用架构的设计将表示逻辑的构件、业务逻辑的构件以及EIS资源存取构件在逻辑层面上分层，获得与物理分层同样的可维护性和可重用性。 只有采用J2EE Application Server才能够获得系统性能的线性升级能力(scalability)和可靠性(reliability) 目前良好的Web Container实现(如Weblogic Express等高端产品)也能够提供健壮的容错切换(failover)机制和群集(clustering)机制，因此不需采用完整的Application Server实现也能保证应用系统的线性升级能力和可靠性。在确定选用何种J2EE应用模式时，下列需求是起决定性因素的： 需要支持分布式的或异构的数据库的复杂交易管理功能； 业务逻辑构件需要支持除Browser和Web Service以外的其他远程访问协议 (如RMI/IIOP)。如果应用系统的需求满足上述任一条限制条件，建议采用多层应用模式。否则两种应用模式都是可选项，建议采用以WEB为中心的应用模式。影响J2EE应用模式的非技术因素有：用户在Application Server投资上的预算，以及用户对技术或产品的使用偏好等。3 J2EE应用框架设计本章在已介绍的J2EE应用的技术基础J2EE平台架构基础上，结合公司所常见的应用需求，做出应用框架的设计建议。并分析几种典型的J2EE应用框架定制方案。3.1 应用框架设计目标和总体设计原则J2EE平台提供了企业级应用构建的标准化的基础平台和技术架构。在J2EE平台的基础上，有必要针对不同种类的应用系统做进一步的应用框架设计。良好的应用框架有助于： 降低开发难度 减少开发成本 提高软件开发效率 提高软件质量 快速响应市场的变化J2EE应用框架设计将遵循下列总体设计原则：l 简单性: 降低学习的难度曲线；l 可扩展性: 容易扩展框架的构件，且扩展的构件能够无缝地集成到框架中；l 可重用性: 封装领域知识和设计方案，通过重用解决需求问题和技术问题；l 模块化: 通过高内聚低偶合设计，限制变更扩散，并使得框架的组成部分可按需装配；l 可移植性: 对部署环境做较少的假设，能够部署到多种J2EE容器中；l Scalable: 支持通过硬件处理能力的提升线性提高应用服务的性能；l 成熟性: 基于业界和公司多年的技术经验积淀，大量采用经实际应用证明有效的架构模式和设计模式，以及成熟的第三方产品；l 高性能: 以服务响应时间和服务吞吐率两方面的指标衡量系统的性能。3.2 应用框架设计J2EE应用框架采用Multi-Layer，Multi-tier的设计架构。通过将构成应用的各个功能模块进行纵向和横向的分层、分片拆分，使得整个应用系统的体系架构更加清晰，各个功能模块之间的耦合度降低，内聚性提高，从而达到应用框架可裁剪、可扩充，能够灵活适应不同的应用构建需求，从而获得架构、设计以及代码层面的可重用性，为公司的J2EE应用开发提供一致的开发环境。3.2.1 纵向分层(Multi-layer)应用框架采用分层架构设计。下图展示了分层的应用架构以及各层所包含的组成模块。上图展示了各层相互之间的关系。上层模块对下层模块有调用和依赖关系，下层模块是上层模块的构建基础。 平台层平台层是整个应用系统的最底层。平台层为整个应用框架提供了存取宿主平台环境的通用服务。平台层构件提供了存取宿主平台环境服务的通用API，通过J2EE平台技术规范标准化后的接口，上层应用模块可以以面向接口、与实现无关的方式访问经平台层封装后的各种宿主环境服务。宿主平台环境所提供的服务包括但不仅限于：操作系统、数据库、应用服务器、交易中间件、消息中间件、邮件系统以及企业信息系统(EIS)。平台层的组件与特定的应用领域无关，对各种J2EE应用都是适用的。根据不同应用系统的宿主平台环境的区别，具体应用系统的平台层所包含的构件可以按照实际应用系统的需要进行裁剪和扩充。 基础层基础层构建在平台层的基础上，提供了组成应用框架的核心功能。基础层包含一系列提供共性服务的构件，这些构件与特定的应用领域无关，所提供的应用基础服务被应用架构上层的模块共享，并且具有通用性，能够在不同应用中被重用。 根据不同应用系统的需求，具体应用系统的基础层可以进行适当的裁剪。基础层包含下列构件。.1 Logging提供一个统一的面向最终用户、管理员和应用系统开发人员的应用系统运行期间的问题跟踪诊断和审计实现机制。Logging构件采用J2SE所提供的标准logging扩展接口，实现可以有多种产品支持。J2EE应用框架选用log4j作为logging构件的实现产品。Log4j具有下列特征：l 多层次的logging优先级定义l 细粒度的logging优先级控制l 通过静态配置和动态API改变logging的优先级l 多输出通道l 信息输出格式可配置.2 异常提供了应用框架中统一、一致的异常处理机制。异常分为checked和unchecked两类，分别在不同的情况下使用：unchecked异常仅在的发生无法由软件代码自动恢复正常运行的故障情况下使用； checked异常比较常用，当发生可由应用的代码处理的非正常情况下使用。与J2SE的Exception类相比，应用框架的异常类扩展了异常代码标识和表示异常发生时相关环境的参数，支持动态的参数化的异常信息生成。异常信息支持i18n。.3 IOC容器IOC容器的引入并非单纯为了取代标准化的J2EE容器，而是作为J2EE容器的补充：J2EE Web容器仅提供了对web构件(servlet)的支持。J2EE EJB容器仅提供了面向服务的大粒度的业务逻辑构件的管理。而对组成web构件或者EJB构件的面向功能实现的小粒度业务逻辑构件（基于POJO组件模型）的管理却是J2EE标准化容器的空白。IOC容器非常适合于对各种粒度的构件的管理，很好地填补了这方面的空白。IOC容器除了能够管理小粒度的POJO组件，也解除了组件对J2EE容器环境的依赖。由IOC容器管理起来的POJO组件不仅仅能够部署在Web Container中，也可以部署在EJB Container中，甚至脱离J2EE容器的管理，直接部署到普通的Java应用环境中，大大提高了组件的可重用性。IOC容器将工厂设计模式进行了抽象实现，适合细粒度构件的动态装配，从而使得面向接口的设计模式能够容易地实现。IOC容器也往往支持通过配置声明的方式加入AOP机制，提供企业级应用的通用服务(如Transaction管理等)。.4 配置参数管理配置参数管理构件将不确定数据持久化的需求抽象化，为上层应用模块提供持久化的配置参数存储管理机制。配置参数管理提供了统一的接口，用于存储和装载应用的配置数据。配置参数管理构件具有下列特征：l 强类型，基于key-value对机制；l 可扩展性，构件本身不对存储的参数做任何假定(但是需要考虑持久存储实现机制的物理限制)；l 支持文件、数据库、XML等存储实现机制，以及不同存储实现机制之间的复制；l 支持生效期机制；l 支持参数分组；l 支持子层次参数重定义；l 对于日期、字符串等类型支持i18n。 应用层应用层在整个应用框架中是一个功能非常丰富的层次，不同的应用通过应用层模块的定制而体现出该应用所特有的行为特征。应用层负责系统访问的流程控制、应用系统与外界的交互以及领域相关的各种业务功能的实现，因此代码量很大，复杂度也很高。因此有必要对应用层做进一步细化架构设计。对应用层的进一步分解设计见后续章节。通过对J2EE应用所常见的应用功能进行分析，能够将一些在大多数应用中重复出现的应用功能从应用中抽象出来，形成在特定领域范围内具有通用性的应用层构件。应用层构件可分为解决特定应用领域问题的框架(WEB应用框架、持久化框架)和实现特定应用功能的应用模块两大类。.1 WEB应用框架对于WEB应用，由于需要对用户的WEB交互流程、用户界面等进行管理，建议采用业界比较成熟的WEB框架实现产品，利用这些产品提供的MVC模式的WEB应用架构，能够大大降低应用开发的难度。比较成熟的标准或者产品有：l Struts：最早推出且被广泛采用的MVC WEB应用框架。得到了较多软件厂商产品的支持，但不是标准化的产品。成熟性好但技术陈旧。l Spring MVC：较新的MVC WEB应用框架，与spring IOC container集成度高，同样不是标准化的产品，但技术架构合理。l JSF：新一代的MVC WEB应用框架，由JCP标准化。主流J2EE平台提供商以及大量的JSF组件提供商都提供了支持，发展前进良好。基于可视化组件技术和事件驱动机制，技术架构合理。l Portlet规范：基于应用界面集成思路的WEB应用框架标准，由JCP制订，大多数Application Server厂商提供实现产品，也有若干优秀的open source产品实现。对于需要让最终用户或者系统运行期间动态定制用户界面，以及需要满足以松耦合的方式集成多个第三方应用系统的应用界面的需求时，采用这种技术比较合适。.2 持久化框架绝大多数J2EE应用都需要解决应用数据的持久化存储问题。应用数据的持久化存储一般都是通过平台层的数据库服务实现。目前主流的数据库服务提供厂商都采用关系型数据库模型。而J2EE应用的实现是基于面向对象技术的，因此存在所谓的对象关系失配问题。在这种情况下，采用优秀的持久化框架能够大大减少应用对象持久化到关系型数据库中所需做的大量开发工作，提高整个应用系统的性能和质量。比较成熟的持久化框架有：l Hibernate：提供完整的O/R Mapping机制，能够实现POJO的透明持久化，以及延迟加载、Caching等高级性能优化机制。开发效率高且可测试性好，易维护。l iBatis：与JDBC API一样基于SQL编程，但是封装了JDBC API的复杂性，简单且对熟悉SQL语言的开发人员而言容易理解。缺点是没有提供O/R Mapping机制，所有数据库操作均需要手工编写相应SQL的XML配置，开发工作量较高，应用可移植性相对较差。l Entity Bean：J2EE的标准持久化机制。提供了完全的关系模型封装，实现了数据库实现无关性、远程分布式处理和跨资源的交易管理机制。但是EJB技术依赖于EJB Container的支撑，开发效率较低，相对而言性能较差。Entity Bean规范本身仍旧处于不断发展的过程中，最近的发展趋势是通过轻量化设计以提高Entity Bean在开发、部署和执行期间的效率。最新的EJB 3.0规范在这些方面有所改进，但是尚不成熟，也没有很多产品支持。建议对于需要重用的应用层构件，以及需要在业务逻辑层包含大量应用领域相关的逻辑的情况下，采用Hibernate作为持久化框架实现集成层的功能。对于简单的WEB应用，不考虑其可移植性的情况下，可考虑采用iBatis作为持久化框架。不建议采用Entity Bean作为新的J2EE应用的持久化框架。.3 缓存框架缓存对于提高应用系统的性能(以每秒交易数、响应时间和吞吐率来衡量)，往往有明显的效果。另外，在应用水平分层的前层应用缓存则对后层的故障能起到一定的容错效果。并非所有的应用都适合采用缓存来提高性能，而是应根据应用需求来判断是否采用：l 对应用系统的性能需求有较高的要求；l 应用系统对业务数据的读操作所占系统资源消耗比重较大的情况下，缓存对系统性能提升有较明显的效果；l 业务需求能够容忍用户获取过期的数据（仅对于容错情况）。缓存的应用需要综合考虑：对于J2EE应用框架的应用层而言，可以在交互层、业务逻辑层和集成层分别应用缓存机制提高系统的综合性能，但是应避免整个应用系统中重复的缓存。建议采用成熟的第三方缓存框架产品，实现应用层各个水平分层的缓存处理。比较成熟的缓存框架产品有：OSCache。OSCache对采用JSP技术的交互层、Hibernate持久化框架都有良好的内置支持，其对任意POJO的缓存功能结合AOP技术的method interceptor机制，能够很好地实现非侵入式的业务逻辑层缓存。.4 通用应用构件模块J2EE应用框架在应用层也提供了部分开箱即用的应用功能模块，成为应用构件。这些应用构件几乎是每个J2EE应用中不可或缺的组成部分。通过预先实现的这些应用构件，能够大大提高基于应用框架的J2EE应用开发效率。应用构件所覆盖的J2EE应用水平分层，可能是从交互层一直到集成层的完整的应用功能，也可能只覆盖了应用水平分层的部分层面，需要经过框架的定制开发形成完整的应用功能。J2EE应用框架提供的通用应用功能模块有：l 安全管理l 报表l 工作流管理l Web应用个性化定制 业务层业务层通过对业务领域进行抽象建模所形成的逻辑层面。这个层面是完全与业务领域相关的层面。业务层将应用层的各个应用模块按照业务逻辑和业务规则进行封装，形成最终用户所需要的J2EE应用系统的应用服务，呈现给最终用户。业务层领域相关的应用服务的例子如：支付结算、客户管理、贷款风险控制等。3.2.2 应用层的水平分层(Multi-tier)水平分层(tier)通过将系统进行水平分切，形成的独立并且低耦合的功能模块。水平分层是一个逻辑概念，既可能影射到一台物理主机，也可能影射到多台物理主机。J2EE应用框架的应用层采用了水平分层的设计模式，可以分解为3个水平分层，交互层、业务逻辑层和集成层。下图展示了3个水平分层、各分层所包含的典型构件，以及水平分层与其周边子系统之间的关系。图中客户端不属于J2EE应用框架，而是与用户或者外部系统交互的工具。用户通过客户端发起J2EE应用层的请求，获取应答，完成用户交互。EIS不属于J2EE应用层，而是属于J2EE应用框架垂直分层的平台层。平台层提供了整个J2EE应用层(包含3个水平分层)的运行环境。3个水平分层都在J2EE平台的Server Container中部署。J2EE Server Container属于J2EE应用框架的平台层。其中，交互层必须部署在Web Container中，业务逻辑层和集成层根据J2EE平台应用模式的不同，可以选择与交互层部署在同一个Web Container中，也可以在EJB Container中部署。水平分层中各层之间遵循下列设计：l 后层为前层提供服务接口。各层之间采用面向接口的设计，以降低模块之间的耦合度。各层可以独立演进，变更实现方式。l 水平分层的各层实现自己层面所关注的功能，并将这些功能在层内封装，以提高各个层面功能的内聚性。l 各层在接口之间传递的数据必须进行抽象以去除本层特定实现的特征。例如，不允许将http的request参数传递给业务逻辑层。 交互层(表现层)交互层负责J2EE应用系统与外界客户端的交互。对于包含表现逻辑的应用，如WEB应用，交互层也往往被称为表现层。所有的表现逻辑，如用户View界面、外观、i18n资源、页面流程跳转等，在交互层被封装。交互层不实现任何业务逻辑。通过调用业务逻辑层提供的接口，交互层使用后台各层的服务获取动态信息，并根据不同的客户端类型采用相应的展示技术给客户端。常见的交互层展示技术有：l 针对Web Browser的HTML/XHTML/DHTMLl 针对WAP Browser的WMLl 针对Web Service Client的SOAP服务WEB表现逻辑往往较为复杂，涉及到页面流程管理、参数编解码，i18n资源管理等等，因此引入WEB应用框架来解决上述这些问题。WEB应用框架有多种不同的实现，各有独到的特点，但是基本上都以MVC设计模式为基础设计。MVC设计模式由三部分组成，模型（Model），视图（View），控制器（Controller）。模型是应用对象，没有用户界面。视图表示它在屏幕上的显示，代表流向用户的数据。控制器定义用户界面对用户输入的响应方式，负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映数据的变化。三者的关系如图所示：通常当系统发布后，View对象是由美工，页面设计人员或者系统管理员来负责管理的。Controller对象由应用开发人员开发实施，Model对象则由开发人员，领域专家和数据库管理员共同完成的。 业务逻辑层业务逻辑层负责实现业务相关的各种逻辑。业务逻辑层关注于业务功能的实现，并且将业务功能以业务服务接口的形式封装起来，提供给交互层使用。业务服务接口的定义需要考虑到适应不同交互形式的需要，例如：同样的业务服务接口既有可能通过WEB展示模块，以Web页面交互的形式提供给用户访问，也可能通过Web Service的封装，以Web Service的形式提供给第三方的应用系统访问。因此在业务逻辑层中应该将所有与展示相关的内容剥离出来，放到交互层。业务逻辑层也不需要考虑持久化相关的技术实现，这方面的功能通过调用集成层提供的DAO接口实现。处于性能上的考虑，业务服务接口一般是粗粒度的接口，封装了有一定复杂度的业务功能，一方面能够减少交互层和业务逻辑层之间的交互次数，另一方面也能够将服务的实现细节隐藏起来，减少服务的数量。业务逻辑层在传统的J2EE应用中是通过EJB Session Bean的形式封装起来。随着轻量级IoC容器技术的发展，以及Java技术本身的完善，以IoC容器管理的POJO(普通Java对象)已经完全能够胜任本地业务逻辑构件的封装。因此对于不需要提供远程访问的业务逻辑，可以直接采用POJO的形式封装。需要提供远程访问时，既可以将POJO进一步封装为Session Bean，也可以将POJO封装为一组Web Service。 集成层集成层完成和外部系统/资源的调用和访问服务。集成层对外部资源的访问进行了接口化的封装，并对外部资源的使用进行管理。这里所说的外部资源包括各种数据库（基于关系模型的RDBMS、基于层次模型的LDAP数据库等），其他企业级应用系统所提供的服务、以及邮件系统、消息系统等平台层提供服务。J2EE应用框架的集成层中所包含的构件有：l 各种持久化框架：在应用层中已有介绍；l DAO：一组预定义的持久化接口，其目的是封装持久化框架的特有信息，提供对象持久化的独立、透明的访问接口；l 资源池管理构件：对资源连接的pool管理，提高资源连接的利用效率，限制资源连接的并发数量等。l 对LDAP、Mail Server、Messaging Server的访问相对而言比较简单，将直接采用J2EE标准化的API，不再对其进行进一步的封装。l Tuxedo Service集成构件：公司所涉及到的J2EE应用系统，有相当一部分需要与已有的或者新开发的基于Tuxedo交易中间件的Service进行交互。下一节将专门对此类构件进行描述。 与Tuxedo Service的集成BEA公司提供了两种产品对J2EE和Tuxedo Service提供互操作支持：l WTCWTC是weblogic的一部分，也只能在weblogic application server中使用。它支持双向的调用方式，即weblogic中的ejb调用tuxedo service，以及tuxedo service调用weblogic ejb service。l JoltJolt属于BEA tuxedo产品中的一部分。Jolt是BEA官方的java tuxedo client，能够支持远程调用tuxedo server所需要的所有功能，包括调用的api以及打包、拆包等。这个工具库不需要weblogic的支持，各种java环境都可以使用，对环境的依赖性较少。无论是WTC还是Jolt，两种解决方案都是全功能的，即：支持交易传播和安全性传播。选择的主要因素是看是否需要从tuxedo service调用j2EE service：l 如果仅仅是java做tuxedo的客户端发起对Tuxedo service的调用，建议使用jolt。l 如果需要从tuxedo service发起对J2EE service的调用，且J2EE service能够部署在weblogic产品中，则可以采用WTC。l 如果需要从tuxedo service发起对J2EE service的调用，且J2EE service不能通过部署在weblogic产品中，或者J2EE service不是采用ejb形式封装，则建议采用SOA架构解决互操作问题。4 应用框架定制方案没有一个单一的应用架构能够符合所有应用系统的需求。通过模块化设计，使得J2EE应用框架是一个可以按需求驱动的可定制的框架。在后续章节，我们通过将应用需求分类，针对不同的应用类型对前一节设计的应用框架进行裁剪和扩充，满足相应的应用架构需求。应用框架的垂直分层无论在那种应用架构中基本上是不变的，不同的应用架构实际上是在应用层的水平分层中根据应用的需求进行裁减和部署环境的调整，从而形成不同的应用架构。首先我们将J2EE应用架构分为两大类：简单WEB应用架构和以业务为中心的应用架构。这两种架构在应用层的水平分层上有本质的区别。4.1 简单WEB应用架构4.1.1 应用需求“简单的WEB应用架构”适应于需求满足如下特点的应用系统：l 面向B/S，多用户，提供用户访问应用系统的浏览器界面l 业务逻辑简单，不需要做维护和重用的考虑l 多层结构的分布式应用系统（运行在公司的内部网络或者广域网上）l 应用系统要求可以快速构建，方便部署，易于管理和维护l 集成企业信息系统，将传统的终端/CS模式转变为B/S模式l 较低的开发成本和运行维护成本通过对应用架构进行简化，我们可以获得较高的开发效率，较低的部署环境配置要求，但是牺牲的应用系统功能的可维护性、可扩展性和可重用性。4.1.2 案例东京三菱上海分行人民币业务系统上海银行信用卡管理系统上海市付费通系统某些系统的B/S架构控制台4.1.3 架构简单WEB应用架构所采用的J2EE平台应用模式为以WEB为中心的应用模式，见2.1。简单WEB应用架构的纵向分层结构仍旧是J2EE应用框架的分层架构，分为平台层、基础层、应用层和业务层。所进行的裁减主要有：l 在平台层，只采用J2EE Web Container作为应用构件的运行环境，不需要Application Server的EJB Container支持。l 在基础层，一般不需要采用IoC容器，而是直接利用Web Container对组成应用的Web构件进行管理。简单WEB应用架构的水平分层架构如下图。简单WEB应用架构通过对应用水平分层中的业务逻辑层进行了裁减，直接从展现层调用集成层所提供的DAO接口或者外部系统的访问接口，完成数据的持久化和EIS系统功能的调用驱动。这种架构对于基本没有业务逻辑的简单WEB应用，如控制台等比较适合。而对于只有少量业务逻辑的应用，由于将业务逻辑直接写再展示层（如基于Struts WEB框架的应用，将业务逻辑直接写在Action Bean中），虽然提高了开发效率，但是牺牲了系统的可维护性和业务逻辑的可重用性。4.2 以业务处理为中心的应用架构当业务处理的逻辑较为复杂，且有可重用性的需求时，不应采用简单的WEB应用架构，而需考虑以业务处理为中心的多层架构。以业务处理为中心的应用架构可以分为轻量级的架构和基于EJB的架构。这两种架构的主要区别在于是否采用EJB Container作为水平分层中的业务逻辑层和集成层的J2EE容器。关于是否采用EJB Container的讨论，在2.3选择J2EE平台应用模式中已做详细讨论，在此不再赘述。4.2.1 轻量级J2EE应用架构 需求当用户在Application Server投资上的预算较低，并且不涉及分布式的或异构的数据库要求，也没有要求支持RMI/IIOP的远程服务访问接口时，可考虑使用此种应用架构。 案例交通银行个贷系统浦东发展银行的个贷系统 应用架构轻量级J2EE应用架构所采用的J2EE平台应用模式为以WEB为中心的应用模式，见2.1。轻量级J2EE应用架构的纵向分层结构仍旧是J2EE应用框架的分层架构，分为平台层、基础层、应用层和业务层。所进行的裁减主要有：l 在平台层，只采用J2EE Web Container作为应用构件的运行环境，不需要Application Server的EJB Container支持。l 在基础层，需要采用IoC容器如Spring对基于POJO的业务逻辑构件进行管理。轻量级J2EE应用架构的水平分层架构如下图。与简单WEB应用架构不同，轻量级J2EE应用架构的业务逻辑实现核心在业务逻辑层，交互层仅仅负责与客户端交互的呈现逻辑和交互流程管理。业务逻辑层中的业务逻辑被封装为基于POJO的服务接口形式，提供给交互层使用。服务接口的查找，业务逻辑对象的生命周期管理和装配等等工作都由基础层的IoC容器来完成。由于IoC容器所特有的基于POJO的组件模型，使得IoC容器不仅仅适合管理面向业务服务的粗粒度的业务逻辑构件，而且也能够管理面向功能实现的细粒度的业务逻辑构件。这使得我们在设计业务逻辑构件时，能够实践各种最佳的面向对象设计模式，提高构件的灵活性和可重用性。4.2.2 基于EJB的应用架构 需求当用户在Application Server投资上有充足的预算，并且需要对分布式的或异构的数据库支持，或者需要支持RMI/IIOP的远程服务访问接口时(例如需要将交互层构件和业务逻辑层构件分别部署到不同的服务器上以分担负载)，需要采用此种应用架构。 案例银联差错系统中国银联不满意现有的差错系统，希望在将差错子系统归纳入已有的银联新系统体系中，但是要求用户界面是独立的开发。并且将系统部署在银联新系统后线主机上。经分析，银联新系统中数据管理模块，日志模块，异常处理模块，cache模块，WTC通讯模块，以及一些现有参数表的entity bean可以被被继续使用，而用户管理模块需要进行一定的扩展可以被继续使用。由于原系统采用j2ee架构设计，我们很方便的实现了系统的共用模块。我们简单的将原系统的部署的包拆分成专有与公用的两块就简单的避免的大量的重复开发工作。拆分以后的情况如图所示。 应用架构基于EJB的J2EE应用架构所采用的J2EE平台应用模式为多层应用模式，见2.2。基于EJB的J2EE应用架构的纵向分层结构仍旧是J2EE应用框架的分层架构，分为平台层、基础层、应用层和业务层。针对这种应用架构，对J2EE应用框架的组成构件进行了下列特化：l 在平台层，需要采用J2EE Web Container对交互层的应用构件进行管理，并且需要EJB Container对业务逻辑层和集成层的应用构件进行管理。换言之，需要全功能的Application Server的支持。l 在基础层，可以且建议采用IoC容器如Spring对基于POJO的细粒度业务逻辑构件进行管理。基于EJB的J2EE应用架构的水平分层架构如下图。基于EJB的J2EE应用架构与轻量级J2EE应用架构的水平分层架构类似，所不同的是业务逻辑层与集成层部署在EJB Container中。服务接口采用EJB的封装形式，一般是封装为Stateless Session Bean。由于EJB开发测试的工作量较大，且运行期间具有较大的开销，EJB并不适合用于构造面向功能实现的细粒度的业务逻辑构件。因此目前主流EJB应用技术专家所公认的EJB开发最佳实践是采用Faade模式，将粗粒度的业务服务封装为Stateless Session Bean，其实现则采用基于POJO的细粒度构件按照合适的面向对象设计模式构造完成。这种设计模式既兼顾了面向对象设计所带来的系统的灵活性和可重用性，也能够充分利用起EJB Container所能够带来的特有服务特性。基于上述考虑，在基于EJB的J2EE应用架构中， IoC容器也有其用武之地，实现对面向功能实现的细粒度的业务逻辑构件的查找、装配和生命周期管理。换个角度来看，由IoC容器管理的基于POJO组件模型的业务逻辑构件具有很好的可重用性，能够通过EJB Faade的封装部署到EJB Container环境中。5 实现产品选择J2EE平台只定义了J2EE技术架构下的API、规范和策略，在实施J2EE应用项目时，必需选择相应的实现产品以支撑J2EE应用的开发和运行维护。本章后续内容将对若干主流的J2EE平台的实现产品，以及组成J2EE应用框架的各种构件的相应实现产品做简要介绍和建议。5.1 容器5.1.1 Tomcat著名开源组织Apache组织Jakarta项目的一个子项目，最著名也是使用最为广泛的开源Web Container，Servlet/JSP规范的参考实现，且具有较好的兼容性。Servlet/JSP SpecTomcat Version2.4/2.05.52.3//1.13.3既可作为独立的Servlet容器，内置有web服务器的一部分(主要是用于开发与调试)；又可作为对现有web服务器的插件和Java容器的实现(当前支持Apache，IIS和Netscape服务器)。5.1.2 BEA WeblogicBEA Weblogic Platform支持标准的J2EE规范，提供了标准化的Web Container和EJB Container，以及J2EE的各种标准企业级应用基础服务的实现。BEA WebLogic Platform采用统一、简化、可扩展的平台，以端到端的业务流程形式，来构建、扩展、集成、部署和管理各种应用。BEA WebLogic Platform 使 IT 专注于业务目标，而不是基础结构的集成，不但缩短了项目周期，而且降低了复杂性。借助 BEA，IT 技术与业务需求正越来越协调一致，进一步提高了效率，提高了响应性和适应能力。 BEA WebLogic Platform 提供了单一的解决方案，用于开发、集成、管理各种企业应用和业务流程，因而它使IT技术能以单一的解决方案培训适用于所有应用，在跨不同项目部署资源时具有更大的灵活性。 BEA WebLogic Platform 还借助于提交跨平台可重复使用的控件架构，促进 IT 资产的重复使用，加快价值的实现速度，因此可以跨多个项目找出和重复使用技术和业务方面的最佳方案。 BEA WebLogic Platform 借助高效的集成化开发环境（IDE），允许所有开发人员协作开发各种应用，不仅简化了开发，而且加快了提交速度。 BEA WebLogic Platform 运行时框架，隐藏了底层基础结构的复杂性，既简化开发，提高工作效率，又能重复使用各种技巧和软件。这种框架的性能因采用公用开发模型而得到增强，它全方位地简化和整合了应用的构建、扩展和集成，大大提高了所有开发人员的工作效率。BEA WebLogic Platform 降低了支持、管理和维护成本，因为它为定制应用、集成、门户、Web 服务项目提供了统一、简化和可扩展的解决方案。 BEA WebLogic Platform 预先集成在公用技术基础之上，采用公用管理和控制接口，一切功能和支持都以公共源代码库和发布周期为基准。 BEA WebLogic Platform 是一种统一的应用基础结构解决方案，它使用户能够轻松集成和利用现有技术，实现投资保值。 因为基于各种开放式标准，所以 BEA 可扩展平台能确保互操作性、灵活性和选择性，可以循序渐进地全部或部分采用 BEA WebLogic Platform, 整合点解决方案和现有基础结构标准，可以通过独立软件供应商的应用和解决方案进行扩展。BeaWebLogic的优势主要两点，优秀的管理功能，强大的开发工具，毫无疑问，WebLogic的WorkShop能大大提高Weblogic的开发速度，pageflow技术虽然源于struts，明显优于struts。WebLogic本身提供了大量的优秀tag，类库，灵活的使用他们可以大大提高性能。但是在应用Weblogic所提供的这些特有的J2EE扩展机制的同时，也带来了锁定效应，使得开发的应用难以在不同的应用服务器环境中移植部署。5.1.3 IBM WebsphereIBM Websphere支持标准的J2EE规范，提供了标准化的Web Container和EJB Container，以及J2EE的各种标准企业级应用基础服务的实现。WebSphere软件平台能够帮助客户在Web上创建自己的业务或将自己的业务扩展到Web上，为客户提供了一个可靠、可扩展、跨平台的解决方案。作为IBM电子商务应用框架的一个关键组成部分，WebSphere软件平台为客户提供了一个使其能够充分利用Internet的集成解决方案。WebSphere软件平台提供了一整套全面的集成电子商务软件解决方案。作为一种基于行业标准的平台，它拥有足够的灵活性，能够适应市场的波动和商业目标的变化。它能够创建、部署、管理、扩展出强大、可移植、与众不同的电子商务应用，所有这些内容在必要时都可以与现有的传统应用实现集成。WebSphere Application Server提供基本的电子商务功能，可以进行事务处理并将后端的商业数据和应用扩展到Web上去。WebSphere Application Server标准版通过使用Java技术servlet、JavaServer页面技术和XML，可以帮助Web站点的创建者快速地对静态的Web站点进行转换，使其成为至关重要的动态web内容的来源。WebSphere Application Server高级版是一种高性能的企业JavaBean构件服务器，使用这一软件，开发人员可以实现能够对商业逻辑进行合并的EJB组件。WebSphere Application Server企业版使公司客户能够创建大交易量、大容量的电子商务应用。WSAS EE集成了EJB和CORBA技术。5.1.4 Spring经过多年的发展，IoC依赖注入模式被公认为容器对组件管理模式的优选设计模式。Spring即是这种IoC容器中较好的实现产品。在J2EE应用框架中，选择Spring作为框架中的IOC容器。Spring的核心是IOC容器，具有下列特征：l 非侵入性，对被管理的对象没有强制性的接口或者基类的要求，可移植性好；l 管理各种Java对象，支持POJO