Day 10

Quiz

A1:

The three different types of Enterprise JavaBeans are session, entity, and message-driven EJBs.

A2:

A session bean is a reusable piece of code residing on the server that performs transactional processing on behalf of a client application.

A3:

Stateful session beans are session aware; that is, they maintain a conversational state with an EJB client. Stateless session beans do not maintain a conversational state with an EJB client.

A4:

In order to build a session bean, you need to write a remote (or local) interface of the session bean that extends from the javax.ejb.EJBObject (or javax.ejb.EJBLocalObject in the case of local) interface. This will contain the business methods of the bean. The methods that an EJB client uses to obtain the reference of the session bean are written in the home interface, which extends the javax.ejb.EJBHome (or javax.ejb.EJBLocalHome in the case of local) interface. Finally, the actual bean implementation class has to be written. The bean implementation class implements the javax.ejb.SessionBean interface.

Exercises

A1:

Since the Waiter and Chef beans of the restaurant application have been designed to be accessed remotely, the Customer EJB client can easily access them from another location or machine. There will be no changes required to the Customer EJB client, since location of the actual EJBs is not an issue for remote access of EJBs. As long as the EJBs themselves provide the ability for remote access (the remote interface of the EJB extends javax.ejb.EJBObject), the EJBs can be accessed remotely. Moreover, the reference of the EJB is with the JNDI naming service, and hence, as long as the location of the JNDI naming service used by both the EJB and the EJB client remains unchanged, no change is required. The ejbc compiler generates both client-side stubs and server-side skeleton code. Hence, you need to use the ejbc compiler to generate the client-side stubs on the remote machine where the Customer EJB client application will be located.

A2:

To access the Waiter bean locally, you only need to make changes in the WaiterInterface and WaiterHome interfaces. In order for the bean to be accessed locally, the WaiterInterface needs to extend the EJBLocalObject interface. Also, all the methods in the interface will now throw javax.ejb.EJBException instead of javax.rmi.RemoteException. The code for this is as follows:

 package com.sams.learnweblogic7.ejb.stateful;  import javax.ejb.EJBException; import javax.ejb.EJBObject; import java.util.*; /** * This is the local waiter interface, looked up by the restaurant * and passed to the client. * This interface, which extends EJBLocalObject, is the local interface. * The business methods are defined here. */ public interface WaiterInterface extends EJBLocalObject {        public MenuList getMenu() throws EJBException;        public void getOrder(MenuItem orderedItem, int quantity) throws                EJBException;        public void confirmOrder() throws EJBException;        public ChefInterface getChefFromChefPool() throws EJBException;        public Vector serveCookedItem() throws EJBException;        public float getCheck() throws EJBException; } 

The other change is to the home interface of the Waiter bean. The WaiterHome home interface for a bean that is accessed locally must extend from the java.ejb.EJBLocalHome interface instead. The exceptions should also be javax.ejb.EJBException, instead of javax.rmi.RemoteException. The rest of the code remains the same. The code is as follows:

 package com.sams.learnweblogic7.ejb.stateful;  import java.ejb.EJBException; import javax.ejb.CreateException; import javax.ejb.EJBHome; /**  * This is the home interface for the ChefBean.java.  * In WebLogic, this is implemented by the code-generated container  * class ChefBeanC. A home interface may support one or more create  * methods, which must correspond to methods named "ejbCreate" in the          EJBean.  *  */ public interface WaiterHome extends EJBLocalHome {   /**    * Corresponding to the ejbCreate method in the WaiterBean.java.    *    * @return                  WaiterInterface    * @exception               EJBException    * @exception               CreateException    */   WaiterInterface create() throws CreateException, EJBException; } 

A3:

EJB clients need to communicate with the same bean object reference. Unlike a standalone EJB client, a Java servlet handles requests from different clients. Hence, when a Java servlet performs the role of an EJB client, this bean object reference must be saved across different requests. In addition, since Java servlets themselves maintain state for different clients, it is all the more necessary to save the bean's object reference in the session for each client and retrieved during the request processing of each specific client. This is far different from writing a simple standalone EJB client application.



Sams Teach Yourself BEA WebLogic Server 7. 0 in 21 Days
Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days
ISBN: 0672324334
EAN: 2147483647
Year: 2002
Pages: 339

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net