All the applications generated with WebRatio share the same software architecture, which is a classical three-tiers architecture, enhanced to take advantage of a well-known software engineering design pattern, called Model View Controller (MVC).
The MVC architecture is conceived to better separate the three essential functions of an interactive application:
- The business logic of the application (the Model).
- The control of the interaction triggered by the user's actions (the Controller).
- The interface presented to the user (the View).
In the MVC architecture, the computation is activated by a user's request for some content or service. The request is intercepted by the Controller, which is responsible of deciding which action should be performed for serving it. The Controller dispatches the request, in the form of a request for action, to the suitable component of the Model. The Model incorporates the business logic for performing the action, and executes such logic, which updates the state of the application and produces a result to be communicated to the user. The change in the Model triggers the most appropriate View, which builds the presentation of the response. Such presentation typically embodies interaction objects, whereby the user may pose a new request and reactivate the computation process. In WebRatio, the original MVC is adapted to take into account the peculiarity of the Web context, with some implementation issues.
WebRatio Web Application architecture
The figure below shows the architecture common to all the applications developed with WebRatio in the J2EE architecture.
IFML page mapping
Each IFML page is mapped into four elements:
1. A page action in the Model.
2. A page service in the business tier.
3. A JSP template in the View.
4. A page action mapping in the Controller's configuration file.
The page action is an instance of a Java class, sometimes called an action class, which is invoked by the Controller when the user requests the page; the page action class extracts the input from the HTTP request and calls the page service in the business tier, passing to it the needed parameters. When the page processing terminates, the page action notifies the Controller that the page content is ready to be displayed. The page service is a business function supporting the computation of the content of a page. It exposes a single function computePage(), invoked by the page action to carry out the parameter propagation and unit computation process. At the end of the page service execution, a set of Java objects storing the content of the page units (called unit beans) are available to the View. The page template is a JSP template, which computes the HTML page to be sent to the user, based on the content of the Model. It contains the static HTML needed to define the layout where the units are positioned, and custom tags implementing the rendition of the content of units. Finally, the action mapping is a declaration placed in the Controller's configuration file that ties together the user's request, the page action, and the page template.
IFML unit mapping
Each IFML unit maps into two components of the MVC architecture: a unit service in the business layer, and a set of custom tags in the View. A unit service is a Java class, which is responsible for computing the unit's content, and of producing a collection of unit beans holding the content of the unit. The class encapsulates the instructions needed to assemble the data retrieval query, execute it, and package the results into suitable unit beans. Content units also require the implementation of custom tags, used in the page templates of the View to transform the content stored in the unit beans into HTML. Such tags could be taken from a standard tag library, or defined on purpose to match the features of your units. Finally, operation units map into three components of the MVC architecture: an operation action in the Model, which is similar to a page action, an operation service in the business layer, which is similar to a content unit service, and an action mapping in the Controller's configuration file, which dictates the flow of control after the operation action completes the execution.
IFML Control Flow
Page control flow
The typical flow of control after the user sends a request to the Web server for an application page is the following:
- The request (for instance: http://www.myhost.com/page1.do) is addressed to the Controller, which is implemented as a Java servlet; the Controller looks up the action mappings in its configuration file to decide which page action to call for building the page.
- The page action associated with the page is called. This is a Java class, which interacts with the business tier. As a first thing, the page action invokes the page service associated to the requested page, which orchestrates the construction of the page. The page action is also responsible of wrapping the content of the HTTP request and of the JSP session into suitable Java objects, so that the services in the business tier remain independent of the Web front-end.
- The page service calls in the right sequence the services associated with the units that make up the page. Each unit service encapsulates the execution logic of the unit, which typically implies performing some data extraction queries. The results of these queries are stored in the Model,in the form of unit beans.
- Upon termination of the page service and page action, control passes back to the Controller, which looks up again the action mappings in its configuration file to decide which page template to call for showing the content of the unit beans.
- The appropriate page template is processed, which builds the HTML page sent to the user. The processing of the page template triggers the execution of the custom tags designed to render the content of the units present in the page. Some of these tags build HTML anchors or forms, which permit the user to submit new requests.
Operation control flow
The flow of control in case of operation invocation is similar but for the following things:
- The class invoked by the Controller is an operation action, not a page action.
- In the business tier, each operation is mapped exactly to one operation service, not to a page service and a set of unit services. Such operation service encapsulates the business logic of the operation.
- When the operation service terminates, it returns in the unit bean a result code, which is in turn passed back by the operation action to the Controller, for enabling the decision of the link to follow (OK or KO ).
- After execution, the Controller invokes either the subsequent operation or the page action associated with the page pointed by the outgoing OK or KO link of the operation, it this is the last operation of a sequence.
The aforementioned control flow works for any page and operation sequence. You do not need to alter it, but only to provide the components needed to integrate your units.