Applying .Net to Web Services
By Brian Jepson
As long as it has been possible to connect two computers, programmers have built software that communicates over the network. Most of this communication is facilitated by protocols, which standardize and formalize the way information is exchanged among various applications. Protocols that hide the low-level network plumbing make lazy developers like me very happy, because they require less work and offer more reward. For example, the Simple Mail Transfer Protocol (SMTP) requires that each communication session begin with a client transmitting a HELO string to a server. The server knows that this is the initiation of a session and will respond with a similar string. Because the strings and the order in which they're transmitted are standardized, application developers creating email clients are freed from making their own rules to communicate with servers, and from writing extra code for servers that might have their own arbitrary rules.
Remote Procedure Calls (RPCs) take the concept of the protocol to the next level. With these, you can invoke a method in a bit of code residing anywhere on the network as if it were code running on your own system. Why use up some of your workstation's CPU if a more powerful server is available across the network? Further, if you are performing calculations on a large data set, why bring the data set to your workstation when you can let the server with the data do the work, and send only the result to your workstation? If you extend this notion to object-oriented programming, you might start to think of your remote objects as parts of a service—as if there's a machine across the network that's willing to provide objects that perform work on behalf of your application.<>
