Architecture: Tiers and Layers
The reporting system framework is described as a multi-tiered architecture. The architecture is categorized into tiers, layers, and systemic qualities. Tiers represent the logical or physical organization of components into an ordered flow of provider and consumer services from client to back-end resources. Layers represent the hardware and software stacks that support components providing services within a given tier. Systemic qualities represent the tools, techniques, and best practices that deliver the requisite quality of service across the tiers and layers of the architecture.
The client component consists of a browser that can initiate requests for reports using HTTP and can receive reports in either HTML or another format (such as PDF), which are then redirected to the appropriate viewer. Reports can also be generated via a batch job defined to run periodically or on a one-time basis. Batch jobs can be considered clients of the reporting framework. There is a test client and servlet supplied as part of the code that can be used to exercise the implemented framework.
Middle-tier components provide the core application framework structure. If the framework is to be accessed by servlets, then J2EE components are included in the middle tiers. If the framework is to be accessed as a Web service, then Web service components are included in the middle tiers. In addition to the reporting framework, Java libraries for XML, XSL, XSLT, JDBC support, and Formatting Objects Processing that are used to support the framework are included in the middle tier.
The Resource tier represents components used to populate reports with content. Data sources are typically a vendor-specific database implementation accessed through JDBC or stored procedures. Additionally, other third-party reporting tool libraries and components could be used to augment data access when creating report content.
Figure 1.Tiers and Layers.
Logical Architecture View
The high-level decomposition of the architecture can be represented in terms of its package hierarchy and layers. Decomposition is shown using packages and their relation to the various tiers in the architecture. Packages are later further broken down into class representation to describe the relationships and sequence flow in the design.
Figure 2. Top Level Packages
The Requester package represents the client components requesting reports.
All clients requesting reports must be authenticated before requests are passed on to the reporting system. This package represents the authentication mechanism. Clients requesting reports should be checked for some kind of valid authentication.
The reporting system architecture should be able to utilize different possible authorization mechanisms. It will likely include a central repository for security policy definitions that are accessed by the mechanism and a tool to administer the content. The framework provides a standard way for authorization security policies to be accessed by the reporting framework. Resource access privileges are defined for users accessing reports. Resources' definitions will typically correspond to a particular report type and data content components that make up the report.
Report creation defines the operations needed to produce the report content and formatting. One or more data sources may be required to access data used as content in a report. XML parsers are applied to report templates, and handlers of the XML tags determine when data content is required. Data is retrieved from content databases and produce valid XML representing the data to be included in the report. The authorization mechanism is called from this package to determine if the requester is authorized to have the data. This package also coordinates the function of generating the report. It manages starting the threads of execution that merge data content into report templates, apply styles to the content, and render the data into final formats.
The reporting system is the front end to the whole system. It manages communications, requests, and responses with clients. It delivers the completed report to a designated location. Reports are delivered to requesting clients waiting for the response to the report request, or the report can be streamed to a file in a designated location. Asynchronous requests usually require some kind of notification that report generation has been completed. The method of notification needs to be defined by the requester. We assume that a notification mechanism is in place for use by the report generation system (e.g., email, paging, JMS).
To access the reporting system, the following interfaces are defined:
For a synchronous request:
public OutputStream requestReport(String reportType, String styleSheet, int renderFormat, java.security.Principal principal)
For an asynchronous request:
public void requestReport(String reportType, String styleSheet, int notification, String notificationAddress, int renderFormat, java.security.Principal principal)
Application Layer Structure Across Tiers
Figure 3. Application Layer
The application layer represents the highest level of logic in the system. Most of the reporting system framework resides in this layer. The structure of the framework is broken down across the tiers in the following way to depict responsibilities of system components.
- The client tier creates the user interface by visually displaying the application information and controls. It is in this tier that report requests are made and completed reports are viewed.
- The presentation tier transforms requests from the client to the business tier, and generates responses from information created by the report-creation subsystem. The reporting service uses the report-creation subsystem to create the report in the proper output format and desired style before storing or sending it to the requester. This is where the capabilities of FOP, XML, XSL, and XSLT are heavily used. These libraries significantly reduce the work required to implement a working framework.
- The business tier handles all business logic. In this architecture, a security service is used to perform the authorization required to determine report content based on requester access definitions.
- The integration tier contains Java objects that encapsulate the persistence mechanism and the report data. Data Producer objects are used to access data in report content databases. JDBC creates the interface to the database.
- The resource tier provides managed information resources. At the application layer, custom stored procedures may be available to access data. Other reporting tool APIs defined to access data may also be utilized here.