JavaBeans and EJB Primer

White Paper Sections

• Introduction
• Explanation of JavaBeans
• Distributed JavaBeans using Remote Method Invocation (RMI)
• Introduction to Enterprise JavaBeans
• EJB Application Server
• EJB Component Deconstructed
• EJB Object
• Home Object
• Home Interface
• Remote Interface
• Client Access to EJB
• Home Stub
• Obtaining the Home and Object Stub
• Conclusion

Introduction

So, you don’t know beans about JavaBeans, not to mention Enterprise JavaBeans? Well, don’t be too alarmed. If you are reading this paper, it likely means you are a computer professional with a great deal of experience in some area of computer development. Believe it or not, this knowledge will be very helpful in learning about JavaBeans and Enterprise JavaBeans.

You might be surprised to know that many of the topics and concepts related to the Java technology are already familiar to you based upon your experience working in another language, C++ perhaps. Assuming you have worked with object-oriented technology before, you should be able to make connections between your current OO knowledge and the JavaBeans world. This paper is intended to be a primer for those wishing to learn about the general concepts surrounding the JavaBeans technology. In the following sections you will be given a rudimentary exposure to JavaBeans and Enterprise JavaBeans. Hopefully, this look into the "beans" world will better equip you for future dealings in this area.

Return to Top of Page

Explanation of JavaBeans

The obvious first question on this topic is: "What are JavaBeans?" Simply put, a Java Bean is a reusable software component that can be visually manipulated by a visual builder tool. In other words, it is a listbox, scroll bar, push button or timer like you might find in Visual Basic, Delphi or some other Visual IDE. If you are more familiar with the X Windows or MOTIF world, you might be more familiar with toolkits and widgets. In the Java world these types of components are called JavaBeans. It is really that simple.

If JavaBeans are so similar to other types of components, then you are probably wondering why you should use JavaBeans over the others? This question has multiple answers. For one, JavaBeans has been developed with a strict set of guidelines in mind. The goal of these guidelines is to cause developers to create components with a standard interface. By developing JavaBeans with this standard interface they are easily passed to other Java software applications and easily used because the interface is already known. In other words, once you understand how one bean works, you understand how all beans work. This obviously aids in the development of an application when a new Bean can be introduced requiring little effort by the developer. As you become more experienced in the “bean” world you will learn that someone probably has already created software that you need. Often times your job, as a developer, is to take these existing components and integrate them into your application, rather than reinventing the wheel.

Another reason JavaBeans are believed superior to previous components is that JavaBeans are introspective. The term "introspection" means that when you use a Java designer tool you can inspect a beans’ methods, properties and events during design time. This allows a designer to understand immediately the behavior of a particular bean and thus makes it easier to make use of the beans’ functionality.

Probably the most notable reason JavaBeans are preferable to preceding components is that like other Java software, beans are readily portable across platforms and between other Java programs. What this means is that a developer can design a bean and be assured that this bean will be able to work in conjunction with other beans and other Java software on any Java-enabled platform.

To fully appreciate the significance of this portability, consider a Microsoft component. In the case of an OCX or Active X component the operating system in which these components must reside is one of the 32-bit Microsoft operating systems. A system running UNIX cannot make use of these components and cannot easily interact with the Microsoft applications. A JavaBean, on the other hand, can be moved from a Microsoft operating system over to a UNIX operating system with zero coding effort. This type of portability is one of the major reasons that Java has been so widely embraced.

Return to Top of Page

Distributed JavaBeans using Remote Method Invocation (RMI)

You might now be wondering, can I build a component and distribute it to another machine on a network? The answer is yes. For some readers, Distributed COM (DCOM) might come into mind while others might be thinking of Remote Procedure Calls (RPC). In the Java world this type of client/server architecture would be implemented using Remote Method Invocation or RMI.

Consider a retail store that has a simple two-tiered client/server application for tracking customer purchases. In this case, we are dealing with a Fat Client with most of the software running on the client workspace. Some services, however, cannot be deployed on all of the client machines due to resource scarcity. Perhaps the credit card authorization functionality requires a modem connection or network connection that must be shared among all clients. In this case, the credit card authorization service must be deployed on the server system. This service would be deployed as a JavaBean and would need to be accessed using RMI.

As you probably gathered from the above example, RMI allows a client to request work to be performed on its behalf on another computer system on a network. The beauty of RMI is that it allows developers to use local objects in the same way they would use remote objects. In other words, a call made to a remote object’s method looks exactly the same as if the remote object existed within the client. In order to accomplish this seamless interaction between an application and a remote object, the designers of RMI separated the method calls into three layers. When the client makes a remote method call, it is actually interacting with all three layers, but the call appears to the client to be local. Below is an illustration of the layers that are involved during a RMI call.

Stub and Skeleton layers

These layers on the client and server respectively are responsible for hiding the remoteness of a method call from an application. If you were to interrogate the methods listed from your stub object they would correspond to the methods available in the server component. In this sense, the remote object appears to be local, because the stub object is local and is acting as a surrogate for the server object.

Remote Reference Layer

This layer is responsible for intercepting the method call from the clients stub object or passing control to the skeleton object on the server. This layer performs necessary packaging routines allowing the method calls to be passed to and received from the Transport Layer.

Transport Layer

This layer represents the actual network link or connection between the client and the server. This layer potentially can support any variety of network protocols that has been implemented in Java.

Return to Top of Page

Introduction to Enterprise JavaBeans

By mastering the specific details of JavaBeans and RMI one could develop a fairly robust client server application for a small static business. But what about a large company requiring a multi-tiered enterprise architecture? For these types of applications Enterprise JavaBeans (EJB’s) have been introduced.

The word "enterprise" is associated in the computing world with the following principles: scalable, highly available, maintainable, transactional and secure. The goal of the EJB architecture is to allow developers and third party software vendors to concentrate on creating distributed business logic components (EJB’s) without needing to concern themselves with the specific implementation of things like security and transaction processing.

In simple terms, the EJB architecture requires that low-level complex services such as security, transaction processing, thread pooling, resource sharing, and many other complex tasks be handled behind the scenes. This behind-the-scenes work is performed within the middle-tier of a multi-tiered application.

Return to Top of Page

EJB Application Server

The EJB middle-tier or application server is both an object broker and a transaction monitor. The object broker portion of the EJB server is responsible for allowing clients easily to locate and use distributed objects or EJB’s. The transaction monitor portion of an EJB handles issues related to transactions, consistency, persistence and other system level considerations. The EJB middle-tier will be referred to as the EJB application server or EJB server.

Below is a logical illustration of an EJB application server.

In order for an EJB to be used it must be deployed within an EJB application server. On behalf of the Java community Sun Microsystems maintains a strict specification detailing how an EJB application server must behave. These guidelines insure that the application server will handle the many complex tasks related to enterprise applications and that an EJB can be deployed on any EJB application server.

In the above illustration you will notice that the EJB server component is represented inside of a cloud. This cloud represents something called a “container”. When an EJB is deployed, the application server allocates a special context for the EJB to run under called a container. The container is the environment that surrounds the EJB. Conceptually, the container is the intermediary between the EJB component and the EJB server. The container is responsible for defining how services, such as security and transactions, are to be managed by the server on behalf of the EJB. For each EJB that is deployed the application server allocates a unique container to manage the EJB.

Return to Top of Page

EJB Component deconstructed

From a conceptual view an EJB is thought of in terms of a single distributed component that provides specific business functionality. While conceptually this is true, in reality an EJB is made up of two distinct objects called the home object and the EJB object. These objects are provided by the application server vendor and work with the container to manage the EJB. This type of architecture presents a complex problem. Since different application vendors are supplying their own versions of the home and EJB objects, how can any EJB work with any application server? Furthermore, how can a client know how to access these proprietary objects? This complex issue is dealt with through the use of interfaces.

In Java an interface is a construct that defines particular methods that can be used on an object. In some ways an interface can be thought of as a contract that explains the acceptable usage of an object. What this means is that a client can work with any type of home object or any type of EJB object provided that the appropriate contract or interface is defined. The interfaces that are used with EJB’s are called the "home interface" for the home object and the "remote interface" for the EJB Object.

Return to Top of Page

EJB Object

The EJB object has two main functions. First, the EJB object must work with the container to apply security, transaction requirements and other types of system behavior. Second, the EJB object must define the specific business functionality. The first portion of the EJB object is provided by the EJB application server vendor and will never be modified by an EJB developer. The second portion of the EJB object contains the specific business functionality and is provided by the EJB developer.

How does the EJB object obtain the business functionality? When a developer sets out to create an EJB, the developer codes a piece of the EJB known simply as the “bean class”. The bean class contains the specific business logic code. In the credit card authorization example given earlier, the bean class would house the specific business requirements for authorizing a credit card purchase. When you deploy an EJB the bean class code merges with or extends the generic EJB object code to create a specific EJB object. This deployment process also creates a specialized instance of the home object.

Return to Top of Page

Home Object

What is the home object? The home object is responsible for working with the container to manage the life cycle of the EJB. When a client makes a request to create an instance of a particular EJB, the home object actually works with the container to create the EJB object and perform any system maintenance related to the EJB object. Conversely, when the client wishes to remove an EJB, it is the home object working with the container that causes the EJB to be removed.

How does the client make use of the EJB? As was mentioned earlier, the client uses the interfaces in order to make use of the home and EJB object. In order to allow client access to these objects two standard interfaces are used. These interfaces are called the home interface and the remote interface. Essentially, these interfaces define what methods are available for a client to invoke.

Return to Top of Page

Home Interface

The home interface describes the methods that are available within the home object. Since the home object is responsible for the life cycle aspect of the EJB, the home interface would consist of at least one "create" and one "remove" method definition to allow for the creation and removal of the EJB.

Return to Top of Page

Remote Interface

The remote interface describes the methods available within the EJB object. Since the EJB object’s main purpose as it relates to the client is to allow for the execution of specific business logic, the remote interface would consist of the business related methods that are found in the bean class. For example, in the credit card authorization example one method might have been written in the bean class called "getAuthorization". If this were the case, the "getAuthorization" method would be defined in the remote interface.

You might be wondering why the interface exists within the server when the client is the one that needs to make use of the EJB. The reason that the server has a copy of the interface is due to the fact that EJB’s can call other EJB’s. In this sense an EJB can also be a client.

Return to Top of Page

Client access to EJB

While it is true that one EJB can call another EJB, the more useful implementation is to have a network client make calls remotely to an EJB. Since the EJB is comprised of two objects that are remote from the client, the client must somehow access these objects across the network. As you might have guessed, this is done using Remote Method Invocation or RMI.

As you will recall, when you use RMI the client object makes use of three layers: stub, remote reference, and transport. These layers help hide the remoteness of the call. The goal of the client call is to make use of the server side home object and EJB object. In order to make these calls, the client must use an object called the home stub and another called the object stub.

Return to Top of Page

Home Stub

Since the home object on the server is responsible for creating and removing an EJB, this is the first object that the client must access. Remote access to the home object is made possible through the use of the home stub. The client uses the home interface in order to access the methods within the home stub. Because it implements RMI behavior the home stub will cause the methods of the home object on the server to execute.

Return to Top of Page

Obtaining the Home and Object Stub

One interesting aspect regarding the home stub is that before the client can make use of it, the client must actually download it from the application server. When an EJB is deployed on an application server, the home stub is placed into an area known as the "Java Naming and Directory Interface" or JNDI. By placing the home stub in a common area such as the JNDI, multiple clients can gain access to the same object. As a result, when the client code is compiled only the interface describing the home stub is required. This interface tells the client what methods the home object can perform.

Initially, the client will want to invoke the create method of the home object stub. Invocation of the home stub create method will cause the server side home object to execute its create method. After the create method has executed, the server returns the EJB object stub to the client.

The client makes use of the object stub’s method through the remote interface. The remote interface tells the client what methods are available within the EJB object. Since the EJB object contains all of the specific business functionality of the EJB, the client uses the remote interface to invoke business method calls available in the object stub. Again, since the Object stub extends the RMI behavior, the method calls are ultimately executed on the server EJB object and returned to the object stub.

Return to Top of Page

Conclusion

While this look into the Java world does not make you an expert, it hopefully clarifies some questions regarding the JavaBeans and Enterprise JavaBeans technology. Because of the component architecture and the portability of JavaBeans and EJB’s, development effort and time is greatly simplified and reduced. These are benefits companies like to hear.

As you can no doubt tell, the "bean" technology requires massive cooperation from the business community. If the bean guidelines are not followed the previously discussed concepts are useless. But thanks to the many benefits the bean technology provides, buy off from the business community has been rapid and pervasive. Considering the relative youth of Java and beans, the coming years will no doubt extend the existing functionality making development tasks even easier.

~end of Aurora Information Systems White Paper Series #10
  "JavaBeans Primer"~

Return to Top of Page

Do you find this information interesting? Consider employment with Aurora!

Do you need help implementing your Middleware app? Aurora can make your life easier.