ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button O'Reilly Book Excerpts: Building Java Enterprise Applications, Vol I: Architecture

Business Logic, Part 1

Related Reading

Building Java Enterprise Applications
By Brett McLaughlin

by Brett McLaughlin

This excerpt is Chapter 8 from Building Java Enterprise Applications, Vol I: Architecture, published in March 2002 by O'Reilly.

You have now completed the data layer of your application, and are ready to dive into the business layer. If you recall from Chapter 2, the business layer incorporates your application's business logic. Specifically, you will need to provide access to your entity beans, business calculations, and a scheduling facility. In this chapter, I'll detail the access to entity beans already in place, and discuss how to handle more complex business tasks. Chapter 9 then details the scheduling process.

First, I'll discuss the façade pattern, in which you use session beans to access entity beans. This access method is used instead of allowing direct access to entity beans, and is key to a sound strategy in building enterprise applications. I'll also outline the problems and penalties associated with this approach, giving you the information you need to make good decisions in your own applications. This pattern goes hand in hand with the manager component discussed in Chapter 6 when working with directory servers. I'll illustrate the pattern with a simple example, an OfficeManager session bean.

From there, I'll move on to slightly more complex session beans. You'll see how a single session bean can perform operations on multiple beans and on other Java components. You'll build a UserManager component, which will administrate users, and will operate upon the User entity bean as well as the LDAPManager directory server component. This should give you an idea of how to handle these more complex tasks.

Finally, I'll spend some time detailing the difference between stateless and stateful beans, and demonstrate how stateful beans can generally be converted into simpler, more efficient stateless session beans. You'll also see how helper classes can make stateless beans appear as stateful ones, allowing your clients to get simple interfaces while your beans remain fast and lightweight. I'll explore these concepts in developing an AccountManager component for working with user accounts.

Before Going On

At this point, you need to make sure you have some components in place. In addition to the code covered in the first seven chapters, you also need to make sure that the other Forethought entity beans are in place and available for access. These beans are detailed in Appendix E. These should be deployed in your EJB container, as many will be referred to in this chapter. You can either type these beans in yourself, or download the source code from the book's web site, http://www.newInstance.com.

The Façade Pattern

I've already mentioned the façade pattern in several earlier chapters, but never truly delved into the pattern's details. It's appropriate to do that now, and see why an extra layer of abstraction is necessary. In practice, most developers instinctively know that they should use a layer of session beans that prevent direct entity bean access, but then convince themselves to abandon this approach because they cannot justify it. I'll try and provide you some justification for that decision here.

Data Schema Exposure

The most obvious rationale for using session beans to abstract entity beans is that the approach also abstracts the structure of your data stores. To understand this better, you may want to take a second look at the actual structure of the Forethought database schema, and the SQL used to create it. Figure 8-1 shows the Forethought OFFICES table to serve as an example.

Figure 1. The Forethought OFFICES table.

The presumption is that you do not want to expose the inner workings of your application's data store, or even the specifics of how that data is stored. In other words, letting users (also known as potential hackers) know your database schema is a bad idea. Problems in this area arise when allowing direct access to the entity bean layer. The methods in entity beans typically map directly to underlying fields in the data schema, as shown in Figure 8-2.

Figure 8-2. Mapping the Office entity bean to the OFFICES table.

As you can see, for each column in the OFFICES table, a corresponding method exists in the Office entity bean. The same, of course, occurs for the rest of the database schema.

It is trivial to examine entity beans and then extrapolate the data schema from them, which is precisely the situation you are trying to avoid in application design. This becomes a simple problem to overcome with the introduction of session beans that abstract these details. For example, consider an OfficeManager bean that provides methods to add, update, and delete Forethought offices. The remote interface for this bean is shown in Example 8-1.

Example 8-1: The OfficeManager Remote Interface

package com.forethought.ejb.office;

import java.rmi.RemoteException;
import javax.ejb.EJBObject;

public interface OfficeManager extends EJBObject {

    public OfficeInfo get(String city, String state) throws RemoteException;

    public OfficeInfo add(String city, String state) throws RemoteException;

    public void update(OfficeInfo officeInfo) throws RemoteException;

    public boolean delete(String city, String state) throws RemoteException;
    public boolean delete(OfficeInfo officeInfo) throws RemoteException;

This manages to hide some of the details of database schema implementation. While it might seem obvious to you that the OFFICES table contains a CITY and STATE text column, you are seeing through the eyes of someone who already knows the database schema. Figure 8-3 shows how this exact session bean might map to several different database implementations; therefore, it does hide the database schema by providing logical methods on entities, instead of physical methods.

Figure 8-3. Mapping the OfficeManager to different database schemas.

"Obfuscation" means "to make so confused or opaque as to be difficult to perceive or understand." It's often used to describe the process of scrambling bytecode so that it cannot be decompiled, and is used here to represent the same concept with respect to the database schema in use.

You can see that it's no longer obvious exactly how the database is laid out. Using session beans and the façade design pattern will aid in security by providing this layer of obfuscation over the data schema.

Finally, for those of you still unsure why this is worth going on about, let me explain why this obfuscation is so critical. Many of you are probably wondering why it is important to abstract your database schema from your presentation layer; wouldn't the developers and designers of one layer work with, or even be the same people as, the developers and designers of the other? That would seem to be the case, at least in many situations. In fact, you will code the Forethought application from front to back, so it might seem silly to go to this trouble.

However, as the era of service-based computing takes off, this process becomes vital. Instead of providing complete applications, the J2EE specification (as well as Microsoft's .NET platform, UDDI, SOAP, and other developments) indicates that organizations are focusing more on components than on complete applications. Interchanging data components from one application and company with presentation components from another application and company is becoming common and even standard. As a result, it is unsafe to assume that only you or your company's developers will be accessing your business layer and EJBs. You should assume that your EJB layer will be exposed to many others, some of whom you want to provide access but not application information to. For all of these reasons, a sound design of the business layer can save you some trouble, even make you a hero, when your pointy-haired boss insists that now the beans you worked on must be accessible by a new partner, but that the partner doesn't get database schema information. Suddenly, the work done on your session beans really begins to pay off!

Pages: 1, 2

Next Pagearrow