COM+ и .NET – практичный подход - часть 1 - Придание максимальной доступности приложению
ОГЛАВЛЕНИЕ
Придание максимальной доступности приложению
Одной из стратегических целей, тактикой достижения которых является .Net, является рынок корпоративного программного обеспечения. Microsoft хочет проникнуть в этот рынок, на котором многие годы господствовали Oracle и SUN (поставщики Java и сервера приложений java). Потребности корпоративного рынка отличаются от потребностей рынка электронной коммерции. Обычно корпоративное ПО применяется для обработки больших разных баз данных с набором приложений внутренней сети, являющихся единой большой программой для конечного корпоративного пользователя. Эти приложения (обычно десятки) размещаются на одном и том же сервере, являющемся частью кластера балансировки нагрузки. Создание набора приложений разными группами разработчиков, с большим объемом связи между ними, которые в итоге будут рассматриваться как единое приложение и размещаться на одном и том же сервере, требует отличающегося набора требований от создания одиночного клиент-серверного приложения или приложения электронной коммерции. Microsoft начинает выпускать все больше программных средств и средств разработки, помогающих предприятиям разрабатывать свое ПО. Одно из таких средств - COM+, один из вкладов COM+ - мощная поддержка доступности и масштабируемости.
Размещение множества приложений на одном и том же сервере очень выгодно для предприятия. Такая конфигурация обеспечивает лучшую производительность из-за связи между приложениями и экономит деньги (Представьте стоимость покупки и обслуживания сервера для каждого приложения). Но есть один крупный недостаток. Если часовая система отчетности даст сбой и потребит 100% ресурсов процессора, все остальные приложения, работающие в том же самом IIS, тоже пострадают. Такая ситуация может повредить доступность приложения и даже данных и должна предупреждаться или хотя бы отслеживаться и прекращаться.
Один из очевидных выводов из производительности и ограничений заключается в том, что лучше не использовать приложение сервера COM+. Несмотря на то, что этот вывод базируется на веских доказательствах, приложение сервера COM+ легко способно решить проблему доступности, но с издержками производительности. Большей частью издержки производительности неважны для корпоративного ПО, которое в крайнем случае должно обслуживать десятки тысяч пользователей, разделенных между тремя серверами или более.
Максимальная изоляция
Регистрация класса в качестве приложения сервера COM+ дает специальный процесс по имени dllhost.exe, который будет выполнять объекты класса, когда они будут созданы. Этот подход изолирует объекты класса от адресного пространства вызывающего приложения и позволяет уничтожать объекты класса без завершения вызывающего веб-приложения.
По сути, IIS5 и IIS6 обеспечивают другой механизм изоляции. IIS 5.0 захватывает запрос к приложению .Net и посредством конвейера передает запрос специальному процессу для обработки приложений ASP.NET - aspnet_wp.exe. Есть только один процесс aspnet_wp на сервере, и каждое веб-приложение имеет свой собственный домен приложения внутри aspnet_wp. ASP.NET пользуется преимуществами такой архитектуры и перезапускает приложение путем перезапуска домена приложения веб-приложения. Хотя ASP.NET может перезапустить приложение в определенных ситуациях, администраторы не могут. Администратор может использовать механизм перезапуска веб-приложения ASP.NET при внесении любого изменения в каталог bin приложения. Этот обходной прием будет работать, только если приложение не обрабатывает входящий запрос. В таком случае перезапуск приложения произойдет сразу после завершения запроса. Если один из шагов обработки запроса войдет в бесконечный цикл, веб-приложение не перезапустится.
Такое поведение IIS5 вместе с внутрипроцессным режимом активации сборок, используемых веб-приложением, может привести к недоступности нескольких приложений, даже если всего одно приложение неправильно функционирует. Чтобы преодолеть данную ситуацию, администратор должен перезапустить процесс aspnet_wp, что в итоге перезапустит все приложения, работающие на сервере. Единственный способ предотвратить такую ситуацию – использовать расслоение и размещать слои, не являющиеся графическим пользовательским интерфейсом, как приложения COM+, чтобы администратор мог с помощью консоли управления COM+ перезапустить специальный процесс, не вредя процессу aspnet_wp.
IIS6 вводит пулы приложений, вмещающие несколько веб-приложений. Пулы приложений имеют свой собственный процесс w3_wp, который может перезапустить администратор, тем самым позволяя завершить одно веб-приложение без вреда для других. Данная опция IIS6 позволяет администраторам завершить одно приложение, но все еще лишена возможностей отслеживания, встроенных в COM+, позволяющих администраторам быстро найти неправильно работающую сборку.
Показывается изоляция на практике. Будет создано простое веб-приложение (AvailabilityCheck) со сборкой, содержащей один регистр класса в COM+. Этот класс содержит два метода - DoItRight и NeverEndingStory, содержащий бесконечный цикл. Веб-форма содержит две кнопки, каждая из которых вызывает метод класса.
Рисунок 1.0
//код класса
namespace AvailabilityCheckDll
{
public class AC : System.EnterpriseServices.ServicedComponent
{
public AC()
{
}
public string DoItRight()
{
return DateTime.Now.ToString ();
}
public string NeverEndingStory()
{
// моделировать незаконченную рекурсию
for(;;)
{
}
return DateTime.Now.ToString ();
}
}
}
// код страницы
public class WebForm1 : System.Web.UI.Page
{
protected System.Web.UI.WebControls.Button btnDoItRight;
protected System.Web.UI.WebControls.Button btnNeverEndingStory;
private void Page_Load(object sender, System.EventArgs e)
{
}
+#region Web Form Designer generated code
private void btnDoItRight_Click(object sender, System.EventArgs e)
{
AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
Response.Write ( oAc.DoItRight ());
}
private void btnNeverEndingStory_Click(object sender, System.EventArgs e)
{
AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
Response.Write ( oAc.NeverEndingStory());
}
}
Запуск веб-приложения заставляет класс AC зарегистрироваться как приложение библиотеки. Нажатие на кнопку DoItRight возвращает страницу с напечатанной датой и временем. Нажатие на NeverEndingStory загружает процессор на 100%. Единственный способ завершить 100% использование процессора - перезапустить aspnet_wp (IIS5) или перезапустить пул приложений (IIS6). Теперь измените метаданные AC в консоли управления COM+, чтобы работать как приложение сервера, и нажмите кнопку NeverEndingStory. После того как вы заметите, что использование CPU достигло 100%, остановите приложение COM+. Использование CPU вернется к норме, и выведется страница с ошибкой с указанием какой-то проблемы в приложении. Данный сценарий показывает эффективность использования приложения сервера COM+. Вредоносный код легко останавливается без вреда для других веб-приложений.
Другая возможность добиться изоляции – использовать дистанционную связь и разместить сборки в специальной службе Windows. Администратор может остановить специальную службу без вреда для другого приложения. У такого подхода есть два минуса. Остановка службы влияет на все сборки, размещенные в этой службе, и нет статистики для использования.
Регистрация класса в качестве приложения сервера COM+ дает более доступные приложения и в сочетании с отслеживанием существенно сокращает период недоступности приложения. Только не забывайте, что регистрация класса в качестве приложения COM+ вредит производительности приложения. Прежде чем решить, регистрировать ли сборку в качестве приложения сервера, следует свериться с ACT (центральное испытание приложения) на RPS (запросов в секунду) и лишь затем принять решение.