Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
php/2201701
http://www.developer.com/article.phpr/2201701/NET-Remoting-Versus-Web-Services.htm
Back to Article
With the advent of .NET and the .NET Framework, Microsoft introduced a set of new technologies in the
form of Web services and .NET remoting. .NET remoting and ASP.NET Web services are powerful
technologies that provide a suitable framework for developing distributed applications. It is important to
understand how both technologies work and then choose the one that is right for your application.
The Web services technology enables cross-platform integration by using HTTP, XML and SOAP for
communication thereby enabling true business-to-business application integrations across firewalls.
Because Web services rely on industry standards to expose application functionality on the Internet, they
are independent of programming language, platform and device.
Remoting is .a technology that allows programs and software components to interact across application
domains, processes, and machine boundaries. This enables your applications to take advantage of remote
resources in a networked environment.
Both Web services and remoting support developing distributed applications and application integration,
but you need to consider how they differ before choosing one implementation over the other. In this
article, I will show the differences between these two technologies. I will present samples for each type of
implementation and identify when to use which technology.
DCOM
If you are a real Microsoft platform developer then you have done some work on COM and interface
based components. When it comes to distributing your program logic, you are almost tied to Distributed
COM (DCOM).
DCOM is a very proprietary RPC-based communication protocol for COM-based distributed component
architectures. Even though DCOM allows us to create scalable and reliable architectures in the Intranet
environment, there are a lot of problems with DCOM when you try to integrate with different platforms
and technologies in an Internet environment.
In .NET remoting, the remote object is implemented in a class that derives from
System.MarshalByRefObject. The MarshalByRefObject class provides the core foundation for enabling
remote access of objects across application domains. A remote object is confined to the application domain
where it is created. In .NET remoting, a client doesn't call the methods directly; instead a proxy object is
used to invoke methods on the remote object. Every public method that we define in the remote object
class is available to be called from clients.
When a client calls the remote method, the proxy receives the call, encodes the message using an
appropriate formatter, then sends the call over the channel to the server process. A listening channel on
the server appdomain picks up the request and forwards it to the server remoting system, which locates
and invokes the methods on the requested object. Once the execution is completed, the process is
reversed and the results are returned back to the client.
Out of the box, the remoting framework comes with two formatters: the binary and SOAP formatters. The
binary formatter is extremely fast, and encodes method calls in a proprietary, binary format. The SOAP
formatter is slower, but it allows developers to encode the remote messages in a SOAP format. If neither
formatter fits your needs, developers are free to write their own and plug it in as a replacement.
Single call . Single-call objects handle one, and only one, request coming from a client. When
the client calls a method on a single call object, the object constructs itself, performs whatever
action the method calls for, and the object is then subject to garbage collection. No state is
held between calls, and each call (no matter what client it came from) is called on a new
object instance.
Singleton - The difference in a singleton and single call lies in lifetime management. While
single-call objects are stateless in nature, singletons are stateful objects, meaning that they
can be used to retain state across multiple method calls. A singleton object instance serves
multiple clients, allowing those clients to share data among themselves.
Consuming a Web service is very straightforward too. You can very easily create a proxy class for your
Web service using either wsdl.exe utility or the Add Web Reference option in VS.NET. The Web service
proxy hides all the network and marshaling plumbing from the application code, so using the Web service
looks just like using any other local object.
As you can see from the above diagram, the client proxy receives the request from the client, serializes
the request into a SOAP request which is then forwarded to the remote Web service. The remote Web
service receives the SOAP request, executes the method, and sends the results in the form of a SOAP
response to the client proxy, which deserializes the message and forwards the actual results to the client.
Now that we have understood the basic concepts of .NET remoting and Web services, let us identify the
differences between these two technologies. For this, I present different factors such as performance,
state management, etc and then identify which technology to use in what situations.
Performance
In terms of performance, the .NET remoting plumbing provides the fastest communication when you use
the TCP channel and the binary formatter. In the case of Web services, the primary issue is performance.
The verbosity of XML can cause SOAP serialization to be many times slower than a binary formatter.
Additionally, string manipulation is very slow when compared to processing the individual bits of a binary
stream. All data transported across the wire is formatted into a SOAP packet. However if your Web service
performs computation intensive operations, you might want to consider using caching to increase the
performance of your Web service on the server side. This will increase the scalability of the Web service,
which in turn can contribute to the increase in performance of the Web service consumers. A remoting
component, using the TCP channel and the binary formatter, provides the greatest performance of any
remoting scenario, primarily because the binary formatter is able to serialize and deserialize data much
faster.
If you use .NET remoting with a SOAP formatter, you will find that the performance provided by ASP.NET
Web services is better than the performance provided by NET remoting endpoints that used the SOAP
formatter with either the HTTP or the TCP channel. However the .NET remoting provides clear
performance advantages over ASP.NET Web services only when you use TCP channels with binary
communication.
State Management
Web services are a stateless programming model, which means each incoming request is handled
independently. In addition, each time a client invokes an ASP.NET Web service, a new object is created to
service the request. The object is destroyed after the method call completes. To maintain state between
requests, you can either use the same techniques used by ASP.NET pages, i.e., the Session and
Application objects, or you can implement your own custom solution. However it is important to remember
that maintaining state can be costly with Web services as they use extensive memory resources.
.NET remoting supports a range of state management options that you can choose from. As mentioned
before, SingleCall objects are stateless, Singleton objects can share state for all clients, and client-
activated objects maintain state on a per-client basis. Having three types of remote objects (as opposed to
one with Web services) during the design phase helps us create more efficient, scalable applications. If
you don't need to maintain state, use single-call objects; if you need to maintain state in a small section
of code, use single call and singletons together. The ability to mix and match the various object types
facilitates creation of solid architectural designs.
Security
.NET remoting plumbing does not provide out of the box support for securing cross-process invocations.
However a .NET remoting object hosted in IIS, can leverage all the same security features provided by
IIS. If you are using the TCP channel or the HTTP channel hosted in a container other than IIS, you have
to implement authentication, authorization and privacy mechanisms yourself.
Since ASP.NET Web services are hosted, by default, in IIS, they benefit from all the security features of
IIS such as support for secure communication over the wire using SSL, authentication and authorization
services.
Reliability
.NET remoting gives you the flexibility to host remote objects in any type of application including a
Windows Form, a managed Windows Service, a console application or the ASP.NET worker process. If you
host your remote objects in a windows service, or a console application, you need to make sure that you
provide features such as fault tolerance within your hosting application so that the reliability of the
remote object is not compromised. However if you do host remote objects in IIS, then you can take
advantage of the fact that the ASP.NET worker process is both auto-starting and thread-safe. In the case
of ASP.NET Web services, reliability is not a consideration as they are always hosted in IIS, making it easy
for them to take advantage of the capabilities provided by IIS.
Extensibility
Both the ASP.NET Web services and the .NET remoting infrastructures are extensible. You can filter
inbound and outbound messages, control aspects of type marshaling and metadata generation. .NET
remoting takes extensibility to the next level allowing you to implement your own formatters and
channels.
Since ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data
to and from SOAP messages at runtime, we can very easily customize the marshaling by adding a set of
custom attributes that can be used to control the serialization process. As a result, you have very
fine-grained control over the shape of the XML being generated when an object is serialized.
using System;
namespace RemoteClassLib
{
public class MyRemoteObject : System.MarshalByRefObject
{
public MyRemoteObject()
{
Console.WriteLine("Constructor called");
}
The above code is very simple and straightforward. We start off by defining a class that inherits from
MarshalByRefObject. After that we add code to the constructor of the class to write out a message to
the console. Then we have a method named Hello that basically takes a string argument and appends
that with the string and returns the concatenated value back to the caller. Once the remote object is
created, the next step is to create a host application that hosts the remote object. For the purposes of this
article, we will create a console application that reads the details of the remote object from its
configuration file.
using System;
using System.Runtime.Remoting;
namespace RemoteClassLibServer
{
class RemoteServer
{
[STAThread]
static void Main(string[] args)
{
RemotingConfiguration.Configure(
"RemoteClassLibServer.exe.config");
Console.WriteLine("Press return to Exit");
Console.ReadLine();
}
}
}
In the main method, we just read the configuration settings from the configuration file using the
RemotingConfiguration.Configure method and wait for the client applications to connect to it.
The configuration file used by the above hosting application looks like the following. In the configuration
file, we specify that we want to expose the remote object using the TCP channel by using the channel
element.
Once the hosting application is started, then client applications can start creating instances of the remote
object and invoke its methods. In the next section, we will understand the processes involved in creating
an ASP.NET Web service.
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
namespace XmlWebServicesExample
{
[WebMethod (EnableSession=true)]
public string HelloWorld()
{
return "Hello World";
}
}
}
As you can see from the above, the Web service class named Service1 is derived from
System.Web.Services.WebService. Inheriting from the WebService class is optional and it is used to
gain access to common ASP.NET objects like Application, Session, User, and Context. Then we also add a
method named HelloWorld that basically returns a simple string back to the callers of the Web service. In
the WebMethod attribute of the HelloWorld method, we also specify that we want to enable session state
for our ASP.NET Web service by setting the EnableSession attribute to true.
So far, we have seen the steps involved in creating a .NET remoting object and an ASP.NET Web service.
As can be seen from the above code, ASP.NET Web services are very easy-to-create. Consuming ASP.NET
Web service is also a very simple process due to the excellent Web service support provided by Visual
Studio.NET. With .NET remoting, you need to create the remote object first and then write a hosting
application (assuming that you are not using IIS) to expose that remote object. You also need to make
sure that the information about the remote object is retrieved from the configuration file to allow for
extensibility in the future. If you all these factors into consideration, you will agree that .NET remoting
objects are complex to develop and deploy.
Type Fidelity
ASP.NET Web services favor the XML schema type system, and provide a simple programming model with
broad cross-platform reach. .NET remoting favors the runtime type system, and provides a more complex
programming model with much more limited reach. This essential difference is the primary factor in
determining which technology to use.
Web services support only the Using binary communication, .NET Remoting
Type System datatypes defined in the XSD type can provide support for rich type system
Web services support interoperability .NET remoting requires the client be built
Interoperability across platforms, and are ideal for using .NET, enforcing homogenous
heterogeneous environments. environment.
Ease-of-
Easy-to-create and deploy. Complex to program.
Programming
Though both the .NET Remoting infrastructure and ASP.NET Web services can enable cross-process
communication, each is designed to benefit a different target audience. ASP.NET Web services provide a
simple programming model and a wide reach. .NET Remoting provides a more complex programming
model and has a much narrower reach.
As explained before, the clear performance advantage provided by TCPChannel-remoting should make you
think about using this channel whenever you can afford to do so. If you can create direct TCP connections
from your clients to your server and if you need to support only the .NET platform, you should go for this
channel. If you are going to go cross-platform or you have the requirement of supporting SOAP via HTTP,
you should definitely go for ASP.NET Web services.
So far, we have understood how the .NET remoting and ASP.NET Web services technologies differ in
implementation. We have also had a detailed look at different factors to understand what technology to
choose in what situation. Even though these two technologies are meant for different purposes, there are
times where you will be able to use the combination of these technologies in your application. For
example, in an application scenario where you are trying to address the needs of both internet and
intranet clients, you might consider using both .NET remoting and Web services as shown in the above
diagram. For the intranet .NET clients, you can use .NET remoting to enable cross appdomain
communication. For the internet clients, you can expose the same functionality as Web services, allowing
client applications running in different platforms to take advantage of the Web service.
Conclusion
Both the .NET remoting and ASP.NET Web services are powerful technologies that provide a suitable
framework for developing distributed applications. It is important to understand how both technologies
work and then choose the one that is right for your application. For applications that require
interoperability and must function over public networks, Web services are probably the best bet. For those
that require communications with other .NET components and where performance is a key priority, .NET
Remoting is the best choice. In short, use Web services when you need to send and receive data from
different computing platforms, use .NET Remoting when sending and receiving data between .NET
applications. In some architectural scenarios, you might also be able to use.NET Remoting in conjunction
with ASP.NET Web services and take advantage of the best of both worlds.
Source Code
Download Source Code: RemoteWeb.zip - 78 kb
###
Search:
About Internet.com
Copyright 2010 QuinStreet Inc. All Rights Reserved.
Solutions
Webcasts
Ensuring Performance Meets Business and Web User Needs MORE WEBCASTS, PODCASTS, AND VIDEOS