Chapter 9. Business Tier Interfaces

If you've been reading this book straight through, you've been subjected to discussions of the top and bottom of a Java enterprise application: the presentation tier and the domain model. However, we've mostly talked around the interface between the two. That's because it's hard to talk about interfaces without knowing what's being interfaced.

But here we are. Business tier interfaces connect the domain model with the client (in thick-client applications) or the server-side presentation layer (in web applications). They also implement some of the business logic for an application, controlling and limiting the actions that the presentation tier can perform on the domain model.

Integrating the client with the business logic for an application poses a few problems for the developer. The big one, of course, is organizational. If you've been doing use case-oriented design, you probably have a very good idea of the activities your users need to perform, and of the various business rules that will apply. But how do you represent these as Java objects? That's a hard question. It's equally difficult to decide where to put everything. EJBs? Client code? Database stored procedures? In Chapter 6, we introduced the ideas of process (or business) logic and domain logic. This split provides the basis for dividing logic between different components of the business tier: process logic for verbs (the transformations of the domain model), and domain logic for constraints on the nouns (the defined interrelations of the object model itself). In Chapter 8, we discussed methods for connecting the domain model and the database persistence layer, and for hiding the nature of the persistence layer from the implementation of the domain model.

Here's the wrinkle: even after several years of madly webizing every legacy application in sight, many enterprise development projects still aren't starting from scratch. Instead, many IT teams are still putting web interfaces on existing applications. Often these projects go a step further and try to create a Java-based path for future development. But this approach can be dangerous: attempting to fit a Java layer over domain models and business logic code designed for an earlier set of technologies risks warping the design into a hybrid monstrosity with one foot in each world.

In this situation, the business tier interface provides the gateway between the Java world and the legacy world. Constructing this gateway may mean the difference between evolving the Java component of the application for years, gradually upgrading or replacing the legacy components, and throwing the whole thing away when the legacy systems are phased out.

This chapter focuses on patterns for packaging and presenting the business logic of an application. The Business Delegate pattern and the Session Façade pattern address the organization of process logic and the division between the domain logic and the process logic. As an added bonus, both of these patterns provide performance enhancements in addition to their organizational benefits. We'll also discuss the Business Delegate Factory pattern, which allows us to build more effective non-EJB applications by creating our own versions of some of the services provided by a full application server.

We also cover two patterns for connecting to remote business services. The Service Adapter pattern, which is a variation on the original Gang of Four Adapter pattern, can be used to provide a useful Java-based interface to non-EJB business tier resources. The Service Locator pattern provides centralized management of connections to Enterprise JavaBeans and other remote resources.