Summary: Allows you to deploy a web application (WAR) into the Service Grid.
OverviewOpenSpaces integration with the Service Grid 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 Container. The integration allows you to make use of the following Service Grid features:
The web application itself is a pure, JEE based, web application. The application can be the most generic web application, and automatically make use of the Service Grid features. The web application can define a Space (either embedded or remote) very easily (either using Spring or not). The web container used behind the scenes is Jetty (with other containers coming in the near future). This page will list the common usage and configuration of web containers. Jetty specific configuration and usage can be found here. DeploymentThe integration can either deploy a packaged WAR file or an exploded WAR file. In order to deploy packaged WAR file, it can be specified using one of the deployment mechanisms (UI/CLI/Programmatic, see more here). When deploying a WAR file, it goes through the following steps until it gets to the GSC:
Deploying an exploded WAR is similar to deploying a packaged WAR. Here are the steps:
Web Application StructureA Web Application deployed into the Service Grid is, at the end of the day, just another type of a processing unit. This means that it inherits all the options that a processing unit has, among which is that it can follow the Processing Unit Structure. A pure web application is also supported, meaning that web application is a special case of a processing unit, and adds additional features on top of it. The most important one is supporting the web application format (actually inherited from the web container used). Naturally, this means that WEB-INF/classes and WEB-INF/lib are supported. The processing unit structure itself provides a special place, where classes that interact with the Space need to be located called shared-lib. When using a Space within the web application, the same rules apply. This means that the JAR files need to be added to either [Root]/shared-lib, or, in case of a web application, WEB-INF/shared-lib. Class LoadersHere is the structure of the class loaders when several web applications are deployed on the Service Grid: Bootstrap (Java)
|
System (Java)
|
Common (Service Grid)
/ \
ServiceCL ServiceCL ... (Service Grid)
| |
Webapp1 Webapp2 ... (Web Container)
The following table shows which user controlled locations end up in which class loader, and the important JAR files that exist within each one:
The class loader delegation model is very important to understand how class loaders work, and where it loads the needed classes from. The ServiceCL and the Common class loaders work in a parent first delegation mode. This means that if the ServiceCL is asked to load a class, it will first check with the Common class loader, and then try and load it itself. In web applications, the delegation model is different, where the Webapp class loader will first try and load the class from its own class loader, and only if it is not found, will it try and load it from the parent. For pure web applications (i.e. ones that do not interact with a Space), this delegation model works out of the box, since all required classes and dependencies exist within the web application. Once a Space is introduced, there are several rules that should be kept:
Using a SpaceThere are several ways that a Space (and other components) can be used, and configured within a web application. Some common scenarios are listed below. Pure Remote SpaceWhen connecting remotely to a Space, typical usage patterns can be used. Here is an example (either using Spring within the web application Spring context file, or using pure Java code):
Spring Namespace
<os-core:space id="space" url="jini://*/*/space" /> <os-core:giga-space id="gigaSpace" space="space"/> Spring Plain XML <bean id="space" class="org.openspaces.core.space.UrlSpaceFactoryBean"> <property name="url" value="jini://*/*/space" /> </bean> <bean id="gigaSpace" class="org.openspaces.core.GigaSpaceFactoryBean"> <property name="space" ref="space" /> </bean> Code UrlSpaceConfigurer spaceConfigurer = new UrlSpaceConfigurer("/./space"); IJSpace space = spaceConfigurer.space(); GigaSpace gigaSpace = new GigaSpaceConfigurer(space).gigaSpace(); // ... // shutting down / closing the Space spaceConfigurer.destroy(); Using pu.xmlA web application is still just a processing unit. This means that a META-INF/spring/pu.xml can be added, which can be used to define a Space and GigaSpace. Accessing the beans is relatively simple as they are automatically added to the web application context and can be accessed from there. The key they are stored under is the bean id that each bean corresponds to. Here is an example that starts an embedded Space as part of the web application within the pu.xml. The following is the content of the pu.xml
Spring Namespace
<os-core:space id="space" url="/./space" /> <os-core:giga-space id="gigaSpace" space="space"/> <os-core:giga-space id="clusteredGigaSpace" space="space" clustered="true"/> Spring Plain XML <bean id="space" class="org.openspaces.core.space.UrlSpaceFactoryBean"> <property name="url" value="/./space" /> </bean> <bean id="gigaSpace" class="org.openspaces.core.GigaSpaceFactoryBean"> <property name="space" ref="space" /> </bean> <bean id="clusteredGigaSpace" class="org.openspaces.core.GigaSpaceFactoryBean"> <property name="space" ref="space" /> <property name="clustered" ref="true" /> </bean> Here is an example of a simple JSP that uses it: GigaSpace gigaSpace = (GigaSpace) getServletContext().getAttribute("clusteredGigaSpace");
Replacing Spring ContextLoaderOne option to enable Spring within web applications is to define a Spring specific web context listener, and define the location of the Spring context xml as a parameter. Here is an example of how this can be configured: <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> This will work with current web application support, or when defining within the /WEB-INF/applicationContext.xml a Space, and GigaSpace beans connecting to a remote Space. If an embedded Space needs to be configured, a "bridge" between the application context starting the pu.xml and specific container context xml to the web application needs to be created (that bridge actually passes the ClusterInfo object). It is a simple change to replace the implementation of the context loader: <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.openspaces.pu.container.jee.context.ProcessingUnitContextLoaderListener</listener-class> </listener> The ProcessingUnitContextLoaderListener acts as a bridge and will pass the ClusterInfo and BeanLevelProperties to the web level Spring context. It also configures the web level application context with a parent, which is the (optional) pu.xml. Embedded SpaceThe previous section described several options of how to start an embedded Space within the web application. The recommended way to work with embedded Space, is to work with its clustered proxy (the clustered flag in GigaSpace set to true) for interactions that originate from a web request. This is mainly since the load balancer does not know about routing specific classes to each cluster member. Note, event driven operations should still work with non clustered embedded Space (usually). For example, a web request that results in writing an Order (using the clustered proxy) to the Space, and a polling container that picks it up and processes it asynchronously. The polling container should work with the non clustered, collocated, proxy of the cluster member space. Load BalancerWhen deploying a highly available web site, usually a load balancer is used to load balance requests between at least two instances of a web container that actually runs the web application. When using GigaSpaces in order to deploy a web application, running more than one instance of a web application becomes a snap, as well as the manageability and virtualized nature of running web applications. In order to create a single point of view, in terms of clients connecting to a server, a load balancer is usually used. While there are many different types of load balancers (both hardware and software), solving the load balancing problem is not new (i.e. it is not something that is introduced because the web application is deployed on GigaSpaces). Examples of how to configure load balancers can be found in specific web container sections. GigaSpaces also comes with a built in integration with Apache httpd load balancer as described in the Apache Load Balancer Agent section. |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |