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 the application boundaries supplied by 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 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.
Process boundaries are a good thing because they allow processes to coexist. However, it takes 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 would involve several short-lived processes, which require 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 the .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. This is why code executed by the CLR is also known as managed code.
Unlike Windows, the CLR can verify the type-safety of programs to guarantee that a program does not request resources outside of its own boundary. The characteristics of the CLR help provide isolation between running programs at a lower cost than the process boundary.
Instead of a process, the basic unit of isolation for running applications in the CLR is an application domain. An application domain (also known as an AppDomain) is the smallest execution unit 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 provided by a Windows process.
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.
Creating, monitoring, and maintaining an application domain uses fewer resources than performing the same operations with a process. In addition, the capability of an application domain to run multiple applications within the same process reduces the overhead of process switching. Thus, application domains increase the performance of the applications.
You can create an application domain in a program using the AppDomain class of System namespace. However, in most cases the application domains are created and managed by the runtime hosts that 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.