eXtreme Scale caching with Worklight 5.0
sbwillia 270004NYR0 Comment (1) Visits (10606)
Mobile devices have become a disruptor to the technology industry. In 2013, the number of mobile devices accessing the internet are expected to exceed the number of desktop machines. The ability to quickly react and adapt to this increased workload for application servers has increased the importance of caching at various levels in the network topology. IBM Worklight 5.0 is the platform for hosting mobile applications and the ability to be agile to this increased workload can be realized by leveraging IBM's WebSphere eXtreme Scale. Worklight Applications using WebSphere eXtreme Scale can realize increased response times and support larger numbers of concurrent client devices. This is due to accessing their applications using WebSphere eXtreme Scale's simplified programming model without having to significantly rewrite their application logic.
II. The Getting Started Dojo Application
The Worklight Starter Dojo Mobile Application leverages an HTTP Adapter to connect and consume content from engadget.com. This content is converted into an application readable format and displayed via Dojo inside of the application. By utilizing Worklight and Dojo, the code is packaged into native applications that allows for deployment on external application stores.
III. eXtreme Scale
eXtreme Scale allows data to be cached at multiple levels (internal, database, etc). By implementing the eXtreme Scale client inside of a HTTP Adapter connected to an external location, there is an opportunity to drastically increase response times for frequently requested data. In addition to the increased speed, there is additional benefit of reducing load off of backend servers, or in this case the external server that is initially generating the cacheable data in eXtreme Scale.
IV. Worklight with eXtreme Scale
There are many benefits that can be obtained by leveraging eXtreme Scale within a Worklight project. By caching the data obtained from the external connections, applications can drastically reduce response times per request. To demonstrate how this can be done, this article will reference the Getting Started Dojo Application (available here).
IV.I Creating an eXtreme Scale Connector
Using the eXtreme Scale API as reference, the application has introduced three classes: a connection class, a basic CRUD class, and a specific storage class to handle the details of importing and exporting the JSON information I receive from Engadget. To make it easier to debug, there is an exception class called ConnectionException to be used if the application is unable to connect to the eXtreme Scale backend for some reason.
The ConnectXS constructor receives either an already initialized ObjectGrid class, or two user supplied variables – the connection string and grid name. Below is the code for the connection using the two user supplied variables.
To work with the eXtreme Scale cache system, the application client code needs to access the ObjectMap inside of the connection. For convenience purposes, the application has introduced a getMap(mapName) method to simplify the API call. In this method, the client fetches the session, and from the session returns the map specified.
To make sure that the session has been initialized, there is another method (getSession) inside of ConnectXS:
Because the session variable needs to be closed (for good practice) there is a closeSession method that handles the closing of the session if the session has been initialized:
IV.I.II. External XS
The ExternalXS class provides a simple implementation to store, update, get, and remove data from the eXtreme Scale cache. Initializing an ExternalXS object requires an ObjectMap object be passed. This ObjectMap object is then stored for later use to manipulate the data. The manipulation methods are straightforward as demonstrated with the following code snippet:
WLCache provides a simple application interface that the HTTP Adapter will leverage for caching HTTP Response Data from the back end service. The constructor stores the connection information for later use when when connecting to the eXtreme Scale cache.
Now that the connection information stored, the adapter can connect to the cache by using the connect method:
These convenience methods provide a simplified API for connecting to the eXtreme Scale client inside of the WLCache object. In a similar way that the application connects to the eXtreme Scale cache, the application needs to close these connections:
This completes the section detailing the closing and opening the connections to the eXtreme Scale cache. The next step is the ability to store and retrieve information easily. When receiving the JSON content from the Adapter, the return value is a Scriptable object from the HTTP Adapter code. To store in eXtreme Scale, the Scriptable object needs to be converted into a String:
Like all of the other CRUD methods, the method first connects to the eXtreme Scale instance and then parses the Scriptable object into a JSONArray object. Using the serialize function, the method then stores the representation of the JSONArray into the eXtreme Scale cache. Finally, when all information is stored, the client disconnects from the cache.
Now that the information inside of the cache, the application client needs to be updated to be able to retrieve the newly cached data. To ensure the cached entry has not been invalidated, the server looks up the cache key by calling the hasKey method:
If the key isn't found, the client returns null value and never executes any transformations on the data. If cache does have the key, the client retrieves the String value, parses the data into a JSONArray, and then stores the JSONArray inside of a JSONObject. By having a JSONObject, the client is able to use the JSObjectConverter class to transform the data back into a Scriptable object. For the return object, the client returns ScriptableObject after disconnecting from the cache. This object is what will be used by the HTTP Adapter to represent the typical data structure if the item returned had been as a result of a non-cache lookup.
Although not used currently in the scenarios described, the client provides the final two CRUD methods post and remove. These methods increase the utilization ability of the WLCache for the future.
IV.II Adding eXtreme Scale Functionality to the Worklight HTTP Adapter
IV.III Integrating the Worklight Project into a eXtremeScale Client
To utilize the eXtreme Scale client capability inside of the Worklight Project, two jar files will need to be added: the jar-ed eXtreme Scale connection scripts (See Section IV.I), and the jar-ed eXtreme Scale client code. Both jars should be dropped into the /server/lib directory of the Worklight Project. After this, stop and start the Worklight Server via the right-click option menu on the Worklight Project folder. After starting the server, the jar files show up as linked resources.
With the proper IP address, port, context, and grid name in place inside of the Work
For the program to work properly, the eXtreme Scale server needs to be running. When coding this example, the server and catalog service leveraged the defaults properties provided the Getting Started example of eXtreme Scale as the starting point with a small modification to each to include a new map named “ResponseCache”. Excerpts of the configured deployment.xml (left) and objectGrid.xml (right) are below:
Also, make sure that the ogclient.jar included in the Worklight project does not contain osgi artifacts. OSGi artifacts inside of any jar dropped into the lib directory will not allow for Worklight to correctly start up due to the fact that these files overlap in the customization.jar file of the Worklight project.
The eXtreme Scale caching system is an extremely beneficial resource to complement the Worklight HTTP Adapter. When attempting to fetch the RSS file from Engadget and display it without eXtreme Scale usually ranged from 1100 ms on a wired connection to even 3800 ms on a wireless connection. By implementing the eXtreme Scale caching mechanism, the cache lookups were in the range of around 5ms when retrieving from the cache. These values illuminate the benefit of caching, specifically with eXtreme Scale. Not only will there be a decrease in the time the mobile user has to wait for data, the application will be freeing up processing time on the servers you access the data from. With less processing time on servers and decreased time of loading for mobile users, leveraging eXtreme Scale inside of a Worklight project increases efficiency in many ways.
Note: Currently, the eXtreme Scale client contains it's own copy of the OSGi framework. Because of this, the Worklight Server would not start when running inside of Eclipse since the Worklight Server is also OSGi based. As a current workaround for this demonstration, the OSGi folder was removed from the jar and repackaged as ogclient-mod.jar