ASP.NET is a giant step forward in the evolution of programming models because it vastly simplifies the development of Web applications. For companies seeking to build traditional thin-client applications鈥攁pplications that rely on browsers to display HTML generated on servers鈥擜SP.NET is the right tool for the job. Its benefits include shorter development cycles and software that is more scalable, more maintainable, and more robust.
Despite the importance of thin-client applications in today鈥檚 market, there still exist applications that benefit from, and sometimes require, a tighter coupling of client and server. In recent years, literally thousands of companies have deployed distributed applications built on DCOM (Distributed Component Object Model), CORBA (Common Object Request Broker Architecture), Java RMI (Remote Method Invocation), and other remoting technologies. These types of applications won鈥檛 go away anytime soon, nor will the advantages that they enjoy over thin-client applications. Closely coupled applications are better suited for two-way communication between clients and servers than are conventional Web applications. They also tend to utilize network bandwidth more efficiently because they can use lean binary protocols in lieu of HTTP. And close coupling facilitates stateful connections between clients and servers, which in turn simplifies the task of building stateful applications.
Many people feel that the sweet spot for intranet applications built with the .NET Framework in coming years won鈥檛 be traditional thin-client applications but 鈥渞ich-client鈥?applications鈥攁pplications that feature Windows forms on the client (better to overcome the limitations of HTML), managed components on the server, and pluggable protocol channels in between. One reason for this belief is that the .NET Framework includes a robust and easy-to-use remoting infrastructure that supports DCOM-style applications. This infrastructure is physically manifested as a set of types in the System.Runtime.Remoting namespace and its descendants. Get to know these types and you can be building closely coupled rich-client applications in no time. And you can do so without all the hassles that come with COM programming鈥攁partments, IDL (Interface Definition Language), reference counting, lack of exception handling, incompatible languages and data types, and so on.
For an author who has spent the past several years of his life working with COM and helping companies overcome the problems and limitations thereof, it鈥檚 fitting that the final chapter of this book be devoted to .NET remoting. In this writer鈥檚 opinion, .NET remoting is a better COM than COM. Let鈥檚 see if that assertion holds up.