ApplicationDomain

.NET에는 Application Domain이라는 개념이 있는데,
사실 시스템의 장애에서 가장 중요한것은 장애의 발생을 막는것도 중요하지만, 장애가 다른 애플리케이션으로 전파되지 않도록 막는것이다.
OS에서는 Process가 가장 작은 단위로 별도의 주소 공간, 별도의 Thread 공간을 가지고 가지기 때문에 일반적으로 Process가 가장 작은 Isolation 단위이다.
.NET에서는 이를 확장해서 ApplicationDomain이라는 개념을 사용하는데,
하나의 Process를 ApplicationDomain이라는 논리적인 단위로 나눠서 관리하고, 하나의 Application이 하나의 ApplicationDomain 위에서 동작된다. 각 Application Domain은 독립된 주소 공간과 Thread Pool을 가지게 되고, 마치 독립된 형태처럼 동작한다. 각 주소공간은 Virtual Address로 .NET의 CLR이 실제 Physical Address로 mapping해준다 즉 CLR이 OS위에 올라가는 조그만 OS처럼 동작한다.

각 Application은 다른 Application Domain의 주소 공간을 침범할 수 없으며, 서로 다른 Security Role을 가지고도 동작이 가능하다.
무엇보다 흥미로운것중의 하나가, Application Domain단위로 Application을 Load/UnLoad가 가능하다는 것이다. 즉 이말은 특정 Application이 문제가 있으면 내리거나 또는 Reload가 가능하다는 이야기다.

Java기반의 WAS에서는 Thread Pool을 나눠서 업무를 관리하는데
ASP.NET에서는 ApplicationDomain 단위로 업무를 나눌 수 있기 때문에 장애에 대한 전파성이 훨씬 낮다. Java의 경우 하나의 Thread가 잘못되서 Lock을 잡거나 하면 다른 업무까지 장애가 전파될 수 있고, 또는 해당 업무를 Restart하려면 다른 업무도 같이 restart가 되어야 한다. (하나의 프로세스이기 때문에) 그러나 ASP.NET에서는 특정 ApplicationDomain만 restart하면 되고, 혹시 문제가 생겼다 하더라도 다른 ApplicationDomain 공간을 침범(Thread나 메모리를)하지 않기 때문에 장애 전파를 막는데 아주 효과적으로 보인다.

ApplicationDomain간의 호출은 ApplicationDomain은 완벽하게 논리적으로 분리된 공간이기 때문에, Applciation Domain간에 Object를 share할 수 없다. WebService나 Remoting Service를 이용해야 하는데, 흥미로운것중 하나는 Remoting을 이용할때, 이 Object는 Internal Object sharing용으로 Marshraring되어서 IPC(Inter-Process-Call)을 위한 Marsharing보다 Cost가 싸게 먹힌다는 것이다.

일단 구조적으로는 Java 기반의 WAS보다는 상당히 진보한것 처럼 보이는데, 실제로는 어떻게 돌아가는지 사실 겪어봐야 알겠다. :)