Using a Cache Hierarchy for a Global Intranet Application

Configuring Common Deployment Scenarios 10-5 ■ Site definition for www.app1.company.com mapped to app1-host1 and app1-host2 ■ Site definition for www.app2.company.com mapped to app2-host 4. Configure Oracle Web Cache server jp.webche-host with the following: ■ Receive HTTP and HTTPS requests on designated listening ports ■ Send HTTP and HTTPS requests to application Web servers us.webche1-host and us.webche2-host on designated listening ports ■ Site definition for www.app1.company.com mapped to app1-host1 and app1-host2 ■ Site definition for www.app2.company.com mapped to app2-host 5. Enable propagation of invalidation messages for each of the caches in the cache hierarchy: 1. Use a text editor to open webcache.xml, located in: UNIX ORACLE_INSTANCEinstance_nameconfigWebCachewebcache_name Windows ORACLE_INSTANCE\instance_name\config\WebCache\webcache_name 2. Locate the INTERCACHE element, a sub-element of the SECURITY element. 3. Modify the ENABLEINBOUNDICC and ENABLEOUTBOUNDICC attributes to YES. For example: ?xml version=1.0 encoding=ISO-8859-1? CALYPSO ... VERSION DTD_VERSION=11.1.1.0.0 GENERAL CLUSTER NAME=WebCacheCluster ... SECURITY SSLSESSIONTIMEOUT=3600 ... USER TYPE=INVALIDATION ... USER TYPE=MONITORING ... SECURESUBNET ALLOW=ALL DEBUGINFO HEADER=YES ... HTTPREQUEST MAXTOTALHEADERSIZE=819000 ... INTERCACHE ENABLEINBOUNDICC=YES ENABLEOUTBOUNDICC=YES SECURITY ... 4. Save webcache.xml. 6. Restart the caches in the hierarchy with the following command: opmnctl restartproc ias-component=component_name This executable is found in the following directory: UNIX ORACLE_INSTANCEbin Windows ORACLE_INSTANCE\bin For more information, see: ■ Section 2.11.1 for instructions about configuring listening ports ■ Section 2.11.2 for instructions about configuring origin server settings ■ Section 2.11.3 for instructions on creating site definitions and site-to-server mappings 10-6 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache ■ Section 7.10.2.2 to understand how invalidation in a hierarchy works

10.3 Using Oracle Web Cache for High Availability without a Hardware Load Balancer

You can make Oracle Web Cache highly available without a hardware load balancer by configuring: ■ Oracle Web Cache solely as a software load balancer of HTTP traffic or reverse proxy to origin servers With this option, you configure one or more caches solely to provide load balancing or reverse proxy support. ■ Operating system load balancing capabilities With this option, you configure the operating system to load-balance incoming requests across multiple caches. When the operating system detects a failure of one caches, automatic IP takeover is used to distribute the load to the remaining caches in the cluster configuration. This feature is supported on many operating systems, including Linux, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, and Windows 2003 all editions. For more information, see Section 3.8 and Section 3.9 for configuration details. Part III Part III Advanced Administration This part presents information about performing advanced administration tasks for Oracle Web Cache. It contains the following chapters: ■ Chapter 11, Caching Dynamic Content with ESI Language Tags ■ Chapter 12, Caching with Third-Party Application Servers 11 Caching Dynamic Content with ESI Language Tags 11-1 11 Caching Dynamic Content with ESI Language Tags This chapter describes the Edge Side Includes ESI tags provided for content assembly of dynamic fragments. ESI is an open specification co-authored by Oracle. Its purpose is to develop a uniform programming model to assemble dynamic pages in a dynamic content cache deployed as a surrogate or proxy between clients and origin servers. ESI is an XML-like markup language that enables dynamic content assembly of fragments by Oracle Web Cache. A template page is configured with ESI markup tags that fetch and include dynamic HTML fragments. The fragments themselves can also contain ESI markup. You can assign caching rules to the template page and HTML fragments. By enabling page assembly in Oracle Web Cache rather than in the origin server, you can increase cache hit rates and improve performance. This chapter includes the following topics: ■ Section 11.1, Introduction to ESI for Partial Page Caching ■ Section 11.2, Enabling Dynamic Assembly of Content and Partial Page Caching ■ Section 11.3, Using Inline Invalidation in HTTP Responses ■ Section 11.4, ESI Tag Descriptions See http:www.esi.org for the ESI language release 1.0 specification.

11.1 Introduction to ESI for Partial Page Caching

Oracle Web Cache provides dynamic assembly of Web pages with both cacheable and non-cacheable page fragments. It provides for assembly by enabling Web pages to be divided into fragments of differing caching profiles. These fragments are maintained as separate elements in the cache. The fragments are assembled into HTML pages as appropriate when requested by end users. By enabling dynamic assembly of Web pages on Oracle Web Cache rather than on the origin servers, you can choose to cache some fragments of assembled pages. With partial page caching , much more HTML content can be cached, and then assembled and delivered by Oracle Web Cache when requested. Furthermore, page assembly can be conditional, based on information provided in HTTP request headers or end-user cookies. The basic structure that an application developer uses to create content for partial-page caching is a template page containing fragments. As depicted in Figure 11–1 , the template consists of common elements, such as a logo, navigation