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 Version 6.0 environment

Use the ObjectGrid framework with or without WebSphere Application Server or WebSphere Extended Deployment. You can use ObjectGrid with a J2SE Version 1.4.2 or higher environment. You can also use ObjectGrid in a WebSphere Application Server Version 6.0.2 or higher environment. When you useWebSphere Application Server support, additional distributed transaction support can be exploited. You can also exploit distributed transactional support if you use any environment that has a reliable publish and subscribe messaging system, such as a Java Message Service (JMS) provider.
Restriction: If you are using ObjectGrid with WebSphere Extended Deployment Version 6.0, additional licensing arrangements are required to also use ObjectGrid in a Java 2 Platform, Standard Edition (J2SE) Version 1.4.2 or higher environment or in a WebSphere Application Server Version 6.02 or higher environment. Contact your marketing representative for details.

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 DeploymentVersion 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 Server 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. With WebSphere Extended Deployment Version 6.0, these transactional changes can be propagated across application servers for ObjectGrid peer synchronization.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.

With the distributed transactional support, peers can be notified of changes by using the message transport. You can also configure the Java virtual machines to invalidate objects that are modified by peer machines or to have a local copy replaced with changes that are on a remote machine.

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.

Distributed cache

The ObjectGrid supports a simple push-based model for change propagation in its initial version. When a transaction is committed to the ObjectGrid, this set of changes can be propagated to peer ObjectGrids using a message transport. The changes can be propagated as an invalidation type message or the actual new values can be pushed to the peer grids. It can be configured to push changes for certain Maps only. The message transport can be the high availability manager on WebSphere Application Server Version 6.x or on any message transport that is available to the customer on other environments. These updates can be applied to peer caches or can be conditionally applied to avoid overwriting or invalidating a more current copy in that peer cache.

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: Oct 16, 2009 11:03:44 AM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/prodovr/cobgojbectgrid.html