If you have ever had the need to isolate a task because it might bring down your applciation? You want to execute a task that needs a specific security context. You want isolate the task and its data. Well the AppDoamin is your new best friend.
Beginning at the beginning
To better understand .Net's AppDomain and how they affect the programs we create and work on, it'll be a good idea to start ground up. So let's start from the point we button click an application. Whenever we start an application, we're actually starting a Win32 process and running our application inside it. These processes use resource such as memory, objects, kernel so on and so forth. All processes process contains at the least one thread and if we are to run other tasks or open up other applications through our application, these tasks will belong to our particular Win32 process running on a collection of multiple threads. For WinForms applications the effect of this when executing on the UI thread can be seen when we make direct calls to long running processes. In that cause the screen to appears to lock up or become non responsive (enter the hourglass), this is also symptomatic of pre AJAX enanbled web applications. One of the cornerstones of a Win32 process is that it is very much like a closed room in your house. It's pretty easy to communicate within the room but the ability to communicate with those inthe room next to you or down the hall is problomatic. To interact with other Win32 processes, we would require some special mechanisms to work on as there are a couple of security contexts we would have to take into consideration and also the need to restrict what a Win32 process can and should given a particular set of circumstances.
To better understand .Net's AppDomain and how they affect the programs we create and work on, it'll be a good idea to start ground up. So let's start from the point we button click an application. Whenever we start an application, we're actually starting a Win32 process and running our application inside it. These processes use resource such as memory, objects, kernel so on and so forth. All processes process contains at the least one thread and if we are to run other tasks or open up other applications through our application, these tasks will belong to our particular Win32 process running on a collection of multiple threads. For WinForms applications the effect of this when executing on the UI thread can be seen when we make direct calls to long running processes. In that cause the screen to appears to lock up or become non responsive (enter the hourglass), this is also symptomatic of pre AJAX enanbled web applications. One of the cornerstones of a Win32 process is that it is very much like a closed room in your house. It's pretty easy to communicate within the room but the ability to communicate with those inthe room next to you or down the hall is problomatic. To interact with other Win32 processes, we would require some special mechanisms to work on as there are a couple of security contexts we would have to take into consideration and also the need to restrict what a Win32 process can and should given a particular set of circumstances.
ScenarioConsider the lowly desktop/ laptop in any given session at our workstations we are hosting 10's or hundreds of processes. Often we are not even aware of the wide array of processes that are working diligently on our behalf to keep the system running. Lets break down exactly what's happening in the scenario. Stepping away from the concerns of what variables are being used and how many may have the same name and who writes efficient software vs.... well enough said what are we really talking about to keep the engine running. At the crux of the issue what we're actually dealing with and what we would have to provide to these applications - Resources, resources and even more resources! The primary resource we are talking about is memory running a close second are security issues; therefore it is imperative that we force absolutely no communication of any sort between the processes of these applications. Wait what's the point of having a computer and all these applications if they can talk to each other. Ah the exception to the rule, there are frequent exceptions based on requirements, so many exceptions that perhaps that should be the RULE. Invoking these exceptional cases can and often does lead to frequent crashes. the instance where one process using up the memory allocated to another process can lead to unstable environments that eventually CRASH! I hate it! Everyone hates it! Especially customers. Anyway, our process dies,blows up, dies an unnatural death ect.. Nothing new it happens we are human after all not machines. These frequent crashes and run-time errors are usually caused due to inefficient use of memory leading to memory leaks, null object referencing, out of memory bounds you get the idea. From this example it becomes clear that running and maintaining processes are VERY expensive on a single workstation not to mention the effect this would have on oh say an App server or a Web server serving up several thousand web sites. Hence, It just isn't a good idea to use a large number of processes since they simply do not scale pretty well. So here's a pretty neat solution that was employed for the above situation. Running a host of multiple applications within a single process will enable us to use fewer resources enter the Web Server code name IIS. This would even result to faster execution. But here's another everyday scenario: in the case where one application crashes, every other application within this process goes down like a deck of cards! OUCH !! Who did that. And we wonder why system administrators are so protective of their servers?
A New Paradigm
Enter the .Net AppDomain. The main purpose of an Application Domain is to isolate our applications from other applications. Application domains run on a single Win32 process. The same solution that we just mentioned above can use an application domain and at the same time, limit the possibility of errors and crashes due to memory leaks while providing isolation, security context and protection of our application from other applications. Hence we're running an application within an application domain and we further run multiple application domains within a single Win32 process. With the CLR's ability to run managed code, we're further cutting down on leaks and crashes. Objects in the same Application Domain communicate directly while Objects that exists in different Application Domains interact with each other by transporting copies of objects to each other or by using proxies for message exchange (by reference). So that's the crux of an Application Domain.
Ah but theres more - It's actually a pretty neat light weight process that runs within a single Win32 process. Infact, as previously noted, we can run multiple Application Domains within a single Win32 process and much like Russian Nesstign Dolls Domains inside of Domains.
Why would I want to do that? Another advantage of using an Application Domain is that we can destroy it through the parent without affecting other Application Domains that exist within that Win32 process. Therfore we can extrapolate that any work occuring in that Application Domain can be independent.
Bonus Features We can also use Application Domains to unload types by destroying the Application Domain that we have loaded it into- support for dynamicloading and unloading . The amazing .Net runtime enforces Application Domain isolation by ensuring control over memory use and therefore all the memory that is used by the Application Domains within a Win32 process is managed by the .Net runtime. (Read no heavy lifting on your part) We are avoiding almost all the problems that we mentioned initially such as one application accessing another application's memory and hence avoiding runtime errors followed by crashes. What we have actually done is provide a secure execution context that isolates current applications from talking to other applications. Practically speaking, Application Domains play a critical security and functional role especially when we're creating applications that do remoting like running web services.
Now how do we create a basic application domain? A basic AppDomain issimplicity itself. The .Net framework provides a beautiful base class that exists within the System namespace so that we can explicitly create an AppDomain. Inheriting the System.MarshalByRefObject base class into our applications, we can create objects that communicate between and across different application domains. Here is a simple application to create an AppDomain in C#.
nice! great article
ReplyDelete