13.5 Deployment Architecture

As the discussions in previous sections have illustrated , OracleAS Portal lets you combine information from different sources into a single, server-based interface. But how, exactly, does OracleAS Portal assemble these pages at runtime? The workflow is shown in Figure 13-4 and is described in the following sections.

Figure 13-4. Requesting and receiving a page from OracleAS Portal

13.5.1 Creating Portal Pages at Runtime

When a browser sends a request for a page to OracleAS Portal, the request is routed to the Parallel Page Engine (PPE), a Java servlet. The PPE is responsible for implementing and overseeing the creation of a single page from the different sources of information shown on the page.

The first step in the process is for the PPE to get the metadata for the page. The metadata describes the overall layout of the page and the portlets used within the page. The PPE builds a structure to hold the page and its information, as described by the metadata.

Once the metadata is retrieved from the OracleAS Portal Repository, the PPE sends a request to the provider for each portlet. When the provider has returned the requested portlet, the PPE adds it to the structure it has created for the page. Once the entire page has been assembled , the PPE returns the page to the requester.

As you can see from this description, the PPE is central to the overall runtime operation of an OracleAS Portal site. To ensure adequate performance, you can have more than one PPE for an OracleAS Portal site. Each PPE has a default number of fetchers, which request data from providers. You can increase this number if the performance of your OracleAS Portal site seems to be suffering from a lack of fetchers.

13.5.2 Caching

The earlier description shows that creating a page involves a number of different resources. There may be pages or portlets in an OracleAS Portal site that contain the same content for all users. You can reduce the overhead of creating these pages by caching the pages at a system level.

You can specify the following types of caching for a page or portlet:

Cache page definition at the system level

This approach caches the page metadata once for all users. You can also set an expiration time for this type of caching.

Cache page definition only

This approach caches the metadata that build the page for each individual user .

Cache page definition and content for a specified length of time

This approach is helpful for pages that are somewhat dynamic, such as pages listing current news items.

This caching is implemented through the file system on the Oracle Application Server server that is running OracleAS Portal, and is separate from the caching performed by OracleAS Web Cache (described in Chapter 7). Like other pages, portal pages can be cached in OracleAS Web Cache as long as they are defined there as being cacheable. You can set a PPE parameter to prevent OracleAS Web Cache from caching OracleAS Portal pages if desired.