Each installment of Innovations within reach features new information and discussions on topics related to emerging technologies, from both developer and practitioner standpoints, plus behind-the-scenes looks at leading edge IBM® WebSphere® products.
The 18.104.22.168 release of the IBM WebSphere DataPower XC10 Appliance firmware introduces a new REST Gateway feature. The REST Gateway provides non-Java based clients access to simple data grids using a set of HTTP-based operations. This new feature expands the range of clients capable of utilizing the XC10 appliance for elastic caching to any client with HTTP capabilities, including PHP and .NET clients. Using the REST Gateway feature, the XC10 can be used as a service-oriented architecture (SOA) results side cache for the IBM WebSphere DataPower XI50 Integration Appliance.
Using the XC10’s simple data grid as a side cache for an XI50 can significantly reduce the load on the back end systems by eliminating redundant requests to the back ends, improving the response time to the clients and increasing total system throughput. This article will highlight the REST Gateway feature of the XC10 and provide a high-level overview of XI50/XC10 integration.
The IBM WebSphere DataPower XC10 Appliance is designed to be the drop-in elastic cache for your enterprise infrastructure. The XC10 appliance is the combination of the robust WebSphere DataPower hardware platform and state of the art IBM distributed caching technology.
The XC10 supports three types of data grids:
- Simple data grids store simple key-value pairs.
- Session data grids store HTTP session management data.
- Dynamic cache grids store cacheable objects from applications that utilize the WebSphere Application Server dynamic cache APIs or container-based caching.
To utilize a simple data grid hosted on the XC10 appliance, Java-based applications use the IBM WebSphere eXtreme Scale ObjectMap APIs to cache serializable objects as key-value pairs. Using the REST Gateway feature, non-Java based clients, such as Microsoft® .NET clients or a WebSphere DataPower Integration Appliance XI50, can use the HTTP POST method to insert or update data in a simple data grid, the HTTP GET method to get data from the grid, and the HTTP DELETE method to delete data from the grid. The REST APIs use a very simple URI format:
For example, if you created a simple data grid named SOAGrid on the XC10 appliance, then myXC10.ibm.com, the resulting URL to access key name my.data.item in the default map (called SOAGrid), would look like this:
The REST APIs use the Content-type header in the HTTP request to determine the format of the data stored in the grid. You can store multiple content types in the same grid.
The REST APIs also support the creation of dynamic maps. When a simple data grid is created, a default map is created with the same name as the grid. The default map does not have any time-to-live (TTL) expiration. Therefore, entries in the grid will remain in the grid until they are explicitly deleted.
Using the REST APIs, applications can dynamically create additional maps as needed. Dynamic maps can be configured with one of three map TTL templates:
- No time-to-live expiration (.NONE).
- Last update time (.LUT) expiration.
- Last access time (.LAT) expiration.
It is important to know that the first operation to a map that matches a
map template -- but has not yet been created -- will result in the
creation of the new dynamic map. Time-to-live values are set by adding a
ttl parameter in the HTTP request. Below is an
example of setting the TTL value to 120 seconds for key "a,key." The ttl request parameter is used when the a.key value is inserted or updated into the grid using the HTTP POST method.
In order to access a data grid hosted on an XC10 appliance, a Java-based client must provide a user ID and password for authentication and to verify that the client is authorized to access the grid. This same security requirement applies to REST access to a data grid. The application client must provide a basic authentication header (which contains an authorized user’s user ID and password) in the HTTP header of the HTTP request. Additionally, the REST gateway supports HTTPS protocol if transport level security is required.
When data is inserted into a map using the REST gateway, a wrapper class of type com.ibm.websphere.xsa.RestValue is used to wrap the supplied content-type and request body. Using the ObjectMap APIs, a Java client can utilize this same RestValue class to insert or get data from the map. The example in Listing 1 shows the proper use of the RestValue class to access a map and insert data from a Java client.
RestValue rv = new RestValue(); rv.setContentType(“application/xml”); String myXml=”<customer>thomas</customer>”; rv.setValue(myXml.getBytes(“UTF8”)); ogSession.begin(); ObjectMap map = ogSession.getMap(“MyMap.LUT”); map.insert(“thomas”,rv); ogSession.commit();
An Enterprise Service Bus (ESB) is a critical component of an SOA. The ESB connects and integrates applications, services, and business process flows at the messaging layer. It performs mediation, message transformation, routing, process choreography, and provides quality of service (security, reliable message delivery, and transaction management). The WebSphere Datapower Integration Appliance XI50 is a secure easy-to-deploy hardware ESB. The XI50 is a highly scalable integration solution in a purpose-built hardware appliance. It is capable of off-loading eXtensible Stylesheet Language Transformation (XSLT) processing, XPath routing, XML conversion, and other resource intensive tasks, such as message-level or transport-level security processing, from servers to reduce latency, improve throughput, and improve server utilization.
Using the new XC10 REST Gateway feature, you can now integrate the elastic caching tier with the ESB. Traditionally, the elastic caching tier is inserted between the application server tier and the database tier; however, in this configuration, integrated with the ESB, the elastic caching tier acts as a side cache for the ESB. A simple data grid hosted on an XC10 functions as an SOA results cache for the XI50 hardware ESB. In an SOA, all application requests pass thru the ESB before they are routed to the application. Therefore, if the result of an application request is retrieved from the elastic caching tier, the application processing and processing latency for that request are eliminated. The result is a significant decrease in response time and reduction of application processing.
To use the XC10 as a side cache, an XML proxy is defined as the first component in the XI50 processing chain. It will use a set of caching policy rules to determine the cacheability of each incoming request. The rules are application specific, but in general, caching policy rules can trigger on the request URI, specific XML contents within the request body, or a combination of both. The rules are defined using an XSL. The XSL is then loaded into the XI50 memory. Additionally, a set of XSLs are used to generate the appropriately formatted REST requests to the XC10 REST gateway to store or retrieve data in the grid.
For this scenario, the XC10 is configured with a simple data grid that contains two maps. The first map, called the request cache, is used to cache incoming requests. The second map, called the results cache, is used to cache the results of each cached request. These maps can be created dynamically with the appropriate TTL template based on the application and data requirements. For security, a unique user ID and password needs to be configured on the XC10, which will be used by the XI50 to access the data grid.
Figure 1. High-level design
Figure 1 shows the high-level design of the XI50, using the REST APIs to utilize XC10 simple data grids as an SOA results side cache. As incoming client application requests are received, the XML proxy inspects the URI or XML body contents to determine if the request meets the criteria for being cached, based on the caching policy rules. If the request is cacheable, the XML proxy will perform a standard side cache operation. Using the REST-based HTTP GET method, the XML proxy will look to see if the request is cached in the simple data grid. If the HTTP GET returns an HTTP 404 NOT FOUND, signifying a cache miss, the XML proxy will enable the request to pass through to the existing processing flow to the application hosted in the back end systems. The XML proxy will use the REST-based HTTP POST method to insert the request into the request cache. The XML proxy will also cache the result to the result cache as it flows back through the XML proxy to the client application. If the incoming request was found in the request cache, then the result would be retrieved from the result cache, bypassing the back end systems, thus removing the latency introduced by the application and data layers.
Using the new REST Gateway feature, non-Java based clients can access simple data grids hosted on the IBM WebSphere DataPower XC10 Appliance. The REST Gateway expands the range of clients that can utilize elastic caching technology. As described here, integrating a WebSphere DataPower Integration Appliance XI50 with the XC10 as an SOA results side cache has the potential to significantly reduce the load on the back end systems by eliminating redundant requests to the back end systems.
IBM WebSphere DataPower XC10 Appliance product information
IBM WebSphere DataPower XC10 Appliance Information Center
IBM WebSphere DataPower XC10 Appliance Session Management
IBM WebSphere DataPower XC10 Appliance Monitoring
IBM WebSphere DataPower Integration Appliance XI50 product information
Charles Le Vay is a senior software architect. He is the elastic caching technical evangelist as part of WebSphere Emerging Technologies team. His focus is on promoting the advantages of elastic data grid technology within the enterprise. Before becoming a technical evangelist, he was the Web Service interoperability architect for IBM's WebSphere Application Server. He represented IBM on the Web Service Interoperability Organization (WS-I) Reliable Secure Profile (RSP) Working Group. As an interoperability architect, Charles focused on ensuring IBM products meet industry standard interoperability criteria. He was responsible for identifying and detailing best practices for Web services interoperability. Prior to this position, Charles specialized in mobile application development, wireless technology, and extending enterprise applications securely to mobile devices. Before joining IBM, Charles developed advanced submarine sonar systems for the Navy and specialized in signal processing and underwater acoustics. Charles is a graduate of Duke University with a degree in physics.
Tom Gissel is a Senior Technical Staff Member and lead architect for IBM Elastic Caching hardware and software platforms, WebSphere eXtreme Scale and the DataPower XC10. Prior to this, Tom was member of the WebSphere Technology Institute where he made significant contributions to a number of innovative products. Tom was the release architect for IBM Blueworks Live, https://www.blueworkslive.com, WebSphere sMash’s run-time lead, and the original team and technical lead for WebSphere Virtual Enterprise’s Dynamic Workload Management and Dynamic cluster components. Tom is a graduate of the University of Wisconsin with a degree in Computer Science.
Lan Vuong is currently a technical evangelist for the WebSphere elastic caching solutions. She previously worked as a software engineer for WebSphere Virtual Enterprise and was the team lead of several component areas. Lan is a graduate of the Pennsylvania State University with a degree in Computer Science.