The desire to call software methods “over there” from “over here” has been around ever since the advent of distributed computing networks. Beginning in the days of Remote Procedure Calls all the way through the latest version of Distributed COM (DCOM), the promise of remoting has been to exercise a network of computers to solve computing problems rather than pinning the whole problem on a single computer.
Remoting involves several fundamental steps:
The caller flattens the call stack into a stream that may be sent over the wire.
The caller sends the serialized call stack across the wire.
The endpoint receives the serialized call stack and turns it into a usable call stack on the server.
The endpoint processes the method call.
The endpoint transmits the results back to the caller.
Several different network remoting technologies have emerged over the last decade, including DCOM and CORBA among others. (CORBA is an acronym for Common Object Request Broker Architecture—a remoting technology prevalent on other operating systems). It doesn't matter if the remoting framework is DCOM, CORBA, or even the .NET remoting services—the fundamental steps of remoting remain the same. For example, in DCOM the client talks to a component named the proxy, whose job it is to flatten the call stack and send it on its way. On the server side, a component named the stub receives the network packets and turns the incoming stream into a real call on the server. If the framework is .NET remoting, then the term for the proxy component is the “transparent proxy.” The transparent proxy talks to the real proxy, which sends the bytes across the network. Once at the server, a component named the sink unpacks the bytes and turns them into a real call.
Web services work much the same way. The fundamental remoting steps are all there. However, this time around the wire format is an XML format formalized as SOAP and the connection protocol is HTTP.