There's an Analyst Lurking in that Business
I recently read an editorial from Grid Today (GT) based upon conversations with Forrester’s Frank Gillett suggesting that interest in Grid computing is waning. I will not dispute the veracity of this claim; rather I will leave that to the people such as the HPC Today editorial staff who have access to the Forrester report. Irrespective of the actual level of interest that buyers have in the Grid, I was rather baffled by the reasons that Grid Today provided for the general "malaise".
The first reason that GT offers is that, "grid computing is, in general, beneficial to vertically specific applications." More specifically, they indicate that there are limited sets of applications that could benefit from grid computing. I am assuming that the set of applications that they are referring to are those which require high-performance parallel calculations as well as any algorithm that can use the Map-Reduce pattern to distribute the computational load across many servers.
So which classes of applications do not work well on the grid? Clearly Service Oriented Architectures (SOA) works well on the Grid. In fact the Globus Toolkit, a popular software toolkit for building grids, uses SOA at its core.
Yet I believe that any n-tier application run on a Grid has many advantages. For example, imagine a web-based application with a supporting relational database that is required to scale under significant user loads including the number of connections but also the complexity of the requested services. Also imagine that clusters of users in different regions will use this application.
First of all, it would be nice for us to provide the data-services of this application using a SOA. Doing so allows us to expose the data through a single access-layer. Thus any program can access the data using the same business rules without tying it to a single-application interface. Secondly, if users require any complex reports or other heavy-duty calculations, a single web-server might easily be overwhelmed and thus forced out of the rotation until the process completes. A better solution would be for the web-server to farm these sorts of operations out to the Grid – maybe even using a Map-Reduce pattern. Furthermore adding Grid capacity is an easy way to handle high-peak loads of the application. These resources could be used by other projects during the off-peak periods. Lastly, the grid could coordinate resources that are proximate to the regional user-clusters and thus reduce communication latency for any data that needs to be exchanged without having to keep copies of the web or data-infrastructure throughout the enterprise.
If there are advantages to running your n-tier applications on the grid, it is not much of a stretch architecturally to extend that to other classes of application. I could not imagine implementing a SaaS (Software as a Service) application on anything but a grid. Having said that, I don’t believe that an application needs to be complicated to run better on a Grid. Rather, I think any application that users rely on is a good candidate.
Many "desktop" applications not only can be run on the grid but also are more appropriate to do so. Data centric applications are the prime candidates that come to mind. First of all, keeping results on your desktop all but kills collaboration between users because it is likely on an high-latency low-availability network, may be a separate security-domain and thus inaccessible to many users, and could be shutdown at any time. In addition, if an application reads and/or writes significant amounts of important data, it is best to keep it in the data-center on reliable and, more-importantly, regularly backed-up storage. Of course, the application could write across the typical high-latency low-availability desktop network into the datacenter, but that is fraught with problems. Personally I believe that perhaps the most significant source of user frustration is "network drives" – but I digress. If an application’s calculations take any significant resources, the user’s desktop quickly becomes a bottleneck. Even if the user’s machine is beefy enough to handle running a job while still allowing access to email, they are still hardware limited. In particular, if the application can be submitted in batch to the grid, the user could literally submit dozens if not hundreds of individual calculations and get the results in a fraction of the time it would take on their desktop. Lastly, running jobs at the datacenter frees users from using a single desktop. Rather, they can manage their computing from any location, which provides them significantly more freedom.
All of this brings me to GT’s second key assertion: that the term Grid has been, "bandied about so much that no one knows what it means or what business benefits they might derive from it." This is indeed the core challenge. My experience is that very few business proponents specify software-architectures. Generally they could care less whether a salesperson is pushing SOA, Grid, Cloud, SaaS, or whatnot. These are the concerns of people who support business-lines: CTOs, IT support-managers, etc.
Chances are you are not dealing with these sorts of technical folks when you are drafting a proposal. Rather, you are likely speaking with a business-analyst. The ones I know are not easily charmed by buzzwords (even if their bosses or peers are). They are more than aware that terms mean different things to different vendors and their staff.
Frankly they don’t care about your pet technology. Instead, they have a set of goals and a given budget. They are measured on how well the project met the user’s needs, how under-budget it came in, and how much time it took. If any one proposal that they have happens to align with other business initiatives of which they are aware, then they will consider the advantages as well as the costs of implementing it. We all know that individual business groups tend to go their own ways, particularly in large companies. We are not going to corral them with the "Grid".
Yet there is plenty of hope for us. We Grid proponents should focus on providing small group-level systems that are quickly setup, scale easily, and meet the customer’s defined business goals. These implementations do not need to fall under the traditional association that Grid has with high-performance computing (HPC): HPC is not often amongst the business goals. However if the group Grid is built using open-standards, has a resource manager, and allows for the provisioning of global management systems (e.g. authentication domains), it is easy for the technical types to incorporate this small-Grid into an enterprise-wide effort. This is how we can sell the Grid.
منبع : http://gridgurus.typepad.com
Distributed Resource Management Application API (DRMAA) is a high-level API that allows Grid applications to submit, monitor and control jobs to one or more DRM systems. 
Grid Engine 6.2 will come with some interesting new features. In addition to advance resource reservations and array job interdependencies, this release will also contain a new Service Domain Manager (SDM) module, which will allow distributing computational resources between different services, such as different Grid Engine clusters or application servers. For example, SDM will be able to withdraw unneeded machines from one cluster (or application server) and assign it to a different one or keep it in its “spare resource pool”. It is also worth mentioning that Grid Engine (and SDM) documentation is moving to Sun’s 
Xgrid : اپل همراه Tiger Server نرمافزار 1.0 Xgrid را نيز عرضه ميكند. نرمافزار رايانش توزيعي اپل، كار ساخت ابررايانههاي موردنياز مراكز علمي و تحقيقاتي را بسيار سادهتر و كم هزينهتر از قبل خواهد ساخت. Xgrid 1.0 براي انجام پردازشهاي توزيعي از ده هزار كار در انتظار پردازش، ده هزار وظيفه در هر كار در انتظار پردازش، دو گيگابايت داده در هر كار منتظر پردازش، يك گيگابايت داده در هر وظيفه و مجموعاً ده گيگابايت نتيجه مرجوعي پشتيباني ميكند.