Web Services vs. Remoting

My last post on Remoting and proxy authentication elicited the following response from Simon Stewart.

>>Without knowing the exact details, wouldn't a web service have avoided these problems?

This brings up a very interesting question. When should I use .NET Remoting verses Web Services? This in fact gets even more interesting when we throw Enterprise Services into the mix, and this is an option that I always consider, but will not be addressing here.

There are numerous resources on the Internet that address this question, yet it still seems to be a difficult question to answer. I do not have the answer, only some ideas on a starting point.

To decide on which technology to use, some of the factors to consider include

• Performance
• Security
• Interoperability
• Visibility
• Scalability

These factors assume that we are looking at a service-oriented architecture. One of the other factors, that I will not be addressing here, is the programming model. .NET Remoting provides a very flexible selection of programming models. And these would also weigh in on the decision.

Performance

This can be a very strong deciding factor in choosing not only between .NET Remoting and Web Services, but also the various combinations of hosts, channels and formatters used for .NET Remoting.

Security

While neither Web Services nor .NET Remoting provide a native security model, both are extensible enough to allow for a security model to be imposed on them. Both can also be hosted in IIS and utilize IISs support for SSL to provide security, without any extra coding on the part of the developer, though from a performance point of view this would not be the best option.

Interoperability

Interoperability defines what types of clients will be accessing the service. I might require any client on any platform to have access to the interface I am providing.

Visibility

I define the visibility as the number and types of client over what medium will access the service. Visibility introduces the possibility of firewalls and access to the system over the Internet.

Scalability

Scalability is the ability for the system to scale both upwards and outwards to handle higher request. The scalability requirements do not only help select between .NET Remoting and Web Services, but again also the kind of host I would select for a .NET Remoting solution.

Having said that, when looking at scalability I think we are reaching a point where many developers are forgetting that we still have bandwidth considerations and that server side scalability is not always the solution.

These factors are not viewed in isolation, but as a whole in context of the system performance and functional requirements.

Here is a quick example of how I might apply these factors to make a decision.

When performance out weighs things like interoperability, I believe .NET Remoting with a TCP channel and binary formatter, hosted in a Windows Service is the best .NET option. If scalability weighs into this, then .NET Remoting with Http channel and binary formatter hosted in IIS is a more suitable option, this would also be the case if there is a requirement to access the service over the internet and interoperability is not a factor.

If performance is critical as well as interoperability, then Web Services are clearly a better option. I have also used .NET Remoting to provide access to .NET clients and have a Web Service provide the interoperable interface to non-. NET clients.