EJB------Local and Remote EJB Interfaces

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.

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.

Local Versus Remote

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

• When you will potentially use a distributed environment (if your enterprise bean should be independent of its deployment place), you should obviously chooseremote client view.
• Use remote client view when you need to be sure that parameters passed between your EJB and the client (and/or other enterprise beans) should be passed "by value" instead of "by reference." With pass-by-value, the bean will have its own copy of the data, completely separated from the copy of the data at the client. With local client view, you can do pass-by-reference, which means your bean, as well as the client, will work directly with one copy of the data. Any changes made by the bean will be seen by the client and vice versa. Pass-by-reference eliminates time/system expenses for copying data variables, which provides a performance advantage.
• If you create an entity bean, you need to remember that it's usually used with a local client view. If your entity bean needs to provide access to a client outside of the existing JVM (i.e., a remote client), you typically use a session bean with a remote client view. This is the so-called Session Facade pattern, the goal of which is that the session bean provides the remote client access to the entity bean.
• If you want to use container-managed relationship (CMR) in your enterprise bean, you must expose local interfaces, and thus use local client view. This is mentioned in the EJB specification.
• Enterprise beans that are tightly coupled logically are good candidates for usinglocal client view. In other words, if one enterprise bean is always associated with another, it's perfectly appropriate to co-locate them (i.e., deploy them both in one JVM) and organize them through a local interface.

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

• Creating a remote object (if it does not exist yet) requires creating a stub and a skeleton, which will cost cycles.
• When you transfer variables via remote method invocation, the type of the transmitted data plays a big role. Different types of data entail different marshalling overhead. Naturally, transferring primitive data types usually do not create problems, but transferring complex data types, such as Collections, can be very problematic.
• Returning a remote object is somewhat expensive, taking time to transfer the object to the client and create copies. Speaking of returning remote objects, it is necessary to remember that you must not return a remote interface from a local interface method. Never!

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:

• When enterprise beans are packaged within the same EJB-JAR package.
• When enterprise beans are packaged within different EJB-JAR packages, but everything is still packaged within the same application's EAR package.
• When a web component in a WAR file is packaged within the same application's EAR package.

Local client view cannot be accessed:

• When an EJB or web component is packaged in a different application's EAR packages.
• When a web component is deployed in a web container, and EJBs are deployed in an EJB container, and these containers are separated (even if they are running on the same machine).

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 thelocalremote_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.

Conclusion

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!

(Reference : Head first EJB)