Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

Local and Remote EJB Interfaces Local and Remote EJB Interfaces

by Olexiy Prokhorenko

As you may already know, the Enterprise Java Bean (EJB) 2.0 specification contains both a remote client view and a new local client view. Thus, session and entity beans can have a local home interface and a local component interface, either with or instead of a remote home interface and a remote component interface (the latter is usually called "component interface", omitting the word "remote").

Local and remote interfaces. Which one to choose? In which case? Why? On the one hand, it looks like the choice is completely clear just from their names. However, the same questions come up in forums all the time: "What for?" "Why?" "When it is necessary to use ...?", etc. We shall try to break it down to the details that will help you choose the right interface for your application.

It's desirable to note that this article is not a detailed manual on using local and/or remote interfaces. We shall only try to describe the various plusses and minuses of both of them. Certainly, the final decision is up to you, and will depend on the specifics of your application.

The reader should have some knowledge of EJB technology, though it's OK to have questions about practical matters, particularly in terms of the proper interfaces to use.

When Local and When Remote?

Generally, your Enterprise Java Bean will need a remote client view in cases when you plan to use the bean in distributed environments. Specifically, these are the cases when the client that will be working with it will be in a different Java Virtual Machine (JVM). In the case of a remote client view, calling any method from the remote home interface and/or remote component interface will be handled via remote method invocation (RMI).

An EJB can use local client view only if it is really guaranteed that other enterprise beans or clients will only address the bean within a single JVM. If this is the case, such access will be carried out with direct method calls, instead of RMI.

Related Reading

Head First EJB
Passing the Sun Certified Business Component Developer Exam
By Kathy Sierra, Bert Bates

Local Versus Remote

We can describe the following common rules for choosing whether to use remote client view or local client view:

Local and client views also have different performance characteristics, which depend on the specifics of the bean's implementation:

Before you start running to implement local client view into your application, you need to be aware of some restrictions. Local client view can only be accessed:

Local client view cannot be accessed:

One more note: when using local interfaces, you have to pay attention to the client's code. Inside of it, you still have to go through JNDI and do lookup (as is the case with remote interfaces), but this time you get a reference to a real Java object on the heap, instead of a stub to a remote object.

Hopefully the discussion above has convinced you that a poorly chosen client view can sharply worsen the performance of your whole project, and perhaps cause it to fail completely under a real-world load. But it is not necessary to go all the way to one extreme or the other. I personally prefer to combine remote and local client view, and to precisely divide methods by interface, making some only remote and others only local. In my opinion, it is necessary to consider all of your enterprise beans in detail, to see which are using remote client view, and see if it's possible to create some additional methods that will relieve the client of a few remote method calls, instead of doing the same operations in only one remote method.

An Example

To conclude, I think it is correct and simply necessary to give you source code that will show how practical and simple it is to work with remote and local interfaces.

Clients will be implemented as Java Server Pages (JSP), and packaged into a WAR file. EJB components will be submitted as two stateless session beans, one with local client view, and the other one with remote client view. These will be packaged into an EJB-JAR file. And both of these WAR and EJB-JAR files are packaged in one common application EAR file.

The process of compiling and assembling our source code is perfectly easy. First of all, you will need to unzip the localremote_src.zip file into any directory you like. The sample code requires Apache Ant and the BEA WebLogic 8.1 application server. Of course, you can use another application server, but you'll need to edit the configuration files to suit your choice of app server.

You will need to edit the build.xml file and change greendomain to the title of your domain, which is configured in your BEA WebLogic. Then just simply type ant all on the command line to compile and package the code. When ready, type ant deploy and wait a few seconds (or minutes) while the EAR package is deployed on your application server. When finished, just open your browser, go to http://localhost:7001/localremote, and choose which client you want to test first, local or remote. I bet you see that everything is as easy as 1-2-3!

However, there's not much obvious difference between the local and remote clients--the only thing that is certain is that everything is really working. Please look into the source code of the enterprise beans and the code of the JSP pages to see how they actually work.


I hope that this article has helped you to understand the importance of the process of application design, and will provide useful guidelines in choosing a proper client view. However, as you understand, in one article it is impossible to describe all nuances of remote and local interfaces usage. What I've tried to do is to describe the basics and the most important (in my opinion) details. But do not worry, you will understand the rest when it becomes necessary to do so. I wish you all the best!


Olexiy Prokhorenko is a Sun Certified Enterprise Architect whose areas of interests include Web software architecture and development of software with frequently changing requirements.

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.