Choosing the Right .NET Technology

One principle I've stressed throughout this book is that every .NET technology has an ideal niche. To build a successful distributed application, you need to understand not only how to use these technologies but also when to use them. The next sections consider a few miniature scenarios and the designs they lead to.

Internal and External Systems

The internal system is the proprietary software that manages some part of the day-to-day tasks of running a business. It can include bug tracking or project-management software used by the development department, or a custom sales-tracking and inventory-management application. In either case, you have two choices.

A .NET Remoting based solution provides the best possible communication speed. Of course, internal systems often don't stay that way. If the system is successful, you'll often require some sort of bridge to expose some functionality to other systems. In this case, an XML Web service based solution provides an easy migration path if you need to open up parts of the system to a third party. XML Web services also provide ASP.NET services such as caching an integrated authentication that can enhance performance or simplify coding. Either way, the client portion is usually created using Windows Forms. This provides the most flexible user interface and enables you to create different application types, such as long-running system tray applications.

Systems exposed to outside parties (such as e-commerce storefronts) can rely on ASP.NET or an XML Web service backbone. The key consideration is determining whether you should use a disconnected architecture that relies on message queues or a similar technology to distribute client requests. If you are expecting a heavy load concentrated in peak hours and clients do not need an immediate response, this type of disconnected architecture maximizes the processing capabilities of the server.

Hybrid Internal/External Systems

Some systems combine XML Web services and .NET Remoting in parallel. .NET Remoting is used for internal clients, and XML Web services expose a subset of the same features to third parties or other platforms. The success of this approach depends on ensuring that both the XML Web services and the remoted components use the same service provider components to perform the heavy lifting (such as accessing the database). Although the XML Web services and remoted components will execute separately, they will be sharing the same version of the service provider components, as shown in Figure 10-6.

Figure 10-6. A hybrid system

Note

Technically, it is possible to create a component that can work as an XML Web service and a remote object. You just need to derive the class from MarshalByRefObject to enable .NET Remoting support, and add the <WebMethod> attribute and create an .asmx file to expose Web methods. However, this approach is strongly discouraged. You will still have to host the component separately, and the subtle differences in the way XML Web services and .NET Remoting handle issues such as serialization mean that this is a recipe for future headaches. Instead, move shared functionality into a separate component.

The Common Back End

The disadvantage with hybrid systems is that they are inefficient for large client loads. For example, connections can't be pooled between XML Web services and components exposed through .NET Remoting, and load balancing is more complicated because you are dealing with two duplicate implementations.

The solution is to create a common back end of processing components exposed through .NET Remoting (as shown in Figure 10-7). This extra layer results in additional cross-process communication, so it will reduce performance for small numbers. However, it is much more scalable in the long run.

Figure 10-7. A common back end

Partially Disconnected Systems

Partially disconnected systems include clients that aren't always connected and therefore can't always interact with server-side components. For example, you might create a program that logs expenses for traveling employees. When the computer reconnects to the network, these expense reports are inserted into the central database. Another example of a disconnected system is some sort of tool that you distribute to a third party. For example, you might provide authorized dealers with a sales-ordering tool. However, you probably can't assume that these dealers will have a continuous connection to the Internet when they use your application (and you definitely can't assume they will have a connection to your internal network).

There is more than one possible approach to communication in a disconnected system. One option is to use message queues (as shown in Figure 10-8), in which case Windows automatically sends the messages when the connection returns. This approach is helpful because it enables you to use the same application design for connected clients that you use for disconnected clients. Either way, a message is sent when an operation is complete; the only difference is when Windows dispatches the message.

Figure 10-8. A disconnected client with a message queue

In other cases, you might have specific requirements that require the development of a custom solution. You can create an application that polls for a network connection or manually waits for the user to tell it that a connection is available. This is conceptually similar to the way an e-mail program works. If you send an e-mail message while disconnected, exit the program, and then reconnect, the message won't be sent until you reload the program.

A final approach is to create a dedicated Windows service that handles the submission of information to a central service. This service will run perpetually on the computer, checking for a connection. If one exists, it transmits the information stored by the client program. This approach is conceptually similar to a message queue. It's most common if you can't be sure all clients have the Message Queuing software installed or configured correctly.

More Information

Chapter 16 presents a case study in which a legacy disconnected system must be migrated into the .NET world.

Upgrading from COM

In today's world, distributed systems commonly need to evolve from existing COM architecture. .NET makes this process relatively easy. Migrating from COM to .NET is a major shift, however, and it's important to follow a disciplined, phased approach to ensure that the system works. For most organizations, this will mean a considerable amount of time spent with a hybrid system that includes both COM and .NET components.

When you upgrade a legacy multitier application, it's best to begin by recoding the client program because it's easier for a .NET client to communicate with a COM component than for a COM-based client to communicate with a .NET component. The first stage of any migration should be to rewrite the presentation layer using ASP.NET or Windows Forms, as shown in Figure 10-9. You can use .NET's built-in COM interop support to access the middle-tier COM objects.

Figure 10-9. Phase-one migration

As long as clients communicate directly with the COM layer, it is difficult to update the business components. In addition, if the components are located on another computer, you must use DCOM for remote communication. The next phase is to correct this problem by moving the COM interop layer to the server, as shown in Figure 10-10. You can do this by creating another .NET layer using XML Web services or components exposed through .NET Remoting. The clients connect directly with this layer of .NET components, which just forwards requests and retrieves the results from the underlying COM components.

Figure 10-10. Phase-two migration

The final stage is to rebuild the business layer using .NET components, as shown in Figure 10-11. In the best-case scenario, you will be able to deploy these components one by one. The client code won't require any modifications at all you'll just need to update the layer of .NET XML Web services or remote components.

Figure 10-11. Phase-three migration