An introduction to EJB development

The "Enterprise JavaBeans (EJB) 1.1 specification" formally defines a Java server-side component model and a programming interface for application servers. Developers build the components, called enterprise beans, to contain the business logic of the enterprise. Enterprise beans run on an EJB server that provides services such as transaction management and security to the beans. Developers don't have to worry about programming these low-level and complex services, but can focus on encapsulating the business rules of an organization or system within the beans, knowing that the services are available to the beans when they are needed.

While the Enterprise JavaBeans specification is the ultimate authority on the EJB framework, it's primarily useful to vendors such as Inprise who build the EJB servers and containers the beans run in. This book will help you, the JBuilder developer, learn what you want to know about developing enterprise beans and creating applications that use them.

If you are already familiar with EJB development and want to get started creating enterprise beans with JBuilder, start with "Developing enterprise beans with JBuilder".


Why we need Enterprise JavaBeans

The client-server model of application development has enjoyed considerable popularity. The client application resides on a local machine and accesses the data in a data store such as a relational database management system (RDMS). This model works well as long as the system has only a few users. As more and more users need access to the data, these applications don't scale well to meet the demands. Because the client contains the logic, it must be installed on each machine. Management becomes increasingly difficult.

Gradually the benefits of dividing applications into more than the two tiers of the client-server model becomes apparent. In a multi-tier application, only the user interface stays on local machines while the logic of the application runs in the middle tier on a server. The final tier is still the stored data. When the logic of an application needs updating, changes are made to the software of the middle tier on the server, greatly simplifying the management of updates.

But creating reliable, secure, and easily managed distributed applications is notoriously difficult. For example, managing transactions over a distributed system is a major task. Fortunately using components that follow the EJB specification to build distributed systems relieves much of the burden by:


Roles in the development of an EJB application

The work of developing an EJB distributed application is divided into six distinct roles. Each role is assumed by an expert in their domain. By dividing the work this way, the task of creating and managing a distributed system becomes much easier.

Application roles

Those who assume the application roles write the code for the enterprise beans and the applications that use them. Both roles require an understanding of how the business runs, although at different levels. These are the two application roles:

JBuilder users who are interested in Enterprise JavaBeans are usually bean providers and application assemblers. Therefore, this book is written primarily for them. JBuilder has wizards, designers, and other tools that simplify the development of enterprise beans and the applications that use them.

Infrastructure roles

Without a supporting infrastructure, the enterprise beans and the applications that use them cannot run. Although the two infrastructure roles are distinct, they are almost always assumed by the same vendor. Together they provide system-level services to the enterprise beans and provide an environment in which to run. These are the two infrastructure roles:

In almost all cases, the EJB server provider and the EJB container provider are the same vendor. The Inprise Application Server provides both the server and the container.

Deployment and operation roles

The final steps in the development of an EJB distributed application are to deploy the application and to monitor enterprise computing and network infrastructure as it runs. These are the deployment and operation roles:


EJB architecture

Multi-tier distributed applications often consist of a client that runs on a local machine, a middle-tier that runs on a server that contains the business logic, and a backend-tier consisting of an enterprise information system (EIS). An EIS can be a relational database system, an ERP system, a legacy application, or any data store that holds the data that needs to be accessed. This figure shows a typical EJB multi-tier distributed system with three tiers:

Because our interest is how to develop enterprise beans, our focus is the middle tier.

The EJB server

The EJB server provides system services to enterprise beans and manages the containers in which the beans run. It must make available a JNDI-accessible naming service and a transaction service. Frequently an EJB server provides additional features that distinguish it from its competitors. The Inprise Application Server is an example of an EJB server.

The EJB container

A container is a runtime system for one or more enterprise beans. It provides the communication between the beans and the EJB server. It provides transaction, security, and network distribution management. A container is both code and a tool that generates code specific for a particular enterprise bean. A container also provides tools for the deployment of an enterprise bean, and a means for the container to monitor and manage the application.

The EJB server and EJB container together provide the environment for the bean to run in. The container provides management services to one or more beans. The server provides services to the bean, but the container interacts on behalf of the beans to obtain those services.

Although it is a vital part of the Enterprise JavaBeans architecture, enterprise bean developers and application assemblers don't have to think about the container. It remains a behind-the-scenes player in an EJB distributed system. Therefore, this book goes no further explaining what a container is and how it works. For more information about containers, refer to the "Enterprise JavaBeans 1.1 Specification" itself. For specific information about the Inprise EJB container, see the Inprise Application Server's Enterprise JavaBeans Programmer's Guide.

How an enterprise bean works

The bean developer must create these interfaces and classes:

Once the bean is deployed in the EJB container, the client calls the create() method defined in the home interface to instantiate the bean. The home interface isn't implemented in the bean itself, but by the container. Other methods declared in the home interface permit the client to locate an instance of a bean and to remove a bean instance when it is no longer needed. The EJB architecture diagram omits the home object.

When the enterprise bean is instantiated, the client can call the business methods within the bean. The client never calls a method in the bean instance directly, however. The methods available to the client are defined in the remote interface of the bean, and the remote interface is implemented by the container. When the client calls a method, the container receives the request and delegates it to the bean instance.

Types of enterprise beans

An enterprise bean can be a session bean or an entity bean.

Session beans

An enterprise session bean executes on behalf of a single client. In a sense, the session bean represents the client in the EJB server.

Session beans can maintain the client's state, which means they can retain information for the client. The classic example where a session bean might be used is a shopping cart for an individual shopping at an online store on the web. As the shopper selects items to put in the "cart," the session bean retains a list of the selected items.

Session beans can be short-lived. Usually when the client ends the session, the bean is removed by the client.

Session beans can be either stateful or stateless. Stateless beans don't maintain state for a particular client. Because they don't maintain state, stateless beans can be used to support multiple clients.

Entity beans

An entity bean provides an object view of data in a database. Usually the bean represents rows in a set of relational database tables. An entity bean usually serves more than one client.

Unlike session beans, entity beans are considered to be long-lived. They maintain a persistent state, living as long as the data remains in the database, rather than as long as a particular client needs it.

The container can manage the bean's persistence, or the bean can manage it itself. If the persistence is bean-managed, the bean developer must write code that includes calls to the database.