It’s becoming increasingly important for organizations to share HTTP session data across multiple data centers, multiple web server instances or different types of web servers. For example, you may be porting your application from one web server to another and there will be a period of time when both types of servers need to be active in production.
Another scenario is when applications are modularized such that different functionalities are deployed across multiple server instances. For example, you may have login, basic info, check-in and shopping functionalities split into separate modules and deployed individually across different servers for manageability or scalability. In order for the user to be presented with a single, seamless, and transparent application, session data needs to be shared between all the servers.
Finally, you may need to deploy your application across multiple data centers for high availability, scalability or flexibility, so session data will need to be replicated.
The following image depicts a common use case where there are multiple data centers connected across the WAN, and each is running a different type of web server.
The GigaSpaces XAP global HTTP session sharing architecture allows users to deploy their web application across these multiple data centers where the session is shared in real-time and in a transparent manner. The HTTP session is also backed by a data grid cluster within each data center for fault tolerance and high availability.
With this solution, there is no need to deploy a database to store the session, so you avoid the use of expensive database replication across multiple sites. Setting up GigaSpaces XAP for session sharing between each site is simple and does not involve any code changes to the application.
To Deploy GigaSpaces XAP Global HTTP Session Sharing
You simply need to configure your web application to use the Shiro session manager with GigaSpaces XAP, deploy the XAP in-memory data grid (IMDG) and its WAN Gateway in each data center and deploy your web application. That’s it!
There is no need to change the web application or plug in any custom code in order to enable session sharing between servers running in remote data centers. In addition, you don’t have to add the HTTP session classes to the IMDG classpath.
The below diagram shows a more detailed view of the IMDG deployment. In this case, there are multiple partitions for high scalability, as well as backup instances for redundancy. The WAN Gateway is also deployed and shows replication to each remote site.
The end-to-end path between the 2 data center nodes includes the servlet and Shiro filters, and the IMDG with local cache and WAN Gateway.
The Web Application
The web application requires a couple of configuration changes to the web.xml file in order to include the Shiro filter:
The shiro.ini file needs to be placed within the WEB-INF folder and to define parameters for the session manager for it to be able to access GigaSpaces XAP:
Web Application Libraries
The web application should include the following libraries within its WEB-INFlib file folder:
GigaSpacesHTTPSessionManager.jar, aopalliance-1.0.jar, commons-beanutils-1.8.3.jar, commons-collections-2.1.1.jar, gs-runtime.jar, jcl-over-slf4j-1.6.4.jar, log4j-1.2.16.jar, shiro-all-1.2.0.jar, slf4j-api-1.6.4.jar, and slf4j-log4j12-1.6.4.jar.
The IMDG
The IMDG should be deployed using your favorite topology (replicated and/or partitioned, static or elastic) and include a reference to a WAN Gateway.
The WAN Gateway
The WAN Gateway should be deployed using your preferred replication topography, such as multi-master or master-slave. See the WAN Replication Gateway best practice for an example of how a multi-master Gateway architecture can be deployed.
Summary
Sharing session data between web server instances and remote sites is a difficult and tricky problem. Gigaspaces XAP provides a simple solution that meets even the most demanding performance requirements, and is available for you to deploy today.
