WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


ObjectGrid

ObjectGrid is an extensible transactional object caching framework for Java 2 Platform, Standard Edition (J2SE) and Java 2 Platform, Enterprise Edition (J2EE) applications.

You can use the ObjectGrid API when developing your applications to retrieve, store, delete, and update objects in the ObjectGrid framework. You can also implement customized plug-ins that monitor updates to the cache, retrieve and store data with external data sources, manage eviction of entries from the cache, and handle background cache functionality for your own ObjectGrid application environment.

Map-based API

The ObjectGrid provides an API that is based on the java.util.Map interface. The API is extended to support the grouping of operations into transactional blocks. This interface is a superset of the java.util.Map interface and adds support for batch operations, invalidation, keyword association, and explicit insert and update. The Java Map semantics are enhanced with extension points so that you can implement the following enhancements:

The ObjectGrid environment

You can use the ObjectGrid framework by installing one of the existing offerings: In both offerings, ObjectGrid supports client/server features. The server runtime supports full clustering, replication, and partitioning of distributed object caches. The client runtime supports the concept of a near cache and workload management routing logic to remote clusters. The client runtime also supports local object map creation.
The level of support varies depending on if you are running the client runtime, server runtime, integrated ObjectGrid, or the stand-alone ObjectGrid.
ObjectGrid integrated with WebSphere Extended Deployment offering
Server runtime: The server runtime is integrated. For WebSphere Extended Deployment Version 6.0.1, the integrated runtime is not supported on the z/OS platform.

Client runtime: The client runtime is supported on J2SE and J2EE at SDK level 1.3.1 and later, including WebSphere Application Server Version 5.0.2 and later. The client runtime is fully supported on the z/OS platform.

Standalone ObjectGrid offering
Server runtime: The server runtime can run in stand-alone Java virtual machines (JVM) as a single server or as a cluster of servers. The standalone server is supported on most J2SE and J2EE platforms at SDK level 1.4.2 and later. The stand-alone server is supported on WebSphere Application Server Version 6.0.2 and later. The stand-alone server runtime is not supported on the z/OS platform for WebSphere Extended Deployment Version 6.0.1.

Client runtime: The client runtime is supported on J2SE and J2EE platforms at SDK level 1.3.1 and later, including WebSphere Application Sever Version 5.0.2 and later.

Session management

A fully distributed HTTP session management implementation is provided that stores HTTP session objects in the ObjectGrid.

Simple installation

You can install and configure ObjectGrid in a few simple steps. These steps include copying the Java archive (JAR) files to your class path and defining a few configuration directives.

Transactional changes

All changes are made in the context of a transaction to ensure a robust programmatic interface. The transaction can either be explicitly controlled within the application, or the application can use the automatic commit programming mode. These transactional changes can be replicated across an ObjectGrid cluster in asynchronous and synchronous modes to provide scalable and fault tolerant access.

You can scale ObjectGrid from a simple grid running in a single Java virtual machine (JVM) to a grid that involves one or more ObjectGrid clusters of Java virtual machines. These servers make data available through the Map APIs to a large set of ObjectGrid-enabled clients. The ObjectGrid clients use the basic Java Map APIs. However, the application developer does not need to develop Java TCP/IP and remote method invocation (RMI) APIs because the ObjectGrid client can reach the other ObjectGrid servers that are holding information across the network. If your data set is too large for a single JVM, you can use ObjectGrid to partition the data.

ObjectGrid also offers your application solution added high availability capabilities. The object sharing is based on a replication model where a primary server, one or more replication servers, and one or more standby servers exist. This cluster of replication servers is referred to as a replication group. If the access to the replication group is a write operation, then the request is routed to the primary server. If the access is a read operation, or if the map is a read-only map, the request can route to the primary or replication servers. The standby servers are defined as potential replication servers if a server fails. If a primary server fails, then a replication server becomes the primary server to minimize any outage. This behavior is configurable and extensible based on your needs.

If you want to use a simpler object propagation approach, a lower quality of service peer-to-peer model is also available, as it was in Extended Deployment Version 6.0. With this simpler distributed transactional support, peers can be notified of changes by using a message transport. The message transport is built in if you are running WebSphere Application Server Version 6.0.2 or later. If you are not running WebSphere Application Server Version 6.0.2 or later, another message transport must be supplied, such as a Java Message Service (JMS) provider.

Injection container compatible APIs

Configure the ObjectGrid using a simple XML file or programmatically using Java APIs. The Java APIs are designed to also work in environments where you are using injection−based frameworks to configure your applications. You can also invoke the APIs and interfaces of the ObjectGrid objects by an Inversion of Control (IoC) container and by injecting references to key ObjectGrid objects into the application.

Extensible architecture

You can extend most elements of the ObjectGrid framework by developing plug-ins. You can tune the ObjectGrid to allow an application to make trade-off decisions between consistency and performance. Plug-in customized code can also support the following application-specific behaviors: You can implement each of these behaviors without effecting the use of the basic ObjectGrid cache API interfaces. With this transparency, applications that are using the cache infrastructure can have data stores and transaction processing greatly changed without effecting these applications.

Use ObjectGrid as a primary API or second-level cache

The application can use ObjectGrid APIs directly as a lookaside cache or as a write through cache. In write through mode, the application plugs in a Loader object so that the ObjectGrid can apply changes and fetch data directly and transparently to the application. You can also use ObjectGrid as a second-level cache for popular object relational mappers by writing an adapter. The cache is invisible to the application in this mode because the application uses the APIs from the object relational mapper as the primary API for accessing the data.

To begin using and developing ObjectGrid applications, see Getting started with ObjectGrid by running the sample application .

For more information about the ObjectGrid APIs, see the ObjectGrid programming guide. See ObjectGrid resources for more information.




Related tasks
Getting started with ObjectGrid by running the sample application
Concept topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 3:56:25 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/prodovr/cobgojbectgrid.html