J2EE编程架构介绍分析.doc

''当前流行的当前流行的 J2EEJ2EE WEBWEB 应用架构分析应用架构分析1. 架构概述J2EE 体系包括 java server pages(JSP) ,java SERVLET, enterprise bean，WEB service 等技术。这些技术的出现给电子商务时代的 WEB 应用程序的开发提供了一个非常有竞争力的选择。怎样把这些技术组合起来形成一个适应项目需要的稳定架构是项目开发过程中一个非常重要的步骤。完成这个步骤可以形成一个主要里程碑基线。形成这个基线有很多好处：1.各种因数初步确定为了形成架构基线，架构设计师要对平台（体系）中的技术进行筛选，各种利弊的权衡。往往架构设计师在这个过程中要阅读大量的技术资料，听取项目组成员的建议，考虑领域专家的需求，考虑赞助商成本（包括开发成本和运行维护成本）限额。一旦架构设计经过评审，这些因数初步地就有了在整个项目过程中的对项目起多大作用的定位。 2.定向技术培训一旦架构师设计的架构得到了批准形成了基线，项目开发和运行所采用的技术基本确定下来了。众多的项目经理都会对预备项目组成员的技术功底感到担心；他们需要培训部门提供培训，但就架构师面对的技术海洋，项目经理根本就提不出明确的技术培训需求。怎不能够对体系中所有技术都进行培训吧！有了架构里程碑基线，项目经理能确定这个项目开发会采用什么技术，这是提出培训需求应该是最精确的。不过在实际项目开发中，技术培训可以在基线确定之前与架构设计并发进行。 3.角色分工有了一个好的架构蓝图，我们就能准确划分工作。如网页设计，JSP 标签处理类设计，SERVLET 设计，session bean 设计，还有各种实现。这些任务在架构蓝图上都可以清晰地标出位置，使得项目组成员能很好地定位自己的任务。一个好的架构蓝图同时也能规范化任务，能很好地把任务划分为几类，在同一类中的任务的工作量和性质相同或相似。这样工作量估计起来有一个非常好的基础。 4.运行维护前面说过各个任务在架构图上都有比较好的定位。任何人能借助它很快地熟悉整个项目的运行情况，错误出现时能比较快速地定位错误点。另外，有了清晰的架构图，项目版本管理也有很好的版本树躯干。 5.扩展性架构犹如一颗参天大树的躯干，只要躯干根系牢，树干粗，长一些旁支，加一些树叶轻而易举无疑。同样，有一个稳定的经得起考验的架构，增加一两个业务组件是非常快速和容易的。 大家都知道这些好处，一心想形成一个这样的 J2EE 应用程序架构（就像在 windows 平台中的 MFC）。在这个路程中经历了两个大的阶段：1.1. 模型 1模型 1 其实不是一个什么稳定架构，甚至谈不上形成了架构。模型 1 的基础是 JSP 文件。它从 HTTP 的请求中提取参数，调用相应的业务逻辑，处理 HTTP 会话，最后生成 HTTP 文档。一系列这样的 JSP 文件形成一个完整的模型 1 应用，当然可能会有其他辅助类或文件。早期的 ASP 和 PHP 技术就属于这个情况。''总的看来，这个模型的好处是简单，但是它把业务逻辑和表现混在一块，对大应用来说，这个缺点是令人容忍不了的。1.2. 模型 2在经过一番实践，并广泛借鉴和总结经验教训之后，J2EE 应用程序终于迎来了 MVC（模型-视图-控制）模式。MVC 模式并不是 J2EE 行业人士标新立异的，所以前面我谈到广发借鉴。MVC 的核心就是做到三层甚至多层的松散耦合。这对基于组件的，所覆盖的技术不断膨胀的 J2EE 体系来说真是福音和救星。它在浏览器（本文对客户代理都称浏览器）和 JSP 或 SERVLET 之间插入一个控制组件。这个控制组件集中了处理浏览器发过来的 HTTP 请求的分发逻辑，也就是说，它会根据 HTTP 请求的 URL,输入参数，和目前应用的内部状态，把请求分发给相应的 WEB 层的 JSP 或 SERVLET。另外它也负责选择下一个视图（在J2EE 中，JSP,SERVLET 会生成回给浏览器的 html 从而形成视图）。集中的控制组件也有利于安全验证，日志纪录，有时也封装请求数据给下面的 WEB tier 层。这一套逻辑的实现形成了一个像 MFC 的应用框架，位置如图：1.3. 多层应用下图为 J2EE 体系中典型的多层应用模型。Client tier 客户层一般为浏览器或其他应用。客户层普遍地支持 HTTP 协议，也称客户代理。 WEB tier WEB 应用层在 J2EE 中，这一层由 WEB 容器运行，它包括 JSP, SERVLET 等 WEB 部件。 EJB tier 企业组件层企业组件层由 EJB 容器运行，支持 EJB, JMS, JTA 等服务和技术。 EIS tier 企业信息系统层企业信息系统包含企业内传统信息系统如财务，CRM 等，特点是有数据库系统的支持。 ''应用框架目前主要集中在 WEB 层，旨在规范这一层软件的开发。其实企业组件层也可以实现这个模型，但目前主要以设计模式的形式存在。而且有些框架可以扩充，有了企业组件层组件的参与，框架会显得更紧凑，更自然，效率会更高。2. 候选方案目前，实现模型 2 的框架也在不断的涌现，下面列出比较有名的框架。2.1. Apache StrutsStruts 是一个免费的开源的 WEB 层的应用框架，apache 软件基金致力于 struts 的开发。Struts 具是高可配置的性，和有一个不断增长的特性列表。一个前端控制组件，一系列动作类，动作映射，处理 XML 的实用工具类，服务器端 java bean 的自动填充，支持验证的 WEB 表单，国际化支持，生成 HTML，实现表现逻辑和模版组成了 struts 的灵魂。2.1.1.2.1.1. StrutsStruts 和和 MVCMVC模型 2 的目的和 MVC 的目的是一样的，所以模型 2 基本可以和 MVC 等同起来。下图体现了 Struts 的运作机理：''2.1.1.1. 控制如图所示，它的主要部件是一个通用的控制组件。这个控制组件提供了处理所有发送到 Struts 的 HTTP请求的入口点。它截取和分发这些请求到相应的动作类（这些动作类都是 Action 类的子类）。另外控制组件也负责用相应的请求参数填充 From bean,并传给动作类。动作类实现核心商业逻辑，它可以通过访问 java bean 或调用 EJB。最后动作类把控制权传给后续的 JSP 文件，后者生成视图。所有这些控制逻辑利用一个叫 struts-config.xml 文件来配置。2.1.1.2. 模型模型以一个或几个 java bean 的形式存在。这些 bean 分为三种：Form beans(表单 Beans)它保存了 HTTP post 请求传来的数据，在 Struts 里，所有的 Form beans 都是 ActionFrom 类的子类。 业务逻辑 beans专门用来处理业务逻辑。 系统状态 beans 它保存了跨越多个 HTTP 请求的单个客户的会话信息，还有系统状态。 2.1.1.3. 视图''控制组件续传 HTTP 请求给实现了视图的 JSP 文件。JSP 能访问 beans 并生成结果文档反馈到客户。Struts 提供 JSP 标签库： Html，Bean，Logic，Template 等来达到这个目的，并有利于分开表现逻辑和程序逻辑。2.1.2.2.1.2. StrutsStruts 的细节分析的细节分析2.1.2.1. 视图-控制-模型用户发出一个*.do 的 HTTP 请求，控制组件接收到这个请求后，查找针对这个请求的动作映射，再检查是否曾创建过相应的动作对象（action 实例），如果没有则调用 actionmapping 生成一个动作对象，控制组件会保存这个动作对象供以后使用。接着调用 actionmapping 的方法得到 actionForm 对象。之后把actionForm 作为参数传给动作对象的 perform 方法，这个方法结束之后会返回给控制组件一个 actionforward 对象。控制组件接着从这个对象中获取下一个视图的路径和重定向属性。如果为重定向则调用 HTTPSERVLETREPONSE 的方法来显示下一个视图，否则相继调用 requestdispatcher, SERVLETcontext 的方法续传 HTTP 请求到下一个视图。当动作对象运行 perform 方法时，可能出现错误信息。动作对象可以保存这些错误信息到一个 error 对象中，接着调用自身的 saveerrors 方法把这个错误保存到 request 对象的属性中。接着动作对象调用actionmapping 对象的 getInput 方法从动作映射中获取 input 参数，也就是产生输入的视图，并以这个input 为参数生成一个 actionforward 对象返回。这个 input 参数的 JSP 中一般有 HTTP:errors 定制标签读取这些错误信息并显示在页面上。下面是一个 logon.JSP 的代码实例：''2.1.2.2. 模型到视图模型到视图指视图在显示之前装载系统数据到视图的过程。系统数据一般为模型内 java bean 的信息。示意图表现了由控制组件 forward 过来的有 html:form 定制标签的 JSP 的处理逻辑。''html:form 定制标签处理对象从 application scope（通过查询 SERVLETCONTEXT 对象的属性来实现）获取先前由控制组件 actionSERVLET 放在那里的动作映射等对象，由 html:form 的 action 属性查得actionform 名字、类型和范围等信息，在相应的范围内查找 actionform，如果有则利用它的信息填充html form 表单实际填充动作在嵌套的 html:text 等定制标签的处理对象中。否则在相应范围内创建一个 actionform 对象。2.1.3.2.1.3. 优缺点优缺点优点：一些开发商开始采用并推广这个框架 作为开源项目，有很多先进的实现思想 对大型的应用支持的较好 有集中的网页导航定义 缺点：不是业届标准 对开发工具的支持不够 复杂的 taglib，需要比较长的时间来掌握 html form 和 actionform 的搭配比较封闭，但这也是它的精华所在。 修改建议把 actionform 属性的设置器和访问器修改成读取或生成 xml 文档的方法，然后 html form 和 actionform之间用 xml 文档进行数据交换，使之松散耦合，适应数据结构易变化的应用。''2.2. JATOJATO 应用程序框架是 iPlanet 应用程序框架的旧名。它是一个成熟的、强大的，基于 J2EE 标准的面向于开发 WEB 应用程序的应用框架。结合了显示字段、应用程序事件、组件层次和以页面为中心的开发方法、以及 MVC 和服务到工作者 service-to-workers 的设计模式等概念。JATO 可适用于中、大、超大规模的WEB 应用。但是它也不是一个企业层的应用框架，也就是说它不会直接提供创建 EJB, WEB services 等企业层组件的方法，但用它可以构造出访问企业层组件的客户应用。这个框架功能主要有三部分组成：''iPlanet 应用框架核心； iPlanet 应用框架组件； iPlanet 应用框架扩展。 应用框架核心定义了基本接口、对象协议、简单组件，以及 iPlanet 应用框架程序的最小核心。包括视图简单组件、模型简单组件、请求分发组件和可重用命令对象。iPlanet 应用框架组件利用框架核心定义的基本接口、协议和组件向开发者提供高层的重用组件，这些组件既有与特定视觉效果无关的水平组件，同时也有适应特定实用环境、提高可用性而特意提供的垂直型组件。框架扩展实现了用框架相容的方法访问非 J2EE 环境的方法。通常情况下，扩展被框架应用程序用来无缝访问 J2EE 容器特定功能。JATO 平台栈图很清楚地表达了这个情况。JATO 最大的威力在：对于快速开发用户，你能利用框架组件和扩展提高生产率，对于要求更大灵活性的用户，你能实现框架核心提供的接口来保持应用的框架兼容性。''此图表示实现一个 JATO 应用程序，可以简单地实现控制组件 module1Servlet，视图组件ListCustomersViewBean 和模型组件 CustomersModuleImpl，以及一个给客户代理显示界面的ListCustomers.jsp 文件。并清楚地表明这些组件与 JATO 框架组件的继承关系。''JATO 标签库提供了 VIEW 对象与 JSP 文件的接口。库中标签处理程序负责实现 VIEW 对象和 JSP 产生地客户端文档的信息同步和交换。这个图清楚地表达了这种对应关系2.2.1.2.2.1. MVCMVC 分析分析''前端控制组件接收用户发来的任何请求，这个可在 WEB.xml 中指定请求分发组件负责视图管理和导航，和前端控制组件封装在 ApplicationSERVLETBase 一起实现。应用程序开发者需要为每一个子系统（人力资源，财务，CRM 等）实现一个此类的继承。请求分发组件分发请求给工作者，工作者实现了 command 接口。应用开发者可以实现这个接口。JATO 提供了一个缺省实现：DefaultRequestHandingCommand，这个实现会把请求传给视图组件的特定事件。组合视图是指视图组件在显示给用户时的层次关系：根视图是一个 ViewBean 类的对象字段是一个DisplayField 类的对象，容器视图是一个 ContainerView 类的对象。视图组件类的层次关系如下图：''2.2.2.2.2.2. 优缺点分析优缺点分析优点：这种框架的适应范围大，即提供了底层接口，也有立即可用的组件 具有与客户端 RAD 开发工具相似的开发概念如页为中心（等同于 VB 的 FORM） ，事件处理等. 对大型的应用支持较好 缺点：不是业届标准 目前还没有开发工具的支持（然 JATO 已经为工具支持做好了准备） 没有定义网页导航，开发者在视图中自己指定具体的导航 URL 修改建议把众多的 VIEW/MODEL 对应修改成 xml 文档传递数据，加上集中的网页导航定义2.3. JSF(JavaServer Faces)JSF 是一个包括 SUN 在内的专家组正在定义的开发 WEB 应用用户界面的框架，JSF 技术包括：一组 API，它实现 UI 了组件，管理组件的状态，处理事件，输入校验，定义页面导航，支持国际化和访问； 一个 JSP 定制标签库实现与 JSP 的接口。 JSF 非常简单，是一个定义良好的编程模型。利用这个技术，开发者通过在页面内组合可重用的 UI 组件，在把这些组件和应用的数据源相连，路由客户产生的事件到服务器端的事件处理器进行编程。JSP 处理了所有幕后的复杂工作，使得开发者把关注重点放在应用代码上。2.3.1.2.3.1. STRUTSSTRUTS、JATOJATO 和和 JSFJSF 比较比较''它们之间有部分重叠，但重点不一样。STRUTS 和 JATO 都提供了一个 MVC 式的应用模型，而 JSF 只在用户界面上提供编程接口。这意味着前两者涉及的范围比后者广。JSF 可以成为前两者在 UI 开发的部分。 JSF 的规范的发布版将在 2002 年底发布，实现可能要比这个时间晚些。另外将会有工具支持这个框架的应用开发。 2.4. WAFWAF 是 WEB APPLICATION FRAMWORK 的简称，是 SUN 蓝皮书例子程序中提出的应用框架。它实现了 MVC 和其他良好的设计模式。2.4.1.2.4.1. 细节分析细节分析点击这里看大图2.4.2.2.4.2. 视图视图- -控制控制- -模型模型如图所示，开发人员编写的两个 xml 配置文件定义了 WAF 的运作参数。Screendefinition.xml 定义了一系列的屏幕(screen)。Mapping.xml 则定义了某个动作之后应该显示的屏幕，但没有指定屏幕到哪里拿数据。用户发出一个 HTTP 请求（*.screen），由 TemplateSERVLET 屏幕前端控制组件接收，它提取请求信息，设置 request 对象 CurrentScreen 属性，再把请求发到模版 JSP。模版 JSP 收到请求后，JSP 中的Template 标签察看这个当前屏幕，并从屏幕定义文件（Screendefinition.xml）中获取这个屏幕的具体参数，再生成 html 返回给客户。''假设返回给客户的 html 中包括了 html 表单，用户在输入一定数据之后提交，发出一个 HTTP 请求（*.do）。这个请求被 MainSERVLET 接收，它提取请求信息，察看动作映射文件（mapping.xml），设置处理这个请求的动作对象(HTTPAction 对象)，交给 requestprosessor 对象处理。Requestprosessor 对象调用动作对象完成任务，如果需要进一步处理，requestprosessor 对象会调用 WEBclientcontroler 对象的事件处理机制。MainSERVLET 在处理完请求之后，从屏幕流管理对象那里得到下一个屏幕，并把请求传给这个屏幕的 JSP 文件。值得一提的是 WEBclientcontroler 事件处理机制最终把 HTTP 请求的数据传到了 EJBAction 对象那里处理。这样 HTTPAction 对象和 EJBAction 对象形成了两级处理机制，前一级与 request 对象紧密相关，把数据封装起来形成一个 Event 对象，再传给了 EJBAction 对象，后者与 Request 对象无关。这个方式可以形成一个 session 级别的数据处理机制。下图显示了这个方法。HTTPAction1 对象处理一个请求，并把数据放到一个状态 SessionBean 内，HTTPAction2 也如此，当 HTTPAction3 接收到 HTTP 请求之后，把控制传给EJBAction, 后者获取状态 SessionBean 数据，处理请求，成功后清控状态 SessionBean 的内容。这个机制非常适应多个输入页面才能满足一个业务的输入数据的情况（比如购物车）。2.4.3.2.4.3. 优缺点分析优缺点分析优点屏幕导航定义明确 为框架的扩展提供了一个空间 缺点源码比较乱，稳定性和可靠性没人验证。 只是一个框架躯干，没有正式的 model 层，视图的概念不强 没有模型到视图的定义 修改意见只有一个框架躯干，正为实现自己的应用框架提供了灵活性。没有僵化的视图概念，提供了在网页输入到模型的扩充接口，比如插入 XML 数据交换。