The Parallel Page Engine (PPE) is a servlet, which runs in the middle tier, that builds portal pages for display. This document describes in detail the underlying architecture and functionality of the PPE. It will cover all aspects of page rendering as it pertains to the internal functionality.
The Parallel Page Engine is a multi-threaded engine that takes a set of data representing the page layout, and then converts that data into a page containing portlets. The Parallel Page Engine sits in the Portal Middle Tier as a servlet and runs in the mod-Jserv of Apache.
Figure 1: Middle Tier Diagram
The Parallel Page Engine receives requests through Apache, and makes requests through the Caching Routines back to Apache, or to external providers running their own listeners. Requests which are made back to the same listener are made through MOD PLSQL which talks to the Portal Database.
When a page request is made, the Parallel Page Engine makes several requests to retrieve the data needed to display the requested page. The general flow of a page request can be broken down into 5 basic steps. A more detailed description of the Page flow can be found in Oracle9iAS Portal Page Request Flow.
Page Flow Steps
The Browser requests a page from the Parallel Page Engine.The Parallel Page Engine requests the corresponding meta-data representation of the page from Portal.
The meta-data is parsed, and requests for each portlet on the page are made.
The Portlet data and meta-data are combined to form a page.
The Page is sent back to the browser.
Figure 2. Page Flow
The different data which is retrieved in the assembly of a page is retrieved in parallel through the use of multiple threads which perform the data requests over HTTP. In this way we can retrieve all of the data quickly for all portlets and meta-data without having to wait on any one request to complete.
PARALLEL PAGE ENGINE INTERNAL FUNCTIONALITY BREAKDOWNInternally the Parallel Page Engine can be broken down into three main sections which all communicate to build a page and return the desired result to the user. Each of the three parts have distinct tasks which they are designed to perform. Since the work has been divided up into different tasks, different parts of the Parallel Page Engine could be used by other applications in the future.
Figure 3: Internal Section Breakdown.
When a page request is received, this section builds a request to portal to send the needed meta-data, and hands the request to the Management section.
Then it waits to receive the meta-data from the Management. Once the meta-data is received, the Processing of the meta-data begins.
The meta-data is broken up into a specific set of objects containing data on the Page, Portlets, Providers and nodes.
For each portlet found a request is built, and sent to the Management Section.
Figure 5: Page Processing Details.
Management section manages all requests and fetchers. The Management section operates as a single thread, and receives requests from multiple page engines, and then sends those to multiple Fetchers. It can be broken down into 3 sections of its' own, each having a specific task.The request manager receives requests and places them in a queue if no fetchers are available, or pairs them with a fetcher if one is waiting.
The fetcher manager keeps track of which fetchers are available, and which are in use. Those, which are available, are queued, until a request is available to be processed.
Figure 5: Management Details.
Multiple Fetchers execute all of the actual requests for data, and hands that data back to the Management section when it is complete. Each fetcher runs as a thread which waits in a loop for the Management section to notify it that there is a request to be worked on. When one is available, the fetcher thread is given the request, and then begins processing, and retrieving the data.FEATURESThe Parallel Page Engine contains some features which are not a direct part of the general architecture, but are an integral aspect to the success of the Parallel Page Engine. These features generally improve performance or stability, or facilitate a particular feature.
HTTPS Support
The fetchers are capable of not only communicating over HTTP, but can also make requests over the HTTPS protocol. Because of the way in which pages are processed, using separate portlet data, a page may consist of both secure and unsecure data. The fetchers understand X.509 certificates, and require the listener to have the root CA and Certificate Chain File on the listener. This does require a little more set up than just creating a certificate for a browser, however the added security is a great benefit. When using HTTPS, a JNI (Java to C communication) call is made, and the C program performs the communication. This allows for the best HTTPS performance, and keeps the certificate memory usage out of the JVM.
Connection Pooling
The fetchers execute a type of connection pooling which allows for the re-use of connections. This means that each connection made to a listener, that fetcher keeps this connection open. When the fetcher receives a request over the same server, it can reuse the request without having to go back through the handshake to get the request moving again. This is especially effective when dealing with HTTPS where the biggest performance hit comes from connection setup when the listener and client are exchanging certificates.
Cookie Management
Cookies are an important part of any Internet / Intranet application. Generally cookies are sent directly to the browser. With the Parallel Page Engine the model is different; the Parallel Page Engine acts as the client to Portal, and a server to the browser. To manage the cookies from multiple providers the Parallel Page Engine updates the browser as needed. This is done using the domain of the cookie. If the domain of the cookie in question belongs to the domain of the Parallel Page Engine, then the cookie is sent to the browser, and thus the browser is up to date with whatever is being displayed. If the domain of the cookie does not match that of the Parallel Page Engine, then the cookie is not updated in the browser. In this case the cookie is stored in Portal, and used only to get the portlet data for display. Providers in domains other than the domain of the Parallel Page Engine are sent only the cookie that was produced by that portlet.
Caching
The Parallel Page Engine supports page caching, and portlet caching.
Page caching is very effective when displaying pages in that none of the above architecture is needed. The Parallel Page Engine simply receives the request from the browser, and then displays the proper page without all of the processing. This is very effective for pages that do not change too often and contain data that is viewed frequently. The caching model is ping based and also employs use of Browser caching for even better performance.Portlet caching, Web providers in particular, allows a provider to dictate that their portlet should be cached, and thus saving network traffic. Like the page, the portlet is cached directly on the local disk, for quick retrieval. Providers however can cache their portlets based upon either an expires model, or a ping / validation model. This is especially useful when the page is dynamic, but displays some portlets where are static. By using caching on the static portlets, the page processing can be completed faster.
April 19, 2001