.NET Remoting vs. ASP.NET Web Services
Introduction:
ASP.NET Web services and .NET Remoting provide a full suite of design options for cross-process communication in distributed applications. In general, ASP.NET Web services provide the highest levels of interoperability with full support for WSDL and SOAP over HTTP, while .NET Remoting is designed for common language runtime type-system fidelity and supports additional data format and communication channels.
ASP.NET Web Services:
ASP.NET provides a Microsoft® IIS-hosted infrastructure that supports industry standards such as SOAP, XML, and WSDL. Although.NET Remoting supports IIS hosting and SOAP over HTTP, ASP.NET is designed to provide the highest level of SOAP interoperability including support for SOAP Section 5 and document/literal.
ASP.NET can leverage the features available with IIS, such as security and logging. IIS hosting is also robust in that it will re-spawn Aspnet_wp.exe if it terminates. Also, ASP.NET Web services are much easier to create and consume than services exposed using .NET Remoting because configuration is simplified both at the server and client.
.NET Remoting:
.NET Remoting is more versatile and extensible in terms of enabling communication between objects using different transport protocols and serialization formats. TCP, HTTP, and custom protocols are supported as are Binary, SOAP, and custom formats. Multiple-object creation and lifetime modes are supported including Singleton, SingleCall, and Client-Activated. Remoting requires a host process, which can be IIS, or a Microsoft® Windows service or executable written in .NET.
A .NET Remoting object using the SOAP formatter can be exposed as an XML Web service when hosted in IIS with ASP.NET. Since the payload is encoded in SOAP over HTTP, any client that supports the SOAP Encoding format can access the objects over the Internet. Another advantage of using the HTTP protocol is that it generally passes unobstructed across most firewalls. The TCP channel and the Binary formatter can be employed in an intranet environment where both the server and client are running on the .NET Framework. This approach is optimized for performance since raw sockets are used to transmit data across the network using a custom protocol that is more efficient than HTTP. Though this approach offers excellent performance in a closed environment, it cannot be employed in cross-platform scenarios where the client is not running the .NET Framework.
IIS hosting provides secure communication for wire-level protection using Secure Sockets Layer (SSL), and you can also leverage IIS and ASP.NET authentication and authorization. The TCP channel as well as the HTTP channel with non-IIS hosting do not support secure socket transmission, so data is transmitted in clear text. You are required to implement your own security if you are using the TCP channel or the HTTP channel hosted in processes other than IIS.
See more: http://msdn.microsoft.com/en-us/library/ms978411.aspx
ASP.NET Web services and .NET Remoting provide a full suite of design options for cross-process communication in distributed applications. In general, ASP.NET Web services provide the highest levels of interoperability with full support for WSDL and SOAP over HTTP, while .NET Remoting is designed for common language runtime type-system fidelity and supports additional data format and communication channels.
ASP.NET Web Services:
ASP.NET provides a Microsoft® IIS-hosted infrastructure that supports industry standards such as SOAP, XML, and WSDL. Although.NET Remoting supports IIS hosting and SOAP over HTTP, ASP.NET is designed to provide the highest level of SOAP interoperability including support for SOAP Section 5 and document/literal.
ASP.NET can leverage the features available with IIS, such as security and logging. IIS hosting is also robust in that it will re-spawn Aspnet_wp.exe if it terminates. Also, ASP.NET Web services are much easier to create and consume than services exposed using .NET Remoting because configuration is simplified both at the server and client.
.NET Remoting:
.NET Remoting is more versatile and extensible in terms of enabling communication between objects using different transport protocols and serialization formats. TCP, HTTP, and custom protocols are supported as are Binary, SOAP, and custom formats. Multiple-object creation and lifetime modes are supported including Singleton, SingleCall, and Client-Activated. Remoting requires a host process, which can be IIS, or a Microsoft® Windows service or executable written in .NET.
A .NET Remoting object using the SOAP formatter can be exposed as an XML Web service when hosted in IIS with ASP.NET. Since the payload is encoded in SOAP over HTTP, any client that supports the SOAP Encoding format can access the objects over the Internet. Another advantage of using the HTTP protocol is that it generally passes unobstructed across most firewalls. The TCP channel and the Binary formatter can be employed in an intranet environment where both the server and client are running on the .NET Framework. This approach is optimized for performance since raw sockets are used to transmit data across the network using a custom protocol that is more efficient than HTTP. Though this approach offers excellent performance in a closed environment, it cannot be employed in cross-platform scenarios where the client is not running the .NET Framework.
IIS hosting provides secure communication for wire-level protection using Secure Sockets Layer (SSL), and you can also leverage IIS and ASP.NET authentication and authorization. The TCP channel as well as the HTTP channel with non-IIS hosting do not support secure socket transmission, so data is transmitted in clear text. You are required to implement your own security if you are using the TCP channel or the HTTP channel hosted in processes other than IIS.
See more: http://msdn.microsoft.com/en-us/library/ms978411.aspx
Comments