|
- A client browser sends a request to DBPrism CMS, this request is routed to an
Apache WebServer, for example, which is listening in the default port (80).
- The Apache WebServer is configured with mod_proxy to route every URL starting
at /dbprism/ to a Servlet container listening on the port 8888.
- In this example an OC4J is configured with the dbprism.ear application file
which defines the mount point /dbprism/ with an instance of Cocoon.
- OC4J pass the URL to zone interpreted by Cocoon, Cocoon receives an URL without
the mount point (/dbprism/), that is /doc/Home.html. At this point Cocoon check
for this page in his own cache and if the page is valid return the cached version,
if not executes the steps 5 and 6.
- Based on the sitemap.xmap definition Cocoon resolves the URL /doc/Home.html
as a content generated by DBPrism, then DBPrism receives a request for an stored
CMS page named /Home.html, note that doc was extracted because is used as DAD
information (information for connecting to the database such as username, password,
connect string and so on).
- A CMS Stored Procedure is executed to retrieve the specific page (/Home.html)
and the page is returned to DBPrism engine, then the page returns in the inverted
path passing to Cocoon (which formats the page and stores it in his Cache System),
OC4J and Apache, finishing in the client browser.
- At this point a Content Writer (like me) writes a new version of the document
/Home.xml (CMS version of /Home.html), and upload it with the CMS Upload Utility
or with JDeveloper using CMS Addin utility.
- The table CONTENT which stores the XML document has a trigger after update which
sends an http message to the Cocoon engine invalidating the cached content.
The invalidation message is sent to the Container directly (not through Apache)
and Cocoon routes the URL /dbprism/x-dbprism-cache-invalidate to an XSP page which
parses this message and contacts the DBPrism External Invalidator Server to
mark the page /doc/Home.html as no longer valid. Note that the post message
includes an username and password encode in a Base64 form. An example of
invalidation message is showed below. After this step a new request comming
from the client browser will be routed following the steps 4,5 and 6.
|
|
