email article printer friendly more resources

Integrate .NET Remoting Into the Enterprise
Learn how .NET's remoting infrastructure can serve your enterprise development plans better than Web services do.
by Don Browning

For this solution: .NET Framework, Visual Studio .NET, .NET remoting, Web services

Microsoft made two announcements at the 2000 Professional Developer's Conference that changed the way the IT community thinks about development in general, and enterprise development in particular. The first was .NET, a development framework for the next decade of Windows development. The second was Web services, which hold the promise for the next phase of distributed development. Two years later, both the .NET Framework and Web services are viable technologies enterprises the world over use. Unbeknownst to some, buried beneath the Web services hype exists a first-class remoting framework that enables developers to create efficient, scaleable, and object-oriented distributed applications.

Remoting is arguably the most under-hyped subset of the massive .NET Framework. It was designed from the ground up to provide developers with a method of creating distributed applications. It's easy to use, but it's also powerfully extendable—something COM+ and Distributed COM (DCOM) aren't. Every enterprise developer should have remoting in his or her toolbox. However, due to the hype surrounding Web services from just about every independent software vendor in the industry, many enterprise IT managers opt to implement Web services instead of remoting, even when it's an overkill for their particular environment.

In this article I'll explain why remoting is a viable alternative to Web services for the majority of enterprise development scenarios. I'll first outline when it might be advantageous to use Web services, then discuss the basics of remoting. I'll compare remoting to Web services, and, finally, examine a couple of scenarios where remoting might best fit your enterprise development plans.

A Web service is a special type of remoting component that runs under Internet Information Services (IIS). It sits in an IIS Virtual Root and needs a myriad of other files to support it. They include a Web Service Description Language (WSDL) file that describes the service, a DISCO file that enables Web service discovery, and a configuration file called Web.config. Visual Studio .NET (VS.NET) generates these files for you automatically, which makes Web services easy to create and manage.

Web services offer some advantages over remoting components, many of which have to do with flexibility. First, Web services typically use HTTP as their transport channel. This solves a major problem inherent in DCOM. DCOM uses TCP as its transport mechanism, using port 135 for communication with the Service Control Manager (the object creation mechanism for DCOM), then any port between 1024 and 65535 for communication. (This is default behavior, which can be modified, though not easily.) This scenario creates a problem for system administrators because it creates a potential security hole in corporate firewalls. Web services help alleviate this issue by allowing method invocations on port 80. This port is typically well secured, allowing you to safely publish a component's functionality.