Virtual Shopping Mall accelerated with OracleAS Web Cache - Readme

Table of Contents 

• Introduction
• Overview of the Virtual Shopping Mall Application
• Role of Oracle AS Web Cache in VSM
• Installation and Configuration

Oracle Application Server Web Cache is the state-of-the-art server accleration soultion that improves scalability, performance and availability of web-based applications. From the ground, Web Cache was designed to acclerate dynamic web based applications to reduce hardware and bandwidth costs. Web Cache sits in front of application web servers, cache their content, and provides that content to web browsers that request it

Edge Side Includes (ESI) is an open specification, to develop a uniform programming model to assemble dynamic pages. ESI is an XML-like markup language. ESI markup tags are used to create a template page that fetch and include dynamic HTML fragments. The fragments themselves can also contain ESI markup tags. Caching rules that are assigned to the template page and HTML fragments, determine the cacheablity of the page at the cache server.

Web Cache is an ESI compliant cache server, which increases throughput, shortens response times and lowers infrastructure costs.

As a case study, let us consider a business firm, Electronics Inc., a distributor of electronic components whose headquarters is in San Francisco, California and has franchisee business units in Europe and Asia. There is currently a Virtual Shopping Mall (VSM) where its customers can place online orders.

Virtual Shopping Mall Application

The Virtual Shopping Mall (VSM) sample application enables

• Franchisees to register and set up online shops.
• System Administrator (Super User) to approve and reject requests for new shops and maintain lists of shop categories.
• Customers to browse through all the shops in the Mall and purchase products of interest.
  

The application identifies three types of users - Mall Administrator, Shop Owner and Mall Customer - each with different privileges.
Here the Electronics Inc is assigned the role of the Mall Administrator and head of each business unit is assigned with role of Shop Owner.

Click here to see more information about VSM Application.

VSM is a J2EE 1.3 compliant application which uses JavaServer Pages as the view component, Apache Struts Framework as the controller and set of EJBs form the business layer interacting with the underlying database. The VSM application initially used <jsp:include> to include fragments in its dynamic content.

The ESI technology offers two models for caching dynamic content

• template/fragement
• control/include model.

jesi:control/include model is used to cache the dynamic content generated by the VSM application. In the control/ include model, the cacheable content is aggregated as included pages from a top level page. The control/ include model is used as follows:

• The top level page is cached using the jesi:control tag
• From the top level page, the content is aggregated using the jesi:include tag.
• While aggregating the content, the top level page and the included pages are treated as individual documents. Hence, the included pages can be cached separately using the jesi:control tag.

The following diagram shows the template followed, while creating the dynamic content in the VSM application.

Fig.2

The jesi:include model naturally fits into VSM application. All the JSP includes where changed to use jesi:include with minor or no changes. Since the VSM application was using the Apache struts Framework controller, minor changes were required. With this minor change, application flow has been changed in such a way that, each request will go through some struts action class defined for the request.

After the above changes, each JSP page can be treated as an individual document. Now, we have to determine the cacheable policy for individual document. Following things were taken into consideration while caching these individual fragments.

• Is the fragment cacheable?
• How long sholud the cached fragment remain in the cache ?
• Does the fragement contain multiple versions?
• When should the cached fragment be invalidated ?

Is the fragment cacheable?

The VSM applications contains JSP docuements which are both static and highly dynamic. For example, login.jsp is static page which is cached by setting the <jesi:control cache="yes"/> tag. The images, stylesheets and java scripts are by default cached, because of the cacheablity rule set in the Web Cache.

The highly dynamic page like shopping cart page which displays shopping cart for every user, are not cached. The pages carry the tag <jesi:control cache="no"/>

How long sholud the cached fragment remain in the cache ?

Once the fragement is made cacheable, we should also specify how long should that fragment reside in the cache. This is done by specifying the expiration value in the jesi:control tag. By default, the content will stay for 86400 seconds (1 day). In the VSM application, the content is allowed to reside in the cache to the default value, unless invalidated based on the application event.

Does the fragement contain multiple versions?

It is common to have multiple versions of the same page. For example, a page can have mulitple version, based on the language. Next challenge in while caching the application, is to handle multiple version of the same page.

The VSM application supports internationalization. It supports English and French language. For English users, the application displays the page in English and in French for the French users. The VSM application was using the 'Locale' object stored in the session, to determine the content language. If we were to read this object every time from the session, then the cached page cannot handle multiple versions. To over come this, the Locale was made to be sent with the request. If Locale is sent along with the request, Web Cache treats each version of the request has distinct page and generates the content for each version of the page and then caches it.

In the VSM application, multiple versions of the page are maintained by passing URL encoded values. For example, the request /vsm/help.do which displays help page of the application is made to maintain multiple version by passing URL encoded values like

• /vsm/help.do?lang=en - for English version of the page
• /vsm/help.do?lang=fr - for French version of the page

When should the cached fragment be invalidated?

To invalidate cache content, Web Cache provides three mechanism viz.,

1. manually using the administration console or sending invalidation messages to the Web Cache
2. Time based- by specifying the expiration time in the cache policies
3. Event based - by explictly sending invalidation message via database triggers or java api's.

In the VSM application, the cached content are invalidated using the event based mechanism. For example, the item details page, which is cached by setting up the jesi:control tag is invalidated when the item detail changes. The item details changes when the shop owner add/modify/ delete the item. When such an event occurs, the particular page is invalidated using the java api's provided by web cache. For example, the following code in ShopOwnerBean.java:updateItem(..), is used to invalidate the item details page, when the item is modified.

  public void updateItem(Item item) throws ItemException {
    ....

    // invalidate cached pages in web cache
    String regExp =  "items.do\\?catName=.*shopID=" +
          item.getShopID() + "\\&subcatID=" + item.getSubCatID();

    WebCacheUtils.invalidatePages("/vsm/",regExp);
    ...

The following code snippet in WebCacheUtils.java is uses to invalidate the cached content.

 /**
  * This method invalidates the given uri from the cache server.
  *
  * @param uri - uri to invalidate
  * @param uriIsPrefix - true, if the uri is in the prefix
  */
  public static void invalidatePages(String uri, String uriPrefix) {
     try {
       Properties props = Utilities.loadParams("webcache");
       String url = "http://" + props.getProperty("webcache.host") + ":"
          + props.getProperty("webcache.invalidation.port");

       String auth = "invalidator:" + props.getProperty("webcache.invalidation.password");

       /* Create Invalidation Connection */
       InvalidationConnection conn = new SimpleInvalidationConnection(url, auth);

       /* Create Invalidation Message */
       Invalidator inv = new Invalidator(false);

       ObjectInvalidator objInv = new ObjectInvalidator();
       objInv.add ( new AdvancedSelectorInvalidator(uri,uriPrefix));
       objInv.add ( new ActionInvalidator("0") );
       inv.add (objInv);
       invMsg.add(objInv);

       /* Send Invalidation Message to Web Cache and print result */
       System.out.println( conn.send(invMsg) );
     } catch (Exception e) {
        e.printStackTrace();
     }
  }

Use of Web Cache in the VSM application reduced the load on the application server. The content assembly and delivery is handled by the Web Cache. The application server is left to do the content generation and processing the user transactions alone.