- Introduction
- When It All Began
- Multitiered Development with J2EE
- Core J2EE Packages
- J2EE Components
- Presentation Tier Components
- Business Tier Components
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Multitiered Development with J2EE
The development of J2EE applications requires a multitiered approach to application development. Unlike the fat-client approach in which a single application included presentation logic, business logic, and data access (resources) logic, the distributed application takes this functionality and places it in various components across multiple logical tiers. The components represent pieces or portions of the application.
The division of the application into components is based on the responsibilities of the component. The logical association of component to tier is based on the same responsibilities. The use of multiple tiers requires a different development approach, one that takes into account the capabilities of the components, the resources available on that tier, and the skill of the developers who will create the components—for instance, in creating a component that would control the user interface.
A simplified version of a multitiered architecture involves three logical tiers: client tier, business tier, and resource tier. The client tier manages the client interface and communicates with the business tier to obtain the information needed to present to the user. The business tier reacts to client calls and retrieves data from the resource tier as needed.
A common problem with this multitiered approach is to allow functionality that should be executed on the business tier to creep into the client tier. The client tier may be deployed across numerous platforms, so business logic that has been allowed to creep into the client application now resides on numerous platforms and must be updated on each platform.
The J2EE architecture expands on the three-tiered architecture to provide for additional delineations of responsibility and to acknowledge the specific requirements of the Web application. The multiple tiers commonly identified with J2EE development are listed in Table 1–1 and are explained in more detail in the following sections.
)
Figure
1-1 Components on multiple architectural tiers.
Tabke 1-1 J2EE Development Tiers
|
Tier |
Description |
|
Client |
The portion of the application which is responsible for interacting with the end -user. |
|
Presentation |
Responsible for creating the presentation used by the client to interact with the user. |
|
Business |
Responsible for executing the business logic of the application. Applies the business logic to the information received from the integration tier. |
|
Integration |
Performs the data access operations for the application. |
|
Resource |
Contains the persistent data of the application. This is usually a database. |
Client Tier
The client tier logically enough represents the client application. The purpose of this tier is to render the presentation prepared by the presentation tier and to react to the input from the user. The client tier must also communicate with the presentation tier and relay the user's input to that tier.
The client tier can be a Web browser, an applet and Swing applet, or a WebStart client. Using a thin-client architecture, the component should have a minimal footprint. The goal is to avoid the problems of fat-client architectures where deploying to the client tier was difficult and expensive.
In order to keep this client a thin client, the responsibilities of this tier must be minimized. By minimizing and focusing the responsibilities of this tier, the amount of information that must be sent to the tier will be minimized. If we determine that this tier should only render the display and respond to the user's input, then decisions on what to display and how to display it should be left to another tier.
Presentation Tier
The presentation tier is responsible for the preparation of the output to the client tier. Since in a Web application we are usually preparing these pages dynamically, this tier must be able to store and retain information between calls, either in memory or in a data store.
If we are using a Web browser as our client, then the protocol between the client tier and the presentation tier is Hypertext Transport Protocol (HTTP). The most logical server for the presentation tier is a server that can perform HTTP, such as Apache.
Additionally, we would like the server to be able to manage dynamic content using a robust language such as Java. The Tomcat server, the reference implementation of the Java servlet engine, provides this capability using servlets and JSP pages.
The components used most often on this tier are either Java servlets, JSP pages, JavaBeans, and tag libraries. But the component could also be an applet running in a Web browser. The question we need to answer at the design stage is which type of component should be used. If we want to create components on this tier that require minimal support from Java developers, then JSP should be used to provide the bulk of the presentation logic. JavaBeans and tag libraries could be used to isolate more complex logic, leaving a JSP page that would be familiar and maintainable by most Web page developers.
By maintaining this separation of roles, staff with more specialized skill sets can maintain the presentation tier components. If these components are primarily Hypertext Markup Language (HTML), then developers familiar with HTML can be used to maintain these pages. Java provides a number of technologies that make this approach even more attractive: tag libraries and Java Bean integration into the JSP page. Using these technologies, presentation tier logic can be isolated in the JSP page and any additional logic can be moved to backend-components like Java Beans and Tag libraries. The resulting JSP page, composed primarily of HTML elements, can be maintained by an HTML developer.
The end result of this separation of roles is a flow of control for the application, which extends from the client browser to the servlet or JSP page and from the servlet or JSP page to the business tier. The business tier will execute any business logic and access the resource tier as needed.
Business Tier
The business tier isolates, encapsulates and codifies the business logic (the business rules) of the organization in the application. These are rules such as how to select sales regions for sales reports, including the usual list of exceptions that always seem to exist for many business rules.
Logic that could have resided in the presentation tier in Web components such as JSP pages or servlets is effectively pushed off and managed in this tier. Here in the business tier, under their auspices of an application server, the component is easy to look up and use, thus enhancing reusability.
The components on this tier can be created using a variety of Java technologies: Java Beans, tag libraries, and EJBs, or remote components delivered using RMI.
Integration Tier
The purpose of the integration tier is to apply the logic needed to extract data from the resource tier. This logic may involve performing necessary data conversions or applying business logic filters on the data. The data store can be any data source required by the application, such as a relational database, a legacy mainframe system, or a flat file.
Resource Tier
The resource tier is represented by the data store which could be a relational database, an object-relational database, an object database, or any technology which provides data storage (persistence services) for the application.
The resource tier is responsible for providing persistence services for the application. This usually involves storing and maintaining the consistency of application data. Communication with the resource tier is accomplished with a standard API such as JDBC for relational databases.