Читать онлайн «C# для профессионалов. Том II». Страница 60

Несмотря на свои достоинства, очереди сообщений имеют также серьезные ограничения. Очевидно, что когда службы COM+ ставят сообщение в очередь к недоступному серверному объекту и возвращают управление клиенту, они не могут вернуть сложный ответ. По этой причине необходимо принимать в расчет возможность возникновения неподтвержденных ошибок при проектировании компонентов, которые используют очереди сообщений. Более того, нельзя использовать значения, возвращенные из компонентов очереди, для выполнения обработки. Если компоненты отключены, они не могут возвращать значения.

Даже с теми возможностями, которые предоставляют пулы объектов, а также оперативная активизация для максимального доступа серверных ресурсов, возникают ситуации, когда одна серверная машина просто не может обслужить всех прикладных клиентов. В таких случаях разработчики должны воспользоваться службой COM+ выравнивания нагрузки компонентов. Эта служба распределяет прикладные объекты по ферме совместно действующих серверов Web, чтобы ни один сервер не был перегружен объектными запросами и чтобы конечные пользователи продолжали работать с высокой производительностью.

Основным объектом стратегии выравнивания нагрузки компонентов является сервер выравнивания нагрузки компонентов, или CLB (Component Load Balancing). CLB является машиной Windows Advance Server или Windows Data Server, которая служит менеджером для других серверов в ферме. CLB отвечает за распределение запросов объектов между доступными серверами.

Алгоритм, который использует сервер CLB для выбора хоста объекта, является достаточно сложным. Он проходит в определённом порядке список доступных серверов, передавая запросы создания первому доступному серверу. Так как этот список упорядочен от наиболее надежного к наименее надежному серверу, скорее всего запрос будут обрабатывать более мощные серверы.

Когда установлено соединение между клиентским приложением и серверной машиной, которую CLB присвоил клиенту, коммуникация продолжается между ними без последующего вмешательства CLB. Так как не существует гарантии, что объект сервера клиента будет находиться на все той же серверной машине, компоненты не должны иметь состояния, и таким образом, пулы объектов недоступны.

Теперь когда мы разобрались с различными службами COM+, давайте посмотрим, как службы могут использоваться со сборками .NET. Мы представим обзор общей технологии, и рассмотрим детали работы конкретных служб в последующих разделах. В конце главы мы научимся использовать транзакции, безопасность на основе ролей, пулы объектов и активацию JIT из компонентов .NET.

Взаимодействие со службами COM+ из сборок .NET делается возможным в основном через атрибуты. Задавая префиксы для определений классов с помощью атрибутов, определенных в пространстве имен EnterpriseServices, можно определить, как службы COM+ используют эти классы. Компилятор C# знает, как транслировать атрибуты в "крючки" необходимого кода, которые службы COM+ ожидают от компонентов.

Некоторыми из атрибутов, определенных в пространстве имен EnterpriseServices, являются:

□ Transaction

□ ObjectPooling

□ JustInTimeActivation

□ EventClass

□ ApplicationActivation

В дополнение к этим атрибутам пространство имен EnterpriseServices определяет различные классы и перечисления, некоторые из которых мы скоро подробно рассмотрим. Если надо увидеть содержимое пространства имен, воспользуйтесь утилитой WinCV. Чтобы увидеть классы в пространстве имен System.EnterpriseServices, добавьте строку:

<assembly name = "System.EnterpriseServices" />

в элемент <wincv> файла WinCV.exe.config.

Вероятно, можно согласиться, что атрибуты являются достаточно хорошим ненавязчивым подходом для использования служб COM+ в классах .NET. Нужно просто вставлять их в начале подходящих классов, не так ли? К сожалению, все не так просто, как кажется. Давайте начнем с предварительных шагов, которые необходимо предпринять, чтобы подготовить классы для служб COM+.

Первое. Компания Microsoft предлагает стандартизованное множество "атрибутов сборок", которые должны включаться в каждую сборку .NET, использующую службы COM+.

Следующий пример кода перечисляет их:

[assembly:ApplicationActivation(ActivationOption.Server)]

[assembly:ApplicationID("448934a3-324f-34d3-2343-129ab3c43b2c")]

[assembly:ApplicationName("SomeApplicationName")]

[assembly:Description("Description of your assembly here.")]

Рассмотрим каждый из этих атрибутов по очереди.

Ранее упоминалось, что существуют два вида приложений COM+ — серверные приложения и библиотечные приложения. Первый атрибут в коде примера — ApplicationActivation — позволяет определить, каким из этих видов приложений является определенная сборка. (Допустимые значения для этого атрибута определяются в перечислении ActivationOption, которое можно заметить внутри скобок атрибута.) Определяя тип приложения программным путем с помощью этого атрибута, можно избежать необходимости открывать менеджер службы компонентов и делать это вручную. Это перечисление имеет два значения: ActivationOption.Library и ActivationOption.Server.

Второй атрибут, ApplicationID, определяет присоединенный 128-битный уникальный идентификатор (GUID) сборки. (GUID являются идентификационными номерами, которые гарантируют уникальность в течение очень большого периода времени. Службы COM+ ожидают такой идентификатор от каждого приложения.) В коде примера случайно выбранный GUID не имеет ничего существенного, он присутствует только для целей демонстрации. Для каждой создаваемой сборки придется создавать свой собственный. Чтобы сделать это, можно использовать утилиту GuidGen.exe компании Microsoft, которая распространяется вместе с Visual Studio.

Третий атрибут в коде примера, ApplicationName, позволяет определить имя приложения службы COM+, которое будет создано для размещения сборки .NET, когда она импортируется в службы COM+. В данном примере используется значение SomeAppliсationName.

Четвертый и последний атрибут, ApplicationDescription, позволяет связать описание со сборкой, чтобы предоставить разработчикам некоторые идеи о том, что она делает.

Документация компании Microsoft определяет, что любая сборка .NET, использующая в соединении со службами COM+, должна применять все эти четыре атрибута.

Развертывание сборки, использующейся со службами COM+, будет ненамного труднее, чем развертывание любой другой сборки .NET.

Первое: необходимо предоставить сборке сильное имя. Это делается с помощью утилиты sn.exe из SDK .NET (см. главу 10). sn.exe будет выводить файл сильного имени, на который можно ссылаться из командной строки, когда сборка компилируется, чтобы встроить сильное имя в компилированную сборку.

Второе: необходимо зарегистрировать сборку в глобальном кэше сборок (см. главу 10).

Если сборку будут использовать только управляемые клиенты (то есть, клиенты .NET), никаких дополнительных усилий по развертыванию не требуется. Когда управляемый клиент создает в сборке экземпляр обслуживаемого класса, CLR использует атрибуты в сборке для автоматической регистрации компонента в службах COM+.

Однако, если классы в сборке используются неуправляемым кодом, необходимо самостоятельно явно зарегистрировать сборку в службах COM+ до выполнения любой клиентской программы. Программа для выполнения этой регистрации, RegSvcs.exe, предоставляется компанией Microsoft как часть SDK .NET. Когда RegSvcs выполняется на компоненте .NET, она создает приложение COM+ с именем, указанным атрибутом ApplicationName в сборке, и импортирует сборку в него.

Для чего же требуется RegSvcs.exe? 

Как можно помнить из предыдущей главы по взаимодействию COM, сборки .NET имеют архитектуру, отличную от архитектуры компонентов COM. Задача RegSvcs.exe состоит в разрешении этих различий, чтобы сборки .NET удовлетворяли интерфейсу, ожидаемому службами COM+. Чтобы выполнить свою работу, утилита RegSvcs.exe проделывает четыре вещи.

1. Загружает и регистрирует сборку .NET.

2. Создает библиотеку типов для сборки .NET.

3. Импортирует библиотеку типов в приложение служб COM+.

4. Использует метаданные внутри DLL, чтобы правильно сконфигурировать библиотеку типов внутри приложения служб COM+.

RegSvcs не только заботится обо всех деталях импортирования сборки в службы COM+, но предоставляет также достаточно хороший контроль за тем, как это происходит. Этот контроль обеспечивается в форме дополнительных параметров командной строки. Вот синтаксис команды: