Introduction

My previous two articles in this series have provided a general overview of the Java 2 Platform, Enterprise Edition (J2EE) and a more detailed look at the technologies contained within the web-tier of the J2EE platform. Using these technologies allows us to build scalable web-based interfaces for our applications but one question still remains. Where should the business logic reside? This is the subject of this article.

What is business logic?

Business logic is an often overused term that can be used to describe many things and the definitions are typically very verbose. However, a general definition is that business logic is logic that is related to and can be described in terms of the domain in which the application is operating. Of course, this is a rather idealistic definition, but essentially what this says is that business logic is related to the information being manipulated within the application rather than, for example, the logic associated with any of the external interfaces such as the user, the database, etc.

As an example, consider an e-commerce site such as Amazon. The domain in which the site operates is the online sale of products such as books, CDs, DVDs, and so on, while the business domain includes concepts such as products, customers, addresses, etc. Here, business logic might involve the process of a customer buying a product, applying discount rules and so on.

How and where is business logic implemented?

Before the introduction of J2EE and, specifically, Enterprise JavaBeans, business logic was implemented in several ways. The first of these was that business logic was embedded within the user interface code, alongside any logic required to present information to the user. While this worked and still works, it does lead to systems that are fragile when it comes to modifying the way that the system works. Also, changes to the user interface code can easily affect the way that the system behaves. At the other end of the architecture, business logic is often tied to the database being used, perhaps being implemented within stored procedures or triggers. Wherever it is located, mixing business logic with application specific code is not good for aspects such as reusability and maintainability.

A natural progression from here is to encapsulate business logic inside reusable classes or components. With Java, a possibility is to build JavaBeans - reusable software components that can run within any Java virtual machine. The benefit that this provides over embedding business logic alongside the application specific code is that the application is much easier to maintain. Any changes to the business processes realized by the system are easy to find and easy to change. In addition to this, business logic is now reusable both within the application and within other applications that operate within the same business domain. In other words, more than a single development team within the same company or business area can take the same code to reuse in their application. However, with the introduction of J2EE, a new mechanism for wrapping up business logic is available - Enterprise JavaBeans.

What are Enterprise JavaBeans?

Enterprise JavaBeans (EJBs) are reusable, serverside components that are designed to be executed within a J2EE application server. Unlike classes that you instantiate to use, EJBs are remote components that live inside the application server.

There are three flavours of EJB – session, entity and message-driven beans. As we saw in my first article, session beans are used to wrap up business logic, entity beans are used to represent persistent information and message-driven beans are used to provide an asynchronous interface into the functionality provided by an application. From the various flavours of EJB, we can see that session beans are suited to encapsulating business logic but why is this so?

Wrapping up business logic in Enterprise JavaBeans

Essentially, session beans are simply reusable components that can be used to contain logic rather than data. Of course, this doesn't mean that session beans can't contain data, it's just that the usage pattern associated with session beans is that an instance is obtained and methods are invoked. This is similar to the way in which JavaBeans are used. You create a new instance and then invoke its methods.

What makes EJBs different from regular JavaBeans?

This is one of those questions that keep coming up time and time again. After all, both JavaBeans and Enterprise JavaBeans are reusable software components that can be used to wrap up data and any code that operates on that data. However, the key difference is that EJBs are an enterprise, serverside technology.

Okay, because regular JavaBeans are written in Java, they can be and are used on the server and within J2EE application servers. After all, JavaBeans can be used anywhere there is Java. But, with JavaBeans, you have to create a new instance before using it. Enterprise JavaBeans on the other hand are components that live inside the application server meaning that you can't just instantiate them to use them. Instead, you must look up a reference to an EJB through a directory service called the Java Naming and Directory Interface (JNDI) that gives you a reference to a live component running inside the server.

What benefits do EJB provide?

Since EJBs are remote components, there are several characteristics that can be beneficial, depending on the circumstances and the application being developed. First of all, EJB makes it easy to build distributed, component-based systems. This means that any code written inside EJB will be executed on the server rather than on the calling client, taking advantage of the power that is available on the server. In addition to this, having a central place for executing business logic again improves the reusability and maintainability of that logic. In any organization, there may be many applications that provide implementations of the processes operated by the business. Adopting EJB means that each application can simply make use of that centralized business logic. Now you have the ability to reuse deployed components rather than just reusing code.

From a more technical perspective, EJB provides an architecture from which to help build scalable applications. Although you write your business logic as usual, at runtime the J2EE application server can choose to provide a pool of EJB instances to service incoming requests rather than a single instance. Also, EJBs can be clustered across multiple J2EE application servers for truly a truly distributed and failsafe deployment.

Finally, another important benefit is that of transactions. Transactions are an integral part of most business systems and the ability to mark a batch of work to be a transaction is vitally important for the integrity of business data. These ensure that all of the work is done and committed or it is not done and the transaction is rolled back. Encapsulating business logic inside EJBs makes it very easy to provide visible transaction boundaries, allowing complex business processes to be implemented correctly.

Are there any disadvantages to using EJB?

With every benefit there is a disadvantage. We've already said that EJBs are remote components that live inside a J2EE application server and this itself can be seen as a disadvantage. Traditionally J2EE application servers were complex and expensive, although with open source efforts such as JBoss and the commoditization of the application server market, this is not seen as such a big issue anymore. However, the lifecycle of EJB instances is managed by the application server and therefore there is always going to be a slight overhead to account for this. However, for this overhead you do get free transaction management, failover, pooling, clustering and so on.

Are EJBs complicated to build?

To be honest, I've never found the Java code for EJBs to be complicated to write. What I, and many people, do have a problem with are the deployment descriptors for EJBs. These are just XML files that describe the way in which that EJB component is deployed and how it operates when running inside the J2EE application server. Admittedly, it's not a very complicated process, but it's very easy to make errors and the deployment descriptors themselves can become quite large and unwieldy.

For this reason, there are now many tools available (open source and commercial) to help with building EJBs. For example, many integrated development environments (IDEs) such as IntelliJ and JBuilder provide support for EJBs in the form of wizards and EJB specific help. Also, other tools such as XDoclet allow you to define some of the deployment characteristics inside the Java code and the XML deployment descriptors are then automatically generated for you.

When should I use EJBs?

This is another one of those frequently asked questions and unfortunately there is no right or wrong answer. There are, however, some guidelines that are generally considered best practice around the usage of EJBs.

Probably the most important, technical, deciding factory is your deployment environment and whether you can actually use EJB. For example, if your hosting environment only supports J2EE web technologies such as JSPs and servlets, then using EJB is probably a bad idea. Second, although probably not that important is whether your team has experience in building EJBs as there is a slight learning curve involved with the process around building and using them.

What many decisions about whether to use EJB come down to are based around the size and complexity of the application you are building. EJB is seen as a fairly heavyweight technology in terms of processing power required to run EJBs and the development effort involved. Actually, this isn't strictly true because EJBs really aren't that heavyweight. However, they are in relation to building the same logic inside plain old Java objects (POJOs) such as JavaBeans. This is the point at which many people ask themselves whether they actually do need EJB.

What you need to do here is ask yourself a few questions. Apart from getting real world experience with EJB, what benefit does adopting it give you? Will you be able to take advantage of the facilities provided by EJB such as transaction support, failover, clustering, etc? Are your EJBs likely to be used by other clients? Are you likely to be able to take advantage of any of these benefits further down the line?

Many small systems simply don't need the added complexity of EJB, including for example, many web-based data entry applications. In fact, many high traffic web-based applications don't need the added complexity of EJB. Where EJB provides benefits are for high volume, transactional systems and those systems where you really do need to take advantage of distributed processing such as where you have clients installed across an enterprise. Using EJB to represent your business logic is often a tough decision to take, but hopefully this article has given you some insight into the type of questions that you should be asking yourself before adopting it.

Summary

In this article we've looked at what business logic is and how it can be wrapped up within reusable components when building J2EE applications. Depending on the size and complexity of your application, only you can decide whether the additional, overhead of building and deploying EJBs is right for you, taking into account the potential benefits of greater reusability and maintainability of your mission critical business logic.

Now that we understand a little more on how to write the business, next time we'll take a look at how information within a J2EE application is persisted with entity beans.