This chapter introduces Oracle Portal and it's architecture, and contains the following sections:
Understand the Oracle Portal Components, which provides you with a basic understanding of the solutions and components of Oracle Portal, so you can have a better understanding on how they work in concert with Oracle Portal.
Note:Oracle Portal cannot be installed as standalone, but must be installed as part of Oracle Fusion Middleware.
Understanding the Oracle Portal Architecture, which provides you with a basic understanding of the Portal architecture.
Understanding Caching in Oracle Portal, which describes the caching configurations you can implement to increase the availability and scalability of medium to large deployments.
Understanding WSRP and JPS, which provides an introduction to the Web Services for Remote Portlets (WSRP) specifications and Java Portlet Specification (JPS). These two standards enable the development of portlets that interoperate with different portal products, and therefore widen the availability of portlets within an organization.
It is important to understand a bit about the overall Oracle Portal architecture so you can more fully understand how your Oracle 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 Portal architecture consists of three basic tiers:
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.
The middle tier, which includes application tier and web tier, is a set of Oracle Portal components typically installed into a single Oracle home. A single enterprise can have one or more Fusion Middleware installations, either residing on one host, or for more complex installations, distributed across multiple hosts.
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 Oracle 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 Portal architecture.
Figure 1-1 Components of the Portal Architecture
The middle tier is the part of a Portal 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 Oracle 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 Fusion Middleware components.
Some of the key components for Oracle Portal middle-tier are divided into:
Application Tier includes:
Oracle WebLogic Server: Oracle WebLogic Server is a 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 WebLogic Server provides full support for the J2EE platform, XML, and emerging Web services standards. With Oracle WebLogic 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 WebLogic Server maximizes your Web site infrastructure by deploying your fast, scalable Internet applications through built-in Web caching, load balancing, and clustering capabilities.
Oracle WebLogic Server is actually a set of solutions with each solution containing one or more components. A component can be a service, an API, or an application. For detailed information, see the Oracle Fusion Middleware Concepts guide.
Portal Services: For Oracle Portal, Oracle HTTP Server handles all incoming requests to Oracle Portal, by forwarding them to the WLS_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.
Fusion Middlware Control: This administration tool for Portal enables you to administer clusters, start and stop services, enable and disable components, view logs and ports, and monitor servers in real-time.
Oracle HTTP Server. Oracle HTTP Server is the underlying deployment platform for all programming languages and technologies Oracle Fusion Middleware supports. Providing a "scalable" Web listener front ending the J2EE container 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.
Oracle Web Cache. Works together with Oracle Portal's own file-based caching to cache page definitions and content in memory, to boost performance. Oracle Portal is closely integrated with Oracle Web Cache to improve Oracle Portal's overall availability, scalability, and performance. Oracle Web Cache combines caching and compression technologies to accelerate the delivery of both static and dynamically generated portal content.
Figure 1-2 The Middle-Tier Components
The middle-tier installation comprises the following components:
Oracle WebLogic Server, Oracle HTTP Server, and Oracle Web Cache, which is the simplest configuration and does not contain any of the Oracle Portal Solution components.
Oracle Portal which adds the Portal solution to those provided by Oracle WebLogic Server and Oracle Web Cache.
Oracle Reports, Oracle Business Intelligence Discoverer, and Oracle Forms, which contains all of the middle-tier components, including Oracle Portal.
Refer to the following sections for more information:
By default, the infrastructure tier handles all authentication requests and hosts the Oracle Fusion Middleware Metadata Repository, which contains schemas and business logic used by Fusion Middleware components (including Oracle Portal) and other pieces of the infrastructure.
For the Oracle Portal middle-tier installation, the infrastructure tier is a prerequisite.
The Oracle Fusion Middleware Infrastructure contains:
Oracle Internet Directory. An LDAP version 3 compliant repository for storing user credentials and group memberships for Oracle Portal and other Oracle products.
Oracle Application Server Single Sign-On (SSO). Authenticates user credentials against Oracle Internet Directory for Oracle 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 Metadata Repository. The repository is installed in an Oracle Database and consists of a collection of schemas that contain product metadata for Oracle Fusion Middleware components. Some middle-tier components, such as Oracle 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 Oracle Portal range from installing everything on a single server to multitier configurations in which the pieces comprising Oracle 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).
Oracle Identity Management components and Oracle Metadata Repository, which consists of all the components listed in the preceding two installation types.
Note:Throughout this guide, you will see references to
The following conventions are used in procedures where it is necessary to distinguish between the Oracle instance, middle tier, WLS instance, or Oracle Metadata Repository Oracle home:
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 Oracle 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 Fusion Middleware components serve as portlet providersFoot 1 for Oracle Portal, which means you can easily integrate information from various components into a single portal page. Other components provide essential services to Oracle Portal, as described in the following list.
Oracle Reports. Oracle Portal includes a simple report building facility. However, as your reports become more complex, you may want to import the report into Oracle Reports Services to take full advantage of the functionality it offers. You can deploy any Oracle 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 Oracle 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.
Oracle Secure Enterprise Search. Secure Enterprise Search (SES) 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 Oracle Portal Repository and search public content. Refer to Chapter 9, "Configuring the Search Features in Oracle Portal" for more information about Secure Enterprise Search.
Oracle Application Server Wireless. Working with OracleAS Wireless, Oracle 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.
Oracle 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 5.7, "Configuring Mobile Support in Oracle Portal"for more information.
Oracle Enterprise Manager 11g. Oracle Enterprise Manager 11g provides Fusion Middleware Control. Oracle Enterprise Manager 11g Fusion Middleware Control can be used for monitoring, diagnostics, and for configuring Oracle Portal-specific integration and performance settings. Refer to Chapter 8, "Monitoring and Administering Oracle Portal" for more information about monitoring Oracle Portal.
Oracle Fusion Middleware 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. Fusion Middleware Forms Services deploys Forms applications to Java clients in a Web environment. Fusion Middleware Forms Services automatically optimizes class downloads, network traffic, and interactions with the Oracle Database. Fusion Middleware Forms Services applications are secured by the OracleAS Single Sign-On, and accessed from an Oracle Portal environment provided by Oracle WebLogic Server.
Oracle Application Server Single Sign-On. OracleAS Single Sign-On authenticates users who are attempting to gain access your portal. Refer to Section 184.108.40.206, "Relationship Between Oracle Portal and OracleAS Single Sign-On" for more information.
Oracle Internet Directory. Oracle Internet Directory is Oracle's highly scalable, LDAP version 3 service, which hosts the Portal's group membership information. Oracle Portal queries the directory and retrieves the group memberships of the user from the directory to determine what they may access and change. Refer to Section 220.127.116.11, "Relationship Between Oracle Portal and Oracle Internet Directory" for more information.
Oracle Delegated Administration. In addition to querying Oracle Internet Directory for user and group information, Oracle 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. Oracle Portal provides links to the Oracle Delegated Administration Services for users with sufficient privileges to add and change users and groups. Refer to Section 18.104.22.168, "Relationship Between Oracle Portal and Oracle Delegated Administration Services" for more information.
Oracle Directory Integration and Provisioning. Oracle Directory Integration Platform notifies Oracle Portal upon the occurrence of any directory events (for example, user deletions) to which Oracle Portal subscribes. In essence, the directory integration server informs Oracle Portal when a change occurs in the directory that requires a change in Oracle Portal. Refer to Section 22.214.171.124, "Relationship Between Oracle Portal and Oracle Directory Integration Platform" for more information.
Metadata Repository. The metadata repository is created using the Repository Creation Utility (RCU) and consists of a collection of schemas that contain product metadata for Oracle Fusion Middleware components. Oracle Portal, store their metadata in this repository and need access to that metadata during run time.
A portal comprises 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 Oracle 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 personalizations are stored in the database as part of the overall page definition, completely separate from any portlet content. This information may, in turn, be cached by the middle tier.
The fully assembled page may be cached in Oracle Web Cache based on the page's caching properties. However, if full-page caching is used, pages are not re-assembled with each request, because they are served directly out of Oracle Web Cache.
The portlets that appear on the page can be written in PL/SQL or Java. For PL/SQL portlets, the source is an Oracle Metadata Repository database. This could be the database where the current instance of Oracle Portal is installed, or some other Oracle 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 content from many different providers. These providers can be database providers, Web providers, or WSRP producers.
Figure 1-4 shows how a typical page is assembled. In this release, Oracle Web Cache, using Edge Side Includes (ESI) processing, is the entry point for page request processing rather than the PPE. The various pieces of metadata involved in a page request are cached at a more granular level, increasing the cache hit ratio and enabling a more granular invalidation of portal content. This new approach also provides support for secure full page caching in Oracle Web Cache.
Figure 1-4 Portal Page Request Flow
Figure 1-4 shows the steps performed when a client requests an Oracle Portal page.
The client browser requests a portal page. Oracle Web Cache receives this request.
Oracle Web Cache retrieves the page stub. You can think of the page stub as a blueprint for the page that is to be assembled. If the page stub is not already cached in Oracle Web Cache, then it is generated by the Portal Services running in the Oracle Portal instance
Note:The Portal Services are used to assemble portal pages, access portal and page metadata, and so on. The Parallel Page Engine (PPE) continues to be 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 Web Cache parses the page stub and retrieves additional user and page security metadata. Examples of the User Metadata (UMD) are user name, device type, and language. This user information is gathered once per session per user. If the UMD is not already cached in Oracle Web Cache, then it is generated by the Portal Services running in the Oracle Portal instance. The page security metadata (SMD) contains information that is used to determine whether the user is authorized to see the content at a given URL. If the SMD is not already cached in Web Cache, a request is sent through Portal Services to the portal schema in the Oracle Metadata Repository (not shown in Figure 1-4). If the user has not logged in and is requesting private data, then the user will be challenged to log in. An error page displays if it turns out that the user is not authorized to view the page.
Oracle Web Cache returns the already fully assembled copy of the page if it is found in the cache. Otherwise, it requests the content from Portal Services. The content of the page is assembled as follows:
Portal Services tries to get the cached copy of the page metadata (PMD) from Oracle Web Cache. The PMD, or the page definition, contains information about the portlets on a page and their layout. If there is a cache miss in Oracle Web Cache, then it checks if the portal cache has a valid cached copy. Finally, if no cached copy of the PMD exists, then the portal schema in the Oracle Metadata Repository generates the PMD.
Portal Services retrieves common page components, such as navigation portlets, banners, tabs, and subpage regions, from Oracle Web Cache if they exist. These requests are performed in parallel. A request is sent to the portal schema in the Oracle Metadata Repository if no valid cached copies exist.
For each portlet on the page, Portal Services checks if a cached copy of the portlet's content exists in the Portal Cache. If there is a cache hit, the cached content is used. If there is a cache miss, Portal Services fetches the content from the appropriate provider. These requests are performed in parallel along with the requests described in the preceding step. Each provider returns content for the portlet. Content can be requested from Web providers, WSRP producers, or Database (DB) providers.
Oracle Web Cache returns the fully assembled page to the client browser.
The Oracle 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 Oracle 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 Oracle 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 Oracle Portal.
Figure 1-5 Communication Flow and Protocols
The three tiers and the communication protocols used between them is described next:
The client sends a request to Oracle Portal, which is part of the middle tier, using the HTTP or HTTPS protocols. 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 or HTTPS and supports the implementation of both firewalls and reverse proxies in the network environment.
The infrastructure tier consists of the Oracle HTTP Server, OracleAS Single Sign-On, Oracle Internet Directory, and Oracle 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 Oracle 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 Oracle Metadata Repository, the Oracle 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 Oracle 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 HTTPS-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.
The middle tier is divided into tiers:
The middle tier consists of the Application Tier and Web Tier, includes Oracle Web Cache, Oracle HTTP Server, Oracle WebLogic Server, and other Oracle Portal components.
Note:Oracle Web Cache, Oracle HTTP Server, and Oracle WebLogic Server can be installed on different hosts to allow scalability and high availability.
Oracle Web Cache front ends the middle-tier components and thus optimizes the throughput of Oracle Portal. When a page request comes from the browser, Oracle 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, Oracle 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 Containers for J2EE. A URL request to the servlet is forwarded through the Oracle HTTP Server's plug-in, mod_weblogic. As a standards-based plug-in, mod_weblogic communicates with Oracle Containers for J2EE using the Apache Java Protocol (AJP).
The WSRP container is a Java portlet container that implements the WSRP specification and the Java Specifications Request (JSR) 168 APIs.
The PPE itself makes requests to database providers, Web providers, and Web Services for Remote Portlets (WSRP) producers through HTTPS-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 or HTTPS, and the call to a WSRP producer is by use of the WSRP communication protocol using the Web Services Definition Language (WSDL) URL.
If any Web providers require information from the Oracle Metadata Repository, they issue the appropriate call through the PDK using a SOAP-based message protocol over HTTP or HTTPS.
The Oracle 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 Oracle Portal experience, or if the privileges configured to use the user changes, the Oracle Portal invalidates the appropriate cached objects within Oracle Web Cache. To do this, the Oracle Portal issues a HTTPS-based request directly from the Oracle Metadata Repository to the invalidation port of the Oracle Web Cache.
Oracle Portal caches data in the following locations:
Browser – Data that does not change between requests can be cached in the browser, for example, expiry-based pages.
Oracle Web Cache – Many types of portal data are stored in this in-memory caching system. See Section 1.3.1, "Understanding Oracle Web Cache".
Portal Cache – Many types of portal data are also stored in this persistent file system-based cache. See Section 1.3.2, "Understanding Portal Cache".
Oracle Portal uses three methods to cache Web pages and content:
Invalidation-based caching is used by Oracle Web Cache. An item remains in the cache until it is explicitly invalidated. For example, a user may update some item, requiring the cache to be invalidated. As part of the update, the Oracle Metadata Repository or a Provider sends an invalidation message to Oracle 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 126.96.36.199, "Setting the Expiry Time for Invalidation-based Caching" for more information.
Validation-based caching is used by the portal cache. Before an item in the portal cache is used, Portal Services contacts the Oracle Metadata Repository or a Provider to determine if the cached item is still valid.
Expiry-based caching is used by the portal cache, Oracle Web Cache, and browsers. Expiry-based portlets are cached in the portal cache, whereas, expiry-based assembled pages are cached in Oracle Web 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.
Caching can be done at the following levels:
User – A separate copy of the data is cached for each user.
System – A single copy of the data is cached for all users.
Oracle Web Cache is a powerful server acceleration and load balancing solution. Oracle Web Cache is required for running Oracle Portal. Oracle Web Cache offers intelligent caching, page assembly, and compression features. Oracle Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Fusion Middleware.
To increase the availability and scalability of medium to large deployments, consider configuring multiple instances of Oracle Web Cache to run as members of a cache cluster. A cluster is a collection of cooperating Oracle 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 Oracle 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 Oracle 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.
Oracle 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
Layer 7 load balancing and failover detection
Performance assurance and surge protection
Portal sites can choose from the following deployment options:
Collocated: Web Cache runs on the same physical server as the Oracle 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 Oracle Portal middle-tier servers. Dedicated deployments are usually preferable to collocated deployments, as there is no risk of resource contention with other server processes. Oracle 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 Oracle Web Cache and Oracle 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. Oracle 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. Oracle Web Cache can be used to balance the load between multiple Oracle 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 Oracle Web Cache may be deployed behind a Load Balancing Router (LBR). If you have multiple deployments of Oracle 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 6.7, "Managing Oracle Portal Content Cached in Oracle Web Cache" for more information about configuring Oracle Web Cache.
In addition to providing failover, an Oracle Web Cache cluster also balances the load it forwards to the middle tier.
Figure 1-6 Adding Oracle Web Cache to a Medium to Large Portal Configuration
After the initial request to the owner node, the content is cached across any requesting instances. In Figure 1-6, the LBR distributes incoming requests to the three Oracle 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 page matching the request is returned to the Browser.
To take advantage of Oracle 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 Oracle Web Cache instance and a matching middle-tier instance. As shown in Figure 1-6, Oracle Web Cache 1 provides load balancing between middle tiers 1, 2, and 3. Oracle Web Cache 2 and 3 do the same.
You will find additional information about caching and performance on the Oracle Technology Network (OTN).
Portal cache is a file system-based cache for Oracle 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 Oracle Portal, which includes page metadata, database portlets, Web portlets, documents, style sheets, images, and full-page caches.
Oracle 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 and is configured in the file
\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf. You can specify content cache for Oracle Portal from the Fusion Middleware Control. See Section 5.6.6, "Configuring the Portal Cache Using Fusion Middleware Control" 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 must 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:
Total cache size
Maximum cacheable file size
Maximum time a cached file can be in the cache system
Cleanup of the cache storage
Oracle Portal makes use of two caching systems: Oracle Web Cache, and portal cache. Oracle 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 are queued up over the duration of a single browser request and are then processed when the Oracle 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 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 Oracle Web Cache
When either hard or soft invalidations are processed, a TCP/IP connection is established with the Oracle Web Cache invalidation port from the Oracle Metadata Repository, to send invalidation messages.
For both hard and soft invalidations, all the messages queued are sent using a TCP/IP connection to Oracle Web Cache. Oracle Web Cache receives these invalidation messages and attempts to invalidate cached data. This load may affect Oracle 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 Oracle 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.
The WSRP specification is a Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container based on a particular language (such as Java, .NET, Perl) and any WSRP portal. Therefore, a portlet (regardless of language) deployed to a WSRP-enabled container can be rendered on any portal that supports this standard. For more information about WSRP, see
JPS is based on JSR 168 and JSR 286. It defines a set of APIs for building standards-based portlets using Java. Portlets built to this specification can be rendered to a portal locally or deployed to a WSRP container for rendering portlets remotely. For more information about JSR 168, see
You are ready to move on to Chapter 2, "Planning Your Oracle Portal", now that you have a basic understanding of the Oracle Fusion Middleware architecture, how Oracle Portal fits in, the working of caching in Oracle Portal, and WSRP producers. By the end of that chapter, you should have a good idea of how you want to configure your installation.
Footnote LegendFootnote 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.