Enterprise JavaBeans For Dummies Cheat Sheet - dummies
Cheat Sheet

Enterprise JavaBeans For Dummies Cheat Sheet

From Enterprise JavaBeans For Dummies

By Mac Rinehart

Enterprise JavaBeans (EJB) is object-oriented programming. EJB technology streamlines the development process and makes it easy to change and retrofit applications with new features as needed. Before you begin using Enterprise JavaBeans, it helps to understand some fundamentals about components, containers, and writing EJB code.

The Component Model of Enterprise JavaBeans

Enterprise JavaBeans (EJBs) are software components. A software component is a program that runs inside a container. (What’s a container? Read on!) The component provides some unique functionality that is specific to the application you develop, whether it’s a shopping cart for an online retailer or an account management service for a bank. The container provides your software components with system services. System services are generic services that any type of application can benefit from, such as security and transaction services. That means you can benefit from many very powerful system features in your software components without writing any code to create those features.

The EJBs you develop in your EJB application should provide services that are unique and special to the business problems your software needs to address. If your EJB components don’t address a unique problem, then you don’t necessarily need to develop them yourself; you can probably buy existing components that do the job.

Now for the catch. (You never get somethin’ for nothin’.) In the case of EJBs, in order to benefit from any container’s services, you — as the EJB developer — must adhere to a contract with the container. The container agrees to provide certain features to your EJBs according to a specified set of rules. In exchange, you must develop your EJBs to conform to a specified structure that the EJB container can understand.

Think of this component concept in the same way that you might think of your home entertainment system. You have the ability to choose between a variety of brands for its different components — you may get one brand of TV, another brand of Blu-ray player, and yet another brand of home theater/speaker system. You can plug them all together because each component adheres to a convention that requires consistent interfaces. Likewise, Enterprise JavaBeans can be added and removed from any EJB container because the EJB specification requires consistent interfaces between the container and the EJB component.

The following figure illustrates a simple view of the component model for Enterprise JavaBeans.


The component view of an EJB application.

The figure shows the following three key players in an EJB application:

  • The client is a software application that makes use of EJB components. The client can reside on the same computer as the EJB component, or it can reside on a remote computer. The client can also be virtually any type of application. You may have a JavaServer Pages (JSP) application as a client, or a desktop application residing on a user’s computer. The client may also be another Enterprise JavaBean.

  • The container is the host for EJB components. It provides a variety of system services to the EJB component so you don’t have to develop them yourself. When a client application — such as a JSP application — invokes a method on an EJB component, the call is passed through the EJB container first. The container performs these extra services and then passes the client’s call to the EJB component. Ultimately, the EJB component performs the operations requested by the client. This entire process is completely transparent to the client application; as far as the client is concerned, it thinks it’s talking directly to an EJB component.

  • The EJB component is a provider of business services or business data. Business services and business data are processes and information that you define and which are specific to the needs of your business. As an EJB component developer, your development responsibilities are two fold:

    • Your EJB components must implement the methods required by the EJB component architecture. These methods are collectively referred to as the application programming interface (API). The methods defined in the API allow the EJB container to provide system services to your EJB components. They also allow you to make requests to the container to perform certain actions, such as getting the identity of a user.

    • You must implement the business methods required for the application you’re developing. That allows the client to receive business services and business data from your EJB component. For example, if you’re developing a shopping cart application for your business, you’ll need to define methods to add items to the cart and remove items from the cart.

The Basics of Writing Enterprise JavaBean Code

An Enterprise JavaBean (EJB) is like a mini-program that confers some unique functionality to the application, or container, it runs in. Below are the fundamentals of writing EJP code.

Summary of frequently used EJB interfaces

The following table identifies the interfaces you need to implement for each type of Enterprise JavaBean (EJB) that you create.

Interface/Class Message-Driven Bean Session Bean Entity Bean
Remote interface None javax.ejb.EJBObject javax.ejb.EJBObject
Local interface None javax.ejb.EJBLocalObject javax.ejb.EJBLocalObject
Remote Home interface None javax.ejb.EJBHome javax.ejb.EJBHome
Local Home interface None javax.ejb.EJBLocalHome javax.ejb.EJBLocalHome
Bean class javax.ejb.MessageDrivenBean javax.ejb.SessionBean javax.ejb.EntityBean

The EJB 2.0 DOCTYPE tag

The following DOCTYPE tag must be included in all EJB 2.0 deployment descriptor files:

            "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"

Basic description of a session bean

The following block of XML contains a typical entry for describing a session bean in the EJB application’s deployment descriptor:

  <session-type>Stateless | Stateful</session-type>
  <transaction-type>Container | Bean</transaction-type>

For the <session-type> attribute the value can be either Stateless or Stateful. For the <transaction-type> attribute the value can be either Container or Bean.

Basic description of an entity bean

The following block of XML code is a typical description for an entity bean class in the EJB application’s deployment descriptor:

  <persistence-type>Container | Bean</persistence-type>

For the <persistence-type> attribute the value can be either Container or Bean.

Basic description of a message-driven bean

The following block of XML illustrates a typical description of a message-driven bean in the deployment descriptor:

  <transaction-type>Container | Bean</transaction-type>
    Auto-acknowledge | Dups-ok-acknowledge
    <destination-type>javax.jms.Queue | javax.jms.Topic
<!-- use the following only if destination type is Topic.→
      Durable | NonDurable

For the <transaction-type> attribute, the value can be either Container or Bean. For the <destination-type> attribute, the value can be either javax.jms.Queue or javax.jms.Topic. For the <subscription-durrability> attribute, the value can be either Durrable or NonDurable.

5 Responsibilities of the Enterprise JavaBean Container

The Enterprise JavaBeans (EJB) container is responsible for providing a number of services to your EJB programs. The services the EJB container must provide are enumerated by the Enterprise JavaBean Specification. That means that you can deploy your EJB to any specification-compliant container and receive the benefit of all the mandated services. Those services include the following key features:

  • EJB containers provide support for remote and local communication between your EJB components and client applications. This is accomplished in a manner that’s virtually transparent to you, so you don’t have to worry about how it’s implemented when you’re developing EJB components.

  • EJB containers provide pool and cache services to EJB components. A pool is a repository of unused EJB components that are supplied to a client on demand. A cache is a storage area for EJB components that are assigned to a client program, but not currently in use. These services minimize the memory requirements for the EJB container while providing high performance service to the client program.

  • EJB containers must provide security services for EJB programs. When you deploy an application you can configure these services according to guidelines laid out in the specification, but you don’t have to perform any special programming to utilize them.

  • EJB containers must provide transactional services for EJB programs. Transactions define units of work that must all succeed or all fail as a set. Transactions can contain many EJB programs, including EJB programs residing on remote computers. The transactional characteristics of an EJB container can be configured when your EJB application is deployed, but require little to no special programming from you as the EJB developer.

  • EJB containers provide transparent integration between your EJB components and external data sources such as databases. As a developer, you don’t have to manage storage and retrieval of data from a database, although you may choose to do so if it fits your needs.

The EJB container provides these and other features according to the rules that you define. This is referred to as declarative programming. Declarative programming is a mechanism that allows you to declare the services you want in an XML formatted document. This XML document is called the deployment descriptor, which is deployed with your EJB application. The server reads the deployment descriptor and automatically implements the services you request according to the rules that you declare. Thus, the complexity of implementing these services is completely hidden while you retain the ability to configure the EJB application to suit your needs.

While the EJB specification defines many of the options that you can modify in the deployment descriptor, it doesn’t prohibit EJB container vendors from creating their own custom deployment descriptors to extend existing configuration options or to add new options. All container vendors provide extensions to the deployment descriptor; they use these extensions to connect the generic EJB deployment descriptor to container-specific services. While these extensions are often essential, they’re not standard and not portable. EJB component developers are not responsible for working with container-specific extensions to the deployment descriptor. The service is generally reserved for someone who has specialized knowledge of administering the EJB container.