PRESENTATION OF THE SAMPLE APPLICATION in Font

Maker Data Matrix 2d barcode in Font PRESENTATION OF THE SAMPLE APPLICATION

The Transfer Object Pattern The use of other design patterns can also improve the design of a J2EE application, particularly in terms of performance. The transfer object pattern allows us to group together services used by a facade. This is useful when the services have fine-grained parameters that can cause multiple sequences of calls between the client and the server, as these calls tend to induce a great deal of network traffic, especially costly connections. A transfer object implements the java.io.Serializable interface. The state of the transfer object corresponds to a set of parameters and return values for a group of services. A transfer object can be grouped inside another transfer object recursively; this is called a composite transfer object. Transfer objects are shared by the client and business layers. They must be accessible to both layers and are therefore defined in the application s Commons project.

The client tier must use the remote resolving and communication APIs to access the services of the business tier. However, this can make the client-side code complicated. When this complication occurs, J2EE design pattern guidelines recommend the use of two design patterns: the service locator and business delegate. We describe these patterns in the sections that follow. The Service Locator Pattern The service locator pattern allows generic access to a service by hiding from the client the access mechanisms involved. Examples of this are the use of Home interfaces and using cache management to improve service resolution performance. The service locator is generally implemented in the form of a singleton with a resolve method that the client uses directly. Service resolution is not limited to the session facades; we can, for example, access data sources in the same way. The service locator pattern can also be used in the business layer when EJBs such as facades need to access services. Because different layers use the service locator, its code is contained within the application s Commons project. Figure 10-7 shows the organization of the Commons project, which contains the classes and interfaces used by the client and business layers. As you would expect, it contains a package for managing exceptions (aop.j2ee.commons.exception), but also the transfer objects (aop.j2ee.commons.to) and the service locators (aop.j2ee.commons.util.locator) explained in this section.

Figure 10-7. Organization of the Commons project The Business Delegate Pattern The business delegate pattern creates a client-side object, allowing the client to access the facades of the business layer. In general, a delegate has the same interface as the facade to which it is delegating, but this is not a requirement. The main functions of the business delegate are as follows: To make the client independent of the facades, guaranteeing better application structure and independence of the projects. For example, with an application programmed in this way, recompiling the business layer has no effect on the clients. To simplify the client-side code by regrouping common or generic functions within the delegates. For example, a delegate can be used to group together replay policies or the processing of certain exceptions. To make the client more independent of the way services are resolved. The business delegate usually uses the service locator.

In our application, the client-side administration application uses a delegate to access the Bank facade. For organizational reasons, delegates can be put in a separate project, as shown in Figure 10-8.

A number of design patterns are recommended for use when developing the business tier of an application: The front controller pattern is used to centralize the management of requests. The application controller pattern is used to transparently manage application-level requests. The context object pattern is used to allow object encapsulation of the request parameters simplifying the code of the presentation layer. The view helper pattern is used to migrate complex processing in JSP pages to Java objects. The intercepting filter pattern is used to allow specific objects to systematically intercept requests and process them with additional functions in a modular and parameterizable way. Although these design patterns are documented, using several together is not an easy task for designers or developers. It is often preferable to use frameworks that integrate the full range of presentation tier design patterns in a consistent and transparent manner. This is the chosen solution for the original version of the sample application, Duke s Bank, which is implemented using the Struts open source framework.