How an EJB Client Accesses EJBs

Figure 1 shows how an EJB client accesses an Enterprise Java™ Bean (EJB). This information applies to both the example EJB and to EJBs in general.

The client never communicates directly with the EJB. Instead, it “talks to” the EJB via its home interface and its remote interface. The home interface and remote interface code are both created by the WebSphere Application Server during deployment of the EJBs.

The EJB server and EJB container are part of your Web application server (such as the WebSphere Application Server), and might be supplied by independent software vendors.

Therefore, this code must be implemented for an EJB:
  • The EJB client, that communicates with the EJB. This is usually a servlet or an applet, but could also be any other Java program.
  • The EJB home interface. The EJB developer simply specifies the interface. The EJB home interface is then created by the WebSphere Application Server when it deploys the EJB.
  • The EJB remote interface. The EJB remote interface is also created by the WebSphere Application Server when it deploys the EJB.
  • The EJB class. This class implements the EJB's business logic.
Figure 1. How an EJB Client Communicates with an EJB
An explanation of this figure is provided in the surrounding text.
In Figure 1, the EJB client can be:
Servlet or JSP
Runs in the same WebSphere Application Server as the EJB. Using servlets as EJB clients makes it possible to obtain access to the EJB data from any Web browser, via your company's Intranet or the Internet. The deployed ejb-jar file resides on the server that runs the WebSphere Application Server. For example, online shopping is often performed using a combination of static Web pages and servlets.
Java application
Runs on a different workstation and communicates with the EJB via a TCP/IP connection. You will normally use a Java application as an EJB client for test purposes in your development environment. A Java application is the most simple EJB client and can be used to implement a variety of test cases. Because the deployed ejb-jar file must be accessible by both the EJB client and the WebSphere Application Server, you must either copy the file to the workstation where your EJB client runs, or run the EJB client on the same machine as the WebSphere Application Server. You might also make the file accessible to both platforms over your company's network.
Applet
Runs in a Web browser on a different workstation and communicates with the EJB via a TCP/IP connection. If you require a more advanced user interface than is possible using HTML, you can use an applet as the EJB client. For example, online banking systems often use applets. In such systems, all classes that the applet requires, including the deployed ejb-jar file, are downloaded to the Web browser client when the applet runs. This can lead to performance problems, especially where the applet is accessed via the Internet.
Another EJB
Runs in the same or a different WebSphere Application Server as the EJB. For example, the employer bean and employee bean provided with the VSE Connector Client example, act as EJB clients when they access the record bean.
In other words, an EJB client is any Java program that accesses an EJB.