01 Aug 2003
这是一篇关于网络方面的文章，本人无意中在IBM中找到，感觉特有意思拿来跟大家分享下！！
One of the problems with any computing technology is getting the different components to talk to each other. This is why we have standards. But how do we apply standards in grid computing? What standards are available? And how much can you really gain from using standard solutions in your grid applications? In this article, Martin C. Brown answers these questions and provides a history of where grids have come from and where grids should be going.
One of the problems with any computing technology is getting the different components to talk to each other. Nowhere is this more critical than when trying to get different platforms and environments to talk to each other. This is one of the challenges facing grid computing. To make the most effective use of the computing resources available, these environments need to talk the same language.
In this article, we're going to look at the significance of standards in grid computing, how they affect our capabilities and facilities, what standards exist, and how they can be applied to the problems of distributed computation. We're also going to have a look at the benefits of a standards-based environment.
To understand how standards fit into the overall makeup of grid computing, we need to look back at how grid computing has grown and developed.
It's probably fair to say that the origins of grid computing came out of the early days of computer networks where using the "spare" CPU cycles was seen as an efficient and cost-effective way of getting the most of what was then very expensive hardware. It's 1970: Computers are big mainframes that cost hundreds of thousands of dollars, every second has to be accounted for, and those otherwise "wasted" cycles can be used to get the most out of the cost.
Fast forward a bit: The Internet has created a huge potential for untapped computing power. Two leaders, distributed.net and SETI@Home, emerge from the field in making the general public's own computers capable of processing work in a distributed computing environment. Distributed.net concentrates on the computational needs of solving encrypted strings through brute force methods.
SETI@Home made the idea of finding extraterrestrial life exciting by allowing the public to process radio logs for peaks and regular signals. Behind the scenes, other companies produced solutions -- some generic, such as those from United Devices, and others supporting specific goals, like Parabon.
All of these systems, however, are different. If you've installed the distributed.net client, you can't process or even access work from SETI@Home. Nor can you deploy a United Devices client solution without also using its distribution and management system.
 |
|
Twwl hgoiwh, ghgi, ahdfigh pkasdp ndpjw pipinmg.
Did you understand the above? I'm sure you didn't, but it very neatly describes the problem of living without standards in our lives. Without a standard method for communicating the written word, we'd never be able to understand each other.
The same is true in computing. If you're reading this online, not only are you probably reading it in English, but also you've done so by using TCP/IP, a network communication standard; HTTP, a file transfer protocol standard; and HTML, a text description standard. You probably also used a keyboard and mouse that also adhere to a number of different standards to make them work with your computer. Finally, don't forget the operating system and applications needed to communicate and translate all of this from bits to pixels on a monitor.
In the emerging technology called grid computing, the lack of standards has meant that a whole host of companies, developers, and organizations have been developing and supporting the technology using different techniques and solutions. In the relatively isolated worlds of each grid computing group, this hasn't caused a huge number of issues. But in the wider world of extending the grid computing environment, it has created divisions, disagreements, and limitations.
An effective grid relies on making use of computing power, whether on your LAN, over an extranet, or through a wider Internet system. To use computing power efficiently, you need to support as wide an array of computing platforms as possible, while also having a flexible mechanism for distributing and allocating the work to individual clients.
Looking at some of the better-known grid computing projects on the Internet, you can probably already see the limitations of a nonstandard approach. Take distributed.net, for example. To become a service provider for the distributed.net grid, you must download a specific client that is capable of processing the work units from the corresponding servers. With a distributed.net client installed, you can only process work units supplied by distributed.net.
Such a closed environment limits the ease in which you can distribute work, who can become a service provider, who can be a service requester, and how you can find out about the available projects. Distributed.net service providers can only process those work units supplied by distributed.net.
Taking a closer look at some specific problems, the following areas detail where a lack of grid standards cause potential problems:
Looking from the perspective of the grid developer, the use of closed environments is also a problem. To make use of the computing resources across a grid, a grid developer has to use a specific toolkit or environment to build, supply, and process work units. This limits the grid platforms on which work units can be executed and also limits how you use and supply work and requests to the grid.
It also means that you cannot combine or adopt other grid solutions for use within your own grid without redeploying the grid software. Imagine, for example, if distributed.net wanted to allow their service providers -- those people with the distributed.net client installed -- to process SETI@Home work units -- they'd have to redeploy their service provider. They'd also have to redesign many of their discovery and distribution systems to allow different work units to be deployed to service providers, and they'd need to update their statistical analysis on completed units to track it all properly.
The purpose of a grid is to make use of the available computing power. But without standards, we are actually limiting -- rather than extending -- our ability to use spare computer power for grid services.
|
|
Advantages of a standard approach
The advantages of the standardized approach are many, but they all boil down to the same basic advantage: the extension and expansion of the resources available for grid computing. More specifically, following the OGSI standard should provide the following benefits:
By using a series of standards, we can increase our potential resource pool, expand our grid services, make them easier to manage, and enable them to operate in an open and efficient manner that will make it easier to deploy and use grid services.
But which standard do we choose?
|
|
Understanding the OGSA and OGSI
Currently, there is only one grid services standard: the Open Grid Services Architecture (OGSA), and its companion implementation standard, the Open Grid Services Infrastructure (OGSI).
OGSA aims to address these issues by defining the basics of a grid application structure that can be applied to any grid system. In essence, the OGSA standard defines what grid services are, what they should be capable of, and what technologies they be based on. OGSA, however, does not go into specifics of the technicalities of the specification. Instead, the aim is to help classify what is and what isn't a grid system.
OGSI is a formal technical specification of the concepts described by the OGSA. OGSI consists of specifications on how work is managed, distributed, and how service providers and grid services are described. Web services, particularly the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL), are a major part of this specification.
The Web services component is used to help distribute and manage work across the grid. Because Web services offer a transparent method of communication between hosts, you can use them to easily transfer work, describe resources and configuration information, and communicate and dispatch grid information, irrespective of the underlying language or platform. WSDL provides an easy method of describing and advertising the Web services that support your grid application.
It's hoped that the OGSI will form the basis of a number of different grid implementations. The first of these is the Globus Toolkit, which is now in version 3.0. This latest version is based on the OGSI standard.
To understand the differences, the OGSA takes the role of a designer when building a car, OGSI takes the role of the engineer who turns the design into a technical specification, and Globus acts as the people who actually build the car and make it work.
Because the OGSI standard is based on many other standards (XML, Web services, WSDL), it is an open and standards-based solution. In the future, this should mean that grid services can be built that are compatible with the OGSI standard, even though they may be based on a variety of different languages and platforms.
Currently, both OGSA and OGSI are works in progress. We're on the first rung of the ladder towards producing a more generic standard that addresses all of the problems with nonstandardized solutions.
IBM is a key driving force behind the move to a standardized grid environment. It is a key supporter in the Globus Toolkit, the primary solution that supports the new standards of the OGSA/OGSI system. IBM is also a sponsor of the Global Grid Forum, whose mission is the development of industry standards for grid computing. The company is also deploying a version of WebSphere®, the Web development platform, that makes use of grid technology to help spread the load of requests for a Web application.
|
|
It would be nice to think that in the future a standard grid platform can be developed and deployed across any capable device, with a submission system that allows anybody with the appropriate authority to be able to submit jobs to the grid. Instead of a number of individual grids affiliated with specific companies or projects, we could have one global grid, with jobs being spread across the grid according to the job requirements and resource availability.
Looking even further forward, a standard method for describing the processing required for individual work units would also be an advantage. If we can deploy a standard service provider to each grid provider, regardless of the underlying platform, it would be able to process any work without requiring the client to be updated. It would present an almost limitless resource for grid projects.
|
|
In this article, we've looked at a number of benefits of using a standard grid environment, such as the OGSA/OGSI system. There are two main benefits to moving to standards-based grid applications. The first is the ease of development and deployment of the grid technology. The second benefit is more significant: using a standards-based system increases interoperability and flexibility, and should ultimately lead to larger grids and the wider use of resources for grid projects.
 | ||
| Martin C. Brown is a former IT director with experience in cross-platform integration. A keen developer, he has produced dynamic sites for blue-chip customers, including HP and Oracle, and is the technical director of Foodware.net. Now a freelance writer and consultant, MC, as he is better known, works closely with Microsoft as an SME; is the LAMP Technologies Editor for LinuxWorld magazine; is a core member of the AnswerSquad.com team; and has written books such as XML Processing with Perl, Python and PHP, and the Microsoft IIS 6 Delta Guide. MC can be contacted at questions@mcslp.com. | |
评论