Free Online Courses for Software Developers - MrBool
× Please, log in to give us a feedback. Click here to login
×

You must be logged to download. Click here to login

×

MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

×

MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Working with Remote EJBs in Java

In this article we will see how to use one of the most important features of JEE: EJBs, not locally, but remotely.

Enterprise Java Beans or EJB is a framework adopted in the Java Enterprise Edition, JEE world since the late nineties. It is widely being used by the java developers as a backbone to develop highly scalable and robust applications. Over the years, EJB has seen and adopted all the technological changes which have come in its way. EJBs need a Java Enterprise based container to execute which is provided by an array of application servers. Commonly used application servers are - JBoss, Glassfish, Websphere, Weblogic. In this article, I will talk about the different concepts about EJB and Remote EJB in detail.

Benefits of EJB

Let us have a look on the benefits that EJB presents -

  • Simple development mechanism for large scale complex application.
  • The system level services e.g. transaction handling, maintaining the logs, load balancing, data persistence, exception handling etc are taken care of by the EJB container, thus enabling the developers to concentrate on the business logic.
  • The EJB container is responsible for managing the life cycle of the EJB, thus the developer doesn't need to worry about the tasks e.g. creation or deletion of objects.

Types of EJB

EJBs are classified into three categories based on the purpose they are being used for. These are:

  • Session Beans - This type of EJBs are responsible for storing the user data for every single session. It can be stateful or stateless. These beans get destroyed as soon as the session is terminated by the user.
  • Entity Beans - This type of EJBs are responsible for persisting the data in the database. User data can be stored in the database and also fetched from the database using entity beans.
  • Message Driven Beans - This type of EJBs are responsible for handling messages in the context of JMS or Java Messaging Services. These types of beans are capable of consuming messages from external resources and then taking appropriate action based on the business logic.

Remote EJBs

EJB 2.0 specification comes up with both remote and local interfaces. In other words, both the entity and session beans have a local client interface and remote client interface. The remote interface of an EJB defines the business methods along with the lifecycle methods which are specific to the bean. For example, the remote interface of a bean named BankCustomerAccountBeanmay have the business methods for debit and credit transaction in the customer account. These methods may be named as debit and credit respectively. The following picture depicts how this interface controls the client’s view for an enterprise bean -

Figure 1.Interface of an EJB with Remote access.

The above figure shows the standard flow in a request from a client of an EJB goes to the EJB. The Client of the EJB is only aware of the remote interface. The remote interface is responsible for executing the actual business logic which is written in the EJB and sending back the response. The local interface also works in the same manner. The only difference is that the calling client should reside within the same container.

A remote client of an EJB has the following features:

  • Remote clients have the ability to run on different machine and also on a different JVM.
  • The remote client can be a web component, an application client, or some enterprise java bean itself.
  • The location of the enterprise bean is transparent to the remote client.
  • The enterprise bean needs to implement the business interface. Thus the remote clients should not be allowed to access the enterprise bean over a no-interface view.

In order to create an enterprise bean which allows remote access, we need to take either of the following steps -

  • We need to decorate the business interface of the enterprise bean using the annotation - @Remote as shown under :

@Remote
public interface MyInterface { ... }

Or

We need to decorate the bean class with the annotation @Remote, along with specifying the business interface name(s).

@Remote(MyInterface.class)
public class BeanName implements MyInterface { ... }

Accessing a Remote EJB

Client programs can access an enterprise bean which implement a remote business interface either via the dependency injection approach or via the JNDI lookup method.

  • In order to access the remote business interface of an enterprise bean using dependency injection, we use the annotation - javax.ejb.EJB(@EJB) and mention the name of the remote business interface of the enterprise bean as shown below -

@EJB
EJBNAME nameOfTheEJB;

  • In order to access the remote business interface of an enterprise bean using JNDI lookup, we use the javax.naming.InitialContext interface’s lookup method as shown below -

try {
	Context initialContext = new InitialContext();
	Object remObject = initialContext.lookup("ejb/RemoteClient/HelloMessage");
	HelloBeanRemoteHome remHome = (HelloBeanRemoteHome) PortableRemoteObject.narrow(remObject, HelloBeanRemoteHome.class);
	remoteClient = remHome.create();
	System.out.println(remoteClient.getGreetingMessage("Remote USER"));
} catch (Exception ex) {
	System.out.println(ex);
}

The text - '"ejb/RemoteClient/HelloMessage"' is the name of the EJB which we define in the deployment descriptor file. Deployment descriptor is a file which has all the information about the ejb, which are required to access the EJB either via local home or remote home.

Out of these two methods, dependency injection is the easier way to connect to a remote interface of an enterprise Java bean. Clients which are running within a Java EE server-managed environment, e.g. JavaServer Faces based web applications, JAX-RS based web services, other enterprise java beans, or any other Java EE application clients support this dependency injection mechanism using the javax.ejb.EJB annotation.

Applications which are not on any Java EE server-managed environment, e.g. Java SE applications need to go through an explicit lookup mechanism. JNDI Comes up with a global syntax support which is used to identify the Java EE components in order to simplify the explicit lookup mechanism.

When to go for remote and when to go for local access

While designing a Java based enterprise application, one of the first decisions we need to take is the type of client access which should be allowed by the enterprise beans. We need to take a call between - remote access, local access, ora web service access to our EJBs. This decision is taken after considering the following factors -

  • Tight or loose coupling of the related enterprise beans: Beans which are tightly coupled heavily depend on each other. Let us consider the case where a session bean which is responsible for processing sales orders, makes a call to another session bean which is responsible for sending email confirmation message to the customers. In this situation, these beans are tightly coupled. These types of scenario are the ideal candidates for local access. Since both the Session bean stay together as a logical unit, they can typically call each other often and would get the benefit of higher performance which is possible only in case of local access.
  • Type of the client: When the enterprise bean is to be accessed by the application clients, we should allow remote access of the enterprise bean. In a typical production environment, most of the times, these clients run on different machines than on which the application server which is hosting the enterprise java beans is running. If the clients of an enterprise java bean are either web components e.g. JSPs, JSFs or any other enterprise beans, in this case we are free to provide the type of access as per our wish.
  • Component distribution: The Java based enterprise applications are scalable because of the fact that the server-side components can be distributed across several machines. In case of a distributed application, the server which is hosting the web components be the same on which the enterprise beans which they are accessing are deployed. In this distributed environment, where different components are different servers, the enterprise java beans should allow remote access.
  • Performance: Given the facts e.g. network latency, remote calls may prove to be slower when compared to the local calls. On the other hand, when we distribute the components on different servers, we should get an overall improved performance of the application. Both of these statements are correct. Performance normally depends on various operational environmental parameters. We should be very careful while taking these calls at the time we design our application that might affect performance of the application.

A generic rule every Java enterprise developer should follow - If we are not sure, which type of access an enterprise java bean should have, we should opt for the remote access. Taking this call gives us more flexibility. In case, in the future, if we need to distribute the components in order to accommodate the growing demands of our application, we can do that without any hindrance.

Though uncommon, but technically it is possible to have an enterprise java bean allowing both remote and local access. If that is the case, we need to either design the business interface of the bean must be explicitly as a business interface using the decoration tags - @Remote or @Local annotations, or our bean class should explicitly have the business interfaces with annotation - @Remote and @Local. The same business interface cannot serve both as a local and as a remote business interface at the same time.

Conclusion

Let us conclude our discussion summarising this document in the following bullet points -

  • Enterprise Java Beans or EJB framework is used by the JEE developers since the late nineties.
  • Over the years, EJB has seen and adopted all the technological changes which have come in its way. Thus being the most robust development framework in the enterprise Java World.
  • Enterprise java beans are of three major categories -
    • o Session Bean
    • Entity Bean
    • Message Driven Bean
  • In a broad level, enterprise java beans provide two ways of accessing mechanism -
    • Via local Interface
    • Via remote Interface
  • Local Interfaces are typically used in case one enterprise bean has to call another enterprise bean
  • Remote Interfaces are typically used when the calling components are on distributed environments.
  • It is always advised to use the remote Interface until and unless we are 100% sure that the enterprise java bean will only be accessed locally.
  • The following factors should be taken into consideration while taking a call to choose between local interface and remote interface -
    • Type of coupling between the calling client and the enterprise java bean.
    • Type of the client
    • Component distribution
    • Performance

Through this document, I have tried to cover the basic concepts of EJB and remote interface in detail. Also after going through the sample code, I hope you will now have a better understanding of this concept. Once you are accustomed with these concepts, you can try with some sample exercises.



Over 16 years of hands on experience in different Java/JEE technologies. Have worked on different business domains ranging from finance to insurance to telecom and other domains as well. Have lead the architecture team of several ...

What did you think of this post?
Services
[Close]
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!


> More info about MrBool Credits
[Close]
You must be logged to download.

Click here to login