Petstore source Tracking (3)-Business logic processing (iv)

Petstore Source Record (3)-business logic processing (bottom)
(OUXIANCIU)
For an illustrated version, please refer
Http://www.javatwo.net/JavaPaper/Petstore-3_business_logic.pdf

Continuation of the previous period ...

We have seen the steps of Signonfilter in the Web tier process, it needs to read data from the database through the EJB tier, so next explore the EJB tier operation, from Figure 14, 15 can find the actual corresponding EJB, from the graph above can be This EJB is known as the Local stateless property
Session bean, which is rare, most of the books introduced to the local bean usage are used in the Entity bean, so the use of local beans can also be used in the Session bean.
SIGNONEJB, source code in Petstore_home/src/components/signon/src/com/sun/j2ee/blueprints/signon/ejb/signonejb.java, By the way, the reader is accompanied by the Scout code:

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 ();
Get Userlocalhome Reference, which is the Local Entity Bean that represents the user's basic information
Ulh = (userlocalhome) ic.lookup (user_home_env_name);
} catch (Namingexception ne) {
throw new Ejbexception ("SIGNONEJB Got naming exception!" +
Ne.getmessage ());
}
}

/**
* This function is called by Signonfilter to find the corresponding user entity according to user account
* (instance), then call the User entity's password alignment function-User.matchpassword ()
* Business method used to check if a user is allowed
*/
public Boolean authenticate (string userName, string password) {
Please join the Scout code to wait for program verification
System.out.println ("SIGNONEJB execution Authenticate () for user authentication
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.
}
}
The following slightly ...


Figure SIGNONEJB EJB Reference

USEREJB, the source code in
petstore_home/src/components/signon/src/com/sun/j2ee/blueprints/signon/user/ejb/
Userejb.java, which is the Local Entity Bean, corresponds to the actual data table in the database-
Userejbtable can see the function called by SIGNONEJB in about 88 columns, please add the reader by the way
On the Reconnaissance program code:


public boolean Matchpassword (String password) {
Please join the Scout code to wait for program verification
System.out.println ("USEREJB execution Matchpassword () for password comparison");
Return Password.equals (GetPassword ());
}


Figure USEREJB is an Entity Bean

Click on the lower right corner of Figure 17 "Deployment Settings" button, visible to Figure 18 screen,
Select "Method implementation Queries" in the lower left corner "Container Methods"
"CreateRow", you can see the SQL Query in Figure 18:

Figure userejb corresponding table for userejbtable

By the program code and diagram listed above, the reader should be able to understand the user login in the EJBZ tier operation situation, in USEREJB also saw a different usage, is to use the business logic-Matchpassword () function on the Entity Bean, in most of the EJB books or The file tells us that the business logic should be done with the Session bean, and the data is actually done with the Entity bean, but the business logic of the password comparison here is very simple, only a single line of the program is solved, so there is no need to do another session bean for it,
Perhaps the reader will ask why this function is not written in SIGNONEJB. I think the password is not only in the login process will be used, in the user's basic information editing may also be used, so still put on the USEREJB more suitable: we can know that the user's basic information is stored in userejbtable, how we know what the contents of this table is. See note 4.

Now repeat the first phase verification step to re-edit and deploy the program, and discover that the program executes as we expect.

Figure 19 Phase II program validation results

Phase III
As you can remember in the Signonfilter Validatesignon () function, verifying success will
The value of the Signed_on_user variable (corresponding to the actual variable is J_signon) is set to Truth (true):

Hreq.getsession (). SetAttribute (Signed_on_user, New Boolean (true));

When we enter the user profile page again from the homepage, we will intercept the Signonfilter again, remove the Signed_on_user variable from the Session (corresponding to the actual variable is J_signon), judged to be true, Signonfilter Will be released to the user Profile Browsing screen (customer.do), the reader can refer to the following program code to join the Scout Code, in about 125 columns of the DoFilter () function:


Boolean Signedon = false;
if (Hreq.getsession (). getattribute (signed_on_user)! = null) {
Signedon
= ((Boolean) hreq.getsession (). getattribute (Signed_on_user)). Booleanvalue ();
Add Scout Code
System.out.println ("signedon=" +signedon);
} else {
Hreq.getsession (). SetAttribute (Signed_on_user, new Boolean (false));
}
Jump to the resource if signed on
If you have already logged in, end this filter work and enter filter chain, in this case it is
Filter chain The last filter, so just do nothing, let the user enter his purpose screen
if (Signedon) {
Add Scout Code
SYSTEM.OUT.PRINTLN ("User has logged in. ");
Chain.dofilter (Request,response);
Return
}

Refer to the previous description to recompile the deployment after the execution, you can get the following diagram expected results:


Figure 20 Phase III program validation results


Customer.do

It is believed that readers can have a better understanding of the Petstore login process Control, through the login process to reach the user basic data Viewing screen (customer.do), *.do with the first two introduced *.screen different, *.screen represents a picture, such as main . screen represents the home page, which can be composed of multiple. JSP, *.do represents an action, customer.do represents the user basic information related actions, such as new, modified, deleted, it will be through the EJB tier and database interaction, the final result is to show, using *.S Creen mechanism composed of the results of the screen, so we can imagine that *.screen is a noun, *.do is a verb, in this case, just read the data, although the use of *.do, but there is no action, in order to let the reader understand the entire architecture, or here a little explanation.

Please open the Deploytool, click the left pane, Files > Applications > Petstoreear > Petstorewar > Mainservlet, select the Alias page on the right to find processing *.do That's mainservlet.

Figure *.do corresponds to Mainservlet

Click on the General page to find the actual corresponding category, the source code in
Petstore_home/src/waf/src/controller/com/sun/j2ee/blueprints/waf/controller/web/mainservlet.java
, the initial function can be found in approximately 79 columns:

public void init (ServletConfig config) throws servletexception {
Read the default language, the value is "en_US"
String defaultlocalestring = Config.getinitparameter ("Default_locale");
Defaultlocale = i18nutil.getlocalefromstring (defaultlocalestring);
This.context = Config.getservletcontext ();
String requestmappingsurl = null;
try {
Read 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");
}
Convert Mappings.xml into HASHMAP category and deposit to ServletContext
urlmappings = Urlmappingsxmldao.loadrequestmappings (Requestmappingsurl);
Context.setattribute (Webkeys.url_mappings, urlmappings);
eventmappings = Urlmappingsxmldao.loadeventmappings (Requestmappingsurl);
Context.setattribute (Webkeys.event_mappings, eventmappings);
Screenflowmanager Initialize and deposit ServletContext
Getscreenflowmanager ();
Requestprocessor Initialize and deposit ServletContext
Getrequestprocessor ();
}

Figure Mainservlet Actual corresponding category

Mainservlet will read the preset language and the corresponding profile when initializing