ASP.NET Versus .NET Remoting

Chapter 7 - Distributed System Design
byAndrew Filevet al.?
Wrox Press ©2002
Team FLY

While both .NET Remoting and ASP.NET help with object-oriented remote method invocations, they differ in a number of aspects such as allowed data types, the way the service schema is presented and stored, security support, performance, interoperability, host process, and transport protocol.

  • Service schema: ASP.NET describes schemas of web services it exposes in WSDL (Web Service Description Language), a W3C standard for describing web services. Remember that in previous sections, we said that for a proxy to represent a remote server object, the proxy needs to have knowledge of the server object's type information. The service schema here is what we called type information at that time. At the .NET Remoting side, as we already said in the .NET Remoting section, type information of remote objects is stored in assemblies. .NET provides a utility, soapsuds.exe, for you to retrieve that information from assemblies.

  • Host process: In the .NET Remoting section, we said that .NET Remoting objects can be hosted in an executable, in IIS or in .NET Component Service. ASP.NET Web services on the other hand run only in the aspnet_wp.exe execution process started by IIS.

  • Transport protocol: .NET Remoting objects and clients can communicate over a wide range of protocols such as HTTP, TCP, SMTP, etc. ASP.NET web services and clients can communicate over only HTTP because ASP.NET relies on IIS web server for receiving and sending requests and responses.

  • Security: Because ASP.NET relies on IIS for receiving requests and sending responses, it can benefit from all the transport-level security features IIS provides, including Basic Authentication, Digest Authentication, Certificate Authentication, and Windows NT Challenge/Response. ASP.NET also supports authentication based on .NET Passport. As to .NET Remoting, if remote objects are hosted in IIS with ASP.NET, they will benefit from the same security features IIS has; otherwise, they are on their own and designers and developers of the remote objects have to concern themselves with security issues from ground up.

  • Performance: .NET Remoting objects communicating in a binary stream with clients over TCP has the best performance. .NET Remoting objects communicating in a binary stream with clients over transport protocols other than TCP, and .NET Remoting objects communicating in a SOAP stream with clients over any transport protocol, have no performance advantage, or even prove mediocre, when compared to ASP.NET.

  • Data types: You can use only a limit set of data types, specifically data types supported by the XML Schema standard, when building ASP.NET Web services. If you use data types outside the scope of XML Schema in your ASP.NET Web services, those types cannot be expressed in the WSDL schema. With .NET Remoting, all data types supported by the CLR (Common Language Runtime) can be used.

  • SOAP Interoperability: .NET Remoting objects have poor SOAP interoperability with clients on platforms other than .NET. The SOAP messages to and from .NET Remoting objects contain many .NET-specific tags for the rich features (object activation mode, object leasing, callbacks, etc.) that .NET Remoting provides. Clients must understand those tags in order to communicate with .NET Remoting. ASP.NET has a much better interoperability because it's comparably simple and it limits the allowed data types to those portable ones supported by XML Schema.

We have two .NET infrastructures for building distributed components. When should we favor one over the other? From the above list of differences between the two infrastructures, the assessment and final judgment is easier to make. If interoperability is necessary, and you cannot control client environments, then ASP.NET is the favored choice. If some security mechanism like certificate authentication is required and for some reason you can't host .NET Remoting objects in IIS and building the required security feature is the last thing you would like to do, then ASP.NET is the favored choice.

Team FLY


Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
ISBN: 1440490856
EAN: N/A
Year: 2001
Pages: 85

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net