|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) B14037-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) B14037-03 |
|
|
Previous |
Next |
This chapter introduces Oracle Application Server Portal and explains how it fits in the Oracle Application Server architecture.
This chapter contains the following sections:
What Is the Oracle Application Server?, which provides you with a basic understanding of the solutions and components comprising Oracle Application Server so you can better understand how they work in concert with OracleAS Portal.
Understanding the OracleAS Portal Architecture, which describes how OracleAS Portal and relevant pieces of Oracle Application Server work together.
Understanding Caching in OracleAS Portal, which describes the caching configurations you can implement to increase the availability and scalability of medium to large deployments.
|
Note: OracleAS Portal cannot be installed standalone, but must be installed as part of Oracle Application Server. |
Oracle Application Server is a completely standards-based application server that provides a comprehensive and fully integrated platform for running Web sites, J2EE applications, and Web services. It addresses all the challenges that you face as you refine your business processes to become an e-business.
Oracle Application Server provides full support for the J2EE platform, XML, and emerging Web services standards. With Oracle Application Server, you can simplify information access for your customers and trading partners by delivering enterprise portals that can be customized and accessed from a network browser or from wireless devices. It enables you to redefine your business processes and integrate your applications and data sources with those from your customers or partners. You can deliver tailored customer experiences through real-time personalization, and assess and correlate customer navigation, purchasing, ratings, and demographic data.
You can also implement a centralized management, security, and directory framework to manage and monitor all of your distributed systems and diverse user communities. Oracle Application Server maximizes your Web site infrastructure by deploying your fast, scalable Internet applications through built-in Web caching, load balancing, and clustering capabilities.
Oracle Application Server is actually a set of Oracle Application Server solutions. Each solution contains one or more components. A component can be a service, an API, or an application. For detailed information, see the Oracle Application Server Concepts guide.
It is important to understand a bit about the overall Oracle Application Server architecture so you can more fully understand how your OracleAS Portal configuration fits within that structure. The next few sections provide some key concepts and terms you will need as you plan your configuration strategy.
The Oracle Application Server architecture consists of three basic tiers:
Client Tier
Middle Tier
Infrastructure Tier
Client Tier
From the client computer, a user can connect to the middle tier and the infrastructure tier to access the self-service tools for publishing information, build applications, deploy content management, and administer enterprise portal environment.
Middle Tier
The middle tier, or application server tier, is a set of Oracle Application Server components typically installed into a single Oracle home. A single enterprise can have one or more application server installations, either residing on one host or, for more complex installations, distributed across multiple hosts.
Infrastructure Tier
The infrastructure installation consists of several components that help authenticate users, store access control information, and pass on the required content to the user based on the privileges the user has on OracleAS Portal. Like the middle-tier components, infrastructure components can be distributed across multiple hosts to enable scalability and high availability.
Figure 1-1 shows the three parts of the Oracle Application Server architecture.
Figure 1-1 Components of the Oracle Application Server Architecture
The middle tier is the part of an Oracle Application Server architecture that contains several components responsible for accepting requests from clients, validating the requests, and providing content, while using intelligent data caching for faster and reliable performance.
For OracleAS Portal, the middle tier handles all Web requests by forwarding them to the appropriate provider. This is also where portal pages are assembled, and where the caching of portal content is managed. The middle tier also provides other functions for other Oracle Application Server components.
Some of the key components for OracleAS Portal in the Oracle Application Server middle tier are:
Oracle Application Server Containers for J2EE. Oracle Application Server Containers for J2EE (OC4J) are fast, lightweight, and scalable J2EE containers that are written in Java and run on a standard Java Virtual Machine (JVM). OracleAS Portal's Parallel Page Engine (PPE), for example, is a servlet that assembles portal pages, and runs in the Oracle Application Server Containers for J2EE. OC4J have been designed for ease of use and to support standard APIs.
Oracle HTTP Server. Oracle HTTP Server is the underlying deployment platform for all programming languages and technologies Oracle Application Server supports. Providing a Web listener for OC4J and the framework for hosting static and dynamic pages and applications over the Web, Oracle HTTP Server includes significant features that facilitate load balancing, administration, and configuration.
Portal Services. For OracleAS Portal, Oracle HTTP Server handles all incoming HTTP requests to OracleAS Portal, by forwarding them to the OC4J_Portal instance, which provides all the Portal Services. The Parallel Page Engine (PPE) is one of the Portal Services that assembles portal pages. Other services, like those previously provided by mod_plsql, are now incorporated in the Portal Services as well.
Oracle Application Server Web Cache. Works together with OracleAS Portal's own file-based caching to cache page definitions and content in memory, to boost performance. OracleAS Portal is closely integrated with OracleAS Web Cache to improve OracleAS Portal's overall availability, scalability, and performance. OracleAS Web Cache combines caching and compression technologies to accelerate the delivery of both static and dynamically generated portal content.
Application Server Control Console. This administration console for the Oracle Application Server enables you to administer clusters, start and stop services, enable and disable components, view logs and ports, and monitor servers in real-time.
There are three types of middle-tier installations:
Oracle Application Server Containers for J2EE and OracleAS Web Cache, which is the simplest configuration and does not contain any of the OracleAS Portal Solution components.
OracleAS Portal and OracleAS Wireless, which adds the Portal and Wireless solutions to those provided by Oracle Application Server Containers for J2EE and OracleAS Web Cache.
Business Intelligence and Forms, which contains all of the middle-tier components, including OracleAS Portal.
To use OracleAS Portal, you must choose Option 2 or Option 3.
Refer to the following sections for more information:
By default, the infrastructure tier handles all authentication requests and hosts the Oracle Application Server Metadata Repository, which contains schemas and business logic used by application server components (including OracleAS Portal) and other pieces of the infrastructure.
For the OracleAS Portal middle-tier installation, the infrastructure tier is a prerequisite.
The Oracle Application Server Infrastructure contains:
Application Server Control Console. This administration console for the Oracle Application Server enables you to administer clusters, start and stop services, enable and disable components, view logs and ports, and monitor servers in real-time.
Oracle Internet Directory. An LDAP version 3 compliant repository for storing user credentials and group memberships for OracleAS Portal and other Oracle products.
Oracle Application Server Single Sign-On (SSO). Authenticates user credentials against Oracle Internet Directory for OracleAS Portal and other applications, thus enabling users to log on once to the Web portal to access multiple accounts and applications with a single user name and password.
Oracle Application Server Metadata Repository. The repository is installed in an Oracle Database and consists of a collection of schemas that contain product metadata for Oracle Application Server components. Some middle-tier components, such as OracleAS Portal, store their metadata in this repository and need access to that metadata during run time.
Figure 1-3 The Infrastructure Tier Components
You can install multiple instances of any of these components on multiple servers, and then connect the servers to suit your needs. Deployment configuration options for OracleAS Portal range from installing everything on a single server to multitier configurations in which the pieces comprising OracleAS Portal are located across multiple servers.
There are three types of OracleAS Infrastructure installations:
Oracle Identity Management, which installs and configures Oracle Identity Management services (Oracle Internet Directory, OracleAS Single Sign-On, Oracle Delegated Administration Services, Oracle Directory Integration and Provisioning, OracleAS Certificate Authority).
OracleAS Metadata Repository, which installs a new Oracle Database 10g containing the OracleAS Metadata Repository, and also stores the database objects that comprise OracleAS Portal, Oracle Internet Directory, and OracleAS Single Sign-On.
Oracle Identity Management components and OracleAS Metadata Repository, which consists of all the components listed in the preceding two installation types.
After your development team builds your Web portal, the next step is to deploy a production version of it. Successful deployment means that end users are able to access content in a timely manner, without delays, errors, or server downtime. Because OracleAS Portal can be installed in a variety of configurations on different machines, a successful deployment ultimately depends how you configure portal to address the requirements of your site. This section provides some background information that should be useful to you as you plan your configuration.
Some Oracle Application Server components serve as portlet providersFoot 1 for OracleAS Portal, which means you can easily integrate information from various components into a single portal page. Other components provide essential services to OracleAS Portal, as described in the following list.
Oracle Reports. OracleAS Portal includes a simple report building facility. However, as your reports become more complex, you may want to import the report into OracleAS Reports Services to take full advantage of the functionality it offers. You can deploy any OracleAS Reports Services report as a portlet.
Oracle Business Intelligence Discoverer. As a portlet provider, OracleBI Discoverer offers Worksheet portlets and List of Workbooks portlets to OracleAS Portal users. A Worksheet portlet contains information from a single Discoverer worksheet. The portlet displays this information in a table, a graph, or both. The List of Workbooks portlet presents a list of available workbooks.
|
See Also:
|
Oracle Ultra Search. Oracle Ultra Search, which is integrated with OracleAS Portal, enables portal users to add a powerful search capability to their portal pages, and can be used to perform a search over a variety of content repositories and data sources. It also has the capability to crawl the OracleAS Portal Repository and search public content. Refer to Chapter 8, "Configuring the Search Features in OracleAS Portal" for more information about Oracle Ultra Search.
Oracle Application Server Wireless. Working with OracleAS Wireless, OracleAS Portal automatically transforms the portal page structure to a format appropriate for the smaller screens of most wireless devices. Only portlets generating OracleAS Wireless XML content can display on a wireless device.
OracleAS Portal developers also have access to a set of page design tools that help in creating portal pages that optimize the wireless experience. With these tools, developers can build a distinct portal structure for their wireless users. The wireless pages and portal pages can share portlet instances, which enables clients to reuse portlets on browser and wireless clients without reconfiguring each portlet.
Refer to Section 4.6, "Configuring Mobile Support in OracleAS Portal" for more information.
Oracle Enterprise Manager 10g. Oracle Enterprise Manager 10g provides the Application Server Control Console, and the Grid Control Console. Oracle Enterprise Manager 10g Application Server Control Console can be used for monitoring, diagnostics, and for the configuration of OracleAS Portal-specific integration and performance settings. The Oracle Enterprise Manager 10g Grid Control Console can be used for monitoring OracleAS Portal, and tracking historical trends, but not for configuration. Refer to Chapter 7, "Monitoring and Administering OracleAS Portal" for more information about monitoring OracleAS Portal.
Oracle Application Server Forms Services. Oracle Forms applications combine interactive, graphical interfaces with strong support for data validation. Forms developers can quickly create applications with powerful data manipulation features. OracleAS Forms Services deploys Forms applications to Java clients in a Web environment. OracleAS Forms Services automatically optimizes class downloads, network traffic, and interactions with the Oracle Database. OracleAS Forms Services applications are secured by the OracleAS Single Sign-On, and accessed from an OracleAS Portal environment provided by Oracle Application Server.
Oracle Application Server Single Sign-On. OracleAS Single Sign-On authenticates users who are attempting to gain access to non-public areas of your portal. Refer to Section 6.1.7.1, "Relationship Between OracleAS Portal and OracleAS Single Sign-On" for more information.
Oracle Internet Directory. Oracle Internet Directory is Oracle's highly scalable, LDAP version 3 service and hosts the Oracle common user identity. OracleAS Portal queries the directory to determine a user's privileges and what they are entitled to see and do in the portal. In particular, OracleAS Portal retrieves the group memberships of the user from the directory to determine what they may access and change. Refer to Section 6.1.7.2, "Relationship Between OracleAS Portal and Oracle Internet Directory" for more information.
Oracle Delegated Administration. In addition to querying Oracle Internet Directory for user and group information, OracleAS Portal must provide users with a user interface to add and modify user and group information. To change information in the directory, you use the Oracle Delegated Administration Services user interface. OracleAS Portal provides links to the Oracle Delegated Administration Services for users with sufficient privileges to add and change users and groups. Refer to Section 6.1.7.4, "Relationship Between OracleAS Portal and Oracle Delegated Administration Services" for more information.
Oracle Directory Integration and Provisioning. Oracle Directory Integration Platform notifies OracleAS Portal upon the occurrence of any directory events (for example, user deletions) to which OracleAS Portal subscribes. In essence, the directory integration server informs OracleAS Portal when a change occurs in the directory that requires a change in OracleAS Portal. Refer to Section 6.1.7.3, "Relationship Between OracleAS Portal and Oracle Directory Integration Platform" for more information.
Oracle Application Server Metadata Repository. The repository is installed in an Oracle Database 10g and consists of a collection of schemas that contain product metadata for Oracle Application Server components. Some middle-tier components, such as OracleAS Portal, store their metadata in this repository and need access to that metadata during run time.
You will find additional information in the white paper titled "OracleAS Portal Architecture Overview" on the Oracle Technology Network (OTN), http://www.oracle.com/technology/.
A portal is comprised of groups of pages, each page divided into regions. The regions specify how space on a given page is allotted to that page's items and portlets.
Each time a user requests an OracleAS Portal page, the page is dynamically assembled and formatted according to the portlets and layout chosen for that page. Keep in mind that the parts that comprise the page are typically drawn from a variety of sources. For example, the page's layout, look and feel, and user customizations are stored in the database as part of the overall page definition, completely separate from any page content. This information may, in turn, be cached by the middle tier. (However, if full-page caching is used, pages are not assembled, because they are served directly out of the cache.)
The portlets that appear on the page can be written in PL/SQL or Java. For PL/SQL portlets, the source is an OracleAS Metadata Repository database. This could be the database where the current instance of OracleAS Portal is installed, or some other OracleAS Metadata Repository database located on a remote server, which is accessed through the Federated Portal Adapter. If written in Java, a Web provider provides the portlet from any location accessible from the network, either Internet or intranet. For example, you could create a portal page that displays both the following types of content:
Portlet content from an external Web provider.
Content from a portlet that resides in the OracleAS Metadata Repository.
Figure 1-4 shows how a page is assembled. As you can see, when a client requests an OracleAS Portal page, many Oracle Application Server components must respond to various parts of the request:
The client browser requests a portal page. OracleAS Web Cache receives this request.
OracleAS Web Cache forwards the request to the Oracle HTTP Server.
Oracle HTTP Server forwards the request to the Portal Services.
The PPE, which is part of the Portal Services, retrieves the portal page definition. The page definition contains information about the portlets on a page and their layout.
First, it tries to get the cached copy of the definition from OracleAS Web Cache.
If there is a cache miss in OracleAS Web Cache, it checks if the portal cache has a valid cached copy.
Finally, if no valid cached copy of the definition exists, then the OracleAS Metadata Repository generates a page definition from data in the portal repository. The portal repository is either in the OracleAS Metadata Repository or in your customer database.
The PPE parses the page definition. If a fully cached copy of the page exists, then the page is returned to the client browser through OracleAS Web Cache. If it does not, the PPE builds the page from cached and non-cached data with the remaining steps.
For each portlet on the page, the PPE checks if a cached copy of the portlet content exists in the portal cache, OracleAS Web Cache, or both portal cache and OracleAS Web Cache, and then forwards a request to the appropriate provider, through OracleAS Web Cache (not shown in the image).
Each provider either validates the cached portlet or generates content for the portlet. Web providers return this directly to the PPE using HTTP/S. Database (DB) providers return the results to the PPE through OracleAS Web Cache, Oracle HTTP Server, and Portal Services, using HTTP/S or SOAP.
The PPE aggregates the content into a single page. This page is sent to OracleAS Web Cache.
OracleAS Web Cache returns the final page to the client browser.
The OracleAS Portal implements a distributed architecture consisting of multiple communication points and protocols. For complex configurations including the introduction of firewalls and proxies, you need to understand the communication points, and how the various components of OracleAS Portal integrate together. Likewise, to allow for the distribution of the various functions across multiple servers, it is necessary to be aware of the network protocols that are used in the internode communication.
The OracleAS Portal architecture consists of three basic tiers: the client browser (pictured at the far left in Figure 1-5) the middle-tier server (pictured on the bottom left), and the infrastructure server and repositories (pictured on the top left). Although the default installation places all servers and repositories on the same host, it is recommended that you install these functions on separate servers, for increased performance and high availability.
Figure 1-5 shows in detail the communication flow between the various components of OracleAS Portal and Oracle Application Server.
Figure 1-5 Communication Flow and Protocols
The three tiers and the communication protocols used between them is described next:
Client
The client sends a request to OracleAS Portal, which is part of the middle tier, using the HTTP/S protocol. The use of firewalls and proxies is supported between the client and the middle tier.
If the user needs to be authenticated, the client browser is redirected to the Oracle HTTP Server in the infrastructure tier. This connection is through HTTP/S and supports the implementation of both firewalls and reverse proxies in the network environment.
Infrastructure Tier
The infrastructure tier consists of the Oracle HTTP Server, OracleAS Single Sign-On, Oracle Internet Directory, and OracleAS Metadata Repository.
If the requested page requires authentication, the user is prompted for a user name and password. This function is carried out by the Portal Services, through a redirection to OracleAS Single Sign-On for authentication. All authentication requests are communicated using the SQL*Net protocol.
OracleAS Single Sign-On verifies user credentials against the Oracle Internet Directory through LDAP/S. The credentials are compared to those found within the Directory (LDAP compare) and the result returned to OracleAS Single Sign-On. Upon successful authentication, OracleAS Single Sign-On creates a single sign-on cookie. Once the user is authenticated and an appropriate OracleAS Portal session created, the user may access pages and other objects.
As the access control lists (ACL) for all portal objects are held in the OracleAS Metadata Repository, the OracleAS Portal uses an LDAP/S request to communicate with the Oracle Internet Directory to query the appropriate user and group membership information defined in the Directory. When a user first logs in to OracleAS Portal, the group memberships of the user are copied to the portal node and cached on that tier. This process allows for fast lookup of object privileges. Once the object and page privileges of the user are known, the Parallel Page Engine goes on to generate the page from the appropriate pieces.
All user provisioning is performed against the Oracle Internet Directory. The interface between the Infrastructure tier's Oracle HTTP Server and the LDAP server is through the Oracle Delegated Administration Services servlet. The Oracle Delegated Administration Services interface uses the LDAP/S protocol to communicate with the Oracle Internet Directory.
The OracleAS Single Sign-On model includes the addition of mod_osso, which allows any URL to be protected within the OracleAS Single Sign-On environment. Calls to the Delegated Administration Services servlet are protected by the mod_osso plug-in. This verifies that the user has been properly authenticated before providing access to the Oracle Internet Directory. In effect, mod_osso filters the URL and forwards the HTTP/S-based request, only if the user has previously been authenticated.
The Oracle Directory Integration Platform automatically keeps the locally cached information up to date with changes in the Oracle Internet Directory. Just as the Oracle Directory Integration Platform keeps the local cache synchronized with the Oracle Internet Directory, it also keeps the Oracle Internet Directory synchronized with any external repository. The Oracle Directory Integration Platform communicates with the Oracle Internet Directory through LDAP/S.
Middle Tier
The middle tier consists of the OracleAS Web Cache, Oracle HTTP Server, Oracle Application Server Containers for J2EE, and other Oracle Application Server components.
|
Note: OracleAS Web Cache and Oracle HTTP Server can be installed on different hosts to allow scalability and high availability. |
OracleAS Web Cache front ends the middle-tier components and thus optimizes the throughput of OracleAS Portal. When a page request comes from the browser, OracleAS Web Cache evaluates the URL and services the request from the cache if possible. If a requested page is not previously cached, the request is forwarded to its origin server (Oracle HTTP Server in this case) for generation. As a Web accelerator, OracleAS Web Cache allows the use of HTTP or HTTPS communication between itself and:
The client browser
The appropriate origin server
Both the origin server and the client browser
The Parallel Page Engine (PPE) runs as a servlet within the Oracle Application Server Containers for J2EE. A URL request to the servlet is forwarded through the Oracle HTTP Server's plug-in, mod_oc4j. As a standards-based plug-in, mod_oc4j communicates with Oracle Application Server Containers for J2EE using the Apache Java Protocol (AJP).
The PPE itself makes requests to both database providers and Web providers through HTTP/S-based communication. The render request to a database provider is through a URL loopback to the Portal Services, while the call to a Web provider is by use of a SOAP-based message protocol over HTTP/S.
If any Web providers require information from the OracleAS Metadata Repository, they issue the appropriate call through the PDK using a SOAP-based message protocol over HTTP/S.
The OracleAS Web Cache component uses an Invalidation-based cache methodology. If a requested URL can be serviced from the cache, it is assumed to be correct until the specified URL is invalidated. If a user customizes their OracleAS Portal experience, or if the privileges configured to use the user changes, the OracleAS Portal invalidates the appropriate cached objects within OracleAS Web Cache. To do this, the OracleAS Portal issues a HTTP/S-based request directly from the OracleAS Metadata Repository to the invalidation port of the OracleAS Web Cache.
OracleAS Portal uses three methods to cache Web pages and content:
Invalidation-based caching is performed using OracleAS Web Cache. An item remains in the cache until some event occurs that requires it to be refreshed. For example, a user may update some item, requiring the cache to be updated. In response to the event, the OracleAS Metadata Repository or a Provider sends an invalidation message to OracleAS Web Cache. The next time there is a request for the invalidated item, it is refreshed in the cache. You can set the expiry time for invalidation-based caching. See Section 5.7.3.3, "Setting the Expiry Time for Invalidation-based Caching" for more information.
Validation-based caching is performed using the portal cache. Before an item in the portal cache is used, Portal Services contacts the OracleAS Metadata Repository or a Provider to determine if the cached item is still valid.
Expiry-based caching also uses the portal cache. A retention period for the item specifies how long it is valid in the cache, before a refresh is required. Pages that use expiry-based caching may also be cached in the user's browser.
OracleAS Web Cache is a powerful server acceleration and load balancing solution. Using OracleAS Web Cache is required for running OracleAS Portal. OracleAS Web Cache offers intelligent caching, page assembly, and compression features. OracleAS Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Application Server.
To increase the availability and scalability of medium to large deployments, consider configuring multiple instances of OracleAS Web Cache to run as members of a cache cluster. A cluster is a collection of cooperating OracleAS Web Cache instances that work together to provide a single logical cache. Cache clusters provide failure detection and failover, increasing the availability of your Web site. If an OracleAS Web Cache instance fails, other members of the cache cluster detect the failure and take ownership of the cached content of the failed cluster member. This is achieved because the nodes that receive requests hold the content, after forwarding the request to the owner cache node.
By distributing the Web site's content across multiple OracleAS Web Cache servers, more content can be cached and more client connections can be supported, expanding the capacity of your Web site. You make use of the processing power of more CPUs and, because multiple requests are executed in parallel, you increase the number of requests that are served concurrently
OracleAS Portal functions as a Web Cache origin server to take advantage of the following Web Cache features:
Caching dynamically generated, user-specific page structure and portlet content
Fine-grained cache control
Invalidation-based caching
Layer 7 load balancing and failover detection
Performance assurance and surge protection
Portal sites can choose from the following deployment options:
Co-located: Web Cache runs on the same physical server as the OracleAS Portal middle tier. This configuration is appropriate for smaller, low-volume sites where the scalability of the middle tier is not a concern.
Dedicated: Web Cache is deployed on a dedicated server that sits in front of one or more OracleAS Portal middle-tier servers. Dedicated deployments are usually preferable to co-located deployments, as there is no risk of resource contention with other server processes. OracleAS Web Cache performs well on commodity hardware, so a dedicated deployment does not have to be costly in terms of hardware expenditure.
For medium to large business Web sites with high volume, the dedicated topology is advantageous for the following reasons:
No resource contention. Installing OracleAS Web Cache and OracleAS Portal middle tier on different servers will guarantee no competition among different services for hardware resources.
Performance assurance and surge protection. By separating the middle-tier server and cache server, this topology minimizes compound failure rates. OracleAS Web Cache offers patent-pending techniques to guarantee site performance and scalability, even when Web server loads surpass capacity levels. A surge protection mechanism detects system overload conditions, providing a crucial buffer against traffic spikes and denial-of-service attacks.
Server affinity. OracleAS Web Cache can be used to balance the load between multiple OracleAS Portal middle-tier servers and providers in a cluster. Cookies can be used to maintain persistent, or "sticky", connections to a specific server when necessary to preserve state.
To avoid a single point of failure in very high-volume sites, two or more nodes running OracleAS Web Cache may be deployed behind a Load Balancing Router (LBR). If you have multiple deployments of OracleAS Portal, each portal site can have its own Web Cache server. One or more sites can also share a single Web Cache server. Similarly, a provider can share a Web Cache with a portal site, or a dedicated Web Cache can be deployed in front of the Web server that hosts the provider. Refer to Section 5.7, "Managing OracleAS Portal Content Cached in OracleAS Web Cache" for more information about configuring OracleAS Web Cache.
In addition to providing failover, an OracleAS Web Cache cluster also balances the load it forwards to the middle tier.
Figure 1-6 Adding OracleAS Web Cache to a Medium to Large Portal Configuration
After the initial request to the owner node, the content is cached across all instances. In Figure 1-6, the LBR distributes incoming requests to the three OracleAS Web Cache instances. When the on-demand content is not available on the node receiving the request, the other instances are checked for the cached content, and the content matching the request is returned to the Browser.
To take advantage of OracleAS Web Cache's clustering capability, you must configure each instance as a member of a cache cluster. In this setup, there is no one-to-one relationship between an OracleAS Web Cache instance and a matching middle-tier instance. As shown in Figure 1-6, OracleAS Web Cache 1 provides load balancing between middle tiers 1, 2, and 3. OracleAS Web Cache 2 and 3 do the same.
You will find additional information about caching and performance on Oracle Technology Network, http://www.oracle.com/technology/.
Portal cache is a file system-based cache for OracleAS Portal pages and portlets. Portal cache supports validation-based caching and expiry-based caching.
Portal cache consists of two kinds of caches:
The content cache contains user level and system level content generated by OracleAS Portal, which includes page metadata, database portlets, Web portlets, documents, style sheets, images, and full-page caches.
OracleAS Portal uses session cookies to maintain session details for each portal user. This session cookie is encrypted and contains important information like the database user name, lightweight user name, and Globalization Support characteristics of the session. In order for Portal Services to execute a portal request, it must get the database user name from the session cookie. To avoid an expensive decrypt operation with each user request, Portal Services decrypts the session cookie once and maintains the relevant cookie details in an in-memory session cache. The in-memory session cache may be used for garbage-collection by the JVM, and therefore, the session details are also cached in the file system.
Portal content and session cache content resides on the file system, typically under ORACLE_HOME/Apache/modplsql/cache, and is configured in the file ORACLE_HOME/Apache/modplsql/conf/cache.conf. You can specify content cache for OracleAS Portal from the Application Server Control Console. See Section 4.5.4, "Configuring the Portal Cache" for more information.
In multiple middle-tier configurations, you can set up the portal cache for each middle tier on a shared file system. This ensures that each middle tier can share cached content, rather than each drawing from its own independent cache.
For example, one middle tier might handle a request for an item by caching it in the portal cache. Because you typically use a load balancing router for configurations having multiple middle tiers, the next request for the item could be handled by a different middle tier. This middle tier could access the cached version if the portal caches for each middle tier are shared on a common file system.
Various parameters for configuring portal cache include:
Cache location
Total cache size
Maximum cacheable file size
Maximum time a cached file can be in the cache system
Cleanup of the cache storage
OracleAS Portal makes use of two caching systems: OracleAS Web Cache, and portal cache. OracleAS Web Cache supports invalidation-based caching and expiry-based caching. The portal cache supports validation-based caching and expiry-based caching.
Cache invalidations can be classified into two groups:
Hard Invalidations
Hard invalidations are queued up over the duration of a single browser request and are then processed when the OracleAS Portal user interface action completes. The results will be seen immediately. Most page edits and all portlet customizations are treated as hard invalidations.
Soft Invalidations
Soft invalidations are queued up over many browser requests and are then processed later by the soft invalidation database job. Security related changes, for example, granting privileges on a page to a user or group, are treated as soft invalidations.
Cache Invalidation Resource Requirements
Invalidations are queued up based on edits and personalizations. With more such actions being performed, a greater number of invalidations are submitted. Individual actions that involve more portal objects or users will require more resources to process the corresponding invalidations. For example, changing the access privileges for a group of users will require that data for each user in the group be invalidated. Therefore, the larger the group the more invalidation resources will be needed. Consider another example, deleting a large number of pages as a bulk operation requires invalidation resources proportional to the number of pages being deleted. Processing of invalidations requires storage, CPU, and communication resources. Therefore, large numbers of cache invalidations may slow down the system. The reason for this could be any of the following:
Communication with OracleAS Web Cache
When either hard or soft invalidations are processed, a TCP/IP connection is established with the OracleAS Web Cache invalidation port from the OracleAS Metadata Repository, to send invalidation messages.
For both hard and soft invalidations, all the messages queued are sent using a TCP/IP connection to OracleAS Web Cache. OracleAS Web Cache receives these invalidation messages and attempts to invalidate cached data. This load may affect OracleAS Web Cache's ability to respond to requests for data.
Cache invalidation queue storage
Both hard and soft invalidation messages are queued into a database table in the OracleAS Metadata Repository. As the queue grows in size, more database resources are required to maintain the queue.
Cache invalidation queue optimization
During the processing of hard or soft invalidation messages, queue optimization removes duplicate or unnecessary invalidation messages. For example, if a page group is being invalidated, individual invalidation messages for pages in the page group are unnecessary. If a large number of invalidation messages have been queued up, the optimization process may take a long time.
You are ready to move on to Chapter 2, "Planning Your Portal", now that you have a basic understanding of the Oracle Application Server architecture, how OracleAS Portal fits in, and the working of caching in OracleAS Portal. By the end of that chapter, you should have a good idea of how you want to configure your installation.
Footnote Legend
Footnote 1: Applications and information sources, represented as portlets, communicate with the portal through a provider. Each portlet only has one provider, and a provider can have one or more portlets that expose an underlying application or information source.
