Simon Brown, April 2003
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.
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.
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?
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.
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.
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.
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.
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.