Симон Робинсон - C# для профессионалов. Том II

Основным объектом стратегии выравнивания нагрузки компонентов является сервер выравнивания нагрузки компонентов, или 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, добавьте строку:

в элемент файла 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в сборке, и импортирует сборку в него.