The J2EE platform includes a specification for a distributed component model known as Enterprise JavaBeans (EJB). If you’ve worked with Java for a while, you probably have a basic understanding of EJB and its relationship with business logic. In this article, we’ll dig a little deeper and see how EJB can be used to encapsulate business logic while interacting with other resources. For some background information on how to build business logic components with EJB, see my previous article. You can download the sample code for this article here.

The sphere of tiers
Our investigation into middleware concepts begins by proposing an architecture consisting of one client tier and three server tiers. Our three server tiers are broken down as follows:

  • ·        Presentation tier—Responsible for fielding client requests, distributing those requests to business logic components, and then formatting a response to be passed back to the client
  • ·        Business tier—Responsible for accepting service requests from the presentation tier, accessing data resources and other enterprise systems, and returning result data to the presentation tier
  • ·        Data tier—Point of access for data resources and external enterprise systems

We use JavaBeans as data objects to pass back and forth between the server tiers. Figure A illustrates these concepts and components.

Figure A

Component model and EJB
A software component has a number of identifying characteristics:

  • ·        Autonomous—A software component should be able to perform its work independent of other components or applications.
  • ·        Dynamically discoverable—Although a software component may not need to be discovered dynamically in a desktop environment, it is almost always preferable in a distributed system environment.
  • ·        Business process—A software component should define a logical business process.
  • ·        Consisting of externally published interfaces—A software component should expose one or more interfaces, providing external access to the component’s functionality.
  • ·        Usable for building other components or applications—A software component’s primary job is to enable developers to build other components or applications by combining one or more components with custom application or system code.

To illustrate how components are used to build a more complex entity, we can compare a software component to a car part, where each car part (component) has a specific purpose (process). As long as a part has the correct wires and bolt holes (interfaces), it can be used in the assembly of a complete car (other components or applications).

EJB as business-logic components
The EJB component model conforms to most of the characteristics that we specified for software components:

  • ·        Autonomous—An EJB can perform its work independent of most other components or applications. However, an EJB must be executed inside of an EJB container.
  • ·        Dynamically-discoverable—EJB uses JNDI for locating home interfaces, business methods, and metadata.
  • ·        Business process—EJB components are encapsulated business processes by definition.
  • ·        Consist of externally published interfaces—EJB uses Java interfaces to specify its business methods.
  • ·        Usable for building other components or applications—As with basic software components, EJB can be aggregated to form more complex functionality.

The EJB component model also adds a number of important component-model features that make it even more appealing as a middleware component, such as transactions, security, and database connectivity.

Transaction points and data access points often surface around business logic components in a distributed system. These aspects make EJB a good technology to use for middleware business-logic components.

EJB and the mojo of POJO
EJB has traditionally been called upon when access to business logic was spread across physical boundaries or across JVM boundaries and remote procedure calls made sense. However, since the introduction of local interfaces to the EJB specification, EJB offers a convenient way to expose business logic to objects and components residing on the same physical tier and within the same JVM.

The flexibility of accessing an EJB component using a remote or local interface opens up a number of architectural possibilities. For example, depending upon our business needs, we can call EJB remotely from the presentation tier or locally from other plain-old Java objects (POJO) on the business tier, as Figure B illustrates.

Figure B

The flexibility of EJB access enables you to employ the composition principles to build logical components out of multiple JavaBeans and one or more POJO. Let’s take a look at a simple EJB app that exposes a user account with one business method. The remote interface of the account JavaBean might look something like Listing A. The business-logic class would then look like Listing B. Finally, the client code might look like Listing C.

Imagine now that you want to expose multiple accounts to the presentation tier as one global account. Assuming that you have created EJB for each account, you could use the POJO in Listing D to instantiate each account EJB and present them as one logical account.

We’ve seen how JavaBeans can be used to build middle-tier business logic and how the EJB component model adds a number of important features for distributed component systems. Our next article will look at how EJB can be used to interact with other objects. We will also look at more sample code for creating JavaBeans and for accessing their business methods.