When to opt for remoting over Web services

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 utilise 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 serialisation formats available for use with remoting. By default, the HTTP channel utilises SOAP (Simple Object Access Protocol) and TCP uses binary. These are only defaults; channels may use either serialisation 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 utilise 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 utilise 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 utilise a variety of serialisation 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 utilise inherent data types without problems.

In addition, while you can build stateful Web services, it is much easier to implement this feature utilising remoting. This depends on application requirements. Basically, if you know each point or tier in the application will utilise .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.