Java Technology on the Grid
By templedf on Jul 07, 2004
The role of JavaTM Technology in grid computing is a very interesting topic at the moment. I find it fascinating to see various groups coalescing around the various definitions of Java-enabled grid computing. About 9 months ago, I did quite a bit of talking around to folks in the business and distilled the various notions of J2EETM-enabled grid computing down to 5 basic ideas, which so far seem to be in agreement with what the rest of the industry has come up with.
Grid Service Container
Building a grid services container (as defined by Globus and/or the OGSA working group in the GGF) on top of the J2EE platform seems like a good match. Since grid services are tightly coupled to web services, the J2EE platform is a natural choice for supporting them. However, I am still not converted to the religion of web services. In my opinion, JiniTM technology is the best web service technology out there. Grid services are getting a lot of attention right now, but in my opinion, they're highly overrated.
Provide an API for J2EE developers to use to access the grid from their applications. This could be a JCA adapter for DRMAA or something like my JGrid project (LINK). The strength of this solution is that it opens up the grid to developers, bringing it more into the mainstream. No one writes for the grid right now because there is no way to write to the grid. If a stadard API were widely available that gave Java programmers an easy to harness the grid, I think they would jump all over it. The downside to this solution that apps have to specifically write to the grid and are tied to an API.
Service Management Framework
This one just recently started getting some attention. The idea is to use the intelligence of the grid for scheduling services instead of jobs. It's then the grid's job to keep the network balanced and everything running smoothly. DataSynapse has recently released a product like this. BEA had a BOF at JavaOne this year on a similar topic. It's a neat idea. Whether it's actually workable is another question. I also have to wonder where folks like BEA and Oracle are getting thier grids from. Last time I checked, BEA was not a player in the grid computing field.
The idea here is to use the J2EE platform as a container for running jobs. It sounds really cool, and it gets the marketing people all excited, but I say it's all hogwash. Except for the special case where jobs are services (which is covered under the Service Management Framework heading), the J2EE platform does not provide anything a job needs and fails to provide many of the things a job does need, such as a usable lifecycle model. Jobs are limited-duration pieces of work. They are not services. (There is some overlap here with the Grid Services Container heading, because in OGSA jobs are services, but only in the sense that they provide start, stop, suspend, etc. services. In that case, having a J2EE platform hosting the services that sit in front the actual jobs makes sense, but even then running the jobs themselves in the J2EE container does not.) The biggest point to argue is that not all jobs are written in the Java language.
A temping idea is to use the grid to make intelligent decision about how to route incoming service requests. Tempting, but ultimately not good. Grids today are not up to making the split-second decisions required to effectively do service call routing, unless the duration of the service calls is very long. For N1 Grid Engine, anything less than about 30 seconds is starting to have a bad duration to overhead ratio. Plus, I seriously doubt whether the additional intelligence (and hence additional overhead) of the grid would make it significantly better at routing that a run-of-the-mill load balancer.
There it is in a nutshell: my view of Java technology and grid computing as it stands today. I think the last two are bad ideas, the second and third are good ideas, and it doesn't matter what I think about the first one because everyone thinks it's a great idea.