Traditionally, any piece of software that exposes fundamental functionality of a company has been referred to as business logic. You might define the term further as the code that implements standard services or business rules of an application for a company. Business logic is usually associated with the middle tier of an n-tier system. In other words, business logic occupies the logical area between the presentation tier and the data access tier, as shown in Figure A.
Business logic components or services typically respond to requests from the presentation tier, interact with the data tier to query results from a particular resource, and return the results to the presentation tier. Business logic components should try to remain impartial with respect to particular clients. This allows them to present functionality in a client-independent manner. In a moment, we’ll see how JavaBeans helps you accomplish this. First, however, we need to consider what a software component is and how it differs from an object.
A case for components
A software component can be defined as an implementation of an autonomous, dynamically discoverable business process consisting of externally published interfaces, which can be used to build other components or applications. This mouthful of techno-garble might be more easily swallowed if we mix it with a spoonful of sugar. Think of a software component in the same way you would a car part: Each part (component) has a specific purpose (process), and as long as a part has the correct wires and bolt holes (interfaces), it can be used in the assembly of a complete car (other components or applications).
Maybe an example will help illustrate our point. Let’s suppose that a humble software company had a collection of software technologies: a spreadsheet, a text editor, a graphics drawing tool, and a spell checker. Now, let’s say that each of these technologies had public interfaces that allowed them to be used by other software components or applications. If you use your imagination, it’s not too much of a stretch to see how these technologies could be combined to form a useful software application—maybe a word processor.
You might be saying to yourself, “What is the difference between a component and an object or, for that matter, a simple library of code?” Good question. Let’s examine the differences.
Libraries, components, and objects
A simple library of code might be provided as a logical group of function calls that are packaged as OS-dependent machine code in a linkable file. In Java, this might take the form of a group of static methods packaged in a JAR file. Since these function calls or static methods know nothing of the environment they’re to exist in, they typically do not maintain any state about the client code that calls them. For example, a library of code in Java, packaged as a group of static methods, might look like Listing A.
An object will encapsulate state and functionality about a logical entity. One or more clients might share an object. An object will typically expose some of its state data as well as appropriate operations. For instance, a Java object representing a person might be written like Listing B.
Notice how the Person class exposes state data (name and age) as well as an operation (toString). This is all quite elementary. So what is this ruckus about components?
Software components take the concept of objects a few steps further. As with objects, software components encapsulate state and operations for logical entities, but a software component adds the concept of dynamically discoverable interfaces, properties, and operations. Typical component models also add the concept of events to an object. Let’s look at how we might extend and enhance our Person class to become a component, as shown in Listing C.
The Administrator class has extended our Person class to add two new data values or properties, rights and department. The Administrator class exposes operations that change the rights and department properties. It has also added operations to change the name and age properties of the parent class, Person. The Administrator class adds event functionality so that an interested client can register itself as a listener to any change that might occur in the state of the Administrator component.
Beans about Java
The formal component model in the Java programming language is the JavaBeans specification. This specification adds a number of concepts to promote a component model within the Java programming language. A few of these concepts—properties, events, and methods—follow right along with other standard component models. Although the concept of methods isn’t new to JavaBeans, the JavaBeans model publishes information about methods that makes them easier to discover at design-time and at run-time.
One of the most widely used (although outwardly simple) concepts introduced by the JavaBeans specification is that of naming patterns. Naming patterns are simply standards for identifying methods using recommended prefixes and suffixes. For example, the JavaBeans specification recommends that any method that exposes the value of a property (state data) should prefix the method with the words get or is. Therefore, a method that exposes the value of the age property for a Person object should be named getAge(). In addition, any method that changes the value of a property should be prefixed with the word set. So a method that changes the value of the age property should be named setAge(). The Person class in Listing C illustrates these patterns.
One of the other widely used concepts of the JavaBeans specification is the requirement that all JavaBeans support either serialization or externalization. Both deal with an object’s ability to be automatically written out to storage and read back in from storage. Serialization is controlled mostly by the java.io package, while externalization places most of the control in the hands of the individual class.
Naming patterns, serialization, and externalization are straightforward, and they offer a tremendous amount of power to the Java programming language and to the Web application development environment. Let’s look at some ways we can exploit these JavaBeans concepts in our business logic tier.
The business logic of beans
Since JavaBeans must support serialization and should support common naming patterns, they are natural fits for data transport components. For example, let’s imagine that we are exposing a set of components and services for a banking system. Our business logic tier would consist of components such as accounts, customers, and payments. These components would need to be transported from component to component and from tier to tier. The transport mechanism might need to cross process boundaries as well as machine boundaries. For a component to be portably transported across these boundaries, it needs to be serialized and deserialized as it crosses the wire. Since JavaBeans are required to support serialization, and since we can count on them to support common naming patterns, they can be transported and dynamically deserialized across processes or tiers, as shown in Figure B.
We have introduced how Java and JavaBeans can be used to build business-logic components and middleware technologies. Our next article will expand the discussion of business-logic components and middleware concepts by looking at how Enterprise JavaBeans can be used to encapsulate business logic while interacting with other resources.