Video: Configure session cache management with Liberty and WebSphere eXtreme Scale

The following transcript is for the "Configure session cache management with Liberty and WebSphere eXtreme Scale" video, which describes how to improve the performance of your applications by off loading your current application server and data access processes to an in-memory cache using session cache management with Liberty and WebSphere eXtreme Scale. This transcript is the video storyboard. Audio describes narration and captions. Onscreen Action describes the content shown in the video.

Video Configure session cache management with Liberty and WebSphere eXtreme Scale

Table 1. Introduction. Describe the benefits of session management with Liberty and WebSphere eXtreme Scale.
Scene Audio Onscreen Action
1 Caching sessions in your applications is one of the most beneficial and easy-to-do configurations to improve performance and availability of your web applications. If you have an application server, store your information in sessions, then can offload your current process to an in-memory cache to help your applications run at super fast speeds. This video will help you do that by demonstrating how to set up session management quickly and simply with Liberty and WebSphere eXtreme Scale.

Liberty is a fast, lightweight and simple Java web application container that application developers can use to develop, test and deploy applications easily.

Show the video title, "HTTP Session Failover for WebSphere Liberty leveraging WebSphere eXtreme Scale".
2 WebSphere eXtreme Scale provides distributed in-memory data storage that is replicated across different machines. Show IBM Corporation notices and disclaimers.
3 This video includes an overview of session caching with eXtreme Scale. It also includes quick steps to download Liberty and WebSphere eXtreme Scale for developers. You will also learn how to configure WebSphere eXtreme Scale in Liberty. And finally, a sample web application is included that demonstrates HTTP session failover to an in-memory datagrid that is hosted by WebSphere eXtreme Scale. List video contents:
Show Quick Demo, Set-Up, and Sample of Liberty with WXS

Overview of Session and Data Caching in WXS

Quick Steps to Download Liberty & WXS

How to Configure WXS in Liberty

Sample Web Application demonstrating HTTP Session Failover to an In-Memory Datagrid
4 Why is HTTP Session Persistence important? Without HTTP session persistence, you will lose the session data if an application instance fails or becomes unresponsive. For example, in a retail scenario where a user adds items to a shopping cart, that user will most likely have to log in again and rebuild their shopping list if the application fails and session failover is not enabled. Usually that experience creates an unhappy customer.

Developers have 3 options to persist HTTP session data:

First option: Developers can store sessions locally in the application server memory space, but other application server instances will not share the common user session for web applications. If the instance fails, the session is lost and the user experience is less than desirable.

Second option: Developers can persist sessions in a relational database that is shared among instances, but the architecture of relational databases have inherent scalability concerns and reading or writing to a disk is slower than on an in-memory data grid.

The third and best option is what this video highlights, where Liberty uses a shared persistence engine to store HTTP session data in the memory of an elastic, scalable architecture, which is known as WebSphere eXtreme Scale. Using Liberty with WebSphere eXtreme Scale allows two or more independent Liberty instances to share a common user session for web applications. When one instance fails, the remaining instances can continue to serve user requests as if no failure had occurred.

If maintaining HTTP session high availability is a priority, then use WebSphere eXtreme Scale. Even if a runtime instance fails, the customer session is maintained. The customer is unaware of the failure or maintenance activity, which allows a consistent customer experience without interruption or data loss.

Show information about HTTP session failover:
Hands-On Demo: Session Cache

HTTP Session Failover for Liberty

Customer has an enterprise web application on Liberty, but they want to maintain HTTP high availability, so they use WebSphere eXtreme Scale to store session data.
5 Using WebSphere eXtreme Scale with Liberty offers several benefits to developers:
  • Distributed data access for high availability
  • In-memory access with rapid retrieval
  • Scalability built in over traditional methods like relational databases or memory-to-memory session replication
  • Remote access to eliminate single points of failure
  • The benefit of a quick configuration in a Liberty environment
Show information about Liberty data caching:
Liberty Data Caching with WXS

Supports distributed caching scenarios for web and mobile applications.

Store key and value objects in memory for fast access.

Provides linear scalability, predictable performance, and fault tolerance of the web application's data requirements.
Replicates data so that cache components may be restarted without data loss or performance penalty.

Caching is an example of a composable element that can be used to build applications quickly.
Table 2. Demo installing Liberty and WebSphere eXtreme Scale for Developers Liberty. Show commands and server.xml changes.
Scene Audio Onscreen Action
6 To experience this capability, you can quickly install Liberty and WebSphere eXtreme Scale for Developers Liberty on your development machine:
  1. Go to WASdev.net.
  2. Download Liberty.
  3. Download WebSphere eXtreme Scale for Developers Liberty.
  4. Install the JAR files into the "hands on" directory, which is the example directory for this demo.
Show the steps:
  1. Go to the WASdev website.
  2. Select Want to try the Beta?
  3. From Liberty Repository, select WebSphere eXtreme Scale for Developers Liberty.
  4. Install the JAR files in my c:\hands-on> directory.
7 To demonstrate the capabilities of WebSphere eXtreme Scale as a shared, remote HTTP session data grid, you will see a sample application (from the displayed URL) that is deployed locally in the dropin directory of the Liberty web instances, which shows you some examples of placing and retrieving session objects to a data grid. Show illustrations of the WebSphere eXtreme Scale HTTP session sample and the http://ibm.co/1umQ7iy URL.
8 You will learn how to configure Liberty instances to act as two Liberty web instances that are clients to a WebSphere eXtreme Scale data grid.

You will set up a WebSphere eXtreme Scale server as a HTTP session store running on a separate Liberty JVM.

And finally, you will configure the two Liberty web instances to store HTTP session data in the data grid of a WebSphere eXtreme Scale container.

Show information about HTTP session failover:
Hands-On Demo: Session Cache

HTTP Session Failover for Liberty

Customer has an enterprise web application on Liberty, but they want to maintain HTTP high availability, so they use WebSphere eXtreme Scale to store session data.

A graphic shows ServerA and ServerB in Liberty connected to a session cache.

Table 3. Demo configuring Liberty to connect to the data grid. Show server configuration and testing in a browser.
Scene Audio Onscreen Action
9 Now, you will learn to configure Liberty to connect to the data grid. By installing WebSphere eXtreme Scale with Liberty, you get access to features that you can use to manage HTTP session applications that are installed in Liberty.

For the remote WXS_Session_Server Liberty instance, the server feature will be set. The server feature contains the capability for running an eXtreme Scale server, which means that both the eXtreme Scale catalog and container are running. Add the server feature when you want to run a catalog server in Liberty or when you want to deploy a data grid application into Liberty.

The webGrid feature is to host a session management data grid in the WXS_Session_Server Liberty instance. A Liberty server can host a data grid that caches and then replicates HTTP session data for fault tolerance of applications.

Use the webApp feature to enable session management for ServerA and ServerB Liberty instances. The webApp feature contains the capability to extend the Liberty application. Add the webApp feature when you want to replicate HTTP session data for fault tolerance. Remember to set the catalogHostPort to the host and port of the WXS_Session Server Liberty instance.

Show information about configuring a Liberty server.xml to run WXS:

The server feature contains the capability for running an eXtreme Scale server, both catalog and container.

<feature>eXtremeScale.server-1.1</feature>
<xsServer isCatalog="true"/>

A Liberty server can host a data grid that caches data for applications to replicate HTTP session data for fault tolerance.

<feature>eXtremeScale.webGrid-1.1</feature>
<xsWebGrid objectGridName="session" catalogHostPort="remoteHost:2609" securityEnabled="false"/>

The webApp feature contains the capability to extend the Liberty web application. Add the webApp feature when you want to replicate HTTP session data for fault tolerance.

<feature>eXtremeScale.webApp-1.1</feature>
<httpSession idReuse="true"/>
<xsWebGrid objectGridName="session" catalogHostPort="localhost:2609" securityEnabled="false"/>
10 The Session Sample Application is now launched on both ServerA and ServerB instances.

Now check that the session attribute in ServerA named Loc is empty.

Also check that the same attribute for ServerB is empty as well.

Show a browser open on localhost:9080/HttpSessionWAR/ and a browser open on localhost:9081/HttpSessionWAR/. Both browsers display the WebSphere eXtreme Scale Http Session Sample with no attribute values set.

In the browser open on localhost:9080/HttpSessionWAR/, show typing Loc for Attribute in Getting an attribute and clicking Get Attribute. The browser displays Welcome back. Session attribute retrieved. with the Loc attribute set to null. Then show clicking Main Page to return to the previous page.

Show these same steps repeated in the browser open on localhost:9081/HttpSessionWAR/.

11 Now, specify NC as the value for the Loc session attribute in the data grid through Server A's application, and verify that it was set.

Now let's go to the ServerB Session Application and retrieve the Session attribute Loc from the data grid.

In the browser open on localhost:9080/HttpSessionWAR/, show typing Loc for Attribute and NC for Value in Setting an attribute and clicking Set Attribute. The browser displays Welcome back. Session attribute set. with the Loc attribute set to NC. Then show clicking Main Page to return to the previous page. Finally, show clicking Get Attribute and show that the Loc attribute is set to NC, and show clicking Main Page to return to the previous page.

Show in the browser open on localhost:9081/HttpSessionWAR/ clicking Get Attribute and show that the Loc attribute is set to NC. Then show clicking Main Page to return to the previous page.

12 Now you can test this configuration with a simulated, unplanned outage on ServerA by stopping the Liberty instance for ServerA and verifying that ServerB can still retrieve the Loc session attribute from the session cache of the data grid. Show information about HTTP session failover:
Hands-On Demo: Session Cache

HTTP Session Failover for Liberty

Demonstration of Server failure but Customer Experience is maintained and Session Persist through the entire transaction.

A graphic shows ServerA and ServerB in Liberty. ServerA is crossed out and ServerB is connected to a session cache.

13 ServerA is still running. But the Server A Liberty Instance will be manually stopped using the command line.

Now let's go to the browser that was hosting ServerA Session and refresh to show the unavailable Liberty instance.

Show the browser open on localhost:9080/HttpSessionWAR/. Also show entering a command to stop ServerA at a command line at C:\hands-in\wlp\bin:
server stop ServerA

Show refreshing the browser open on localhost:9080/HttpSessionWAR/. The message This webpage is not available displays.

14 Now that Server A is down you can verify that ServerB can still detect the Session data in the data grid. To do so, change the Loc session attribute to the value, MD. Show the browser open on localhost:9081/HttpSessionWAR/ clicking Get Attribute and show that the Loc attribute is set to NC. Then show clicking Main Page to return to the previous page.

Show typing Loc for Attribute and MD for Value in Setting an attribute and clicking Set Attribute. The browser displays Welcome back. Session attribute set. with the Loc attribute set to MD. Then show clicking Main Page to return to the previous page. Finally, show clicking Get Attribute and show that the Loc attribute is set to MD, and show clicking Main Page to return to the previous page.

15 Now you can simulate ServerA coming back online with the ability to retrieve the new Session value, MD, for attribute Loc, which was just set through ServerB.

Now, the browser has been refreshed and points to Server A, where the value for the Loc attribute from the data grid is retrieved.

Show the browser open on localhost:9081/HttpSessionWAR/. Also show entering a command to start ServerA at a command line at C:\hands-in\wlp\bin:
server start ServerA

Show refreshing the browser open on localhost:9080/HttpSessionWAR/. The browser displays the WebSphere eXtreme Scale Http Session Sample with no attribute values set.

Finally, show clicking Get Attribute for the Loc attribute to show that it is set to MD, and show clicking Main Page to return to the previous page.

Table 4. Conclusion. Summarize the video content and point viewers to more information.
Scene Audio Onscreen Action
16 Congratulations. You've just created your first Liberty cluster with two instances pointing to a shared in-memory data grid for HTTP session storage. Show information about HTTP session failover:
Hands-On Demo: Session Cache

HTTP Session Failover for Liberty

Demonstration of Server Recovery or additional Liberty Instances being added to topology will immediately see and share the Session Cache.

A graphic shows ServerA and ServerB in Liberty with both servers connected to a session cache.

17 In this video, you learned the benefits of using a cache for session persistence.

No code changes are need to the application to leverage the WebSphere eXtreme Scale data grid.

Data for each session persists even with a server outage.

And WebSphere eXtreme Scale is scalable up to terabytes of data and can replicate data to thousands of nodes for fault tolerance and high availability.

Show information about Liberty session management:
Liberty Session Management with WXS

Special purpose elastic in memory cache for storing HTTP session data.

Stores and persists HTTP session objects to the data grid so that they do not have to be stored in the memory.

No code change to applications using the J2EE standard HTTP session cache.

Data for each HTTP session survives on a server outage for an application.

Requires no developer effort to manage
.
Replicates the session data to avoid a single point of failure.

Provides low latency data access, transactional semantics.
18 Visit these resources to download and install WebSpphere eXtreme Scale on Liberty and to access the sample application that was used in this demo.

Thank you for watching and this concludes the video for configuring session cache management with Liberty and WebSphere eXtreme Scale.

Shows resources:

(WASdev) https://developer.ibm.com/wasdev

(How to install WXS with Liberty) http://youtu.be/Zu4Z1GLjMlE

(Sample Application used in Demo) http://ibm.co/1umQ7iy


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: Saturday, 3 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=video_transcript_xs_session_cache
File name: video_transcript_xs_session_cache.html