- 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
From the previous sections, you can see that both process and application domains provide a closely protected environment. As a result, objects in a process or an application domain cannot directly talk to objects in another process or 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:
Establishes communication between objects that run in different application domains and processes whether on the same computer or across the Internet.
Enables enterprise application integration by establishing communication between objects that run on heterogeneous architectures.
Enables application availability by making sure that portions of an application continue to run even if some components are busy or have failed.
Provides 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 in which all components run on a single computer. This is a desirable model for an enterprise application.
Several efforts have been made 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 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 previously mentioned technologies 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, integration, or interoperability.
Developing Distributed Applications Using the .NET Framework
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, as well as to 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 constitutes the .NET remoting framework. The .NET remoting framework enables communication between objects living in different application domains whether or not they are on the same computer. Remoting provides an abstraction over the complexities of network programming and exposes a simple mechanism for interapplication domain communication. The key objectives of .NET remoting are flexibility and extensibility.
The System.Web.Services Namespace—This namespace includes the classes that constitute the ASP.NET Web services framework. ASP.NET Web services enable objects living in different application domains to exchange messages using 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 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 instead of building a distributed programming framework from scratch using the System.Net namespace classes.
The functionality offered by .NET Remoting and ASP.NET Web services appears very similar to each other. In fact, ASP.NET Web services are actually built on the .NET Remoting infrastructure. It is also possible to design Web services using .NET remoting. Given the amount of similarity, how do you choose one over another in your project? Simply put, the decision depends on the type of application you want to create. You'll use
.NET Remoting when both of the endpoints (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 of the endpoints 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 the specific features of both technologies as you progress through this book. I will discuss .NET remoting in this Appendix And I will discuss ASP.NET Web services in Chapter 4, "Basic Web Services," and Chapter 5, "Advanced Web Services."
REVIEW BREAK
An Application domain, or 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.
The System.Net, System.Runtime.Remoting, and System.Web.Services namespaces enable the .NET Framework to support distributed application development.