The Client s Viewpoint

The Client's Viewpoint

If a client now wishes to use the bank account bean installed in the EJB container, it must first locate the bean. For this it uses the naming and directory service. This is addressed via the JNDI interface. (See Figure 3-5.)

Figure 3-5: Finding an Enterprise Bean via JNDI.

Like the Enterprise Bean, the client uses the naming and directory service of the EJB container or of the server in which the bean is installed. The EJB container is responsible for making the Enterprise Bean accessible under a particular name via the naming and directory service. In many cases the name of the bean in the deployment descriptor is used for this purpose. The field of the deployment descriptor in which the name of the Enterprise Bean is entered is called ejb-name (and occurs in our BankAccount example). We now assume that the EJB container uses this name for the publication of the bean's name via the naming service (JNDI). Listing 3-7 shows how a client finds the bank account bean.

Listing 3-7: Finding the home interface using JNDI.

   //depending on the creator of the container or server the appropriate settings   //in the environment should be made in order to generate the correct context.   final String BANK_ACCOUNT = "java:comp/env/ejb/BankAccount";   //generation of the context for access to the naming service   InitialContext ctx = new InitialContext();   //location of the bean BankAccount   Object o = ctx.lookup(BANK_ACCOUNT);   //type transformation; details on this in Section 4   BankAccountHome bh = (BankAccountHome)    PortableRemoteObject.narrow(o,BankAccountHome.class); 

Using the naming and directory service the EJB container provides the Enterprise Bean with an instance of the client stub of the implementation class of the home interface (EJBHome).

Using the methods of the home interface (and those of the interface javax.ejb.EJBHome) the client can govern the life cycle of the bean. For example, it can generate a new account with the following code fragment:

   BankAccount ba = bh.create("0815", "sample account", 0.0); 

The EJBHome object generates a new bean instance (or takes one from the pool), generates a new data set in the database, and generates an EJBObject instance (see Figure 3-6).

Figure 3-6: Generating a new bean via the home interface.

From the parameters of the create method a primary key object is generated, which is associated with the bean instance (via the context of the bean). In this way the bean instance acquires its identity. As a result of this operation the client is provided with the stub of the EJBObject instance. The stub represents the client with respect to the remote interface of the bean.

From this point on the client can use the functionality of the bean by calling the methods of the remote interface. For example, it can increase the bank balance by one hundred units:

   ba.increaseBalance(100.0); 

The call to the method increaseBalance(float) on the client stub passes to the EJBObject instance on the server. From there it is again delegated to the bean instance, which finally has the consequence of changing the data with the assistance of the transaction monitor (for this method it was specified in the deployment descriptor that it must take place in a transaction). (See Figure 3-7.)

Figure 3-7: Invoking a method via the remote interface.

For the client there is no big difference between using an Enterprise Bean and a traditional Java object located in the same process, although it communicates with a transaction-protected component on a remote computer. What begins with a one-line instruction in the code of the client can trigger very complex actions on the server.

From the client's point of view the way that an Enterprise Bean is used via the local interface is analogous to the use of an Enterprise Bean via the remote interface. Similar analogies hold in the processing of the EJBHome and EJBObject classes.

The information presented in this section applies primarily to session and entity beans. Message-driven beans differ from the other two types (as already mentioned) in that they cannot be addressed directly by a client. They can be addressed only indirectly via the asynchronous sending of a message. A message-driven bean is less complex than a session or entity bean and is also easier for the container to manipulate, since the message service takes over a large part of the work. Chapter 6 discusses this issue in detail and makes clear the differences between this type and the other two types of bean.