Petstore源码追踪记(3)－商业逻辑处理(四）

核心提示：接续上期...http://www.javatwo.net/JavaPaper/Petstore-3_business_logic.pdf我们已了解SignOnFilter在Web tier处理登入工作的步骤，它需要透过EJB tier从数据库读取资料进行比对，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。

bill-转自:csdn

（出处：http://www.cncms.com）