WebSphere Extended Deployment (XD) V6.0, IBM's premier J2EE platform for building advanced OLTP applications as well as managing virtualized J2EE environments, has now shipped. Based on Websphere 6.0.2, it offers the following new capabilities:

• J2EE virtualization support.
• Leverages WebSphere 6.0 High Availability Manager
• Batch processing support for J2EE applications.
• Support for mixed batch/online workloads in a virtualized environment.
• HTTP flow control and throttling for 3rd party application servers.
• Improvements in the Partition Facility.
• A new standalone caching infrastructure, ObjectGrid.
• Application Versioning.
• Visualization improvements.

J2EE Virtualization Support
XD can virtualize the resources used by applications deployed on XD application servers. This allows administrators to consolidate multiple applications previously deployed on dedicated hardware on to a shared set of machines. XD can make sure that the applications still meet business goals specified by the application servers by dynamically varying the amount of physical resources allocated to an application.

Leverages HAManager
XD takes advantage of the WebSphere HAManager technology to provide a system with no single point of failure and rapid recovery times from failures when they occur without the need for external HA software, SANs or IP failover. The HAManager was first shipped on WebSphere 6.0 and offers the high availability on commodity hardware.

ObjectGrid
This is a new advanced grid based infrastructure for caching application data. It can run with or without a WebSphere application server and in the standalone case is just a couple of jars with a small footprint and unzip install. It is designed from the ground up as a transactional cache and the APIs reflect this. All aspects of the cache are pluggable (Loaders, Evictors, replication), which makes it extremely flexible. V6.0 of ObjectGrid offers peer to peer invalidatation/data push out of the box using the WebSphere RMM messaging technology or any pub/sub message transport of the customers choice, JMS or not. It can be configured using an XML file, Java APIs or your IoC container of choice such as Spring.

Batch Applications
XD includes APIs allowing batch applications to be written using container managed checkpointing. XD can start/stop these jobs on demand as resource/business goals allow.

Mixed Batch/Online workload
XD already offered virtualization for HTTP online workloads. Administrators could give applications and web pages within an application a service level agreement when it was deployed. Applications could also be prioritised relative to each other. XD would then allocate as many machines as necessary to optimally meet those goals and shift resources around to ensure higher priority pages/applications meet their goals. This now allows batch workloads to run continually and be backed off if online workloads spike.

Application Versioning
XD now supports many common application upgrade patterns directly and allows multiple versions of a single application to be deployed concurrently and an administrator can then specify precisely how incoming traffic is sprayed to the set of applications version which are online.

HTTP flow control/service level agreements for 3rd party application servers.
The OnDemand Router (ODR), a high performance HTTP router, can be placed in front of a cluster of application servers. These application servers can be competitive application servers, including open source or Microsoft based. The administrator can specify maximum response times for particular URIs and the ODR will delay lower priority HTTP requests to ensure higher priority requests do not get starved by lower priority work. Multiple ODRs can be used for more throughput and fault tolerance as the ODR is built on WebSpheres high availability technology (HAManager).

Visualization Improvements
XD offers web based visualization. It allows almost any aspect of the system to be monitored and charted in real time by administrators.

Partition Facility
There are several small improvements in the partition facility and customers are already leveraging the partition facility to build highly available applications with almost linear horizontal scaling. The combination of the partition facility, ObjectGrid and the WorkManager/commonj APIs provides the capability to build advanced applications on XD for the demanding environments.

For more information including programming manuals for the partition facility and ObjectGrid, visit the XD web site at http://www-306.ibm.com/software/webservers/appserv/extend/.

I can't find the ObjectGrid Programming Guide.
The Information Center chapter "getting started" refers back to the XD home page...
Can you post the exact link to this document?

Is this product and its use as a standalone module supposed to competete with Tangosol offerings?

Alex

The direct link for the ObjectGrid programming model doc is http://www-1.ibm.com/support/docview.wss?uid=swg27006432

(The link to the ObjectGrid page from the XD Library is broke and should be fixed early next week.)

Yes, it is but it offers a subset of what's possible with Tangosol right now but that'll change quickly with future releases. We're not aiming at matching competitive products feature by feature, but we do want the most requested features as well as some new unique ones to differentiate us.

The docs are here.

Billy

Congratulations on the release! I gave a quick glance at the posted ObjectGrid documents but could not make out what types of caches are supported. Does this release support some form of partitioned cache?

The ObjectGrid is being delivered in a staged form. The V6 includes what we call the core. It's the basic transactional in memory cache which will be extended using the existing public APIs. XD has an accelerated delivery schedule and the next version is due at year end. The ObjectGrid while delivered as part of XD is not coupled to the runtime so existing customers can 'grab' the updated ObjectGrid and use it with their existing environment. You don't need to upgrade your application server to get the new function. This is basically a realization of what I wrote about in my blog on non invasive middleware.

The V6 ObjectGrid allows transactions in one JVM to be asynchronously published using two approaches. The first publishes just the keys for update/deletes/invalidates and all peers then remove those records if they are present. The second publishes the keys and values for insert/invalidate/update and deletes and the peers apply those changes to their cache. One style does peer invalidation on modification, the other style does peer update on modification. You can control which Maps are replicated and could even filter the data by writing your own transaction log observer.

These invalidations and updates can be made conditional on the version of the source data being more recent than the version on the peers.

The message transport used for this replication is either RMM or a customer supplied transport like ActiveMQ for example. We let you attach any transport. The replication is basically a transaction log observer plugin (an ObjectGridEventListener). RMM has advantages over JMS or other transports in thats it's one of the fastest reliable pub/sub transports on the market.

The Loader architecture allows hub based caches to be readily constructed using any RPC mechanism for the client -> hub comms you choose. The Loader is used by the core when an application asks for data which isn't in the cache. The core asks the Loader to find it if possible. All changes are also provided to the Loader when a transaction completes.

The next version of ObjectGrid will include a client/server mode cache with the data in the grid being striped over a set of servers and each server can have N replicas for fault tolerance. This is being built as a set of plugins for the current core and some additional public services will be added to make the core even more flexible. The focus for the core is extensibility by customers.

Obviously, I can't wait to get the next version out there as a lot of customers want the partitioned cache and the replication. But, the initial version offers probably the most extensible cache core out there and can be used for a variety of customer scenarios.

Billy

Is Object Grid available only as part of XD? In other words if I have regular WAS or even ND do I still need to get XD license in order to be able to use Object Grid?

Robert

Technically, the ObjectGrid is two jars with a very small footprint (4/5MB) and can run standalone or in your favorite application server. The license we shipped in XD6.0 was wrong (mainly my fault) so officially you need to buy XD to get it BUT there is a special bid process which allows customers to get just the ObjectGrid at a much lower price. Contact your IBM rep for details on this pricing but you don't need to buy base or ND licenses with this if you're running Tomcat, for example.

The special bid process should disappear in V6.0.1 when there will be a seperate license allowing the use of ObjectGrid without this hassle.

If you use WAS base or ND then you need to license just the ObjectGrid as stated above to use it. So, it's a lot cheaper than putting all of XD on top and is an unzip install.

Billy

That's certainly very good news. Are there any papers available comparing it to other products in this space? For example why would I choose it over say Coherence?

Robert

That's certainly very good news. Are there any papers available comparing it to other products in this space? For example why would I choose it over say Coherence?Robert

Like, does it only work with Websphere? (ok that would be a reason not to choose it)

Like, does it only work with Websphere? (ok that would be a reason not to choose it)

From the summary (above)

[ObjectGrid] can run with or without a WebSphere application server

Like, does it only work with Websphere? (ok that would be a reason not to choose it)

From the summary (above)

[ObjectGrid] can run with or without a WebSphere application server

Thanks. :) It has been a LONG week (couple of weeks). I need a vacation.

One more...Can it run on J2SE 1.3.x?

Robert

One more...Can it run on J2SE 1.3.x?Robert

I think one of the requirements of J2EE 1.4 is that by default the implementation should use at least JDK 1.4, so I wouldn't bet on it working with 1.3..

From what I understood it did not require J2EE. Pls correct me if I am wrong.

Robert

From what I understood it did not require J2EE. Pls correct me if I am wrong.Robert

Hmm.. Thought it was based on WAS 6, but then again I might have been sloppy in reading the article.. :)

One more...Can it run on J2SE 1.3.x?Robert

Not yet... :-) We have not deliberately implemented any features of ObjectGrid to require J2SE 1.4.2, but our current packaging doesn't allow us to run in a J2SE 1.3.x environment. Look for our next release to support J2SE 1.3.x for the client/core pieces. The standalone server will continue to require a J2SE 1.4.2 environment.

I see. Any hints on when to exepect the next version then? We are still on WAS 5 and not planning to upgrade this year. Also does RMM support data encryption? Here I am mean the data being replicated of course.

Robert

The way we plugin replication is completely pluggable. You can do what you want to with data prior to transmitting it. Compress it, encode it, encrypt it.

RMM itself offers SSL in a WAS environment. In multicast mode, it's plain text. RMM is only available as a message transport for now when ObjectGrid is used in a WAS 6.x/XD environment.


Billy

Hi Billie,

congratulation on the release. Looks like this is direct competition to JBossCache :-)
Is there any information available on RMM ?

Bela

Hi Bellla,
In order:

* Thanks
* yep
* it's an internal WAS component we're leveraging for our message transport and it's very, very fast...

Billy

"It is designed from the ground up as a transactional cache and the APIs reflect this"

Most of the time this will get used it will actually read:

"We made it a transactional cache, because we thought it is cool and we thought that we needed it. Unfortunately, we did not consider that a trip to the database (that is already there and sports a built in query cache) would be about as fast as finding things in the cache. Actually, we did not really think about a transactional cache being a lot slower and more error prone than any decent database in the background, because we had to use XA transactions in order to get it working right in the write through case."

"It is designed from the ground up as a transactional cache and the APIs reflect this"

Most of the time this will get used it will actually read:

"We made it a transactional cache, because we thought it is cool and we thought that we needed it. Unfortunately, we did not consider that a trip to the database (that is already there and sports a built in query cache) would be about as fast as finding things in the cache. Actually, we did not really think about a transactional cache being a lot slower and more error prone than any decent database in the background, because we had to use XA transactions in order to get it working right in the write through case."

I think you'll end up on the wrong side of this one ;-) .. Billy is a huge database proponent, and if you read some of his previous Websphere benchmarking comments you'll see that for most cases he thinks that a federated database model behind a partitioned logic model is a great way to go.

There are cases in which transactional caching could be a net loss, such as with synchronous writes within XA transactions in a relatively write-heavy transaction mix. So because there is one case in which it doesn't make sense, do you therefore believe that there are no cases in which it does make sense?

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

There are few circumstances when a trip to the db is going to be faster than getting it locally. You may be overestimating the implementation of a transactional cache here. The main one is where the data is basically uncacheable. The dataset of too large, individual records are hit rarely and there is no locality of reference. In this scenario, the database cache makes most sense. Online auctions would be a good example of this scenario. Millions of auctions per day lasting a couple of weeks each where each auction is hit rarely over this period.

The other problems is the databases are very expensive to scale up either vertically (box hardware) or horizontally (box + db licenses). A front end cache or a hub based cache tier between the app and the db can lower the cost of a solution significantly by moving mips from an expensive tier (the db) to a lower cost mips tier like a cache. Cameron has made the same points in pitches he's given. This is probably the main reason db vendors don't like this kind of technology one little bit...

Transactional makes a lot of sense for the following reasons:

Our Loader APIs are now batch focused. This is only possible because we have a notion of transactions in the application API. This allows Loaders to take advantage of SQL batching or RPC batching when a Loader is a client to a hub. Being able to use batching in the Loader first class is a big performance win.

Replication is more performant and more correct when the application can explicitly bracket a set of modifications together and they are replicated as a single atomic unit to peers or the hub.

When we implement the hub based cache then this batching should provide significant performance improvements in terms of number of RPCs to the hubs versus a non transactional API which would basically RPC on every modify method. We'd still need an RPC per remote get although there are tricks to play even here depending on the circumstances.

We still provide a flush method to force the current changes to be written to the backend in the context of the backend transaction. This is useful when the application has some ordering issues with backend modify instructions.

We have no XA issues as the ObjectGrid works as the last one phase resource in a 2PC so the ObjectGrid only commits if all 2PCs have committed. There is still a very small window here if the machine hosting the cache dies in the window between committing the XA transaction and calling commit on the cache but this is what optimistic locking was invented for...

The ObjectGrid is not dependant on databases at all. Of course, you can write a Loader that uses JDBC, CMP, Hibernate or TopLink to access data in a database. But, Loaders can be constructed to front end anything, remote systems, CICS systems, SOA backends, you name it, you can plug it in. It makes all these scenarios faster. It's not just about databases, especially with all the SOA type data fascading that seems to be going on. This seems to be the focus of your point but it's a very narrow point of view.

The ObjectGrid can operate in non transactional mode which is like auto commit on a JDBC connection. We reckon that while we support this, it's likely going to be slower than using the transactional support for most scenarios because of various efficiencies with batch type optimizations within the framework and the plugins that we or customers provide.

Billy