JavaBeans and Object-Oriented Design
Virtually every Java developer is familiar with the JavaBean specification. One of the most important parts of this specification is the use of certain predictable method signatures to control properties of the bean (e.g. the “getXXX” and setXXX” methods we all know and love). JavaBeans are of course a specific instance of the general object-oriented method that is a foundation of any well-structured Java application. Objects are, in theory, a combination of data and functionality (methods to operate on the data) into single units. Object are grouped into packages, and packages into applications. In the real world, however, most of us have found that it’s not quite that simple. We often find some objects (or classes, more specifically) are designed to model data, whereas other classes are oriented more towards operations. Often, the classes for operations utilize the data-oriented classes. An example of this design pattern can be seen in the difference between Session Beans in the EJB specification and Entity Beans. In general, Entity beans model data, with their properties being stored in some form of data storage, often a database. Session beans embody functionality, and usually depend on one or more Entity beans to do their jobs. This somewhat contradicts the basic object-oriented principal that says objects combine data and operations, but it does make practical sense in most applications.
Application Logic and Flow Control
Given that a separation, to some extent, of application logic and the data on which it operates is practical, we then can look for the right place in our application for flow control to reside. Flow control within a component is of course handled by the logic statements of the methods themselves, with logic statements such as if, while, for, and exceptions being key tools for crafting the intra-component flow. The overall application flow, however, is at a different level. This is sometimes called application navigation, and particularly for Web applications can present a different set of challenges.
Ideally, we want to maximize the reusability of our application logic components (and the data components they depend on). We would strive, therefore, to keep the details of application navigation out of our application logic as well, so that our logic components can easily be re-used in another application. So if we have, for instance, a component that deletes a customer and related data, we would not include in that component the logic to present the menu of choices available after deleting a customer, as these might well be different in some circumstances than in others.
Application flow control or navigation can be expressed in one of several ways, most of which might be familiar to those who have been working with Java for a long time, before widespread availability of tools that made the more advanced techniques easy.
Most Web applications today assume at least a basic separation of business logic components and user interface. Struts, for example, provides a simple means to associate its business logic classes (Actions) with JSP pages that handle the actual display to the user.
All-in-One Method
Simple servlet (and in many cases, desktop) applications simply bundle everything related to one business logic step into a single class. This class makes direct JDBC calls, and prepares the UI directly, including any necessary navigation links, menus, and so forth. If this class needs to “chain” to another, it simply calls the next class in turn directly, until it is ready to return control to the user for further input or selection of the next step.
This approach has the advantage of being straightforward at least, but lacks flexibility to say the least. Maintainability of an application using this technique can be tedious, as the interdependencies are not clear, being buried in the code of each application logic class.
To use a concrete example, this would be the equivalent of a servlet-based Web application where every new operation was a separate servlet. Within the servlet, JDBC connections would be established and SQL statements executed to access a database, and the servlet would contain logic that “routes” the application flow on to the next step (or presents the user with appropriate options, such as buttons to move on to the applicable next step).
Separate Out the Persistent Classes
A more sophisticated approach introduces some kind of database-access layer, often an object-relational mapping layer such as a JDO implementation, Hibernate, Torque, or one of the other many frameworks available to provide this capability. Now, the business logic calls and uses persistent classes and relies on external management of the database connection—often driven by a configuration file that defines the mapping between Java classes and underlying database tables. The persistent classes (the properties of which are stored in and read from the database) often follow the JavaBean pattern in part: getter and setter methods being used to access properties, often with some validation built into the persistent class. A great many current applications exist in this category, still embedding the navigation and application flow in the logic.
In our example above, this would mean removing the JDBC from the individual servlets, and accessing JavaBean classes for persistent object access. The Navigation would remain the same.
External Application Flow Control
The next step beyond separation of persistence and business logic can be the separation of the application control flow. Business logic classes in this case are written in such a way that they are unaware of how they were called, or what business logic element will be called next. They still require certain inputs, of course, and produce results in some fashion (again, often using the bean pattern to allow result properties to be accessed), but they are a single link in a chain. Some external mechanism is used to control application flow, either another class, or a driver class that reads the sequencing and navigation information from configuration.
Our example now would probably have an external configuration file that defined the application flow, specifying which servlets are called in what order, and what options are available to the user at each step of the way.
The advantage now is that reconfiguring the application for different purposes is straightforward: The flow control is in one place (the configuration file), and steps can be re-arranged simply by changing this file. We have also increased the reusability of our application logic classes considerably, as they no longer need to be concerned with how they were called—the same logic class can be used in many different sequences and applications.
If we take this concept a bit further, and allow the configuration to also specify sequences of application logic classes, we find a bit more flexibility. For example, let’s say we have a business logic class that displays the current company and logged-in user. By itself, not very useful. If we have a way, however, to chain together sequences of application logic classes, and combine their results into a single page to the user, we can use such a simple class over and over. Rather than having each application logic class concern itself with calling some utility method to ensure the company and login info is available to the UI, we simply chain together the two classes via configuration. The same is true of more complex business logic: If we always want to perform a credit check before presenting the loan form in a banking application, for example, we can chain those two classes in sequence, again using configuration only, for the desired effect. The credit check could also be used in many other sequences, promoting re-use at a level not previously possible, and all without code alterations.
Long-time users of Unix-style operating systems will be familiar with the pattern described here, as it is a lot like the Unix command philosophy: Keep each command simple, make it do one thing and do it well, and provide a powerful means to assemble multiple commands into complex applications. In the Unix world, this is achieved by shell scripts and the pipeline technique. The same ideas can be applied to Java applications, with similar powerful results.
Workflow
Many developers, of course, will recognize this technique as the beginnings of a full workflow pattern, where application logic steps can be combined in sequences or “flows” as required, and where the decisions at each step as to what the next step should be (or what the choices for next steps are, if there are several), are in fact left up to the workflow engine, driven by a sophisticated configuration file. This configuration file can even in many cases be created graphically, allowing a developer to literally draw the sequence of operations of the application required, drawing more and more from a pool of re-usable business logic components, and inventing each individual wheel only once, instead of repeatedly.
If it is possible to encapsulate the necessary business logic in a threadsafe class (that is, one with no instance variables, able to be executed by many threads at once without producing inconsistent results), then we can reduce the overall instance count in a running application considerably, reducing memory usage by a factor proportional to the number of concurrent users.
Combining all of these techniques into a single methodology, and using these processes to enhance the well-accepted Model/View/Controller structure of a modern Web application is the goal of a number of projects. One example is the open-source Keel meta-framework. Keel calls the individual application logic classes “Models,” as in MVC. Models are, as often as possible, written to be threadsafe, and may be combined into sequences or even sophisticated workflows entirely by configuration, maximizing reuse and simplifying maintainability considerably.
About the Author
Michael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at mnash@jglobal.com.
