There is only so much a harried back-end server can do (even a really powerful one). A whole new class of applications (under the catchy label "Extreme Transaction Processing") has brought database scalability to the forefront. Consider the remarkable scalability challenges faced by financial services and travel reservation sites. Their data volumes and need for consistent response times and throughput can bring the hardiest database server to its knees.

Is Scaling Up and Out the Solution?
What is an organization facing back-end scalability challenges to do? Developers should, of course, work with the database team to ensure the application and database work together efficiently by optimizing data access patterns for one. However, at some point the back-end server may need to be "scaled up" and/or "scaled out".

Scaling up the back-end is straightforward. Just throw tons of money at the problem and add zippier and likely larger hardware. But if this doesn't do the trick, scaling out the database is a common next step. It involves partitioning the data so that certain data types get allocated to specific back-end servers Although scaling up and scaling out are useful steps they may still not provide sufficient back-end capacity, or be within your organization's budget.

Does Cache Solve All Woes?
When the back-end server is at its limits, thoughts typically turn to caching. Application-side caching implementations are simple in concept yet not so easy to implement in reality. A long standing challenge of caching is to make sure you have the most current version of the data. When cached data is modified the caching code must persist the change, and then notify all the other caches of similar items that a data item has been modified. This results in plentiful network traffic and increased hits on the database as the invalidated data is reloaded. It is also a potential source of race conditions as cache invalidation does not happen instantaneously across multiple servers.

Although application-side caching is often beneficial, it is also very hard to implement correctly. Home-grown caching implementations allow you to scale a bit more while adding much development effort and the risk of data inconsistency.

Get on the Grid
Most organizations have a variety of applications that have been built over time on different platforms. These platforms may simply be different versions of an application platform, such as IBM WebSphere Application Server. They may also be application platforms from different commercial vendors as well as open source platforms. Developers need a technology solution that can help applications lower the load on the back-end without sucking up endless hours of development time. A solution that can achieve this will:

• Delay or eliminate the need to upgrade back-end systems (which can save big $$$).
• Reduce back-end loads so it can support more application load than before.
• Improve client response times.
• Reduce the CPU cost of the back-end to object conversion costs.
• Provide these benefits independent of the application platform, eliminating the cost of migrating.
• Be simple to implement and maintain.

IBM's ObjectGrid is specifically designed to help applications lower the load they place on the back-end. ObjectGrid is a software layer that sits between an application and its back-end. This layer accelerates applications by caching objects obtained from the back-end. The ObjectGrid provides a customizable, pluggable data fabric framework that allows applications to share data across a wide range of application scenarios. Here's how the ObjectGrid can help you:

It's just plain faster—ObjectGrid caches data that's accessed by an application session and also data commonly used by multiple sessions.

It's secure—Security is important for all data, including cached objects. With its extensible architecture, ObjectGrid can be integrated into any security environment. It can then use the chosen authentication and authorization infrastructure to control access to data held within the grid.

It's easy to implement—The ObjectGrid has numerous features that simplify implementation. For example, a plugin is provided so developers can quickly write a loader that sits between application data and the persistent store. Locating data in the grid is similarly straightforward as the ObjectGrid has a flexible query language for retrieving entities using SELECT type queries over an entity or Object-based schema.

It's better than roll-your-own caching—Managing caches can be a real pain. ObjectGrid provides a default mechanism for evicting cache entries and a plugin for creating custom evictors. The ObjectGrid has the flexibility to use "built-in" eviction policies, including Time to Live (TTL), Least Frequently Used (LFU), and Least Recently Used (LRU). The plugin allows ObjectGrid to be extended so any eviction algorithm can be used.

It's application platform agnostic—ObjectGrid is designed as a standalone component that is easy to integrate with any Java application platform. Full function is available regardless of the application platform(s) in use.

It's manageable—ObjectGrid can integrate with a WebSphere Extended Deployment console or any industry standard JMX console. This allows dashboards to be built to monitor how the grid is performing.

It's highly scalable—ObjectGrid can be a local cache within the same JVM as an application. The grid also supports a multi-tiered cache topology where a separate set of JVMs, an ObjectGrid cluster, provide cache services to a large number of application JVMs. A distributed grid supports a potentially unlimited number of cached objects, as ObjectGrid automatically spreads the data over the set of JVMs in the cluster and ObjectGrid can also replicate the data to provide for transparent failover.

How Do I Get There From Here?
If you don't currently have back-end scalability problems, you most likely will soon. Scaling back-end systems is an expensive proposition and can require extra coding to make the most of the new "scaled" resources. Going the extra mile and developing your own application-side caching scheme is time consuming and fraught with pitfalls.

You owe it to your organization to investigate ObjectGrid—it significantly lowers the load on back-end systems through caching and provides these advantages even when running on far less expensive hardware (i.e. blade systems) than back-ends typically require. So jump right in. You'll find the ObjectGrid Wiki briefs you on key concepts while letting you drill-down into implementation details. When your thirst for knowledge has been satiated you can get your hands dirty with the free ObjectGrid trial, and make sure to catch the ObjectGrid demo for even more great information.