Open Grid Forum

Standards Home

Why Standards?
Developing Standards

Using OGF Standards
Areas and Groups OGF Document Series

Why Standards?
Why Standards? Standards are an essential aspect of modern industrialized society. Standards permeate every aspect of life, SAE lubrication standards, standard size screws and sockets, voltage standards, grain and protein feed mix standards, and standard battery sizes are just a few of the thousands of standards that make modern life possible. What makes standards so important is that it allows consumers (or vendors of other products that use the standardized product as an input) a wide choice of different vendors, eliminating vendor lock-in. For vendors it commoditizes the product, facilitates the formation of markets, and allows vendors to compete effectively against others on aspects such as price, quality, or delivery time.

The situation is similar in the Grid computing world. Grid standards benefit users of Grid technology by eliminating vendor lock-in, and permitting the selection of best-of-breed implementations of Grid components. For producers of Grid technology they provide a conformance target that can be used to assure customers of interoperability. Further, they eliminate the need for a Grid vendor to implement all of the many moving parts needed in a successful Grid – they can build specific components of their own (e.g. user interfaces or GUI’s) without the need to develop all of the parts.

Deeper dive.

Before we can understand why standards are important to the to the Grid community, we must first ask “why have Grids failed to “cross the chasm? into mainstream use in computational science and engineering?? While there are many possible explanations, two seem clear in retrospect.

First, Grids depend on the “network? effect. They increase in usefulness as more resources are connected to the Grid. Unfortunately we have many different, non-interoperable, Grid middleware systems in use today: multiple versions of Globus, Unicore, gLite, SGE, Platform, OMII-UK-based grids, Condor, and many others. Instead of a Grid, we have many small islands. Five years ago there were no standards for interoperation. Today, through the work of Open Grid Forum (OGF), there are.

Second, and more importantly, most Grid systems are not easy to use, they are low-level toolkits at best – not integrated systems. They expose many features of the underlying system to the user: failures, disjoint file systems, file system cache coherence, heterogeneous platforms, and explicit identity management to name a few. To write a Grid application often requires the programmer to learn a whole new set of paradigms and tools, and to explicitly manage the environment. Users and organizations want solutions, not toolkits. Indeed they do not even want to know they are using a Grid – they just want it to work.

While both of the above impact architectural decisions, standards are the most important. The benefits of standards vary depending on who you are. Lets look at this from three different perspectives: the perspective of BNGP (Big National Grid Project), the perspective of a middleware developer, and the perspective of an applications developer.

BNGP consists of a number of sites with a number of resources, and historically has used their own Grid software stack. If BNGP does not use standards for the most basic services, authentication, process/job management, inter-process communication, file and database access, and application description and deployment, then BNGP will remain an inward looking software stack, communicating only with itself or perhaps a small number of projects that use the same software stack.

Such isolation has three negative effects. First, BNGP will not be able to exploit “best of breed? implementations of the basic services developed outside of their software stack. For example, Microsoft is investing in Windows cluster management services with OGF standard interfaces. If the BNGP was using those standards, a Windows cluster at a partner institution could be included in the BNGP without having to spend the time and resources to develop a first rate implementation of your own middleware for Windows.

Second, software components developed by BNGP developers targeted at BNGP middleware may not be accessible to the widest possible community of potential users. Only users of BNGP’s software stack will be able to use the developed components. For example, consider a meta-scheduler. If the scheduler is developed using OGSA-BES and the HPC Basic Profile it could be used with a number of different systems, rather than just one.

The third effect is the interoperation between BNGPs around the world. Science is a global enterprise today, with partners and resources scattered around the globe. To realize the potential of the global infrastructure investment requires interoperation between BNGPs. However, one BNGP is unlikely to adopt the complete middleware stack of another BNGP. Interoperation can best be achieved via the use of standards.

Therefore, by embracing OGF standards the BNGP is much more likely to interoperate with other projects and products. This reduces the need (and resources) for software development and increases the uptake at non-BNGP institutions who can adopt the BNGP software without fear of “vendor lock-in?.

Next let’s consider a middleware developer such as an academic research group or a commercial software vendor. As a consumer of standard services you don’t have to implement an entire grid stack in order to provide value, you can focus on your value add and expertise. Similarly, as a provider of standard services, you can “sell? into an existing market of consumers of the standard service. Of course you have to compete with other implementations, perhaps by offering better performance, higher availability, or lower cost. Finally, standards have the potential to increase the size of the market by both reducing the risk of adoption to applications developers and by increasing the number of applications available.

Finally let’s consider the perspective of an applications developer. One of the most frustrating aspects of existing grid software is that after expending a great deal of effort to develop an application on one grid software stack – a complete re-write is often needed to work on another. By using standard services you need write only one implementation rather than one for each stack. Standards also act as a risk reduction mechanism, with the success of your application not being tied to the longevity and success of a particular grid software stack.

> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF