224 lines
14 KiB
HTML
224 lines
14 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="topic" />
|
||
|
<meta name="DC.Title" content="Triggered cache manager for HTTP Server" />
|
||
|
<meta name="abstract" content="This topic provides information about the triggered cache manager, page assembly, and wrappers." />
|
||
|
<meta name="description" content="This topic provides information about the triggered cache manager, page assembly, and wrappers." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzaieconcepts.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002,2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002,2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="rzaietriggeredcacheman" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>Triggered cache manager for HTTP Server</title>
|
||
|
</head>
|
||
|
<body id="rzaietriggeredcacheman"><a name="rzaietriggeredcacheman"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Triggered cache manager for HTTP Server</h1>
|
||
|
<div><p>This topic provides information about the triggered cache manager,
|
||
|
page assembly, and wrappers.</p>
|
||
|
<div class="important"><span class="importanttitle">Important:</span> Information
|
||
|
for this topic supports the latest PTF levels for HTTP Server for i5/OS .
|
||
|
It is recommended that you install the latest PTFs to upgrade to the latest
|
||
|
level of the HTTP Server for i5/OS. Some of the topics documented here are
|
||
|
not available prior to this update. See <a href="http://www-03.ibm.com/servers/eserver/iseries/software/http/services/service.html" target="_blank">http://www.ibm.com/servers/eserver/iseries/software/http/services/service.htm</a> <img src="www.gif" alt="Link outside Information Center" /> for more information. </div>
|
||
|
<p>The triggered cache manager (TCM) function provides a means to manage cached
|
||
|
copies of static and dynamically produced Web pages including those generated
|
||
|
by CGI programs, Net.Data<sup>®</sup>, or Java™ servlets. The triggered cache manager
|
||
|
function does not provide a cache, but rather a cache content manager. Web
|
||
|
pages are actually cached in such places as local file systems, proxy servers,
|
||
|
or caching network routers. When used in conjunction with an application trigger,
|
||
|
the triggered cache manager function keeps caches synchronized with the most
|
||
|
current data while reducing the frequency of unnecessary dynamic page generation
|
||
|
and cache synchronization. See <a href="rzaietrigger.htm">Trigger messages for triggered cache manager on HTTP Server (powered by Apache)</a> for
|
||
|
more information.</p>
|
||
|
<p>These Web pages can consist of a single object or they can consist of several
|
||
|
objects (or page fragments). Dynamically produced Web pages that embed page
|
||
|
fragments are updated anytime an embedded page fragment changes. </p>
|
||
|
<p>For example, several Web pages are constructed by a Java servlet using
|
||
|
data extracted from a DB2<sup>®</sup> database. These Web pages are in turn cached in several
|
||
|
caching network routers. Web pages are served from the network router caches
|
||
|
rather than from the HTTP server running the Java servlet. When the database
|
||
|
data is changed, an application sends a trigger message to the triggered cache
|
||
|
manager function. Through the use of object dependency graphs, the triggered
|
||
|
cache manager function determines which Web pages need to be updated. The
|
||
|
triggered cache manager function then requests new versions of each affected
|
||
|
Web page from the Java servlet and updates the cached copies in the caching
|
||
|
network routers. </p>
|
||
|
<p>In this example, the Web site performance is greatly increased by serving
|
||
|
cached copies of dynamically produced Web pages rather than serving newly
|
||
|
generated Web pages for each request. The Web site consistency and performance
|
||
|
is again increased by using an application trigger, with the triggered cache
|
||
|
manager function, to update cached Web pages only when underlying data changes.
|
||
|
This avoids unnecessary and costly cache updates and synchronization. </p>
|
||
|
<p>The triggered cache manager function is most effective for a Web site that
|
||
|
has a large number of requests for content that is somewhat constant, but
|
||
|
with variables that change frequently. An example of this might be a Web site
|
||
|
that serves an on-line catalog that contains price and inventory information
|
||
|
(the product information is static, but the price and inventory information
|
||
|
changes frequently). One of IBM's first uses of the triggered cache manager
|
||
|
function was to drive the 1996 Winter Olympic Games Web site. </p>
|
||
|
<div class="section" id="rzaietriggeredcacheman__page"><a name="rzaietriggeredcacheman__page"><!-- --></a><h4 class="sectiontitle">Page assembly</h4><p>Often, advanced Web sites
|
||
|
contain information that appears on more than one page. If the information
|
||
|
changes, all of the pages with that information need to be updated. There
|
||
|
are several potentially difficult problems associated with this: </p>
|
||
|
<ul><li>It can be extremely difficult to find and update all affected pages, especially
|
||
|
as a Web site grows in complexity. </li>
|
||
|
<li>Information with a tendency to change also has a tendency to be expensive
|
||
|
to maintain; for example, database activity might be required to effect an
|
||
|
update. </li>
|
||
|
</ul>
|
||
|
<p>If a Web site's pages can be composed from partial HTML fragments.
|
||
|
Each fragment is unique and any page that contains its information acquires
|
||
|
it by embedding the fragment. This can lead to more flexible, diverse, and
|
||
|
complex Web sites. </p>
|
||
|
<p>The trigger cache manager function provides a
|
||
|
way to assemble Web pages from a set of fragments. If a fragment changes,
|
||
|
the author of the fragment needs only to publish that fragment; the triggered
|
||
|
cache manager finds all the affected pages (data sources), rebuilds them,
|
||
|
and copies the updated pages to the configured delivery locations (cache targets).
|
||
|
</p>
|
||
|
<p>To take advantage of this facility, HTML segments must indicate which
|
||
|
other fragments are to be embedded. This is done with a simple tag very similar
|
||
|
to Server Side Includes (SSI). These tags are used for two purposes: </p>
|
||
|
<ul><li>To determine the dependency relationships among HTML fragments (dependency
|
||
|
parsing). </li>
|
||
|
<li>To physically construct pages from the fragments (page assembly). </li>
|
||
|
</ul>
|
||
|
<p>A publish trigger handler is used to accomplish this task. </p>
|
||
|
<p>The
|
||
|
tag used to specify that a fragment is to be included is specified in HTML
|
||
|
as follows. The keyword <em>%fragment</em> is chosen to avoid conflicts with
|
||
|
SSI. </p>
|
||
|
<pre class="block"><!-- %fragment (/source-name, /default-name) --></pre>
|
||
|
<p><strong>Notes:</strong></p>
|
||
|
<ul><li>The <em>source-name</em> is the name of the embedded fragment, relative
|
||
|
to the data source specified in the server configuration. The data source
|
||
|
is searched in this order: <ol><li>Among the objects triggered. </li>
|
||
|
<li>Among objects in the assembled directory within the repository of published
|
||
|
objects maintained by the triggered cache manager function. These are objects
|
||
|
that might have been fetched as a result of previous triggers and correspond
|
||
|
to the assembled versions of fragments, intermediate results, and final publishable
|
||
|
pages. <p>If the data source is a file system, the source-name is a file name.
|
||
|
If the data source is HTTP, the source-name is the file name portion of a
|
||
|
URL. </p>
|
||
|
<p></p>
|
||
|
</li>
|
||
|
</ol>
|
||
|
</li>
|
||
|
<li>The <em>default-name</em> is the name of another fragment that might be
|
||
|
used as a default when a specified fragment cannot be found. </li>
|
||
|
<li>Nesting is supported. The triggered cache manager function uses the object
|
||
|
dependency graph (ODG) specified in the server configuration to start the
|
||
|
page assembler in the correct order to build pages. </li>
|
||
|
</ul>
|
||
|
<p>For example, when one fragment, <em>fragment A.html</em>, embeds another
|
||
|
fragment, <em>fragment B.html</em>, it is said that <em>fragment A.html</em> is
|
||
|
dependent on <em>fragment B.html</em>. This is denoted as either <em>B</em> --> <em>A</em> or
|
||
|
as the ordered pair (<em>B</em>, <em>A</em>). It is said that there is a dependency
|
||
|
relationship between <em>B</em> and <em>A</em>. Suppose that <em>A</em> also embeds
|
||
|
another fragment, <em>fragment C.html</em>, and that <em>fragment C.html</em> in
|
||
|
turn embeds <em>fragment D.html</em>. </p>
|
||
|
<p>Suppose further that some other
|
||
|
fragment, <em>fragment E.html</em>, also embeds <em>fragment C.html</em>. This
|
||
|
relationship can be represented as a directed graph called the object dependency
|
||
|
graph (ODG). The object dependency graph is for <em>fragment A.html</em> and <em>fragment
|
||
|
C.html</em>. The HTML fragments that describe this look something like the
|
||
|
following: </p>
|
||
|
|
||
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" width="33.2089552238806%" id="d0e163"><em>Fragment A.html</em></th>
|
||
|
<th valign="top" width="33.2089552238806%" id="d0e166"><em>Fragment C.html</em></th>
|
||
|
<th valign="top" width="33.582089552238806%" id="d0e169"><em>Fragment E.html</em></th>
|
||
|
</tr>
|
||
|
</thead>
|
||
|
<tbody><tr><td valign="top" width="33.2089552238806%" headers="d0e163 "><pre><html>
|
||
|
...
|
||
|
<!-- %fragment(B.html) -->
|
||
|
<!-- %fragment(C.html) -->
|
||
|
...
|
||
|
</html></pre>
|
||
|
</td>
|
||
|
<td valign="top" width="33.2089552238806%" headers="d0e166 "><pre><html>
|
||
|
...
|
||
|
<!-- %fragment(D.html) -->
|
||
|
...
|
||
|
</html></pre>
|
||
|
</td>
|
||
|
<td valign="top" width="33.582089552238806%" headers="d0e169 "><pre><html>
|
||
|
...
|
||
|
<!-- %fragment(C.html) -->
|
||
|
...
|
||
|
</html></pre>
|
||
|
</td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
</div>
|
||
|
<p>When the triggered cache manager function is instructed to publish <em>fragment
|
||
|
C.html</em>, it determines that <em>C.html</em> embeds <em>D.html</em>. Similarly,
|
||
|
when <em>A.html</em> and <em>E.html</em> are published, it determines <em>B</em> --> <em>A</em>, <em>C</em> --> <em>A</em>,
|
||
|
and <em>C</em> --> <em>E</em>. These relationships are automatically entered into
|
||
|
the object dependency graph when the fragments are processed by the publish
|
||
|
trigger handler. If <em>D.html</em> is republished at a later time, the publish
|
||
|
application can determine, by examining the ODG, that all of <em>C.html</em>, <em>A.html</em>,
|
||
|
and <em>E.html</em> must be rebuilt but that the old copy of <em>B.html</em> can
|
||
|
be used. Similarly, if only <em>B.html</em> changes, none of <em>C.html</em>, <em>D.html</em>,
|
||
|
or <em>E.html</em> are affected. The entire process of discovering dependencies,
|
||
|
updating the object dependency graph, and composing the correct and only the
|
||
|
correct pages is all automatically performed by the publish trigger handler.
|
||
|
</p>
|
||
|
|
||
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" id="d0e252">Graphical representation of fragment <em>A.html</em></th>
|
||
|
<th valign="top" id="d0e256">Graphical representation of fragment <em>E.html</em></th>
|
||
|
<th valign="top" id="d0e260">Graphical representation of ODG for fragments <em>A.html</em> and <em>E.html</em>.</th>
|
||
|
</tr>
|
||
|
</thead>
|
||
|
<tbody><tr><td align="center" valign="top" headers="d0e252 "><br /><img src="rzaie503.gif" alt="Graphical representation of fragment A.html." /><br /></td>
|
||
|
<td align="center" valign="top" headers="d0e256 "><br /><img src="rzaie504.gif" alt="Graphical representation of fragment E.html." /><br /></td>
|
||
|
<td align="center" valign="top" headers="d0e260 "><br /><img src="rzaie505.gif" alt="Graphical representation of ODG for fragments A.html and E.html." /><br /></td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div class="section"><h4 class="sectiontitle">Wrappers</h4><p>In some cases, most notably when HTML is
|
||
|
generated automatically from HTML editors, it might be undesirable to use
|
||
|
the full HTML content in a fragment. Such applications might insist on producing <html>
|
||
|
and <body> tags, for example, which make the fragment nearly unusable.
|
||
|
To manage this, fragments are also parsed for wrappers. </p>
|
||
|
<p>A wrapper directive
|
||
|
begins with the following tag: </p>
|
||
|
<pre class="block"><!-- %begin-fragment( name ) --></pre>
|
||
|
<p>A
|
||
|
wrapper directive ends with the following tag: </p>
|
||
|
<pre class="block"><!-- %end-fragment --></pre>
|
||
|
<p>When
|
||
|
these are encountered within a document, all text before the initial tag and
|
||
|
following the final tag is discarded. Only the text between these tags is
|
||
|
actually used during page composition. The selected text can be given a
|
||
|
name other than the name of the file in which it occurs. This permits multiple
|
||
|
fragments to exist in the same file. That is, if multiple <em>%begin-fragment</em> and <em>%end-fragment</em> tags
|
||
|
are found, the file is treated as multiple files for the purpose of composing
|
||
|
the page and managing the object dependency graph.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzaieconcepts.htm" title="This topic provides concepts of functions on HTTP Server and IBM Web Administration for i5/OS interface.">Concepts of functions of HTTP Server</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|