Technical documentation
- fr.ippon.wip.config: configuration portlet management;
- fr.ippon.wip.filter: filter for logging performances;
- fr.ippon.wip.http: resources for http request / responses;
- fr.ippon.wip.http.hc: HttpClient management;
- fr.ippon.wip.ltpa.*: LTPA authentification management;
- fr.ippon.wip.portlet: configuration and display portlets;
- fr.ippon.wip.servlet: redirection servlet for downloading content;
- fr.ippon.wip.state: state of present and past requests;
- fr.ippon.wip.transformers: data corrections and rewriters call;
- fr.ippon.wip.util: cache DTD resources and other utilities.
The WIP application is built around two portlets named WIPConfigurationPortlet and WIPortlet. The purpose of the first one is to configure the display of the websites that will be proxied by the second one.
The configurations storage has been designed in such a way that one can easily integrate a new persistence system in the application. Right now only one persistence system has been implemented: each configuration is split and stored in three different files: one file containing XSLT clipping directives, one file containing XSLT transformation directives, and one XML file for general configuration. Those files are saved in /webapps/wip-portlet/WEB-INF/classes/configurations of the TOMCAT_HOME. The name of this DAO is XMLConfigurationDAO.
A DAO can be accessed through the factory named WIPConfigurationDAOFactory. This factory will automatically decorate the DAO with a ConfigurationCacheDecorator instance and a DeployConfigurationInstance. ConfigurationCacheDecorator is used as a cache in order to reduce I/O operations on the disk. The purpose of DeployConfigurationInstance is to deploy configurations located in the deploy folder of the application.
HTTP requests are executed using the HttpComponent library of the Apache project.
Building an HTTP request is a two time process: first we need to retrieve a RequestBuilder from the RequestBuilderFactory singleton. The precise subtype of this RequestBuilder instance is determined from the data encoded in the portlet request passed as parameter. Then from this RequestBuilder we can build an HttpRequestBase instance of the HttpComponent library.
The class used to executed a request with HttpComponent is called DefaultHttpClient. However, the application doesn't use the DefaultHttpClient implementation directly, but it decorates it in order to encapsulate cache functionalities, along with transformation capabilities.
This decoration is performed by the HttpClientResourceManager, which also manage cookies, connection manager etc. Moreover, the HttpClientResourceManager will automatically add a private configuration if the configuration requires so.
Here is a sequence diagram showing the process of a standard request through the different concerned entities:
In this diagram, The first CachingHttpClient instance is optionnal and corresponds to the private cache. When activated, it will cache transformed HTTP reponses in order to improve performance.
The purpose of HttpClientDecorator is to filter and transform requests (stape 5 and 6) as well as to transform responses (stape 9). When a request has passed the filter and has been transformed, it is then passed to the second instance of CachingHttpClient (the public cache) for caching HTTP responses returned by DefaultHttpClient. Those responses are then transformed (stape 9) and returned.
The transformation process takes place in HttpClientDecorator and it is split in two phase: before and after the execution of the request. The transformation which occurs before manage LTPA authentication when needed. The transformation which occurs after manage clipping, HTML, CSS, JSON and javascript transformation according to the response content type. The selection to the appropriate transformer instance is done by TransformerBuilder.
Javascript, CSS and JSON transformers use pattern matching in Java to process their input; however the behaviour of HTMLTransformer is different as it uses XSLT code to process an HTML page.