This chapter is from the book
This chapter is from the book
This chapter is from the book
Application Boundaries
An application boundary defines the scope of an application. It encompasses various resources critical to an application's execution, such as address space, executable code, and the data used by the application. A typical multiprogramming execution environment such as Windows uses application boundaries to protect one application from affecting the execution of another application.
In this section, you'll learn about application boundaries with respect to Windows and the .NET Framework. You'll understand how application boundaries protect applications from poorly designed or faulty code. You'll also learn how application boundaries make it difficult to design applications that want to communicate beyond the application boundaries.
Process Boundary
A process is an application under execution. Windows isolates processes from each other to ensure that code running in one process cannot adversely affect other processes. Windows achieves this isolation by creating a process boundary. A process boundary ensures that
Each process has its own virtual address space, executable code, and data.
A Windows process cannot directly access the code or data of another Windows process.
A Windows process runs only one application, so if an application crashes, it does not affect other applications.
A process boundary allows processes to co-exist. However, it takes a lot of system resources to create, monitor, and terminate a process. In addition, when the processor switches between the processes, the processor must save and reset the execution context of the processes. Often an application involves several short-lived processes, which requires the system to spend a lot of resources just for process management.
Application Domain Boundary
The Common Language Runtime (CLR) provides a managed execution environment for .NET applications. The managed execution environment provides various services to the executing code, including cross-language integration, code access security, object lifetime management, and debugging and profiling support. The code executed by the CLR therefore is known also as managed code.
Unlike Windows, the CLR can verify type-safety of the programs to guarantee that a program does not request resources outside its own boundary. This characteristic of the CLR helps provide isolation between running programs at a lower cost than a process boundary incurs.
Instead of a process, the basic unit of isolation for running applications in the CLR is an application domain. An application domain (represented by System.AppDomain class) is the smallest executionunit for a .NET application. The CLR allows several application domains to run within a single Windows process and still provides the same level of isolation between applications as a Windows process does.
The application domains achieve isolation through application domain boundaries, which ensure that
Each application domain contains its own set of code, data, and configuration settings.
An application domain cannot directly access the code or data structures of another application domain.
Code running in one application domain cannot affect other application domains. The CLR can terminate an application domain without stopping the entire process.
It is much cheaper to create, monitor, and maintain an application domain than a process. In addition, the capability of an application domain to run multiple applications within the same process consumes less overhead in process switching; therefore application domains increase application performance.
You can create an application domain in a program by using the AppDomain class of System namespace. However, in most cases the application domains created and managed by the runtime hosts execute your code. Runtime hosts provide the environment to run managed code on behalf of the user. When you install the .NET Framework, you get three runtime hosts already configured—the Windows shell, ASP.NET, and Internet Explorer.