| 
         
     
     | 
     | 
    
  
    | 
    Petstore源码追踪记(3)-商业逻辑处理(四) | 
   
  
     | 
   
  
     | 
   
  
    | 
     作者:未知  来源:月光软件站  加入时间:2005-2-28 月光软件站  | 
   
  
    Petstore源码记纵记(3)-商业逻辑处理(下)                                           ( 欧宣修 ) 图文并茂版请参考 http://www.javatwo.net/JavaPaper/Petstore-3_business_logic.pdf
  接续上期...
  我们已了解SignOnFilter在Web tier处理登入工作的步骤,它需要透过EJB tier从数据库读取资料进行比对,所以接下来探讨在EJB tier的运作情形,从图14、15可找出实际对应的EJB,从图上面可知此EJB的属性是Local Stateless  Session Bean,这很少见,大部份的书介绍到Local Bean的用法都用在Entity Bean,由此可知Local Bean的用法亦可用在Session Bean。      SignOnEJB,源码在Petstore_home\src\components\signon\src\com\sun\j2ee\blueprints\signon\ejb\SignOnEJB.java,请读者顺便加上侦察程序代码:       public class SignOnEJB implements SessionBean {
      private static final String USER_HOME_ENV_NAME =  "java:comp/env/ejb/local/User";     private InitialContext ic = null;     private UserLocalHome ulh = null;
      public void ejbCreate() throws CreateException {       try {         ic = new InitialContext();         //取得UserLocalHome Reference,它是代表使用者基本资料的Local Entity Bean         ulh = (UserLocalHome) ic.lookup(USER_HOME_ENV_NAME);       } catch (NamingException ne) {          throw new EJBException("SignOnEJB Got naming exception! " +  ne.getMessage());       }     }
      /**      *此函数由SignOnFilter呼叫,依使用者帐号找出对应的User实体    *(instance),然后呼叫User实体的密码比对函数-user.matchPassword()      * business method used to check if a user is allowed to sign on      */     public boolean authenticate(String userName, String password) {     //请加入侦察程序代码,方便稍候程序验证 System.out.println("SignOnEJB执行authenticate()进行使用者验证  userName="+userName+", password="+password);         try {             UserLocal user = ulh.findByPrimaryKey(userName);             return user.matchPassword(password);         } catch (FinderException fe) {             return false; // User not found, so authentication failed.         }     }      以下略...      
  图16 SignOnEJB的EJB Reference       UserEJB,源码在 Petstore_home\src\components\signon\src\com\sun\j2ee\blueprints\signon\user\ejb\  UserEJB.java,它是Local Entity Bean,对应数据库中实际资料表- UserEJBTable在约88列可看到SignOnEJB所呼叫的函数,请读者顺便加 上侦察程序代码:            public boolean matchPassword(String password) {   //请加入侦察程序代码,方便稍候程序验证   System.out.println("UserEJB执行matchPassword()进行密码比对");     return password.equals(getPassword()); }      
  图17 UserEJB为Entity Bean
  点选图17右下角”Deployment Settings”钮,可见到图18画面, 选择左下角”Method Implementation Queries”之”Container Methods” 之”createRow”,即可看到图18之SQL Query:
  图18 UserEJB对应资料表为UserEJBTable
  由上述所列程序代码及图,读者应该可以了解使用者登入在EJBz tier的运作情形,在UserEJB也看到一个不一样的用法,就是在Entity Bean上使用商业逻辑-matchPassword() 函数,在大部份的EJB书籍或文件都告诉我们商业逻辑应该用Session Bean去实作,资料则用Entity Bean来实作,但在这里密码比较的商业逻辑是非常简单的,只用了一行程序就解决了,所以也不需为了它另外再做一个Session Bean, 也许读者会问为什么不将此函数写在SignOnEJB?笔者认为密码比对不只在登入流程上会使用,在使用者基本资料编辑时也可能会用到,所以还是放在UserEJB比较适合:)     我们能够知道使用者基本资料是存于UserEJBTable,我们要如何知道此资料表所存内容是什么?请参阅注4。
  现在请重复第一阶段验证步骤将程序重新编辑及部署,可发现程序如我们所预期般执行!
  图19 第二阶段程序验证结果
  第三阶段 大家还记得在SignOnFilter之validateSignOn()函数,验证成功会将 SIGNED_ON_USER变量(对应实际变量为j_signon)的值设为真值(true):
  hreq.getSession().setAttribute(SIGNED_ON_USER, new Boolean(true));
  当我们再次从首页进入使用者基本资料浏览页,会再度给SignOnFilter拦截,从Session取出SIGNED_ON_USER变量(对应实际变量为j_signon),经判断为真值(true),SignOnFilter则会放行转导至使用者基本资料浏览画面(customer.do),读者可参考下列程序代码加入侦察码,在约125列doFilter()函数:
 
      boolean signedOn = false;     if (hreq.getSession().getAttribute(SIGNED_ON_USER) != null) {        signedOn  =((Boolean)hreq.getSession().getAttribute(SIGNED_ON_USER)).booleanValue();         //加入侦察码 System.out.println("signedOn="+signedOn);     } else {        hreq.getSession().setAttribute(SIGNED_ON_USER, new Boolean(false));     }        // jump to the resource if signed on        //若已登入过,则结束此Filter工作,进入Filter chain,以本例来说,它为 Filter chain中最后一个Filter,所以就是不做任何事,让使用者进入他的目的画面        if (signedOn) {            //加入侦察码            System.out.println("使用者已登入过!");            chain.doFilter(request,response);            return;        }
  参考前面叙述重新编译部署后执行,可得下图预期结果:
 
  图20 第三阶段程序验证结果
 
  customer.do
   到这里相信读者能对Petstore登入流程控管有更深入的了解,通过登入流程就到达了使用者基本数据浏览画面(customer.do),*.do与前二篇介绍的*.screen不同,*.screen代表的是一个画面,如main.screen代表首页,它可由多个.jsp所组成;*.do代表的是一个动作,customer.do代表对使用者基本资料相关动作,如新增、修改、删除,它会透过EJB tier与资料库互动,最后得到的结果也是要展现,运用*.screen的机制组成结果画面,所以我们可以这样想象*.screen是名词,*.do是动词,以本例来说,只是读取资料,虽然运用到*.do,但并没有任何动作,为了能让读者了解整个架构,还是在此稍事说明。
  请开?deploytool,点选左边窗格Files > Applications > PetstoreEAR > PetstoreWAR > MainServlet,选择右边 Alias页,可发现处理*.do即是MainServlet
  图21 *.do对应MainServlet
  点选General页可找到实际对应类别,源码在 Petstore_home\src\waf\src\controller\com\sun\j2ee\blueprints\waf\controller\web\MainServlet.java ,在约79列可找到初始函数: 
  public void init(ServletConfig config) throws ServletException {         //读取预设语系,值为”en_US”         String defaultLocaleString = config.getInitParameter("default_locale");         defaultLocale = I18nUtil.getLocaleFromString(defaultLocaleString);         this.context = config.getServletContext();         String requestMappingsURL = null;         try {             //读取mapping.xml             requestMappingsURL =  context.getResource("/WEB-INF/mappings.xml").toString();         } catch (java.net.MalformedURLException ex) {             System.err.println("MainServlet: initializing ScreenFlowManager  malformed URL exception: " + ex);         }        //将mappings.xml转成HashMap类别并存入ServletContext        urlMappings = URLMappingsXmlDAO.loadRequestMappings(requestMappingsURL);        context.setAttribute(WebKeys.URL_MAPPINGS, urlMappings);        eventMappings = URLMappingsXmlDAO.loadEventMappings(requestMappingsURL);        context.setAttribute(WebKeys.EVENT_MAPPINGS, eventMappings);        //ScreenFlowManager初始化并存入ServletContext        getScreenFlowManager();        //RequestProcessor初始化并存入ServletContext        getRequestProcessor(); }
  图22 MainServlet实际对应类别
  MainServlet在初始化时会读取预设语系及对应设定档(mapping.xml),及初始化ScreenFlowManager、RequestProcessor,预设语系设定在MainServlet之init. Parameter页,值为”en_US”(英语系)。
  图23 MainServlet之init. Parameter设定
  对应设定文件位置在 Petstore_home\src\apps\petstore\src\docroot\WEB-INF\mappings.xml ,我们可在约95行找到customer.do的相关设定
  <url-mapping url="customer.do" screen="customer.screen" > <web-action-class>com.sun.j2ee.blueprints.petstore.controller.web.actions.CustomerHTMLAction</web-action-class> </url-mapping>
  这一段卷标(tag)有三个参数: url:标示对应动作 web-action-class:实际执行类别 screen:结果显示画面
       *.do的运作机制是Servlet接收到request,从mappings.xml找到对应的url, RequestProcessor将对应的web-action-class初始化并执行,ScreenFlowManager 将执行结果传回给*.screen,再运用本系列前两篇所介绍*.screen机制组成实际画面,响应给使用者,大致的流程是这样,实际上更复杂,因牵涉到Web tier与EJB tier间沟通,但以本例来说,RequestProcessor对应web-action-class(CustomerHTMLAction)并没有做什么事,后续RequestProcessor接收到结果显示画面(customer.screen),则进行转导(forward)动作。      mappings.xml读取后转成HashMap类别存入ServletContext供所有进入 Petstore系统的人使用,接着将ScreenFlowManager及RequestProcessor初始 化并存入ServletContext。
 
 
  
 
  | 
   
  
     | 
   
  
     相关文章:相关软件:  | 
   
   
      |