Ramesh Loganathan has written on the much hyped topic of "Grid Computing" and asks "Where do J2EE Application Servers fit?". Daniel Sabbah of IBM has his slides on "Bringing Grid & Web Services Together" online.

Read Ramesh in A J2EE App-Server Grid?

Read Daniel in Bringing Grid & Web Services Together

I enjoyed reading the entry. good stuff but i found the items listed there as fuzzy as the definition of grid itself. each item has to examined alone. still it is a good start. I think the most important aspect of grid is 'Provisioning & scheduling of resources/jobs' as stated in the blog entry. I don't remember where but I read something about 'phases of grid computing' and the author was saying that first phase of grid computing is 'clusters', which is the most primitive type of grid computing. we already passed that stage. second stage is 'dynamic clusters' which is clusters with intelligent failover, failback, load balancing and replication. to some degree we passed this stage too; most of the app. servers have dynamic clustering. one of the phases after this was to achieve, if i remember correctly, 'a system which is capable of provisioning & scheduling or allocation of resources'. this phase is not passed yet. I am not sure if this is one of the objectives of J2EE but if it is to some degree i think we need stuff like WorkManager and Timer for J2EE.
 
> Read Daniel in Bringing Grid & Web Services Together

there is only one thing i have to say for this one... my stomach can handle only one buzz word in a title.

Clusters - in many cases represent complete system and process replication in order to provide scalability and as you state dynamic clusters add in fail over and load balancing. I agree that the current view of Grid's implements provisioning, but the job/task scheduling is holding the concept back for what I see as a fourth evolution of the grid - segmentation, autonomy and collaboration.

I've been building some form of application container (called Neon) based on clusters and grid concepts using Jini2.0 and an agent framework. In essence, the components of the application are spread out across the grid to where they are most suited to execute (provisioning) using constraints specified using XML, at that time, (of course this may change as resources change, systems fail etc, so these components migrate if they can to another server and restart). The application dynamically assembles it's disparate components when required, but the nature of the system is extremely fluid.It's coming along fairly well.

For me, J2EE just can't do this kind of work unless you can segment the monolithic server into several 'pieces' that are spread across multiple boxes but still provide a single system (from a development view). That being said there are people out there, far,far more smarter than me, that could probably bend J2EE to provde app segementation.

The concept of job and task scheduling seems to be a bit 'two steps forward, three steps back' - it's extremely limiting you can't assume that every task can be scheduled.

The key to grids is to look at the grid as a whole, but still understand that each node has it's own strengths and weaknesses, and each node will have different integration possibilities, a grid app spread over Linux and Windows is an application with access to the facilities of both Linux and Windows simultaneously.

Cheers

Calum.

<snip>Again, in simple terms computational grid computing is all about taking a long-running task, splitting it (often recursively) into number of sub-tasks, executing them in parallel and then aggregating results back, in the end executing the whole task faster. In a nutshell &#8211; that's it.
</snip>
Not ncessarily. Usage ofr large tasks was the initial origin of the grid. But the essence of grid computing is also about dynamic computing-resource- the "grid" that is very fluid- cells join, cells leave. Anytime. When not on the grid, the cells are used for other purposes.

Current adaptation to an Enterprise Grid, is a set of machines that can join or leave anytime. The primary utility from such grids will be the hi-computing power one can get from a bunch of low-end low-cost machines. The "grid fabric" will ensure that the machines can be got onto the grid (or removed) with very little effort and complexity. The fabric will also allow heterogenous machines and OSs to join this "grid".

Extending to biz-computing grid, such grids will be used for a very large number of small tasks. So no parallel processing, but manage a very dynamic large processing grid. So resource provisioning, scheduling and allocation become the key. Especially doing this in a non-master-slave manner! With the "grid" managing itself- a "self-organising" entity.

A J2EE grid will harness the J2EE abstractions and the component model for load scheduling (more load-distribution!) and resource provisioning.

Cheers,
Ramesh (L)

J2EE grid should allow WL+WS+JBoss+IPlanet servers to run together as so promoting vendor neutral environment. since client proxies to the servers are vendor specific, integration cannot happen through rpc. it has to happen through data. interface should be the data. that is why grid requires a data layer. this grid-wide data layer is called 'data grid', federation of data.

-talip

J2EE grid should allow WL+WS+JBoss+IPlanet servers to run together as so promoting vendor neutral environment. since client proxies to the servers are vendor specific, integration cannot happen through rpc. it has to happen through data. interface should be the data. that is why grid requires a data layer.

Globus does mixed-vendor clustering with J2EE, with features otherwise absent in J2EE, such as distributed indexing, file replication, job scheduling, etc. Globus can deploy as a war. And a Python container is being developed. The Global Grid Forum has decided on WSDL as the official grid language of federating activity, such as advertising and monitoring.

I just want to point out our Sun Grid Engine,which has thousands of customers and an active developer community.
The basic version is opensourced at,
http://gridengine.sunsource.net

-Uday.

>

sounds great, how can we learn more about 'Neon'? is it open to public?

> For me, J2EE just can't do this kind of work unless you can segment the monolithic server into several 'pieces' that are spread across multiple boxes but still provide a single system (from a development view). That being said there are people out there, far,far more smarter than me, that could probably bend J2EE to provde app segementation.
>

what do you mean by 'segmenting the monolithic server in to several pieces'. do you mean something like running tx manager on one of the boxes, jms on another box and ejb container on another but still having them using the same 'server context'... or do you mean running deployed user-applications on different boxes in some distributed fashion?

> The concept of job and task scheduling seems to be a bit 'two steps forward, three steps back' - it's extremely limiting you can't assume that every task can be scheduled.
>

interesting...can you give me an example for unscheduleable task?

> The key to grids is to look at the grid as a whole, but still understand that each node has it's own strengths and weaknesses, and each node will have different integration possibilities, a grid app spread over Linux and Windows is an application with access to the facilities of both Linux and Windows simultaneously.
>

makes a lot of sense..

-talip

Can we not achieve the same goals by using a cluster?? A cluster has many multiple machines, hosting resources which share the work load and are managed by a load balancer. In a grid there will be extra layer of complexity for managing different types/platforms working together in a grid. I still don't see the need for a grid in relation to an application server.

Can we not achieve the same goals by using a cluster?? A cluster has many multiple machines, hosting resources which share the work load and are managed by a load balancer. In a grid there will be extra layer of complexity for managing different types/platforms working together in a grid. I still don't see the need for a grid in relation to an application server.

Sure, a J2EE cluster is powerful. But metacomputing offers more:

- Single sign on
- Job scheduling
- Distributed indexing
- Monitoring
- File replica management

I think misconceptions about grid computing stem from the fact that is still somewhat vaguely defined (it has significantly improved in the last couple of years though) with multitude of concepts, different approaches and implementation strategies.

In the same time I think there is prevailing realization among grid computing community that computational enterprise grid is practically the only type of grid computing application that has gain significant business adoption. In simple terms, enterprise grids don’t suffer from security and resource management problems that plague global grids, for example, in part because these issues are usually addressed by existing enterprise IT infrastructure. Enterprise grids also provide more plausible business use-case that is essential for adoption if grid technology. The latter argument also underscores why computational grids are more adapted then, say, data grids, that have already effective traditional, non-grid, solutions that exist today.

As far as J2EE and grid computing I don't currently see much of a in-place integration beyond some protocol issues such as RMI/IIOP vs. WS which are secondary in nature at best. I think J2EE and grid computing technologies are quite orthogonal at what they are trying to achieve yet they can clearly be used together.

When we are talking about grid computing it seems we often try to over generalize. Again, in simple terms computational grid computing is all about taking a long-running task, splitting it (often recursively) into number of sub-tasks, executing them in parallel and then aggregating results back, in the end executing the whole task faster. In a nutshell – that's it.

One of the problems in grid computing perception stems directly from early implementations that almost solely focused on the type of tasks where we take 1 week task and executed it in 1 hour. Unfortunately, absolute majority of the business (with exception to biotech, major financials, U.S. DoD/DoE, NASA, etc.) don't have computational tasks that takes so long to compute and yet warrant the grid computing adaption.

In upcoming 2.0 version of our product (xTier – Service Oriented Middleware) one of the services we ship is Near Real-Time Computation Grid Service. This simple to use yet extremely powerful service allows to build "commoditized" grid applications where we take 20 seconds task and execute it in 4 seconds type of the problem can be easily solved (additionally to a "1 week" type of a problem). Being cross-paradigm in nature (as the rest of the xTier technology), running on Java or .NET, having unique two-way smooth integration into existing IT environment and possessing near real-time grid characteristics – is what it takes, I believe, to have a successful grid infrastructure.

Regards,
Nikita Ivanov.
xTier - Service Oriented Middleware

>

i think, what you are describing is parallel processing, master-worker pattern, not grid computing but certainly covered by computational grid... provisioning and allocation of resources are the essentials of grid.

-talip

Hi Talip,
Certainly, I did describe a computational grid (intentionally in a very simple way). General provisioning (and allocation) of resources are the nuts and bolts of a specific implementation and for many it can be the most significant part of the implementation.

It was however pointed many times that the difference between classic parallel processing and grid computing lies primarily in definition area rather then in profound conceptual distinctions.

Regards,
Nikita Ivanov.
xTier - Service Oriented Middleware

> Certainly, I did describe a computational grid (intentionally in a very simple way). General provisioning (and allocation) of resources are the nuts and bolts of a specific implementation and for many it can be the most significant part of the implementation.
>
who am i to say what grid is but my limited knowledge says 'splitting the big task (often recursively) into number of sub-tasks, executing them in parallel' is what you can easily achieve with grid but is not the definition of grid computing as i said earlier. take a look at the following 3 main computional grid vendors listed below and also globus project (technicalpapers section has so many good papers on grid) and then if you still say grid computing is 'splitting the big task (often recursively) into number of sub-tasks, executing them in parallel', i have nothing left to say to you...
1. Platform Computing
2. DataSynapse
3. United Devices
4. Globus

best regards,

-talip