ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaie_5.4.0.1/rzaietriggeredcacheman.htm

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">&lt;!-- %fragment (/source-name, /default-name) --&gt;</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> --&gt; <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>&lt;html&gt;
...
&lt;!-- %fragment(B.html) --&gt;
&lt;!-- %fragment(C.html) --&gt;
...
&lt;/html&gt;</pre>
</td>
<td valign="top" width="33.2089552238806%" headers="d0e166 "><pre>&lt;html&gt;
...
&lt;!-- %fragment(D.html) --&gt;
...
&lt;/html&gt;</pre>
</td>
<td valign="top" width="33.582089552238806%" headers="d0e169 "><pre>&lt;html&gt;
...
&lt;!-- %fragment(C.html) --&gt;
...
&lt;/html&gt;</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> --&gt; <em>A</em>, <em>C</em> --&gt; <em>A</em>,
and <em>C</em> --&gt; <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 &lt;html&gt;
and &lt;body&gt; 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">&lt;!-- %begin-fragment( name ) --&gt;</pre>
<p>A
wrapper directive ends with the following tag: </p>
<pre class="block">&lt;!-- %end-fragment --&gt;</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>