Caching In Web Applications


Caching may help in increasing application performance. Here we will explore ways that will help improve the performance of a Web Application.

What is Cache?

Wiki defines a cache as "a store of things that will be required in future, and can be retrieved rapidly." That is the nub of it. In computer science terms, a cache is a collection of temporary data which either duplicates data located elsewhere or is the result of a computation. Once in the cache, the data can be repeatedly accessed inexpensively.

An application requests data from cache using a key. If the key is not found, the application retrieves the data from a slow data source and puts it into the cache. The next request for a key is serviced from the cache.

cache-hit: When a data element is requested of the cache and the element exists for the given key, it is referred to as a cache hit (or simply ‘hit’).

cache-miss: When a data element is requested of the cache and the element does not exist for the given key, it is referred to as a cache miss (or simply ‘miss’)


Target Usage Areas in a Web Application.

Common factors for which caching can be considered are How many times the cached object can be reused and how long is the response time. Other factor include like how much up to date data the user need. These are some of the factor to be kept in mind before considering caching.

Data Access Layer Caching:

Depending on the data if the data is not changing often there are many queries that can be qualified to be cached and can be served from cache instead of hitting the database.

Data Retrieval from Data Warehouse:

One of the important candidate for cache. As we know there are limited connections to DW and we often get connection limit exceeded error. As DW data is a day old and hitting DW for every call doesn’t make sense. Adding a refresh per day on the cache entity will be good enough.

Web Services Caching

Web services caching can be applied both to client side or server side. The areas specifically are authentication information caching, filtering out calls that result in similar results etc. ( to be investigated ).

Open Source Cache Solutions:

Memcached :

The architecture of Memcached consists of two pieces.

– First is a Memcached server that runs in its own process.

– The Memcached client, the second piece of the Memcached system, does know about each of the servers. The client is responsible for picking up the server for each cache entry and either storing or getting the cache entry

Open source Java caching framework

The Cache framework runs within JVM. The caching framework would create the Cache Manager objects in the same JVM where your application is running.

JSR 107: JCACHE – Java Temporary Caching API :

Specifies API and semantics for temporary, in memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVM’s.

The specification request was proposed in 2001 to standardize java application caching. The project is still pending.

Java Caching System (JCS):

JCS is a distributed caching system written in java. It is intended to speed up applications by providing a means to manage cached data of various dynamic natures.

Like any caching system, JCS is most useful for high read, low put applications. It allows both caching in memory or on disk. JCS supports cluster environment.


EHCache is a fast, lightweight, and easy-to-use in-process cache. It supports read-only and read/write caching, and memory- and disk-based caching.

EHCashe can be used for caching Hibernate (second-level cache), data access objects, security credentials, web pages.

It can also be used for SOAP and RESTful server caching, application persistence, and distributed caching.


OSCache is another open-source caching solution. It is part of a larger package, which also provides caching functionalities for JSP pages or arbitrary objects.

It is a powerful and flexible package, which, like EHCache, supports read-only and read/write caching, and memory- and disk-based caching.

It also provides basic support for clustering via either JavaGroups or JMS.


SwarmCache is a simple cluster-based caching solution based on JavaGroups. It supports read-only or nonstrict read/write caching.

SwarmCache is designed to be integrated in to the persistence layer of a database-driven Java application.

This type of cache is appropriate for applications that typically have many more read operations than write operations.

Comparing Cache Solutions:




Java Caching System (JCS):


Fast and Light Weight

Simple, Small foot print, Minimal dependencies

Simple, Small foot print, Minimal dependencies

Simple and small footprint the whole app size is less than 2 MB

fast, reliable, and highly configurable ,

Small and easy to use API Mostly used for Storing POJO objects


Provides Memory and Disk stores for scalability into gigabytes,
Scalable to hundreds of caches,
Tuned for high concurrent load on large multi-cpu servers
Multiple CacheManagers per virtual machine

OSCache is capable of caching data in memory (so it is very fast), and/or to disk

SwarmCache is an in-memory cache

Support both memory and disk caching

Cashe4J is an in-memory cache


Supports Object or Serializable caching
Support cache-wide or Element-based expiry policies
Provides LRU, LFU and FIFO cache eviction policies
Provides Memory and Disk stores
Dynamic, Runtime Configuration of Caches

Multiple caching algorithms are supported such as LRU (Least Recently Used),
FIFO (First In First Out), or unlimited.
It is also possible to plug in your own custom algorithm.

Supports Caching Algorithms, Least Recently Used (LRU),Automatic

Uses LRU (Least Recently Used) and is more like an object cache.

It supports LRU, LFU, and FIFO caching algorithms

Standards Based

Full implementation of JSR107 JCACHE API

Not standard.

not implemented based on standard JSR-107

JCACHE , JSR-107 But it depends on concurent util package before java 5.

Doesn’t follow standard

Distributed Caching

Support for replication via RMI or Jgroups

OSCache can easily be configured to cluster across multiple boxes

Cluster aware

Support distributed cache.

No Support for clustering


High Test Coverage
Fully documented
Trusted by Popular Frameworks

Project is no more active poor documentation.

Poor Documentation, last update was in 2003

Well documented

No Documentation ( only available in Russian).

JSP Tag Support

No Support

provides caching functionalities for JSP tags,
pages fragments cache, pages or arbitrary objects

No support

No Support

No Support


Apache 2.0 license

Unknown open source.


Apache License

BSD license

Learning Curve and Ease of Usage

easy to configure and learn

easy to configure and learn

complex API

New Term usage and relatively high learning curve




Configuring EHCache in Web Applications


To use Ehcache in Web Application the following configuration is needed

– Create a simple ServletContextListener and create a new instance of Cache and store it as attribute in servlet context

public void contextInitialized(ServletContextEvent sce) {

ServletContext ctx = sce.getServletContext();

CacheManager singletonManager = CacheManager.create();

Cache memoryOnlyCache = new Cache("dbCache", 0, false, true, 86400,86400);


memoryOnlyCache = singletonManager.getCache("dbCache");

ctx.setAttribute("dbCache", memoryOnlyCache );


– To use cache get it from context and pass it to DAO layer to cache the return of the query etc.

– To save an object in Cache

Element resultCacheElement = new

Element(resultSet.getString("EMPLOYEE_NUMBER"), emp);


– To get an object from Cache

Element e = cacheRef.get(personId);

if (e != null) {

emp = (Employee)e.getObjectValue(); // get object from cache


Testing EHCache Performance


Below are the results of Ehcache performance. For the demo we created a simple web application. The application structure is similar to the design of a web application used by Sample Web Application. It utilizes connection pool of Glassfish Server. For testing purpose we made the following tests

1. Calling database 500 times and records the time it takes, similarly we will call Ehcache to get the same.

2. To test how much memory space it takes to store the entire employee from DB to Cache. To store 12K records it takes around 48 MB space.

3. Get 1000 records from database and compare the querying the same from Cache.



Sample Usage of EHCache


All usages of Ehcache start with the creation of a CacheManager

CacheManager manager = CacheManager.newInstance()


Create a CacheManager specifying the path of a configuration file.

CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml");


Performing CRUD operations


Put an element into a cache

Cache cache = manager.getCache("sampleCache1");
Element element = new Element("key1", "value1");

Update an element in a cache. Even though cache.put() is used, Ehcache knows there is an existing element, and considers the put an update for the purpose of notifying cache listeners.

Cache cache = manager.getCache("sampleCache1");
cache.put(new Element("key1", "value1"));
//This updates the entry for "key1"
cache.put(new Element("key1", "value2"));

Get a Serializable value from an element in a cache with a key of "key1".

Cache cache = manager.getCache("sampleCache1");
Element element = cache.get("key1");
Serializable value = element.getValue();

Get a NonSerializable value from an element in a cache with a key of "key1".

Cache cache = manager.getCache("sampleCache1");
Element element = cache.get("key1");
Object value = element.getObjectValue();

Remove an element from a cache with a key of "key1".

Cache cache = manager.getCache("sampleCache1"); cache.remove("key1");

HaJJ QUOTA By Country

Every Muslim country gets a quota of 1,000 pilgrims per million inhabitants, or 0.1 percent of its population.


Rank Country Capital City Total Population Muslim Population Hajj Quota
1 Indonesia Jakarta 237641326 204852000 20485200
2 Pakistan Islamabad 181565000 178092000 17809200
3 India New Delhi 1210193422 177291000 17729100
4 Bangladesh Dhaka 152518015 148602000 14860200
5 Egypt Cairo 82999000 80029000 8002900
6 Nigeria Abuja 166629000 75723000 7572300
7 Iran Teheran 75149669 74809000 7480900
8 Turkey Ankara 74724269 74665000 7466500
9 Algeria Algiers 37100000 34785000 3478500
10 Morocco Rabat 32765300 32376000 3237600

SSO in Web Services Using SAML


Web Services provides a standard mean of interoperating between different software applications running on a variety of platforms. The simplest web service consists of a SOAP message for communication and a WSDL for web service description.

Web services use XML extensively which are very well understood technology. WSDL document defines services as collection of network endpoints or ports.

One of the main problems in distributed Web Services is security standards. Due to different platforms the interpretation of security information has different meaning in different security context. For instance if a J2EE application try to exchange security information with a COM+ application, the data sent by J2EE application will not be recognizable to COM+.  The other problem in distributed Web Services application is the capability for single-sign on. Security Assertion Markup Language (SAML) is a standard proposed by OASIS to solve problem like security information exchange and how Single Sign on capabilities be provided within distributed web services application.


Exploring SAML:

SAML is a set of specifications used for transferring information like user authentication, entitlement, and attributes to identity provider (IP) which can authenticate the user and allow access to resources on a server provider.  In SAML a third party which is identity provider will assert the authentication information provided by the consumer and will return SAML assertion which can be passed with any incoming request to the target or resource provider which will identify the assertion and allow access to the corresponding activity.

By obtaining the assertion from identity provider consumer can pass it with any request. The same assertion can be used universally and by any part of application which is a step forward to interoperability in security context.

All the security services which implemented SAML are able to interpret security information transferred by one service to another which makes SAML one of the most accepted solutions for Web Services Security.  The Assertion generated by identity provider can be used by consumer as long as it is trusted by target or service provider. The Service Provider can accept the principal an allow authentication.

SAML provides three types of assertions:

1. Authentication assertion

2. Authorization decision assertion

3. Attribute assertion.

Authentication Assertion


The authentication information is received by identity providers which process this information and authorization assertion is made along with authorization decision and attributes assertion.  Authentication Assertion is composed of the identity of issuer and the principal, the period for which the assertion will be valid and some creation time information. It also input some information about the provider system and validation time etc.

The following is the Authentication Statement Schema

<element name=”AuthenticationStatement”  type=”saml:AuthenticationStatementType”/>

<complexType name=”AuthenticationStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:SubjectLocality” minOccurs=”0”/>

<element ref=”saml:AuthorityBinding” minOccurs=”0”



<attribute name=”AuthenticationMethod” type=”anyURI”


<attribute name=”AuthenticationInstant” type=”dateTime”





Attribute Assertion


The attribute assertion contains attribute authority of the resources provider. Policies which are used to determine what resources are allowed for a particular assertion type. Attribute assertion is passed to policy decision point which make the decision based on it. In attribute assertion policies are attached to Subject element. Here is the schema definition of Attribute Assertion

<element name=”AttributeStatement” type=”saml:AttributeStatementType”/>

<complexType name=”AttributeStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:Attribute” maxOccurs=”unbounded”/>








Authorization Decision Assertion


 Authorization Decision Assertion is responsible for making the decision about a principal if it have  permission for the requested resource. The requester pass Authentication and attribute assertion .  It comprise of policy decision point (PDP)  and policy enforcement point(PEP) .

A fragment of the authorization statement is presented below:

<element name=”AuthorizationDecisionStatement”


<complexType name=”AuthorizationDecisionStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:Action” “maxOccurs =”unbounded”/>

<element ref=”saml:Evidence” minOccurs=”0/>


<attribute name=”Resource” type=”anyURI” use=”required”/>

<attribute name=”Decision”

type=”saml:DecisionType “use=”required”/>






Exploring SSO in SAML Perspective:

One of the main issues with distributed Web Services application is keeping the logged in information across different applications due to its distributed nature. The consumers have to remember different security credentials for different application. One of the possible solutions to this problem is Single Sign-on. The basic concept is to separate the Security information to another service and can be used across the system. All security information will be stored on different server which will act as a wrapper on top of any business application that need any security credentials. SSO can be hosted as a standalone Web Service.

In SSO the authenticated party or consumer first call the SSO server and request for Security token by providing the authentication credentials. SSO server will do validation and issue a security token. The authenticated party can use these token with any system that implemented or support those security credentials. The service provided will verify those authentication tokens and allows access to resources. The below shows a simple scenario.

Through SAML, a customer can login to one System and the authorization information is passed to the next Service. This makes it very easy for related system to exchange trusted information about customers. SAML provides the base for Single Sign-On where user need to login once and the Systems internally will pass along all the security credentials to next service.

SAML can be transferred through different protocols. For instance it can be passed embedded within a SAOP message on HTTP. SAML defines request and response protocol which enable the service provider to allow or deny a             ccess to a particular resources based on the Subject entity.

Mostly of the time in distributed Web Services environment SAML is used on a separate server which is responsible for issuing the SSO Authentication services. The main benefits of this architecture are the following.

•             Security infrastructure is hidden in a separate server which makes maintenance and monitoring easier.

•             SSO implemented through SAML can be transferred as SAOP message and it can be deployed as a separate web service which makes the implementation API accessible like any other hosted web services.

SAML standardized the request and response messages that are transported from third party to a requester. SAML calls the protocols for transporting the messages to and from the authorities the SAML bindings.

In the above diagram it is clear that each the requester want any interaction with the any service and if authentication is needed, the requester has to authenticate itself with SSO server. Another approach is keep valuable information in the security token itself which the requester can pass whenever there is a need for authentication.

The token will contains information like authentication and authorization and information about SSO Server like sign by a particular SSO server which is recognized by the Service provider. The described scenario is outlined in the following diagram:


SAML contains assertion statements about subjects that SSO Server will transfer as a SOAP message. Client can make request to SSO Server and it will response a message with SAML assertion. The client can use this assertion and call the Service provider which can check proof of origin and decide to allow access to resource or not.

One of the major complaints of end user is the usage of different password for different application. The users always want to have one password for all application and the application should be capable of enforcing the security measure across multiple domains.

The major hurdle for achieving Single Sign-On across different distributed application is that authentication credential used by one application is different from another one and not understood by the any other application. Given the widespread acceptance of SAML Single Sign-On can be achieved. SAML Assertion can be passed from one application to another without the need to ask the user to authenticate again.

A Simple Process Flow of Single Sign-on Using SAML:



•             User Create an account in Identity Provider.

•             Using browser the user attempt to access a resource provided by Service Provider.

•             Service provider will send the request to identity provider.

•             User will request Identity Provider with SAML authentication request

•             Identity Provider will responds with SAML Assertion embedded in the form of SOAP message.

•             The User can use this assertion with any request to the Service Provider which makes the decision to allow access to resource.

SAML Single Sign-on For Google Apps Use Case:

Google Apps Services can be invoked using third party Identity Provider based on SAML.  It offers SAML based Single sign-on functionality in which third party provides authentication for the end user.

Below diagram show how end user can use Google Applications by using third party  SAML based SSO.


Due to the diverse nature of Web Services implementation it is very hard to standardize security framework which will provides functionality like Single Sign-on. SAML defines standards which can be used to integrate SSO functionality in distributed Web Services applications. SAML is widely accepted standard which makes it the ideal choice for SSO implementation.




2. Mastering web services Security By Bret Hartman & Donald J. Flinn & Konstantin Beznosov & Shirley Kawamoto




Authentication using Spring Security

What is Authentication?  Authentication is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true. (Wiki) . Spring Security provides a security solution which is very portable. By moving the application from one environment to another there is almost zero configuration change. Security is completely portable at application war level. Spring support many different authentication models which includes HTTP Basic Authentication, Form Based Authentication, LDAP , etc. We will only focus on basic authentication.

Step 1:

Filter Declaration in web.xml to filter the matching URL and delegate it to be handled by Spring Security infrastructure.



Step 2:

Web Security Service Configuration:

Here the parent element is <http. Elements are intercept-url which have the pattern which will be check against the requesting URL once matched the role will be checked in access attribute.

For Basic authentication model putting the attribute auto-config=’true’ will do the track.

<http auto-config='true'>
    <intercept-url pattern="/**" access="ROLE_USER" />

For Form Base authentication the login page url should be explicitly determinted

 <http auto-config='true'>
    <intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
    <intercept-url pattern="/**" access="ROLE_USER" />
    <form-login login-page='/login.jsp'/>

Step 3:

Configuring a provider manager:

ProviderManager is an authentication manager implementation that delegates
responsibility for authentication to one or more authentication providers.

It can use many different identity repositories (Database, LDAP etc ) to authenticate the principle. Let’s take authentication against a database. A DaoAuthenticationProvider is a simple authentication provider that uses a Data Access Object (DAO) to retrieve user information.

Bean userDetailsService must implement interface userDetails which have method loadUserByUsername where username is passed for which a UserDetails
object must be retrieved.

<bean id="authenticationManager">
<property name="providers">
<ref local="daoAuthentication" />

<bean id="daoAuthentication">
<property name="userDetailsService" ref="userDetailsService"/>

Step 4:

Creating simple login page with Spring Security Tags:

<%@ page import="" %>
<%@ page import="" %>
<%@ page import="" %>

<form action="j_spring_security_check">
	<label for="j_username">Username</label>
	<input type="text" name="j_username" id="j_username" <c:if test="${not empty param.login_error}">value='<%= session.getAttribute(AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY) %>'</c:if>/>
	<label for="j_password">Password</label>
	<input type="password" name="j_password" id="j_password"/>
	<input type='checkbox' name='_spring_security_remember_me'/> Remember me on this computer.
	<input type="submit" value="Login"/>

External Versus Internal Web Services : A comparative study

  • Introduction

Web Services is a set of standards to support interoperability between variety of platforms. The simplest web service consists of a SOAP message for communication and a WSDL for web service description. Web services use XML extensively which are very well understood technology.

WSDL document defines services as collection of network endpoints or ports. There are abstract definition for operation and messages that will be used in services provided. WSDL also define what transport protocol will be used for a particular service endpoint through binding section. The last section is service Here the concrete service endpoint is defined. Endpoint address is tied to location. From WSDL the service input and output can be determined.

To use third party or external web service UDDI can be queried . UDDI (Universal Description discovery and integration) is a directory service where any web services carrier can publish their services. Many companies have implemented UDDI as private or public registry services. It is important for web services carrier to publish their web services on UDDI. The consumer can discover the services by checking the UDDI white pages (which have the carrier name, address etc) ,yellow pages ( which contains industry information ) and green pages ( which contains the technical information about the service).      

Each organization must analyze the risk involved in choosing between implementing their own web services versus consuming third party web services. The risk to be kept in consideration for instance will be accessibility, security ,migration and  implementation.


External Web Services

As the web service market continue to grow there are various web services available that can cater many business needs. Depending on functional objectives ,it may be more efficient to use exiting web services that fit the requirement precisely. External web services are easy to use. The only thing need to discover the service, read the technical document if it match the requirement and obtain access to WSDL document. Most organization have secure access to WSDL resources a contract agreement is needed to get the access. Depending on the consumer platform many tools are available to generate code from WSDL. External web services are a lot cheaper and more reliable since the carrier are specialized in the services they provide.

.  Internal Web Services

There are certain requirement that can’t be fulfilled by using external web services. There could be several motive for create internal web services. It could be security the organization can’t allow private data exchange with the third party. If the organization is too big they might have a lot of internal system that need to interact with each other internal web services is the solution in that case. Implementation of internal web services could be very costly creating a new process from scratch from the requirement need a comprehensive study of the requirement.

Evaluation Criteria:


.    Requirement and Guideline:

Utilizing external web services could be easy to utilize but since it is very generalized it may not meet organization requirement. External Web services are not specific to a specific customer problem but rather a common solution whereas Internal web services are created from starch conforming the requirement.

.     Implementation Cost:

Using external web services can reduce the cost dramatically. For a small organization it is not beneficial to create their own web services which don’t have many different platforms. The implementation risk will be very high for internal web services.

.    Time and Resources:

Internal web services takes more time compare to External web services Since many stuff need to be created from scratch. For external web services only implementation is needed.

.    Publishing

Internal software doesn’t need to published in any registry .They can be used anytime if you have access to WSDL(web service description language).For external web services publishing is important at any registry for instance UDDI( Universal Description discovery and integration).

.    Existing infrastructure

Internal web services are very useful for larger organization. Information can be gathered from variety of application written on different platforms. For small organization which don’t have that many system external web services is a good option.

.    Security

By using external web services there is potential security risk. Data misuse and reliance on third party with whom there may be no contractual agreement. Any sensitive data should not be exchanged between transaction when using external web services.

.    Change and Update

The problem with external web services is that if there is any new build or release. They need to inform all the consumer of the service regarding that change.

  • Conclusion

If an organization have general requirement and the information required is only for information gathering then external web services is the best option. If an organization have many different system and to transform it to a unified system in that case internal web service is required. By using third party web services there is security risk any sensitive data should not be exchanged when using external web services.

  • References

.Webservices architecture