By Mike Gunderloy
One of the constant factors of the consulting business is the need to learn new tricks. Although basic client needs don’t really change over time, the tools that we have to fill those needs are constantly evolving. Not long ago, creating a distributed application that used the Internet for communication was nearly impossible. These days, it's routine. In fact, there are so many choices that the essential question is no longer, "Can I possibly get these components to talk to one another?" but "Which technology should I use to hold together my distributed application?"
The .NET Framework, for example, introduces good support for two ways to architect a distributed application. Remoting is the architectural descendant of DCOM, allowing an object on one computer to make proxy-based calls to the methods of an object on another computer. Web services use a completely different technique, based in open XML protocols such as SOAP and WSDL, to invoke methods on a remote machine.
Given this choice, how do you decide whether to use remoting or Web services in a particular application?
Different tools, different abilities
Sometimes you can choose based just on what you need to do with the object at the other end of the communication. Remoting provides a number of capabilities that aren’t built into Web services, including:
- Stateful objects
- Singleton servers
- TCP channels for communication
- Binary object serialization
- Hosting without running IIS
Some of these are tougher limitations to overcome than others. It's fairly easy to add state to a Web service, for example, but difficult to pass messages over any communication channel other than HTTP (at least in .NET 1.0 or 1.1). Still, remoting wins on the basis of sheer comparison of abilities.
Ease of development
With Visual Studio .NET, developing Web services is so simple as to be nearly trivial. You build a Web services project to act as the server, add a Web Reference to that project from the client, and VS.NET takes care of building all of the plumbing needed to make one work with the other. From the client's point of view, invoking a method on a server-side object is no different syntactically from invoking a method on a client-side object.
Remoting is somewhat trickier to get right. You need to choose whether to use server-activated or client-activated objects, which communications protocol to support, and on which port to register the object. You need to decide whether to host the server object in IIS or a custom host. And you'll need to write a lot more "plumbing" code with remoting than you will with Web services. Inevitably, this slows the pace of development, even if you’ve done it before.
So, a point goes to Web services. Note, though, that we ought to develop code once and then use it many times. So if there are other compelling reasons to use remoting, you shouldn't let the seductive simplicity of implementing Web services sway you.
Performance comparisons are always tricky, especially in distributed applications. There are so many variables that it's tough to get repeatable numbers from which you can derive guidance.
Despite the trickiness, it's possible to make a fairly certain statement: For the same data, a remoting application can be designed to be faster than the equivalent Web services application. That's because the Web services application is forced to use SOAP-formatted messages over HTTP for communication, while the remoting application has a choice of communications technologies. In particular, you can build a remoting application to use binary-formatted messages passed over a raw TCP channel. The binary formatter is faster than the SOAP formatter, and binary messages are smaller than SOAP messages so that they can be sent faster. The TCP protocol, too, has less overhead than HTTP. What all this adds up to is that communications between client and server will be faster for a properly designed remoting application.
Keep in mind that communications are only part of the overall performance picture. If the services supplied require a lot of computation on the server, communications performance may not matter much; if it takes the server 50 seconds to come up with a result, do you really care whether the result takes one or two seconds to format? Probably not.
Here, there's a clear distinction between the two technologies. Remoting depends on the client instantiating a proxy object under Windows to communicate with the server. This technology assumes that you have Windows on both ends of the distributed application.
By contrast, Web services depend only on passing standard XML messages. Web services applications don’t make any assumptions about what's at the other end, besides assuming that it can understand SOAP and WSDL. And as a matter of fact, Web services clients and servers are implemented in many languages on many platforms. If your distributed application involves UNIX, Linux, Mac, or other platforms in addition to Windows computers, you’ll find it much easier to use Web services than remoting to communicate between the various platforms.
Making the choice
So what's the bottom line? If you look at all the factors above, remoting gets the nod on capabilities and performance, while Web services wins on ease of development and interoperability. I think that ease of development and communication performance should not figure too strongly into choosing a distributed architecture. The different capabilities, while important, can usually be worked around by a clever programmer. This leaves a rule of thumb that you can tuck away for the future:
If you control both endpoints, and they’re both running on Windows, use remoting for distributed applications. Otherwise, use Web services.
Another way to say this in many organizations is that remoting is best suited for intranet applications, while Web services should be reserved for communicating with partners over the Internet.
One final caution: Like most rules of thumb, this one has exceptions. Remember that I derived this rule from very high-level considerations, without digging into the implementation of any particular application. It's a good starting point if you need to make an architectural decision without the luxury of exhaustive research and prototyping, but it's not the end of the architectural process.
You might, for example, be planning an intranet test of what will later be an Internet application. That's just one of the cases where you'd want to use Web services on your intranet, even with Windows everywhere. As part of the process of learning new tricks, you need these quick rules as signposts, but once you're actually working in the territory, be sure to check where you end up.