- Introduction
- Application Boundaries
- Distributed Applications
- .NET Remoting Architecture
- Applying .NET Remoting
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Distributed Applications
As described in the previous sections, processes as well as application domains provide a close, protected environment. As a result, objects in a process or an application domain cannot talk directly to objects in another process or another application domain.
However, in the increasingly connected world, enterprises and users demand distributed applications. Distributed applications allow objects to talk across process boundaries. Often, distributed applications also meet the following objectives:
Establish communication between objects that run in different application domains and processes, whether on the same computer or across the Internet.
Enable enterprise application integration by establishing communication between objects that run on heterogeneous architectures.
Enable application availability by making sure that portions of an application run even if some components are busy or have failed.
Provide increased security and scalability by dividing the application into several layers (or tiers).
Evolution of Distributed Applications
A well-designed distributed application has the potential to be more connected, more available, more scalable, and more robust than an application where all components run on a single computer. This is a desirable model for an enterprise application.
Traditionally, there have been several efforts to design frameworks for developing distributed applications. A few well-known frameworks are Distributed Computing Environment/Remote Procedure Calls (DEC/RPC), Microsoft Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA), and Java Remote Method Invocation (RMI). Some of these implementations are widely deployed in enterprises.
However, modern business requirements are different from those of earlier days. Today, businesses seek solutions that can be developed rapidly, that integrate well with their legacy applications, and that interoperate well with their business partners. Each of the technologies already mentioned failed to satisfy one or more of these requirements.
In 2000, Microsoft introduced the .NET Framework for designing next-generation distributed applications. As you'll explore more in this book, the .NET Framework is specifically targeted to meet the needs of modern business, whether the need is rapid development or integration or interoperability.
Using the .NET Framework to Develop Distributed Applications
The .NET Framework provides various mechanisms to support distributed application development. Most of this functionality is present in the following three namespaces of the Framework Class Library (FCL):
The System.Net Namespace—This namespace includes classes to create standalone listeners and custom protocol handlers to start from scratch and create your own framework for developing a distributed application. Working with the System.Net namespace directly requires a good understanding of network programming.
The System.Runtime.Remoting Namespace—This namespace includes the classes that constitute the .NET remoting framework. The .NET remoting framework allows communication between objects living in different application domains, whether or not they are on the same computer. Remoting provides an abstraction over the complex network programming and exposes a simple mechanism for inter-application domain communication. The key objectives of .NET remoting are flexibility and extensibility.
The System.Web.Services Namespace—This namespace includes the classes that constitutes the ASP.NET Web services framework. ASP.NET Web services allow objects living in different application domains to exchange messages through standard protocols such as HTTP and SOAP. ASP.NET Web services, when compared to remoting, provide a much higher level of abstraction and simplicity. The key objectives of ASP.NET Web services are the ease of use and interoperability with other systems.
Both .NET remoting and ASP.NET Web services provide a complete framework for designing distributed applications. Most programmers will use either .NET remoting or ASP.NET Web services rather than build a distributed programming framework from scratch with the System.Net namespace classes.
The functionality offered by .NET remoting and ASP.NET Web services appears very similar. In fact, ASP.NET Web services are actually built on the .NET remoting infrastructure. It is also possible to use .NET remoting to design Web services. Given the amount of similarity, how do you choose one over the other in your project? Simply put, the decision depends on the type of application you want to create. You'll use
.NET Remoting when both the end points (client and server) of a distributed application are in your control. This might be a case when an application has been designed for use within a corporate network.
ASP.NET Web services when one end point of a distributed application is not in your control. This might be a case when your application is interoperating with your business partner's application.
You will learn more about architectural differences and specific features of both the technologies as you progress through this book. I will discuss .NET remoting in this chapter and will discuss ASP.NET Web services in Chapter 4, "Basic Web Services," and Chapter 5, "Advanced Web Services."
REVIEW BREAK
An Application domain, AppDomain, is the smallest execution unit for a .NET application. The CLR allows several application domains to run within a single Windows process.
Distributed Applications enable communication between objects that run in different application domains and processes.
System.Net, System.Runtime.Remoting, and System.Web.Services namespaces enable the .NET Framework to support distributed application development.