.NET Remoting Vs. Web Services – What To Choose?

.NET Remoting Vs. Web Services – What To Choose?

While developing distributed applications, developers are often faced with the question of whether to choose Remoting or Web Services as the preferred choice. The answer to this question depends on certain factors that are specific to the application and the distributed data transfer strategy being followed. Let’s discuss each of the factors one by one

Security

Security is a major factor to consider while developing distributed applications. As both Web services and .Net Remoting architecture depend on the IIS security features, there is nothing much to choose between the two based on this factor. If, however, IIS is not being used as a host, Remoting is the only option left.

Communication Mode/ Protocol

If the application is to be used by customers on a LAN/WAN, using Remoting with TCP and binary formatters will be a better option as it does not play with data (no need of formatting or data packaging as in SOAP).

If TCP is the protocol being used for communication, using web services is again out of question.

Data Volume

If the amount of data being transferred is huge, using web services will deplete performance. Web services require transformation and serialization of data and this will result in terrible application performance.

Platform/ Interoperability

If both the client and server are using .NET Runtime for execution, remoting will be the best choice as it can utilize the strongly typed data for communication at both ends.

Web Services on the other hand is an easy picking when either client or server or both are running on some platform other than .NET.

State Management

Web Services are inherently stateless and they never correlate multiple calls from the same user unless session management is explicitly enabled in the Web Service. IF enabled, they provide state management using the inherent ASP.NET state management capabilities.

In Remoting, however, you can perform state management in the following ways:

Stateless Objects: Use .NET remoting with Server Activated Single Call objects

Stateful Objects (Per Application): Use .NET remoting with Server Activated Singleton objects.

Stateful Objects (Per Client): Use .NET remoting with Client-Activated Objects

Flexibility/ Scalability

Web Services work through firewalls and other network security as it uses HTTP and XML for packaging and transporting data. Remoting on the other hand cannot provide such flexibility but in the case of using HTTP with SOAP which diminishes the performance of the application.

Web Services are also much more scalable than remoting as they support many platforms and can be used in applications that are not dependent on .NET Runtime.

Performance:

.NET remoting provides the best performance when using Binary formatters and TCP protocol. In effect, the different combinations of protocols and formatting provide different performance levels for web services and remoting. Here is the table that lists them.

Protocol	Formatter	Best Performance
TCP *	Binary	Remoting
TCP *	SOAP	Web Services
HTTP	SOAP	Web Services
HTTP	Binary	Any

* In case where the TCP protocol is used, the remoting endpoints running on TCP were compared with the HTTP Web Services.

For more information, see the tests conducted to evaluate the performance of both

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp

Development/Deployment

As most of us already know that development, configuration and deployment of web services is much easier than in .NET Remoting infrastructure as they provide a simpler programming model with easy configuration and deployment capabilities.

What to Choose?

Both Web Services and Remoting enable cross-process communication. If your application is in need of interoperability with different platforms and you want it to be flexible enough to accommodate future technology changes, web services is your choice.
Remoting takes the lead where performance, state management and huge data volumes come into consideration.