Exploring Distributed

Objects

Distributed computing is simply the idea that a program’s operation can be spread across multiple computers on a network. As networks grow faster and more common, an increasing number of applications leverage other computers on the network during their processing.

In this chapter, you will learn about distributed objects: the application of object-oriented technologies to distributed computing. This chapter begins by defining distributed computing and distributed objects in more detail, including sample use cases. Next, you will be introduced to CORBA, a powerful architecture for programming distributed objects. Finally, you’ll read about XML technologies and their role in distributed computing.

The Appeal of Distributed Computing

Distributed computing has received much attention in the last decade as the Internet has risen to prominence. Yet it is more than a buzzword — a distributed program is an ideal fit for certain types of applications. For example, try to imagine writing a program that contains all of the information available on the Web. It would be nearly impossible. The Web is only able to contain its massive amount of data and dynamic content because it is distributed across many different machines.

Distribution for Scalability

In an average day, your desktop computer probably spends most of its time doing nothing. Even when you are actively using your computer, modern processors are so fast that they are idle much of the time, waiting for us human beings to catch up. The reality is that the world contains many computers, most of which aren’t exactly overworked. They are, however, ready to be put to use.

Chapter 24

Most computer users have more than enough power on their desktop PC’s. If you use a monitoring tool to examine the utilization of your processor, you’ll see that it rarely hits 100 percent for any length of time. Some applications, however, are extremely processor-intensive. It might take hours to run a program full of complex calculations on your desktop computer. If you were able to harness the power of the unused processors on your network, that time could be greatly reduced. This technique is referred to as grid computing.

One of the classic real-world examples of an application that uses distribution for speed is image rendering. The generation of just one still frame of movie-quality computer animation requires an enormous amount of computation. 3-D rendering applications have taken advantage of distributed computing for many years. So-called rendering farms can be assembled with high-speed network connections. One machine might serve as the central “brain” and hand out small chunks of computation to each machine in the farm. The brain machine would gather the results to assemble the final image or movie.

The SETI@home project is another example of using distributed computing to increase computational performance. The program aids in the Search for Extra-Terrestrial Intelligence (SETI) by spreading the analysis of signals from space among all participating computers. It would be impractical to attempt to analyze such an enormous amount of data on a single computer. The SETI@home project gives users a program they can run on their home PC’s that processes chunks of data when the computer isn’t being used. Of course, we can’t call it a success quite yet (no little green men have been found), but as an early widespread distributed Internet application, it helped popularize the technology.

Distribution for Reliability

Distributed computing can be seen as a solution to Murphy’s Law — whatever can go wrong, will go wrong. Certain applications, such as Web sites and databases, need to be available and working at all times. These applications can be written so that they are running on multiple computers on the network. If one machine goes down, another can immediately take over. In cases like this, distribution becomes mainly an issue of synchronization. All instances of the application need to communicate enough so that when a failover occurs, the user doesn’t experience any change.

When you access a large-scale Web site, you are really connecting to one of many servers, all of which contain mirror images of the same data. A device known as a load balancer is often used to route incoming requests to an available machine. If one machine fails, the load balancer ceases to send it any requests until it is repaired.

Distribution for Centrality

It is often useful to have one system on a network that controls or monitors the behavior of other applications. For example, Sassafras Software’s KeyServer is an application that allows network administrators to ensure that software being used on their network doesn’t violate licensing terms. When a user on the network launches an application, the application contacts the KeyServer to request permission to run. The KeyServer keeps track of how many copies are currently running. If additional licenses are available, the requested application starts up normally. Incidentally, KeyServer also makes use of distribution for reliability — administrators can install multiple “shadow” KeyServers in case one goes down.

694

Exploring Distributed Objects

Distributed Content

Peer-to-peer applications have exploded in popularity recently. The basic idea is that users on a network all run an application that lets them communicate on a one-to-one basis. In a file-sharing application, each user makes files stored on his or her local computers available on the network. Users seeking that file can connect to the user who has it and begin a transfer. By distributing the file-sharing application across all of its users, the application is able to offer a larger quantity of content than could be housed on a single server. It also distributes the communications load, so there is no central server that becomes a bottleneck for all requests.

Distributed versus Networked

You should keep in mind that not all applications that take advantage of networking are necessarily distributed applications. A networked application communicates with other machines to request or transfer data. The term distributed implies a much richer interaction.

The distinction is sometimes difficult to see. For example, consider a video game. If the game communicates with a central server to check for updates, it would be a networked application because the game itself isn’t running on multiple applications — it simply talks to another machine in the course of its operation. However, if the game allowed multiple players to participate on different machines, it could be implemented as a distributed application.

The best approach to labeling an application as distributed or networked (other than deciding it’s an entirely academic distinction and doesn’t really matter) is to take the position of one machine and determine whether computation is happening on another machine. In the networked game case, the individual copies of the game are most likely operating on their own machines. They use the network only for status updates, as shown in Figure 24-1. As the figure shows, when the player on Machine A shoots his or her gun, the information about the shot is transmitted to Machine B. Both machines take appropriate action based on the same event. This style of networked game isn’t generally considered a distributed application.

Machine A

Machine B

Player A shoots gun
Machine A sends event		Machine B receives event
Machine A calculates result		Machine B calculates result
Figure 24-1

695