Many developers consider Web services the
de facto solution in their everyday work. While Web services do work in many
situations, there are alternatives that may be more appropriate depending on
the project. Remoting is a good example, but deciding
when to use remoting as opposed to a Web service can
be difficult. Let’s take a closer look at both technologies, focusing on when
and where they may be used.
The .NET Framework includes remoting
in the CLR (Common Language Runtime). It provides classes to build distributed
applications, as well as network services that send messages over channels.
Remoting allows you to utilize one
of two channels, HTTP and TCP, and it replaces DCOM (Distributed Component
Object Model). You may use remoting in any .NET
application type, including console, Windows form, Window services, and so
There are a variety of serialization formats available for
use with remoting. By default, the HTTP channel utilizes
Object Access Protocol) and TCP uses binary. These are only defaults; channels may
use either serialization format.
Multiple options are available for implementing a remoting application. This includes the following:
- SingleCall: Each client request is serviced
by a new object with the object disposed when the request has finished.
- Singleton: All incoming client requests
are processed by a single server object.
- Client-activated object: This is
the old stateful DCOM model, whereby the client
receives a reference to the remote object and holds that reference (thus
keeping the remote object alive) until it is finished with it.
The main aspect of remoting is
that each endpoint in the process must utilize the .NET Framework. In turn,
object types are easily passed between the endpoints since they are using the
same environment. Each object has a lease time. Upon expiration, the object is
disconnected from the .NET runtime remoting
infrastructure. The passing of an object reference results in the same object
being accessed using the reference thus the necessity of .NET on each end.
A remote object is implemented in a class derived from the System.MarshalByRefObject class. A client makes method
calls via a proxy object, which invokes the necessary method on the remote
object. Every public method defined in the remote object is available to the
client. A good name for remoting is peer-to-peer.
Let’s take a quick look at Web services before contrasting the technology with remoting.
Web services are Microsoft’s mantra these days. That said, Web services are much more flexible than their remoting counterpart. Web services give us a loosely
coupled messaging architecture that scales across the Internet. This Web
service architecture is standards-based, modular, and general purpose. All of
the endpoints do not have to be using the same environment, so a .NET
application can easily utilize a Web service developed with Java and vice
versa. Standards are the backbone of Web services. This includes, but is not
limited to, the following technologies:
(Extensible Markup Language): A simple, very flexible text format derived
from SGML. XML is playing an increasingly important role in the exchange
of a wide variety of data on the Web and beyond.
(Universal Description, Discovery and Integration): Defines a registry
service for Web services and for other electronic and non-electronic
(Web Services Description Language): An XML format for describing network
services as a set of endpoints operating on messages containing either
document-oriented or procedure-oriented information.
(XML Schema Definition): Provides a way to define the structure, content,
and semantics of XML documents.
ASP.NET Web services rely upon SOAP to package and transport
data over the HTTP protocol. You may utilize a variety of serialization formats
to work with objects.
Choosing between Web services and remoting
When designing an application, performance is always a big
factor. If you are working in a controlled environment, like a LAN or WAN, remoting is a good choice given its support of TCP (which
is much faster than HTTP). This removes a wrapper like SOAP where data must be
packaged for transfer and unpackaged on the other end. On the same note, remoting uses .NET on each end, so you may utilize inherent
data types without problems.
In addition, while you can build stateful
Web services, it is much easier to implement this feature utilizing remoting. This depends on application requirements.
Basically, if you know each point or tier in the application will utilize .NET,
thenremoting is a solid
choice. On the other hand, an application tier could change in the future, so
Web services provide more flexibility if that occurs. Web services are
standards-compliant, so working with other systems are not (or should not be) a
problem. However, they can be troublesome if you’re working with wireless
In the end, the ultimate decision rests in the hands of the
application architect. However, some issues can make the decision much easier.
For instance, if all of the application tiers are not using .NET, then remoting is not a viable choice. Remoting
requires a tight coupling of application clients; therefore, its peer-to-peer
nature may not be well-suited or desired for an application. It is much faster
if the architecture is in place. Web services are more flexible, so any future
changes in the application tiers may warrant its selection. They offer more
hooks to build on down the road, which will come in handy if in the future you
may need to do authentication or leverage any of the WSE (Web
Services Enhancements) features.
TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!