PetStore1.3分析 一

<script type="text/javascript"> google_ad_client = "pub-8800625213955058"; /* 336x280, 创建于 07-11-21 */ google_ad_slot = "0989131976"; google_ad_width = 336; google_ad_height = 280; // </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 前言：我只是一个J2EED的新手而已，只能从代码和简单的设计模式上谈一下对PS1.3的认识，如有谬误，还请多多包涵。

概述：

PetStore1.3在原先的基础上更加抽象了通用事务的处理，换句话说，接口更加抽象，使用了更多的设计模式。同时也将Web Services的概念加了进去，还有一些EJB2.0的新特性，比如说Message Driven Bean，比如说本地接口的引入。 Petstore事实上采取的是仿造Struts的结构，使用XML文件配置系统。这在一定程度上不利于分布式部署，however，这并不妨碍我们研究它，学习其中的设计思想。 在这里，我也强烈推荐各位先看看“动物园的猪”大虾所翻译的PetStore的文档，那是宏观上的理解，而本文档将更多地注重细节。

PetStore的构建基础——MVC模式的Web Application Framework

MVC模式这里就不多说了，如果不知道，搜索一下，应该能了解一个大概。就是Model、View、Controller的简写。在J2EE中，也就是Model2：JavaBean或者EJB作为模型处理，JSP作页面展示，Servlet和一些EJB作为控制。 在Struts中，只有Web层的MVC实现，实际上，这已经能够完成很多中小型系统的需求，普通的系统是完全没有必要做到EJB层的。而PetStore则参考Stuts，增加了EJB层的Controller和Model，这一方面满足了大型系统的需求，另一方面，数据和事务处理的管理可以交给Application Server来完成。 在WAF中，设计者主要实现了两方面的功能，一是Controller的功能并且定义了能够被Controller所接受的Ｍodel接口；另一方面是视图的拼装、标签库的定义。 在后文中，我将详细分析waf中的各个程序。 PetStore的配置文件： 采用类似Struts的结构，PetStore使用一些XML作为系统的配置文件。 除了J2EE所指定的web.xml，PetStore还有一些重要的XML文件：mappings.xml，Screendefinitions.xml（在具体应用中，则会依据用户不同选择screendefinitions_en_US或者screendefinitions_ja_JP……嘿嘿，在最新的1.3.1.02中终于出现了中文版，呜呜呜呜，我们不再是被遗忘的一个角落。） 从配置文件上，我们可以大体了解ps的结构。 OK，下面我来说说这些配置文件。 Web.xml 注册了两个过滤器：编码过滤器（EncodingFilter）和登陆过滤器（SignOnFilter）。 注册了两个Listener：组件管理器，这个东东是web层和ejb层传递信息的核心程序。又将SignOnFilter注册成为Listener。 注册了Web层的front controller（front controller模式）的MainServlet，所有以.do为结尾的url请求都必须经过MainServlet的处理。 注册了用于视图拼装TemplateServlet，每一个.screen结尾都会经过TemplateServlet的处理将几个jsp拼装成为一个完成的页面。 注册了PopulateServlet……这个我没看，应该是数据处理的。 接着一段都是数据处理程序的注册信息，PetStore基本上处理信息都是DAO模式 最后是一些具有Local Interface的EJB的注册。 Mappings.xml 定义HTMLAction—Event—EJBAction的映射关系。这将在后面讲述waf结构的时候详细叙述。 ScreenDefinitions.xml 定义每一个Screen的组成。PetStore中每一个链接都是以.Screen结尾的，一个Screen被自定义的taglib划分为banner、sidebar、body、mylist、footer几个部分，每个部分都对应特定的jsp，其中body为真正实现功能的页面。这几个jsp由TemplateServlet和Template.jsp拼装成一个实际页面。 而在具体实现中，将根据区域选择相应的版本。 Signon_config.xml 定义保护资源，SignOnFilter将载入其中的信息，当没权限的用户访问保护资源时，则返回登陆界面。 处理请求的流程 PetStore框架所接受的请求分为两种，一种是以.Screen结尾，一种以.do结尾。前者只是简单的连接，而后者则会触发后台系列处理。 主要程序清单： Web层 MainServlet RequestProcess ScreenFlowManager WebController DefaultWebController ComponentManager DefaultComponentManager EJB层 EJBController（Session Bean） StateMachine 这些是主要的控制程序，其他还有一些涉及解析XML数据和值对象的类。 可以参见Sun文档的这幅图(非常抱歉ThatsOK的图片目前暂时无法传到服务器中，你可以把url贴出来) 这幅图反映了一次.do请求的解析处理过程。 首先过滤器判断客户端请求的编码和权限，同时由MainServlet进行处理。 MainServlet是前端控制器，它协调控制RequestProcessor和ScreenFlowManager兵分两路进行请求的业务处理和页面流控制。 在PetStore服务器启动的时候，MainServlet就被初始化，监听请求。当一次POST/GET发生时，MainServlet调用doProcess()方法，doProcess()方法调用getRequestProcessor()和getScreenFlowManager()。 getRequestProcessor ()方法返回RequestProcess类型的对象，类RequestProcessor是实际意义上Web层的控制器，所有.do的请求都在这里得到解析，进行URL和HTMLAction的映射，找到相匹配的EJBAction，产生必要的信息封装在Event中。 一个Event被封装好以后，RequestProcessor创建ComponentManager和WebController，用类ServiceLocator定位EJB层控制器，将Event传递给EJB层。 EJB层控制器接收到Event后，调用StateMachine进行通用性的事务处理。在EJB层，后台真正运算并且和数据库交互。 GetScreenFlowManager()方法返回ScreenFlowManager类型的对象，类ScreenFlowManager通过类URLMappingsXmlDAO分析mappings.xml，取得相关数据，将MainServlet所得到的URL请求与之比较，获得下一个页面的资源。 一次请求的过程大致如此。下面将针对代码和设计模式更加详细地分析一下PetStore的运行机制。 由于笔记本不在身边，用的老爸的机器，很多之前画的rose图打不开……下面的不得不等拿到机器。关于本文档，不足之处，希望各位多多指点。希望我在哪些方面多加分析也可以给我留言，谢谢。

模式：

MainServlet：Front Controller ServiceLocator：Service Locator DAO StateMachine： StateMachine Adaptor Factory 业务中有 Session Facade …… ……