One of Java's most important features is platform independence. Since its arrival, Java has been depicted as "write once, run anywhere". But Enterprise JavaBeans (EJBs) go one step further. They are not only platform independent but also implementation independent. That is, EJBs can run in any application server that implements the EJB specifications. In this overview, I discuss about the background, necessity and motivations for the emergence of EJBs in the enterprise distributed computing arena and a short EJB architectural overview.

Distributed computing allows a business system to be more accessible. Distributed systems allow parts of the system to be located on separate computers located in different locations, where they make the most sense. That is, distributed computing allows business logic and data to be reached from remote locations at any time from anywhere by any one. The most recent development in distributed computing is distributed object computing. The technologies such as Java RMI, CORBA and Microsoft's DCOM help to accomplish distributed object computing paradigm by allowing objects running on one computer to be accessed for servicing the clients in other computers.

Object-oriented (OO) programming languages, such as Java, C++ and Smalltalk, are used to code software that fulfills the goals such as flexibility, extensibility and reusability, of OO technology. In business systems, OO languages are being used to improve development of GUIs, to simplify access to data and above all, to encapsulate the business logic into business objects. As a business's products, processes,and objectives evolve over time, the software that models the business has to be flexible, extensible, adaptable and reusable. The OO programming methodologies, namely encapsulation, polymorphism and inheritance, play a very important share in accomplishing the above mentioned goals. As today's enterprises are being shaped to comprise a number of business objects fulfilling various tasks, distributed computing is all set to take a very significant role in developing and deploying enterprise-class software in the days ahead. In the following sections, I discuss some of the earlier computing paradigms and the context in which EJB architecture came out and promises to shape the future requirements.

TP monitors have been evolving for about 30 years and have become powerful, high-speed server platforms for mission-critical applications. TP monitors are operating systems for business systems whose applications are written in languages like COBOL. TP monitors automatically manage the entire environment that a business system runs in, including transactions, resource management, and fault tolerance and thus are eligible to be called operating systems. The business logic in TP monitors is made up of procedural applications that are often accessed through network messaging or remote procedural calls (RPC). RPC is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally.

The downside for TP monitors is as follows: TP monitors are not object oriented and they work with procedural code that can perform complex and mission-critical tasks but no sense of identity. Accessing a TP monitors through RPC is like executing static methods; there is no such thing as a unique and distinct object. Also the business logic, which is procedural, is not as flexible, extensible, or reusable as business logic, which is object-oriented.

Distributed objects allow unique objects that have state and identity to be distributed across a network so that they can be accessed by other systems. Distributed object computing technologies like CORBA and Java RMI grew out of RPC with one significant and necessary difference that the invoking method is on an object instance, not an application procedure. Distributed objects are usually deployed on some kind of ORB, which is responsible for helping client applications find distributed objects in a transparent manner. The down side for an ORB is as follows: ORBs do not define an operating system for distributed objects. That is, all the responsibility for concurrency, transactions, resource management and fault tolerance rests on the application developers. These services may be available from the ORB vendors or can be purchased from third party vendors and can be implemented in an ORB, but the developer has to write the glue code to incorporate them into the business objects.

As the advantages of distributed objects became visible, the number of systems deployed using ORBs gets increased. But as indicated above, there happened to be a number of deficiencies on server side due to the poor server-side component model, which ORB architecture has been blessed with. The vital and relevant server-side services according to the ORB architecture specifications have been made to be explicitly accessed through APIs by the distributed object, resulting in more complexity. Also, the resource management strategies such as instance swapping, resource pooling, and activation may not be supported at all in this component model. These strategies are mainly responsible for distributed object systems to scale, improving performance and throughput and reducing latency. Without automatic support for resource management, application developers must implement home-grown resource management solutions, which requires a very sophisticated understanding of distributed object systems. Further on, ORBs fail to address the complexities of managing a component in a high-volume, mission-critical environment, an area where TP monitors have always excelled.

Having realized that combining these two revolutionary technologies will do wonders for enterprises, companies like IBM and BEA started to design a hybrid of ORBs and TP monitor systems, which is referred to as component transaction monitors (CTMs) or application servers. These types of application servers combine the flexibility and accessibility of distributed object systems based on ORBs with the robust operating system of a TP monitor. CTMs provide a comprehensive environment for server-side components by managing concurrency, transactions, object distribution, load balancing, security and resource management automatically.

CTMs have started to come out of several different industries including the relational database industry, the application server industry, the web server industry, the CORBA ORB industry, and the TP monitor industry. Each vendor offers products that reflect their particular area of expertise. But a CTM that supports the Enterprise JavaBeans standard server-side component model from Sun Microsystems seems to be a more elegant and productive choice. There are a number of reasons for this fine architectural decision. Sun Microsystems has framed a number of excellent standard server-side specifications for several technologies and made the Java implementation an open standard quite successfully. The Java Database Connectivity API (JDBC) was one of the shining examples.

Consequently, a critical mass of enterprise computing vendors - developers of application servers, transaction process monitors, object request brokers, database management systems, and others - are rolling out precise, robust and powerful implementations of the EJB technology specifications. Component-based, multi-tier applications are the future of enterprise computing. EJB is poised to realize the benefits of these components: portability, scalability to a wide range of enterprise servers, simplified development, deployment, and maintenance. With this brief background information on EJBs, let us enter a very brief discussion on EJB's robust architecture.

Enterprise JavaBeans (EJB) is a comprehensive technology that provides the infrastructure for building enterprise-level server-side distributed Java components. The EJB technology provides a distributed component architecture that integrates several enterprise-level requirements such as distribution, transactions, security, messaging, persistence, and connectivity to mainframes and Enterprise Resource Planning (ERP) systems. When compared with other distributed component technologies such as Java RMI and CORBA, the EJB architecture hides most the underlying system-level semantics that are typical of distributed component applications, such as instance management, object pooling, multiple threading, and connection pooling. Secondly, unlike other component models, EJB technology provides us with different types of components for business logic, persistence, and enterprise messages.

Thus, an Enterprise Java Bean is a remote object with semantics specified for creation, invocation and deletion. The EJB container is assigned the system-level tasks mentioned above. What a web container does for Java servlets and JSPs in a web server, the EJB container is for EJBs.

Any distributed component technology should have the following requirements:

1. There should be a mechanism to create the client-side and server-side proxy objects. A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object. On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object

2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy.

3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client.

In order to meet these requirements, the EJB architecture specifies two kinds of interfaces for each bean. They are home interface and remote interface. These interfaces specify the bean contract to the clients. However, a bean developer need not provide implementation for these interfaces. The home interface will contain methods to be used for creating remote objects. The remote interface should include business methods that a bean is able to serve to clients. One can consider using the home interface to specify a remote object capable of creating objects conforming to the remote interface. That is, a home interface is analogous to a factory of remote objects. These are regular Java interfaces extending the javax.ejb.EJBHome and javax.ejb.EJBObject interfaces respectively.

As discussed below, the EJB architecture specifies three types of beans - session beans, entity beans, and message-driven beans. A bean developer has to specify the home and remote interfaces and also he has to implement one of these bean interfaces depending upon the type of the bean. For instance, for session beans, he has to implement the javax.ejb.SessionBean interface. The EJB architecture expects him to implement the methods specified in the bean interface and the methods specified in the home and remote interfaces. During the deployment time, he should specify the home and remote interfaces and bean implementation class to define a bean. The EJB container relies on specific method names and uses delegation for invoking methods on bean instances.

Thus regarding the first requirement, the EJB container generates the proxy objects for all beans. For the second one, the EJB container for each bean implement a proxy object to the home interface and publishes in the JNDI implementation of the J2EE platform. One can use JNDI to look for this and obtain a reference. As this object implements the home interface only, he can use one of the creation methods of the home object to get a proxy to the remote interface of the bean. When one invokes a creation method on the home proxy object, the container makes sure that a bean instance is created on the EJB container runtime and its proxy is returned to the client. Once the client gets hold of the proxy for the remote interface, it can directly access the services of the bean.

Finally, once the client decides to stop accessing the services of the bean, it can inform the EJB container by calling a remote method on the bean. This signals the EJB container to disassociate the bean instance from the proxy and that bean instance is ready to service any other clients.

The EJB architecture is based on the concept that in an enterprise computing system, database persistence-related logic should be independent of the business logic that relies on the data. This happens to be a very useful technique for separating business logic concerns from database concerns. This makes that business logic can deal with the business data without worrying about how the data is stored in a relational database.

Enterprise JavaBeans server-side components come in two fundamentally different types: entity beans and session beans.

Basically entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory. Thus entity beans model real-world objects. These objects are usually persistent records in some kind of database.

Session beans are for managing processes or tasks. A session bean is mainly for coordinating particular kinds of activities. That is, session beans are plain remote objects meant for abstracting business logic. The activity that a session bean represents is fundamentally transient. A session bean does not represent anything in a database, but it can access the database.

Thus an entity bean has persistent state whereas a session bean models interactions but does not have persistent state.

Session beans are transaction-aware. In a distributed component environment, managing transactions across several components mandates distributed transaction processing. The EJB architecture allows the container to manage transactions declaratively. This mechanism lets a bean developer to specify transactions across bean methods. Session beans are client-specific. That is, session bean instances on the server side are specific to the client that created them on the client side. This eliminates the need for the developer to deal with multiple threading and concurrency.

Unlike session beans, entity beans have a client-independent identity. This is because an entity bean encapsulates persistent data. The EJB architecture lets a developer to register a primary key class to encapsulate the minimal set of attributes required to represent the identity of an entity bean. Clients can use these primary key objects to accomplish the database operations, such as create, locate, or delete entity beans. Since entity beans represent persistent state, entity beans can be shared across different clients. Similar to session beans, entity beans are also transactional, except for the fact that bean instances are not allowed to programmatically control transactions.

These two types of beans are meant for synchronous invocation. That is, when a client invokes a method on one of the above types, the client thread will be blocked till the EJB container completes executing the method on the bean instance. Also these beans are unable to service the messages which comes asynchronously over a messaging service such as JMS. To overcome this deficiency, the EJB architecture has introduced a third type of bean called message-driven bean. A message-driven bean is a bean instance that can listen to messages from the JMS.

Unlike other types of beans, a message-driven bean is a local object without home and remote interfaces. In a J2EE platform, message-driven beans are registered against JMS destinations. When a JMS message receives a destination, the EJB container invokes the associated message-driven bean. Thus message-driven beans do not require home and remote interfaces as instances of these beans are created based on receipt of JMS messages. This is an asynchronous activity and does not involve clients directly. The main purpose of message-driven beans is to implement business logic in response to JMS messages. For instance, take a B2B e-commerce application receiving a purchase order via a JMS message as an XML document. On receipt of such a message in order to persist this data and perform any business logic, one can implement a message-driven bean and associate it with the corresponding JMS destination. Also these beans are completely decoupled from the clients that send messages.

Session Beans: Stateful and Stateless

Session beans can be either stateful or stateless. Stateful session beans maintain conversational state when used by a client. Conversational state is not written to a database but can store some state in private variables during one method call and a subsequent method call can rely on this state. Maintaining a conversational state allows a client to carry on a conversation with a bean. As each method on the bean is invoked, the state of the session bean may change and that change can affect subsequent method calls.

Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. One can specify whether a bean is stateful or not in the bean's deployment descriptor.

Entity Beans: Container and Bean Managed Persistence

An example entity bean in a B2B application is given as follows. A purchase order is a business identity and requires persistence store such as a relational database. The various purchase order attributes can be defined as the attributes of an entity bean. Since database operations involve create, update, load, delete, and find operations, the EJB architecture requires entity beans to implement these operations. Entity beans should implement the javax.ejb.EntityBean interface that specifies the load and delete operations among others. In addition, the bean developer should specify the appropriate create and find methods on the home interface, and provide their implementation in an entity bean.

There are two types of entity beans and they are distinguished by how they manage persistence. Container-managed beans have their persistence automatically managed by the EJB container. This is a more sophisticated approach and here the bean developer does not implement the persistence logic. The developer relies on the deployment descriptor to specify attributes whose persistence should be managed by the container. The container knows how a bean instance's fields map to the database and automatically takes care of inserting, updating, and deleting the data associated with entities in the database.

Beans using bean-managed persistence do all this work explicitly: the bean developer has to write the code to manipulate the database. The EJB container tells the bean instance when it is safe to insert, update, and delete its data from the database, but it provides no other help. The bean instance has to do the persistence work itself.

EJB Container: The environment that surrounds the beans on the EJB server is often referred to as the container. The container acts as an intermediary between the bean class and the EJB server. The container manages the EJB objects and EJB homes for a particular type of bean and helps these constructs to manage bean resources and apply the primary services relevant to distributed systems to bean instances at run time. An EJB server can have more than one container and each container in turn can accommodate more than one enterprise bean.

Remote Interface: This interface for an enterprise bean defines the enterprise bean's business methods that clients for this bean can access. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote.

Home interface: This interface defines the bean's life cycle methods such as creation of new beans, removal of beans, and locating beans. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote.

Bean Class: This class has to implement the bean's business methods in the remote interface apart from some other callback methods. An entity bean must implement javax.ejb.EntityBean and a session bean must implement javax.ejb.SessionBean. Both EntityBean and Session Bean extend javax.ejb.EnterpriseBean.

Primary Key: This is a very simple class that provides a reference into the database. This class has to implement java.io.Serializable. Only entity beans need a primary key.

Deployment Descriptors: Much of the information about how beans are managed at runtime is not supplied in the interfaces and classes mentioned above. There are some common primary services related with distributed systems apart from some specific services such as security, transactions, naming that are being handled automatically by EJB server. But still EJB server needs to know beforehand how to apply the primary services to each bean class at runtime. Deployment descriptors exactly do this all important task.

According to EJB 1.0 specifications, deployment descriptor (DD) had to be a serialized Java object and by EJB 1.1 version, it got changed to a XML file. This seems to be one of the biggest changes effected in EJB 1.1 as XML DDs are much easier to edit, even without special tools for editing XML files. Also an XML DD is simple enough that it is easy to create a descriptor using nothing more than a text editor such as vi, Notepad or Emacs.

JAR Files: Jar files are ZIP files that are used specifically for packaging Java classes that are ready to be used in some type of application. A Jar file containing one or more enterprise beans includes the bean classes, remote interfaces, home interfaces, and primary keys for each bean. It also contains one deployment descriptor.

Deployment is the process of reading the bean's JAR file, changing or adding properties to the deployment descriptor, mapping the bean to the database, defining access control in the security domain, and generating vendor-specific classes needed to support the bean in the EJB environment. Every EJB server product comes with its own deployment tools containing a graphical user interface and a set of command-line programs.

For clients like enterprise bean itself, Java RMI or CORBA client, to locate enterprise beans on the net, Java EJB specifications specify the clients to use Java Naming and Directory Interface (JNDI). JNDI is a standard Java extension that provides a uniform Application Programming Interface (API) for accessing a wide range of naming and directory services. The communication protocol may be Java RMI-IIOP or CORBA's IIOP

There are some special integrated application development tools such as Inprise's JBuilder, Sun's Forte and IBM's VisualAge, for designing EJBs in the market.