Prerequisites
You should have the following installed on your machine for the demo to work properly:
- Spring framework 2.5.6 (with dependencies)
- GigaSpaces XAP Premium or Standard version 7.0 or higher
General
This example shows how to integrate GigaSpaces with an AJAX based web application. It's based on GigaSpaces as the backbone, with a feeder and processor PUs. The feeder injects stock quotes into the space (as listed in the META-INF/stocks.txt file in the feeder module), and then updates them in batches (the default setting is batches of 100 done by one thread constantly.
The updated stocks are randomly picked, the update rate is very high and on average every stock gets a new price every one or two seconds.
The processor converts StockFeedEntry objects sent by the feeder to Stock objects which contain also the previous price of the stock. This is a typical scenario in real life where you would convert raw feeds into something more meaningful to the application. All objects interfaces The web application is based on Spring MVC framework and ExtJS open source JavaScript library.
It is a standard JEE web application and can be deployed on any Servlet container (Tomcat and Jetty were tested).
It uses AJAX to retrieve the stock prices from the web server via the JSON protocol and updates them in the stocks table. For simplicity, the current implementation uses AJAX polling and not reverse AJAX.
The web application contains a reference to a local view of all the stocks in the central space which is part of the processor PU.
It does so using a Stock DAO object which encapsulates access to stock information.
Using the AJAX UI, you can add and remove stocks from the table as you see fit.
Modules
The application contains the following modules, each has its own Eclipse project and IntelliJ iml file.
(You need to have the following path variables in either IDE for you're project to compile correctly within it:
GS_HOME - points to GigaSpaces XAP home, SPRING25_HOME - points to the Spring framework 2.5.6 distribution)
- Processor: contains the processor PU which starts an embedded space.
- Feeder: contains the feeder PU which creates stock data in the space and updates constantly.
- common: contains classes shared by the PUs and web application, namely the domain model classes (StockFeedEntry and Stock) and the DAO interface and implementation. A mock DAO implementation is
also included for testing purposes.
- Web: contains the web application, including all web related resources.
Build and Deployment
The example uses ant as its build tool and uses a standard build.xml file.
You can run the build script by calling the build.bat/sh script.
Running the build script with no parameters within the current directory will list all the relevant tasks that can be run with this example.
The application depends on GigaSpaces XAP 7.0 and Spring 2.5.6 distributions.
 | Change setenv.bat / setenv.sh
Make sure to edit the setenv.bat/sh file in the root of the project to provide the locations of GigaSpaces XAP 7.0 and Spring framework 2.5 .6 distributions on your local disk |
The output of the build is the feeder and processor PU jars and the web application war file.
Running the dist target will create all archives under the target directory of the project root.
In order to deploy the stock demo onto the Service Grid, a GSM and two or three GSCs will need to be started (note, we need two GSCs because of the SLA defined within the processor module). You can simply start a GigaSpaces agent by clicking the gs-agent.sh/bat script in the bin directory of the GigaSpaces distribution.
Then run "build.sh/bat deploy" to deploy all the components.
You can also deploy manually from the UI (first the processor, then the feeder and the web app).
Some ways to play with the demo can be:
- Start another GSC and relocate (click and drag in the GS-UI) the feeder to the new GSC.
- Kill one of the GSC that runs the Processor processing unit. Thanks to the SLA, each GSC will run a primary partition, and a backup partition (of the other primary partition). This means that the feeder should keep on running, and the active GSC should have its backup partition space turn into a primary one. While this is happening, the two other instances of the processor PU will get relocated to the GSC that is running the Feeder PU.