Static Enabler: A Response Enhancer for Dynamic Web Applications

Static Enabler: A Response Enhancer for Dynamic Web
Applications
Osama M. Khaled
Vodafone Egypt
7A Corniche El Nil, Cairo, Egypt
+20105800582
osama.mabrouk@vodafone.com
okhaled@aucegypt.edu
Hoda M. Hosny
The American University in Cairo
P.O. Box 2511113 Sharia Kasr El Aini,
Cairo, Egypt
+2027975314
hhosny@aucegypt.edu
ABSTRACT
In this paper, we describe a solution for dynamic web applications that need to optimize their performance for
responsiveness. The solution is described as a design pattern to be shared among developers from different
technical backgrounds. The Static Enabler design pattern enhances the performance of a dynamic web
application by converting some of its pages into static ones without losing the reference to the original pages.
1. INTRODUCTION
The Internet was a major breakthrough in the field of information technology. It was an easy method to share
information and as part of this evolution, people started to post their information on websites. A website is a
designated location on the Internet where information is published. It normally contains a mixture of different
media objects, like images, flashes, and text. Static websites emerged as the first elements of this technology.
The only backend application needed to serve a static website is a web server which serves pages directly to the
users. Web applications that depend on static pages are sufficient for small businesses where information is not
expected to change quickly. However, if the business size gets bigger, the need for a dynamic web application
becomes mandatory.
An application that runs over a content management system can publish its content using two methods. The first
one is to build a dynamic web application that interacts with the content management system. The second choice
is to publish the content in static pages, if such feature is available in the content management system, or to
implement an application that will generate the content into static pages. Usually, the first choice is the most
preferred one since it provides higher flexibility in integration with legacy systems than converting the content to
static pages.
A dynamic web application is a very important media for the business nowadays. A dynamic web application
can simply be defined as an application that requires additional server-side processing, besides the web server
processing time, to generate the static content. It provides the business with a lot of online services which speed
up the interaction between the company and the customer. A dynamic web application is also important because
it can be integrated with existing legacy systems. It provides the customers with the facility of communicating
directly with the backend systems and relieving the system administrator from unnecessary work. The main
reasons that a dynamic web application is needed for are: -
1. When content management for a static website is difficult.
2. When a static website cannot be integrated with other legacy systems. A dynamic web application is
mainly needed to achieve an interactive communication with the website users and the already existing
backend.
3. When legacy systems have tons of information that can take a very long time to send and much disk
space to be manually posted on a static web application.
4. When periodic and automatic changes of content cannot be supplied using a static website

5. When a content management pool, e.g. a database, better represents logical and consistent relations of
components in a web application.
On the other hand, a static web application has the following benefits over a dynamic web application: -
1. It responds much more quickly.
2. It is more robust and reliable.
3. It has fewer problems.
4. Implementation is straightforward and can be done more quickly than for a dynamic website which can
have many complexities in the backend.
5. It saves server CPU cycles and memory utilization.
Optimizing web applications performance was implemented on software and hardware levels. All optimization
solutions want to achieve a final goal, which is to serve the user request as fast as possible. Software solutions,
like caching and web server tuning, improve the performance to a noticeable degree. Hardware solutions, like
increasing the memory size and CPU speed, do enhance also the performance. However, they can be sometimes
insufficient costly techniques, and may not pay off for the needed performance.
In fact, a dynamic web application contains many delaying factors especially if it is composed of more than one
system. Every system has to be tuned separately in order to achieve the optimum performance and minimize the
delaying factors as much as possible. However, system tuning does not mean that the web application will give
the best of it. At the end, the performance problem can still exist if the application logic, for example, cannot be
optimized or there is an unexpected delay from one of the systems due to unexpected failure. Although
additional server-side processing is mandatory for dynamic web applications, it is considered to be the major
factor for delaying the client response time. Compensation between the available resources and the required
performance can be a very difficult equation for a dynamic web application and the cost will not, most probably,
be cheap.
The Static Enabler pattern is part of a pattern language suggested by the first author for performance optimization
in database-driven web applications [3]. According to Loosly et al [2], the traversed path for downloading a web
page contains phases of network connectivity, server-side processing, and content download and rendering. The
Static Enabler Pattern minimizes the server-side processing time for the sake of enhancing the responsiveness
behavior. It is concerned with web applications content representation and the technology behind it is in such a
way that would improve performance. Sections (2 through 8) describe our design pattern and are organized
according to the design pattern template mentioned by Gamma et al [1] with some variation.
2. CONTEXT
In light of the mentioned benefits for dynamic and static web applications, the Static Enabler pattern can be used
efficiently as follows: -
The dynamic web application does not rapidly change its content.
The dynamic web application needs to show more responsiveness selectively for certain dynamic pages.
There are limited hardware resources and software resources.
The web application is composed of at least a web server and an application server.
The application server and all other legacy systems may have limited capacity, already loaded, or known
application server and legacy systems’ tuning are not enough to have the required performance.
There is a need to off load the application server and all its dependencies and depend more on the web
server.
Dynamic web pages do not depend on session attributes.

3. PROBLEM
The problem is how to avoid the additional server-side processing for dynamic web applications that must be
constructed from other legacy systems to make the user experience a better performance. How to develop a
highly responsive dynamic web application regardless of the delaying factors that are caused by the legacy
systems.
4. FORCES
The following points are considered the main considerations for the Static Enabler pattern:
• Hardware and Software Resources: the solution should take into consideration the available hardware
resources (e.g. memory, CPU, and disk space).
• Legacy Systems Availability: There is a need to minimize the access to the legacy systems in order to do
other activities over them.
• Complexity: the solution should be simple and straightforward and must not corrupt the functional
requirements of the application.
• Administration: it should be possible to administrate the solution from inside the application.
• Navigational Model: the solution must not spoil the designed navigation paths of the web application.
• Content Validity{ XE "Content Validity" }: the solution must not spoil the content of the new of modified
web pages.
• Transparency: the solution should be transparent to the user.
5. SOLUTION
A web application performance can be enhanced greatly by converting dynamic pages into static ones. In
addition, the reference to the dynamic pages is checked at runtime in order to get the static page instead of the
dynamic one, if converted. The static pages’ content is refreshed every now and then. You may imagine the
solution as if there is a person in the backend doing all difficult stuff and prepares the static pages to the end user
who will access them directly. See below Figure 1 for more clarification. It shows that the user request goes to
the web server and the request goes to the application server with the minimum load which is the normal case for
static web pages. It was proofed that a static page served by an application server shows a better response than a
dynamic page with caching capabilities and served more users as well [3].

W e b S e r v e r
1
4
A p p lic a tio n
S e r v e r
5
2
E n d
U s e r
6
1
7
g e n e r a t e
s t a t ic
p a g e s
B a c k e n d
s o lu tio n
4
3
L e g a c y
S y s t e m s
2
3
Figure 1 Conceptual View of the Pattern
The pattern consists of four components as shown in Figure 2: -
1. Page Mapping Repository{ XE "Page Mapping Repository" }: Where the full path of the static page is set for
the dynamic page. Only the pages that will be converted are specified here.
2. Page Converter{ XE "Page Converter" }: which is responsible for converting all the dynamic pages specified
in the repository to their counter part static pages.
3. Page Reference Keeper{ XE "Page Reference Keeper" }: It makes sure that the embedded links inside the
converted page are pointing to the converted static pages, if found for that link. It works directly with the
Page Mapping Repository. However, its role will be shown when the Page Mapping Repository is filled
with page mapping entries.
4. Scheduler{ XE "Page Conversion Scheduler" }: It schedules the run of the page converter to update the
content inside the static pages.

Figure 2 Converting Dynamic Pages to Static ones: Pattern Structure
The systematic use of the pattern is shown in Figure 3. It starts by wrapping all the page links that will be
converted to static ones using the Page Reference Keeper. It is also recommended to wrap all other pages for
future conversion. Page Reference Keeper will always get a valid link even if there is no static page for the
specified dynamic page. The repository can be filled either before or after wrapping all the links. Actually, the
Page Mapping Repository is the way to control the conversion. The repository administrator can remove all the
entries to make the display purely dynamic, fill it with all the page links to make it purely static, or make a
mixture of this and that depending on the system capabilities.
One may think of the Page Converter component as a client to the system which is triggered by the Scheduler to
make period requests. It makes use of the web application backend, which is already capable of sending static
content out of the dynamic pages, to retrieve the content and save it on disk. This makes the pattern completely
independent from the technology used to build dynamic or static pages.

Figure 3 Static Enabler (Ideal Scenario)
A proper selection for dynamic web pages for conversion is the success factor for the solution. To explain more,
there may be some dynamic pages that load the application server with a lot of work and if they are selected for
conversion, the performance will be enhanced noticeably. On the other hand, the developer may see that it is a
weak solution because he/she did select non-influencing pages. So, first the developer must understand the
performance bottlenecks of the web application then decide which pages to be converted, if not all of them. For
example, a web page that accesses a database, LDAP, and a billing system to post information, is better selected
than another page which depends on database only.
Second, there must be a well-defined scheduling policy for conversion. For example, if the content is updated
once per week, then the Page Converter should also run at least once per week. It should run daily if the content
changes frequently. It may be triggered if there is a need to show the content directly after it is changed on the
content management system.
6. IMPLEMENTATION
The solution implementation is easy, straightforward and does not require big effort. Let’s start by describing the
basic classes shown in Figure 2. The guidelines and implementation suggested here are merely ways to help
developers find their way in similar situations. Developers are responsible for making proper implementation.
The Page Mapping Repository class is considered to be data access object (DAO) to the dynamic page names and
their assigned static page names. The page names may be saved in a database or and LDAP, for example, or they
can be defined in a plain text file. It loads the mappings and stores them in memory. For fast access, the
mapping entries should be indexed. Ready-made libraries, such as java.util.Hashtable in Java, can provide the
needed indexing criteria. The following Java code shows the basic Page Mapping Repository class structure to
be implemented

class PageMappingRepository {
java.util.Hashtable mapping = null;
public java.util.Hashtable getMappingsDAO() {
if (mapping == null) {
synchronized(this) {
// access DB, LDAP, or text file and return the result in a hashtable
}
}
return mapping;
}
}
The Page Converter, as shown below, streams the content of a dynamic web page and saves it on a physical
location. It uses the Page Mapping Repository class to retrieve the mapping list of dynamic pages. There are
ready-made libraries as well in most of the programming languages to make a URL connection and to save files
in a physical path.
class PageConverter {
String targetPath = “Put the physical static pages path“;
public String readWebPage(String webPagePath) {
}
public Boolean savePage(String webPageContent, String path) {
// save the content to the path which is composed of the targetPath + static page
// path
}
public void convertPages() {
// 1. use the PageMappingRepository class to get a list of all the pages
// 2. Loop over the pages and convert those that have a static name mapping
// using readWebPage(String) and savePage(String, String)
}
}
The Page Reference Keeper will decide on the final link which will appear in the web page. The appearance of
the link may vary according to the needed shape of the link. For example, the class may return the link directly
or wrap it with a javascript code. However, the simple and direct path is to return the static or dynamic web page
directly according the Page Mapping Repository. The code below shows an implementation example.
class PageReferenceKeeper {
static public String getPageName(String dynamicPageName) {
if (mapping == null) {
mapping = getMappingDAO();
}
String staticPageName = mapping.get(dynamicPageName);
return staticPageName == null ? dynamicPageName : staticPageName;
}
}
The Scheduler implementation can simply be a class with some waiting time till the next call of the Page
Converter.

The Dynamic web page code will utilize the Page Reference Keeper to make sure that there is always a valid
link. The following code shows how to use it in a JSP page.
<HTML>
<BODY>

<A HREF=”<%= PageReferenceKeeper.getPageName(“/priceplans.jsp”)%>”>Price Plan</A>
<A HREF=”<%= PageReferenceKeeper.getPageName(“/roaming.jsp”)%>”>Roaming</A>
</BODY>
</HTML>
7. CASE STUDY
One of the most important issues in this pattern is to maintain the navigation model of the web application. This
case study provides a simple example that shows valid links in the initial navigation model and the final
navigation model. Assume that there is a web application that contains five pages page1.jsp, page2.jsp,
page3.jsp, page4.jsp, and page5.jsp and that they are interlinked as shown in Figure 4.
Page1.jsp
Page4.jsp
Page2.jsp Page3.jsp
Page5.jsp
link
link
link
link
link
link
link
link
link
link
link
link
Figure 4 Example of a Web Application Navigation Model

Assume also that the Page Mapping Repository contains the following mapping shown in Table 1
Table 1 Page Mapping Repository
Dynamic Page Full Path Static Page Full Path
http://<dynamic_path>/page1.jsp /<static_path>/page1.html
Table 1 indicates that all the dynamic pages on the left should be converted from the <dynamic_path> server to
static pages and saved on the physical machine path <static_path>. The assumption is that Page Converter has
full access to dynamic and static paths. Moreover, a web server should serve the static path.
Page Converter starts its work by listing out all dynamic pages in the table page1.jsp, page2.jsp, page3.jsp,
and page4.jsp, then converting them, and finally saving them as static text format pages on the specified static
path. Page Converter will run periodically according to the scheduler to convert all the pages in the list again.
More enhancements can be added to the scheduler to trigger Page Converter only if content is changed and
convert only the pages that are related to that content. The web application now contains the following pages
with their embedded links (
Table 2):
Table 2 Web Application Navigation Model (Dynamic & Static) without using Page Reference Keeper
Dynamic Page Static Page Embedded Links
Page1.jsp Page1.html page2.jsp
page3.jsp
page4.jsp
page3.jsp
page5.jsp
page4.jsp
page5.jsp
Page5.jsp page2.jsp
page4.jsp

If we assume that the static html pages are accessible to the end user, then he/she will access them only once and
he/she will end at the dynamic pages again. So, before converting the dynamic pages to static, Page Reference
Keeper must wrap all the links inside all the five pages. It will make sure that there is a link to the static page if
found or it keeps the only dynamic link as is. Table 3 shows the web application initially where the dynamic
page links are wrapped by the Page Reference Keeper. After the Page converter runs, the page links will be set as
shown in Table 4
Table 3 Web Application File Tree with Page Reference Keeper
Dynamic Page Embedded Links
Page1.jsp Keeper(page2.jsp)
Keeper(page3.jsp)
Keeper(page4.jsp)
Keeper(page3.jsp)
Keeper(page5.jsp)
Keeper(page4.jsp)
Keeper(page5.jsp)
Keeper(page4.jsp)
Table 4 Web Application Page Tree (Dynamic & Static) using Page Reference Keeper
Dynamic Page Static Page Embedded Links
Page1.jsp Page1.html page2.html,
page3.html
page4.html
Page2.jsp Page2.html page1.html
page3.html
page5.jsp
page4.html
page5.jsp
Page5.jsp page2.htm
page4.html

Although page5.jsp is not converted to a static one, the Page Reference Keeper can still function and get the right
reference. This feature allows the web application behavior to stay as designed and any other expected
references to dynamic pages will still function correctly. In other words, both dynamic and static pages are kept
for use according to the need.
8. CONSEQUENCES
There are some benefits for using Static Enabler pattern: -
Performance: The developer can work with limited hardware and software resources and see noticeable
performance enhancement. At the same time the end user will experience a better response from the web
application.
Availability: It relieves the application server from dynamic page access. It relieves all other legacy
systems from a lot of access as well because most of the burden is thrown to the web server; hence,
increasing the stability of the application server and the legacy systems which can be secured for other
activities. Moreover, some legacy systems can be temporarily shutdown if their dynamic pages are
converted to static ones.
Less CPU and Memory Utilization: It relieves the hardware from unneeded CPU and memory utilization
since most processing time will be I/O from the web server.
Web Technology Independence: The solution works directly on the application servers' engines. In other
words, the solution does not need to know that it is ASP or JSP technology, for example, in order to
convert a dynamic web page to a static one. Put it with any application server technology currently
available and it will work perfectly.
Scalability: The solution allows the developer to decide working with a complete dynamic web
application, a complete static web application, or a hybrid one.
Simplicity: The solution is simple and straightforward.
Search Engines Fast Indexing: Search Engines index static web pages much faster than the dynamic web
pages.
There are some liabilities of using Static Enabler pattern:
Content Validity: The content of the static pages may not be updated directly if the Scheduler is not
triggered after the backend information is changed. So, there will always be a period of time between
updating the backend system and updating the static web pages.
Disk Space: The web application will need more disk space for the generated static web pages. However,
the modern hard disks can have plenty of space which may not be a problem for any system.
Search Engines Valid Reference: Switching between dynamic and static pages may lead to an invalid
reference with outdated information. Moreover, changing the names of the static web pages may spoil
the preserved references on search engines. User may find a search result that is hosted on a web
application, but because of unwise management of the Page Mapping Repository, the reference may be
lost. The search engines will take sometime until the website is re-indexed.
Applications that change their content rapidly may suffer unneeded access to the web server if the Page
Converter is scheduled to run on short periods. For example, a website for stock exchange market may
cause a very high CPU usage on the hosting machine to generate a static web page. This load is not
justifiable if the website access rate is not high. So, it may be preferred to leave these dynamic pages act
as designed.
9. USED IN
The following are examples from industry that use the idea of enabling content in static pages: -

The Static Enabler pattern is used in Vodafone Egypt corporate website. It was initially designed to
convert first level pages into static ones.
Vodafone Egypt corporate website content management has got a preview application for the website
which incorporates the same solution as well.
Many Database Management systems, like Oracle and SQL Server, have such a functionality of
generating content in static pages.
Many known products like(MS word, MS Excel, etc …) publish their files in HTML format.
10. CONCLUSION
A dynamic web application{ XE "dynamic web application" } can benefit a lot if there are static pages bundled
inside it. First, highly accessed dynamic pages can be converted to static ones to introduce a faster response,
while still keeping the dynamic page for other references and at the same time saving disk space. Second, the
decision can be taken to convert all the dynamic pages to static ones or just leave the dynamic ones according to
the capabilities of the working environment. Also, some backend systems can be temporarily shutdown if their
counterpart dynamic pages are converted to static ones. In general, having static pages in a web application
makes it more responsive and reliable.
Moreover, “design patterns” is defined as the abstraction from a concrete form which keeps recurring in specific
non-arbitrary contexts [4]. Design Patterns offer a technology that builds up experience, documents it, and makes
it available for developers coming from different backgrounds. We found it very useful to document this problem
and its solution in a pattern format to easily address the technical people.
11. AKNOWLEDGMENT
Authors would like to acknowledge the following people for their help: -
- Hassan Ali (IBM Egypt): for putting the basis of the pattern solution.
- Klaus Marquard (Viking PLOP): for his useful comments as a shepherd that helped us getting the paper much
better and discovering more about the pattern.
- Waleed El-Sonbaty (Vodafone Egypt): for his support and encouragement to this paper.
12. REFERENCES
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns, Elements of Reusable
Object-Oriented Software. Addison. Wesley professional computing series.
[2] Chris Loosley, Keynote Systems Inc. Richard L. Gimarc and Amy C. Spellmann, HyPerformix Inc (2000). E-
COMMERCE RESPONSE TIME: A REFERENCE MODEL.
[3] Osama Mabrouk Khaled (2004). Capturing Design Patterns for Performance Issues in Database-Driven Web
Applications. M.Sc. Thesis, Computer Science Department, the American University in Cairo.
[4] Dirk Riehle and Heinz Zullighoven (1996). Understanding and Using Patterns in Software Development.
Wiley & Sons, Inc.

Static Enabler: A Response Enhancer for Dynamic Web Applications

More Related Content

Similar to Static Enabler: A Response Enhancer for Dynamic Web Applications (20)

More from Osama M. Khaled (8)

Recently uploaded (20)

Static Enabler: A Response Enhancer for Dynamic Web Applications