3.5. Design Guidelines and Patterns
Even though the Loan EJB is a simple example, it adheres to basic design guidelines common to all enterprise applications. Most importantly, the business methods of an enterprise Java bean are encapsulated into a reusable, distributed component. The business methods perform tasks to accomplish one or more business processes. These business methods are devoid of any formatting or presentation information.
We showed you the Loan EJB's reusability by presenting two different clients: a stand-alone Java application with a simple command-line interface and a JSP client using a browser with HTML. Both clients call EJB business methods and perform the formatting and presentation aspects of the application.
To further explore common J2EE application design guidelines, let's define several terms that were used in our design. We'll introduce more terms in subsequent chapters.
Business Object
A Business Object is an object that implements a business process or business data. We typically implement a business process with a Session Bean and business data with an Entity Bean. In a multitier J2EE application, a business object should be part of the business tier. In our Loan EJB example, the Loan Session Bean is a business object.
Controller
A complex J2EE application needs to efficiently handle user input requests and invoke the correct business process as a result of that request. Applications typically use a Controller object to perform this function. In web-based clients, a servlet usually acts as a Controller. The Controller is the interface between the View (what the client sees) and the Model (the data). In our Loan EJB example, the role of the Controller is diminished because both client applications (the JSP client and the stand-alone Java client) are simplistic. The Controller is one part of the triad that implements the Model-View-Controller Pattern.
Enterprise Bean
An Enterprise Bean refers to an Enterprise Java Bean component, a component that is accessed remotely within the J2EE architectural specifications. Enterprise Bean objects execute within EJB containers under the supervision of a J2EE application server. Enterprise Bean objects are usually Business Objects and may be either Session Beans, Entity Beans, or Message-Driven Beans. Our Loan EJB is a Session Bean.
Model
The Model is the underlying representation of a system. The Model includes objects that represent the data and the business processes. In our Loan J2EE application, the Loan EJB and the LoanVO and PaymentVO value objects are all part of the Model.
The Model is one part of the triad that implements the Model-View-Controller Pattern.
Session Bean
A Session Bean is an Enterprise Bean component that typically performs a business process. It may be stateless or stateful. Our Loan EJB is a stateless Session Bean because it does not store client-specific data. A Session Bean is part of the business tier and is an implementation of the Model (along with the LoanVO and PaymentVO objects).
Value Object
A Value Object is a Java component that encapsulates data for communicating between an EJB and a remote client. Encapsulating data in value objects is convenient for programming clients and EJB components. Perhaps more importantly, value objects reduce the number of remote calls to an EJB to obtain data with multiple access methods. In our Loan EJB, business method monthlyAmortTable() returns a collection of PaymentVO objects. A single remote call returns all the payment information. If we didn't encapsulate the data inside a PaymentVO object, we would have to make multiple remote calls to an expanded list of business methods that return interest amounts, balances, and so on. As the number of remote calls increases, the performance degrades with increased network overhead.
The Value Object Pattern helps keep network traffic minimized to avoid performance penalties. The Value Object Pattern is easy to implement and is a common design pattern in J2EE applications.
View
Another name for View is Presentation. View is also one part of the triad that implements the Model-View-Controller Pattern.
A client can look at the same data in more than one way. For example, we present the output of our monthlyAmortTable() business method as a table of monthly payments on separate lines. Another program might present a graph with different colors representing the interest and principal amounts. This program could display the numbers on a horizontal chart with payment dates representing the horizontal axis. The chart would look like an X, with the interest amount starting out high and gradually lowering towards zero. Meanwhile, the principal amount begins low and increases as more of the interest is paid off. Although this presentation is quite different from the first one, the two “views” represent the same underlying data (or model).
An object that is responsible for presenting data to the user is a View object. View objects should be in the Presentation tier of a J2EE application. In an application that might be more complicated than our Loan application, helper objects could perform specialized formatting of the data. These helper objects may be JavaBean components or JSP tag library components.
Although the Loan EJB example is simplistic, we adhere to the separation of Model and View by keeping only Model-related code and data in the EJB and confining the formatting tasks to the client. We collapse the View and Controller parts (again, because our example is simple).