Deploy a Web App

In this part of the tutorial we will show you how you can deploy a standard WAR file onto the Service Grid A built-in orchestration tool which contains a set of Grid Service Containers (GSCs) managed by a Grid Service Manager. The containers host various deployments of Processing Units and data grids. Each container can be run on a separate physical machine. This orchestration is available for XAP only..

GigaSpaces allows you to deploy web applications (packaged as a WAR file) onto the Service Grid. The integration is built on top of the Service Grid Processing Unit This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. Container. The web container used behind the scenes is Jetty.

The integration allows you to make use of the following Service Grid features:

• Dynamic allocation of several instances of a web application (probably fronted by a load balancer).

• Management of the instances running (if a GSC Grid Service Container. This provides an isolated runtime for one (or more) processing unit (PU) instance and exposes its state to the GSM. fails, the web application instances running on it will be instantiated on a different GSC).

• SLA monitor-based dynamic allocation and de-allocation of web application instances.

Deployment

The web application itself is a pure, JEE-based application. The application can be the most generic web application, and automatically make use of the Service Grid features.

Here is an example how you can deploy a web application on top of the service grid. We can accomplish this in three ways; by command line, with the Web Management Console, or with the REST API REpresentational State Transfer. Application Programming Interface An API, or application programming interface, is a set of rules that define how applications or devices can connect to and communicate with each other. A REST API is an API that conforms to the design principles of the REST, or representational state transfer architectural style.:

Command Line Deployment

You deploy a WAR file just like you deploy a PU This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. JAR.

GS_HOME/bin/gs.sh deploy tutorial.war

GS_HOME\bin\gs.sh deploy tutorial.war

curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/plain' -d '{ 
   "name": "eventPU", 
   "resource": "...path..to\eventPU.jar"  
 }' 'http://localhost:8090/v1/deployments'

Deploy with Web Management Console

You can deploy a WAR file just like a PU with the Web Management Console:

Using a Space

The web application can define a space either embedded or remote using Spring or direct in java code. There are several ways that a space and other components can be used and configured within a web application. Here are some scenarios:

• Creating a space using java code:

  EmbeddedSpaceConfigurer configurer = new EmbeddedSpaceConfigurer("xapTutorialSpace");
  
  GigaSpace gigaSpace = new GigaSpaceConfigurer(configurer).gigaSpace();
  

• Using PU.xml to create a space: A web application is still just a processing unit. This means that a META-INF/spring/pu.xml can be added, where we define the standard data grid components.

Here is the layout of the WAR file structure:

|----META-INF
|--------spring
|------------pu.xml
|------------pu.properties
|------------sla.xml
|--------MANIFEST.MF
|----WEB-INF
|--------lib
|--------web.xml
|----index.jsp
|---- .jsp

For example in the pu.xml file we can define our space that we want to be accessible from the web application.

<os-core:embedded-space id="space" space-name="xapTutorialSpace" />
<os-core:giga-space id="xapTutorialSpace" space="space"/>

Here is an example of a simple JSP that uses it:

GigaSpace gigaSpace = (GigaSpace) getServletContext().getAttribute("xapTutorialSpace");

Jetty Instance

Jetty itself is configured using Spring, and allows you to control all aspects of both the Jetty instance created, and the web application context. There are two flavors of how Jetty instances are created (by default). The first is the plain mode, where a Jetty instance is created for each web processing unit instance running within a GSC. The second is the shared mode, where a single Jetty instance is created, and shared between all the different web processing unit instances running on the same GSC. A custom Jetty instantiation and handling can also be configured.

HTTP Session Management

The GigaSpaces Jetty integration comes with a support for storing the javax.servlet.http.HttpSession in the Space Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model. allowing supporting session replication and failover between different web application instances deployed into GigaSpaces containers.

The GigaSpaces HTTP Session Management provides the following:

• Avoid using database as the persistent storage media - Better performance and simplify the deployment

• Allow management and control of full lifecycle of web application - From the load-balancer to the data

• Dynamic scalability - Allows the web application to scale up or down based on SLA

• Continuous High-Availability - Allows the application to survive any system failures

• Non intrusive session management or explicit Data Grid API access for fine grain control - Allows multiple web servers to share the same session in transparent manner

Enabling HTTP Session Management

There are several ways to configure Space session based support, depending on the definition of which space and how the space was started.

For example, if the session will be stored on a remote clustered space with a local cache, the URL can be: jini:////sessionSpace?useLocalCache (assuming the name of the space is sessionSpace). If the session should be stored on a space that should be started within the web application.

• Using Deploy property Here is how you can deploy an existing WAR file without changing it (or use Spring) to use data grid's HTTP Session Management:

  gs deploy -properties embed://jetty.sessions.spaceUrl=jini://*/*/sessionSpace?useLocalCache xapTutorialSpace.war
  

  In this example we connect to a remote space called sessionSpace and create a local cache for the session caching.

• Using Spring When deploying, include within the META-INF/spring/pu.properties file the jetty.sessions.spaceUrl property value. This should be set with the space URL defining where the sessions will be stored.

Deploying with the Web Management Console

Load Balancing

When deploying a highly available web site, usually a load balancer is used to load balance requests between at least two instances of a web containers that run the web applications. When using GigaSpaces to deploy web applications, running more than one instance of a web application becomes very easy. GigaSpaces comes with a built-in utility allowing you to dynamically update an Apache httpd web server load-balancing configuration, based on deployed web applications.

The integration dynamically creates and updates the mod_proxy_balancer configuration, based on the state of the deployed web applications. Once changes occur (relocation / failover / changes to the number of web application instances), the utility identifies the change, updates the balancer configuration, and sends a soft restart to Apache to take the new configuration into account.