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.
Remoting
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
forth.
There are a variety of serialization formats available for use with remoting.
By default, the HTTP channel utilizes SOAP (Simple 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
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:
- XML (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.
- UDDI (Universal
Description, Discovery and Integration): Defines a registry service for Web
services and for other electronic and non-electronic services.
- WSDL (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.
- XSD (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 channels.
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.