Pizza deliveries are a wonderful thing. Anyone can pick up the telephone, make a call to his local pizza parlour, and request the chefs to make a super-sized pizza with extra cheese and mouth-watering pepperoni. They drive to his house and deliver the fresh-from-the-oven results in thirty minutes.

This pizza delivery isn't unlike a remote procedural call, which extends the concept of distributed computing by allowing one computer to execute a command in another computer. Typically, applications commonly make a "procedural call" to a function — a software routine that performs an operation — in the same application. With remote procedural calls, the application can invoke a function in another application's process, whether it be on the same computer or another computer across the network — provided it has the appropriate middleware to support it.

What makes a remote procedural call special is that it hides the process from the application, making it a cinch for it to invoke function calls on other computers. Similarly, pizza delivery orders across the phone don't require the customer to have an intricate knowledge of the phone lines. He simply needs to pick up the phone and talk as he would talk if he were in the pizza parlor.

A remote procedural call is made when the client application makes a call to what appears to be a local function, according to (Burghart). The middleware takes the call's parameters, packages, and sends them to another computer, where it is unpacked and executed by the real function. When it is complete, the function's return values are packed up and sent back to the original computer and its client application. See figure 1

Although distributed technologies help distribute the workload, different companies are competing with their own proprietary standards, which could make parts from different vendors non-interoperable. It's either all from one company, or nothing. A distributed computing environment, on the other hand, alleviates this problem.

Let's take this from a different perspective. Schools have a standard set of rules and regulations that apply to every classroom, different teachers — depending on the type of class they teach — have their own set of rules. The standard school regulations help maintain an orderly learning environment, so that students and teachers don't get confused with six or seven different sets of rules.

Likewise, the variety of standards each computer has in a distributed computing network can wreak havoc when the computers attempt to get along. The Distributed Computing Environment (DCE) — formulated by The Open Group — formalizes technologies such as remote procedural calls and middleware. The Distributed Computing Environment makes sure applications behave consistently across different operating systems and computers.

The Distributed Computing Environment set of standards includes other features, such as security, synchronizing of time, a distributed file system, and remote procedural calls. (Caution: do not confuse DCE with middleware! Its main concern is to translate the data that computers send to each other. It might seem eerily similar to DCE, but it's because it's actually a part of DCE.)

These specifications help cut down on maintenance costs for different platforms, which wouldn't cooperate with each other without DCE. Plus, it's supported by many companies that provide networking software and network operating systems, including IBM, Digital Equipment, and Microsoft.

Distributed objects are pieces of data in their own little world, yet they are "in vogue" for distributed computing systems. They not only have a standard interface, but are independent of the application, language, and platform. Distributed objects are like building blocks, and can be combined with each other to make different applications (See Figure 2).

For example, Microsoft Office's suite of applications — Word, Excel, and Powerpoint — all share many similarities using the concept of distributed objects. They share the same Open/Save dialog boxes, the same spell checker, and the same drawing tools, because each application consults an object independent of the actual applications' coding. These objects aren't quite distributed, for they work on whatever operating system they were designed for, but they come close to being distributed objects.

Distributed objects are poised to replace remote procedural calls as the standard of communication between distributed applications since they are suitable for complex applications (Seltzer). They are able to roam through a network, work with other components, and clean up after themselves.

Distributed objects are able to communicate with each other through set standards, of which there are two major specifications. CORBA, or Common Object Request Broker Architecture, handles communication by using ORB's, or object request brokers. If the application wishes to access an object, it must go through an ORB first. Microsoft's Distributed COM simply allows objects to communicate with each other.