Which to Use?

Now that you understand the basics of Web services and remoting we can get to the question at hand: how to you decide which one to use? There are several factors to consider.

Security: >Neither remoting nor Web services provides built-in security. They are, however, protected by the security mechanisms that are part of Internet Information Server (IIS), Microsoft's Web hosting platform. These include Secure Sockets (SSL), authorization, and authentication.

Since .Net Web services are always hosted on IIS, you will always have these security tools at your disposal. If a remoting server is hosted on IIS the same is true. If, however, you host your remoting server elsewhere, you have to implement your own security.

Performance: There is no doubt that remoting using the Binary formatter/TcpChannel combination is the performance champ. There's no mystery as to why; SOAP messages are notoriously verbose, and text processing is slower that processing of binary data. Remoting loses its advantage if you use the SOAP formatter with either the Tcp or Http transport channel.

State Management: Web services are inherently stateless. This is fine for many applications, but if you do need to maintain state information, you can call on the same tools that are used to manage state in ASP.NET pages, the Session and Application objects.

Remoting offers more flexibility when it comes to state management. When designing your remoting server, you can create it as one of three varieties of object:

• SingleCall objects are stateless.
• Singleton objects retain shared state information for all clients.
• Client-activated object maintain state information for each individual client.

Interoperability

Web services is a clear winner here. To provide a Web service, all a platform needs to do is understand HTTP and XML. Remoting is more restricted, since it is a .Net-specific technology.

Flexibility: By using standard technologies, namely HTTP and XML, Web services are unlikely to have problems with firewalls and other network security measures. The same cannot be said for binary formatted remoting. Of course, you can use SOAP/XML and HTTP with remoting as well, but then you give up its performance advantage.

Programming and Deployment: Without going into any of the details, I feel safe in saying that Web services are a lot easier to program and deploy. This may not be a factor for most developers. After all, we pride ourselves on using the best tool regardless of difficulty!

Summing Up

I hope this brief tour of Web services and .Net remoting provides you with enough information to make an informed choice. Remoting offers advantages in performance and state management but has narrower applicability. If you are able to use a Tcp channel and performance is an issue, and you know the clients will always be .Net-based, the remoting technology is probably the way to go. These conditions are most likely to be met on an intranet. Web services offer a less capable programming model and inferior performance with the important advantages of cross-platform support and freedom from interference from firewalls and other security measures. Take your pick — one or the other is almost sure to be what you need.