Beth Plale, Ph.D.
Department of Computer Science
Indiana University
August 2, 2004
(pdf version)By now the hype surrounding grid computing has worn thin around the edges, and some people are beginning to suspect that the whole thing was never anything more than just the hype. Has grid computing become passé? We think not. In fact, far from being hype, grid services as a model for organizing large distributed applications has a bet ter chance for long-term success than earlier distributed computing models. It offers the possibility for the kinds of distributed applications that were difficult to imagine even 5 years ago. Severe storm forecasting, for instance, is poised to make large gains in forecast accuracy because these computationally intense forecast models will be able to run on demand and on as many computers as is needed to ensure a fast and accurate forecast. Additionally, the forecasts, which rely on actual observed weather conditions for their starting conditions, will be able to pick and choose from their information sources, whether Doppler radars, sensors, or weather balloons, all monitoring the weather and streaming information to the forecast models in real time.
Building distributed applications is notoriously difficult. The news media and books are rife with stories about project overruns, schedule delays, and downright project cancellations. The computer science community has proposed different approaches over the past 20 years to building wide-area distributed applications, with each new solution addressing the shortcomings of the earlier generation’s solutions. This evolution has generated three dominant approaches: ‘remote procedure call’, which first emerged in the mid-80’s; ‘distributed objects’, which reigned during the 90’s; and finally ‘grid services’ that has emerged within the last 5 years. In this article, we take a historical look at distributed computing models as a means to demonstrate how grid services is poised for success where these other models have failed. Any long lasting success of grid services cannot be wholly credited the grid service notion itself, however, because the wild success of the Internet has laid the groundwork for widespread acceptance of some notions that are fundamental to distributed computing.
Before delving into the details of the three distributed programming models, we define three issues that a distributed computing approach must address. The first of these is security. Security is the preventing of malicious intent, and the dealing with code pieces owned and run by different people. The second is communication.Communication is the means by which software pieces that are distributed across a building or across the world communicate with one other. Difficult problems of heterogeneity in terms of machine architectures, word sizes, etc. must be resolved. Finally, discovery is the process whereby a component piece of software finds the remote functionality that it needs to use. Specifically, how does the software component figure out what other software components are out there, where they are located, and how to talk to them?
In the remainder of the article, we discuss the evolution of approaches to distributed computing, showing how grid services addresses the limitations of the earlier approaches, particularly in the areas of security, communication, and discovery.
The first technique for writing distributed applications to gain acceptance was the remote procedure call, developed in 1986 by Birrell and Nelson. In the Remote Procedure Call (RPC) approach, a distributed application is organized as a set of procedures (or functions) where some of the procedures reside on a local computer and others may reside on a remote computer housed in another building or lab. Middleware that runs on each machine hides the fact that some procedure calls are local and others are remote by hiding a myriad of details: the packaging of the procedure call and its input parameters into a message, the shipping of the message to a remote machine, the invoking of the procedure on the remote machine, then the packaging and shipping of the response back to the calling user are all hidden from the user.
Distributed RPC applications generally assume that the same person owns all procedures, whether local or remote. It also assumes that all computers on which an application runs will execute in the same administrative domain. With these assumptions, security can be accomplished by encrypting the message transfer and validating the sender, both techniques have been implemented in later RPC packages. Communication between local and remote procedures is handled by the use of a machine neutral binary data format, XDR in the case of SunRPC, which encodes data into a network neutral format. The network neutral format addresses problems such as word size and bit ordering (i.e., big-endian, little-endian). Responsibility for discovery in RPC falls to the programmer. The programmer must know the name of the remote procedure and the machine on which the remote procedure is located, and provide this information to the client software.
In the 1990’s the distributed object model gained favor as a viable approach to writing distributed applications. In a distributed object model, of which CORBA and Distributed COM are examples, the programmer organizes an application as objects that invoke each other’s methods. Objects residing on separate computers communicate with each other through an Object Resource Broker (ORB), a special object that handles communication between application objects. As in RPC, security in distributed objects is straightforward because the entire distributed application is run under the same owner. Communication between objects is accomplished by method invocations passed from calling objected to called object. Passed between them is another object that has been flattened, or serialized, into a string of bytes so that it is in a form suitable for transfer across a Local Area Network or the Internet. Method calls to remote objects are identical to calls to local objects; the underlying middleware hides from the programmer the details of local versus remote communication. Discovery is provided through repositories of objects that can be contacted at runtime. The repository, however, is usually closely tied to the ORB and the platform on which it is running.
Recently a third way of organizing
distributed applications emerged on the scene. In the grid
computing model applications are organized as a set of cooperating but
independent services, called grid services. A grid
service is defined as the logical manifestation of some
physical or logical resources (like databases, programs, devices, humans, etc.)
and/or some application logic that is exposed to the network.
Grid services communicate with each other by passing
messages. Grid services are built on top of web
services.
Grid services have the distinct advantage over earlier models in that an individual grid service is far more independent from other grid services than are objects in the distributed object model or procedures in RPC. This is because grid services are encapsulated, meaning that the internal workings of a grid service are not known to other services. Other services do not see the internal workings, implementation details, or resource representations of a service. Services are also autonomous in that service implementations evolve independently of one another. Services share message formats and contracts that define the structure of the information that they exchange, but not information about their underlying type systems. The boundaries of a grid service are explicit, and remain well defined when incorporated into a distributed application.
Communication between services is
restricted to XML messages passed back and forth (using the SOAP message
protocol.) An automated discovery process further enhances this loose coupling
of services. Instead of a programmer having to know the
location of a remote procedure, every grid service agrees to advertise itself by
means of a WSDL description. A WSDL description is an XML document describing
the methods that a service provides, and the means by which a client can
interact with the service. These WSDL descriptions can be inspected by and
acted upon by other services instead of requiring human intervention to
determine where and what functionality a grid service provides.
Is the grid services model passé? We think not. In fact, we posit that grid services will succeed where other distributed programming approaches have largely failed. This success will be attributed in part to grid services being in the right place at the right time. That the Internet has revolutionized information access for millions of people is well known. But a lesser known effect of the Internet is the nearly universal acceptance it has brought for the URL as the means by which content is uniquely identified on the Web. Before the Internet became wildly successful, computer scientists had difficulty agreeing on a single convention for uniquely naming ‘things’, and without this agreement, wide adoption of any distributed approach is difficult to achieve. The second factor to emerge from the success of the Internet is XML. XML is now the lingua franca for groups of people who need to exchange data and other information. Entire scientific communities have gotten together and reached agreement on an XML language defining the terminology and data formats specific to their domain. These languages, called markup languages, define shared namespaces and schemas that groups can use to exchange information. Chemists have defined a ‘chemical markup language’ for describing atoms, molecules, etc. Geologists have Geographic Markup Language for describing planes, points, regions, features such as a rock formation etc.
Advances in security, on the other hand, are a unique contribution that grid services alone has made to the advancement of distributed computing. Researchers in grid computing have devised viable solutions to the complex three-prong security problem that grid services poses: applications must run across computers owned by many different organizations, services must be able to run on behalf of a user they may not know, and a user should only have to prove his/her identity once at the beginning of their work session in order to, for instance, run a separate severe storm model for every county in Oklahoma. Grid services researchers are dealing with another modern problem: that of firewalls. The Internet of today has been said to be made up of thousands of islands of computers, with each island surrounded and protected from outsiders by a firewall. To execute a large-scale distributed application that requires machines and services on numerous islands mandates solutions that work in the presence of firewalls.
Grid services as a paradigm for writing large scale distributed applications offers an improvement over prior approaches in all three key areas of communication, security, and discovery. The security for grid computing is a vast improvement over the single owner solutions of past approaches. Communication by means of XML/SOAP messages is a widely accepted standard that ensures general, portable, reusable solutions. Issues in efficiency of XML are a potential drawback, but are being worked on. Discovery in grid services is by automatic inspection of WSDL documents. Automatic discovery is a huge step towards truly extensible applications.
Grid services have received a lot of attention over the past couple of years, and today some of that attention seems to indicate that grid services are a passing fad. We think not. With help from advances in standardization brought about by the Internet, and some fundamental research in grid computing, grid services are becoming a critical solution for writing large scale distributed applications.
The author would like to thank Dennis Gannon for thoughtful discussion and valuable comments on this article.