Enterprise JavaBeans

EJB, the widely-adopted server-side component architecture for JavaTM 2 Platform, Enterprise Edition (J2EE), enables rapid development of mission-critical application that are versatile, reusable and portable across middleware while protecting IT investment and preventing vendor lock-in.

Well, at least that is what the FAQ on Sun's site says. It is similar to CORBA in ways, but you can only use Java with it (CORBA tries to be language independent). EJB does have the advantage that an EJB container is easier to setup and use then a CORBA orb, but you lose some of the flexability.

Enterprise JavaBeans (EJB) is a Java technology introduced by Sun Microsystems for the development of distributed object-oriented applications.

EJB is named after Java's software component model, JavaBeans. JavaBeans is primarily (though not necessarily) a client-side technology which provides portable, self-contained, reusable Java components with common coding conventions for methods and interfaces.

EJBs provide the same benefits of components for development of distributed applications. The EJB specification describes a server-side component architecture for scalable, transaction-based database and e-commerce applications.

Even without EJB, Java can be used on the server through regular JavaBeans, Servlets and supporting technologies. EJBs add value by moving server-side systems away from a two-tier client-server model, to an n-tier architecture. The goals include scalability, reusability and robustness on the server.

Enterprise JavaBeans servers reduce the complexity of developing the middle tiers ("middleware") of a J2EE system by providing automatic support for services such as transactions, security, and database connectivity. The EJB container, typically purchased as part of a larger solution from an external vendor such as BEA, makes these services available to EJB components.

Application developers focus on business logic, not "glue". Application Server vendors and other third-party providers who implement the EJB containers worry about those services. As long as the application developers ensure their EJB components are compliant with the specification, their classes are automatically extended to include the various services.

EJB is not a stand-alone technology. Many other services and specifications support it, as outlined by some of the authors below.

Sun announced Enterprise JavaBeans in April 1997 and released the initial specification in March 1998. Sun released the updated EJB 2.0 specification in 2001, and J2EE vendors worked throughout 2001 and 2002 to make their systems fully compliant with the new specification.

Some food for thought:

  • The guts of the EJB server (beans, servlets, etc) have to be in Java, nothing earth shattering there. The fun starts with external access to EJBs. It is language agnostic, as long as they follow the interfaced required by the EJB. In the same vein as CORBA.

  • EJBs are very reusable, because one bean can be used across any EJB server. In theory at least. All EJB servers have to follow Sun's EJB architecture standards, but difference do exist. For example, authentication is handled differently from BEA's Weblogic and IBM's WebSpere
  • "You mean," I said, "that it takes five or six tries to get an idea right?"
    "Yes," he said, "at least that."
    "But," I replied, "you also said that if a newly introduced product doesn't catch on in the first two or three times, then it is dead?"
    "Yup," he said.
    "Then new products are almost guaranteed to fail, no matter how good the idea!"
    "Now you understand," said the designer.1

    Over the last 10 years, the software industry has sub-divided and attempted to standardize the interconnecting pieces that comprise client server computing. As the pieces evolve, they become more de-coupled from each other growing into independent, stand-alone objects with standardized interfaces. The goal is to develop independent objects that can dynamically communicate with any other object across the Internet. Many ideas have been proposed for an object-oriented Internet. Currently there are three leading contenders. They are Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), and Enterprise JavaBeans (EJB).

    This node describes the EJB design for an object-oriented Internet using client/server technology. Enterprise JavaBeans provides a framework for extending sever-side functionality by separating and encapsulating business-logic from the system level services.

    I. Description of EJB

    Enterprise JavaBeans is an evolutionary step combining client/server, distributed computing, and objects into a framework to ease the development of large business applications. In earlier technology the programmer had to know about the internal implementations of various parts of the client/server architecture in order to develop an application. EJB allows for greater encapsulation and specialization of the components of client/server computing.

    EJB provides a framework for developing runtime extensions to server functionality by encapsulating business-logic in stand-alone objects. The objects can then be configured at runtime to meet specific application needs. In addition, the specification separates out the low-level, system activity into a standard set of services so developers do not have to re-invent the wheel every time they write an application. The system services are encapsulated with a standard interface and placed in the middleware.

    There are two goals EJB seeks to achieve. The first is to make developing distributed client/server applications easier by separating system services from the application business-logic. The second is to enhance the move of business-logic processing to the server from the client machine. The business-logic functions can be run on the server more efficiently and thus avoid a slow downloading process if sent to the client over the network.

    II. The Architecture of EJB

    There are three basic parts of the EJB architecture. They are the EJB Component, the EJB Container, and the EJB Object. An Enterprise JavaBean is a component, written in Java, that encapsulates business-logic. The component executes within an EJB Container that resides on the server. The client communicates with the EJB Component using the EJB Object. The latter is a "remote interface" that is downloaded to the client. It then handles the communication between the client and the EJB Container.

    A. EJB Component
    The EJB Component is implemented as one of two different models. The first model is called a Session Bean. It is a model of a transient communication between the client and the server. There is no persistence beyond the duration of the interaction. Nothing is stored for later use about the interaction even though a session bean may provide database transaction services to the client.

    The second model of an EJB component is an Entity Bean. The entity bean represents data in a database along with the methods to process that data. An entity bean is long-lived. It has persistence because its state is stored in a database and is obtainable in a later client - server transaction.

    B. EJB Container
    The EJB Container manages EJB Components. It is loaded and run on the server. The EJB Container will in turn handle the object life cycle of the EJB Components for which it is responsible. The container provides all the system services to the component so the latter may focus on just the business-logic of the application. The services include transaction and resource management, versioning, scalability, persistence, and security to name a few.

    C. EJB Object
    The EJB Object is downloaded to the client during the initialization of an interaction between the client and server. The EJB Object provides a set of method calls to the business logic of the EJB Container and Component. The communication between the client and the EJB Component appears seamless to the client because it only needs to invoke the appropriate methods available in the EJB Object. The EJB Object handles all the system level communication over the network to the EJB Container, which in turn communicates with the EJB Component.

    III. Outline of Runtime EJB Activity

    1. Client uses the Java Naming and Directory Interface (JNDI) to locate the Home-Interface for the EJB Component class it wants.
    2. Client calls one of the create() methods to create the server-side object.
    3. The client-side Home-Interface makes a remote call to the EJB Container on the server.
    4. The EJB Container creates the EJB Component, either a Session Bean or an Entity Bean. The EJB Component will reside on the server. Then the EJB Container creates and returns to the client an EJB Object.
    5. The Client now interacts with the EJB Object and thereby with the server-side bean to complete a set of business services.
    6. When finished, the Client will request the EJB Container shut down the EJB Component. The EJB Component will be inactivated or destroyed, resources will be released, and then finally the EJB Object, on the client-side, will be garbage-collected.

    1. Donald A. Norman, The Design of Everyday Things (New York, NY: Doubleday, 1988) page 29.

    Johnson, Mark, "A Beginners Guide to Enterprise JavaBeans", Java World, October: 1998, www.javaworld.com
    Norman, Donald A., The Design of Everyday Things, New York: Doubleday, 1988.
    Nova Laboratories, "The Developers Guide to Understanding Enterprise JavaBeans Applications", Bordentwon, NJ, 2000. www.nova-labs.com
    Orfali, R., and D. Harkney, Client/Server Programming with Java and CORBA, 2nd ed., New York: John Wiley, 1998.
    Orfali, R., D. Harkney, and J. Edwards, Client/Server Survival Guide, 3rd ed., New York: John Wiley, 1999.
    Roth, Bill, "An Introduction to Enterprise JavaBeans Technology", Sun Microsystems, Inc., 2000, Developer.java.sun.com
    Sun Microsystems, Inc., "Enterprise JavaBeans Technology", 2000, Java.sun.com/products/ejb
    Thomas, Anne, "Enterprise JavaBeans Technology: Server Component Model for the Java Platform", Boston: Patricia Seybold Group White Paper, 1998.

    Log in or register to write something here or to contact authors.