Deciding When to Use System.Net

The .NET Framework contains a number of classes that can come into play when building a distributed application. The usage scenarios for these classes range from connecting to a database to calling a method on a remote object, with a significant number of options in between. Given this broad range, it can be difficult to know exactly which set of classes will be best suited to your scenarios. This section briefly covers the most commonly considered options when building a distributed application on the .NET Framework and provides guidance that can help you determine which layer is most appropriate for the needs of your application.

Common Scenarios for Using System.Net

Lets begin this exercise by covering the most common scenarios for using the layers in System.Net . These scenarios can be divided into the three categories shown on the following page.

Accessing an existing service or protocol provided by System.Net
Implementing a protocol not provided by System.Net
Extending a higher layer of the stack that uses System.Net

Seems pretty easy, right? Well, lets spend a bit more time going through each of the categories to talk about why they make sense.

Accessing an Existing Service or Protocol Provided by System.Net

Application services that make sense for System.Net are demonstrated in the samples throughout this book. The most common case by far is that of accessing resources that are available on an HTTP server. If your program needs download or upload resources over HTTP or HTTPS, System.Net should be an easy choice. Likewise, if your application needs to access the name resolution services available in DNS, System.Net.Dns is the best choice. Going forward, FTP and access to other standard protocols will fit into this category as well.

Implementing a Protocol Not Provided by System.Net

Perhaps your application needs to interact with a service that supports some well-known protocol thats not supported directly in System.Net . For example, consider the Network Time Protocol (NTP). RFC 1305 provides the following description of NTP:

NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave.

An application wanting to interact with another service that supports the desired protocol would need to implement the NTP protocol in this example. NTP is layered on top of UDP, which is accessible in System.Net through the socket layer classes. The application would then call the socket layer classes to construct a UDP socket and emit the NTP protocol. Other examples that commonly fit well into this category of protocols that are built using the socket-level classes are the Network News Transfer Protocol (NNTP), the Post Office Protocol (POP3), and the Simple Mail Transfer Protocol (SMTP).

Applications might also be implementing a custom protocol thats only well known within a specific organization. Although this approach is discouraged when architecting new applications, its often required in cases where the new application must interoperate with a legacy system. Often, a good approach in these cases is to use System.Net to write the custom protocol that consumes the data from the legacy system and then use a more interoperable solution, such as XML-based Web services, to expose the data or service to other applications within the organization.

Extending a Higher Layer of the Stack That Uses System.Net

As well discuss at length in Chapters 11 and 12, System.Net provides the underlying transport implementation for the Web services and the .NET Remoting technologies in the .NET Framework. Accessing elements of System.Net to extend and customize the behavior of these higher layers can be a very useful tool for enhancing the performance, interoperability, scalability, and functionality of your application.

System.Net vs. Web Services or .NET Remoting

The .NET Remoting and Web services technologies in the .NET Framework provide rich and extensible frameworks for accessing objects and services that live outside of your application. In some cases, the boundary between the application and a remote object is simply an application domain. In other cases, it might be across a process, and in other cases, it might be across a network.

Its often much easier for applications to interact at an object level rather than deal directly with protocols. Therefore, its recommended that applications use the .NET Remoting and Web services wherever possible. Even when the .NET Remoting and Web services are viable options, System.Net is a better choice in some cases. For example, suppose that your application needs to download a large amount of data, such as a 10 megabyte (MB) file, and it wants the ability to selectively request portions of that data or the ability to cache the download and retrieve only the portions not downloaded in cases of a failure. In this case, using a Web server and the HTTP layer exposed through System.Net might be a more appropriate architecture than exposing the data through a Web service or a .NET Remoting object. The transport and encoding semantics associated with HTTP are more amenable to this scenario than those provided by the higher layers.

Its expected that over time these higher layers will continue to evolve until they are almost always the right choice when you control both the client and the server. However, this transformation will take a significant number of years to achieve. Once we reach that point, System.Net will be most useful for extending and enhancing these higher layers and interacting with legacy services to expose them up through the higher layers.