Страница 191 из 372
• Обеспечивают масштабируемость приложения:
♦ Свободно связанные события
В СОМ+ реализуется новая по отношению к СОМ модель событий. Становится возможным публикация некоторой информации одними объектами и подписка на получение этой информации другими. Сервис событий обеспечивает необходимый механизм для реализации этой модели,
♦ Пул объектов и активация по необходимости
В СОМ+ различают создание/удаление объекта и его активацию/деактивацию. В ряде случаев выгодно создать некоторое число объектов нужных типов, а затем выполнять активацию/деактивацию объектов, помещая деактивированный объект в так называемый пул объектов, и извлекая объект нужного типа из пула объектов при активации,
♦ Базы данных в памяти
Некоторые таблицы из баз данных, которые часто используются только для чтения, могут размещаться в оперативной памяти машин среднего уровня (уровень бизнес-логики в Windows DNA архитектуре),
♦ Динамическое выравнивание нагрузки
При построении новых объектов на фиксированном сервере возможна ситуация, когда некоторый сервер из имеющихся в системе перегружен, в то время как некоторые другие простаивают. Сервис динамического выравнивания нагрузки управляет выбором сервера, на котором будет формироваться новый объект.
Все вышеперечисленные сервисы обеспечиваются СОМ+, но пока остался открытым вопрос о том, как объекты получают к ним доступ. В СОМ+ принят популярный сегодня подход, основанный на парадигме декларативного программирования. Разработчик распределенного приложения программирует только бизнес-логику. Весь остальной код, обеспечивающий использование ранее упомянутых сервисов, генерируется автоматически. Для этого достаточно только описать требования приложения и отдельных его элементов на некотором декларативном языке. В СОМ+ этот декларативный язык очень прост и сводится к заданию значений некоторой совокупности атрибутов, приписываемых приложению в целом, входящим в приложение компонентам, их интерфейсам и методам.
Использование декларативного подхода в данном случае имеет ряд преимуществ по сравнению с процедурным:
• Уменьшается время на разработку приложения
• Повышается надежность кода
Автоматически сгенерированный код надежнее созданного программистом, т. к. он прошел более объемное тестирование
• Уменьшается степень зависимости приложения от конкретной версии платформы (СОМ+)
Пока не изменена семантика, приписанная атрибутам, данное приложение будет работать со всеми последующими версиями платформы.
Атрибуты фактически уже приписывались компонентам и приложению уже в СОМ. Например, каждому классу приписывался его уникальный CLSID, путь к серверу (DLL или EXE файлу), потоковая модель (ThreadingModel). Однако возможности реестра ограничены, и для хранения большого числа дополнительных атрибутов, появившихся в СОМ+, используется дополнительная база данных — так называемый СОМ+ каталог. Имеется менеджер каталога, у которого есть доступ как к реестру системы, так и к каталогу. Разработчик и администратор получают доступ к каталогу через утилиту Component Services, или через иерархию предоставляемых системой объектов.
В данном курсе вопросы администрирования специально рассматриваться не будут. Используя Component Services несложно задать необходимый набор атрибутов для нового приложения. Единственное, что для этого необходимо — понимание имеющихся в СОМ+ сервисов. Именно их изучению и будет посвящена основная часть данной главы.
Архитектура СОМ+
Начнем со структуры приложения.
Понятия приложение, класс, интерфейс, метод образуют следующую иерархию:
приложение / класс / интерфейс / метод.
Иными словами, приложение содержит один или несколько классов (компонентов), каждый класс реализует один или несколько интерфейсов, и каждый интерфейс описывает один или несколько методов. Причем каждый класс может входить не более чем в одно приложение.
Имеется два типа приложений: библиотечные и серверные. Библиотечное оформляется в виде DLL и загружается в адресное пространство клиента. Серверное также оформляется в виде DLL, но при его активации запускается суррогатный процесс (dllhost.exe), в адресное пространство которого и загружается эта DLL. Тип приложения определяется при его создании. Например, при использовании Component Services задается приписываемый всему приложению атрибут, задающий его тип активации — библиотечное или серверное приложение.
Классы бывают конфигурированные и неконфигурированные. Конфигурированный класс включен в некоторое приложение и, следовательно, ему приписаны атрибуты. Класс, не включенный в приложение, не имеет атрибутов и зарегистрирован только в реестре системы.
Теперь рассмотрим, как выглядит приложение во время выполнения. Все, что говорилось ранее о процессах, потоках, апартаментах имеет место и в СОМ+. Но эта архитектура усложняется введением новых элементов: контекст и активность.
Начнем с контекста. Каждый объект инкапсулирует данные и методы. Обычно говорят, что данные описывают состояние объекта. Однако в СОМ+ данные, инкапсулированные в объекте,
не определяют полностью состояние объекта. Эти данные определяют только ту часть состояния объекта, которая связана с бизнес-логикой приложения. Но конфигурированный объект в СОМ+ участвует также в транзакциях и в других сложных процессах, поддерживаемых сервисами СОМ+. Часть состояния объекта, отражающая его требования к среде выполнения и то, как он использует сервисы в данный момент времени, называется контекстом объекта. Для сохранения контекста объекта используется так называемый объект контекста, который автоматически формируется при активации объекта и сопровождает объект до его деактивации. Получить доступ к объекту контекста для заданного объекта можно вызвав из данного объекта функцию
WINOLEAPI CoGetObjectContext
{
[in] REFIID riid,
[out] LPVOID **ppv
};
Первый параметр задает GUID запрашиваемого интерфейса, реализованного объектом контекста(IID_IObectContext, IID_IObjectContextlnfо, IID_IObjectContextActivity, IID IContextState). Во втором параметре возвращается адрес указателя на запрошенный интерфейс. Используя эти интерфейсы объект может не только узнать свое текущее состояние, но и изменить его. Рассматривать данные интерфейсы здесь мы не будем, т. к. первоначально необходимо изучить сервисы, для использования которых эти интерфейсы и разработаны.
Термин контекст используется еще в одном смысле — множество объектов, живущих в одном апартаменте и имеющих одинаковые требования к среде выполнения. Контекст объекта определяется при его активации и зависит как от атрибутов, приписанных соответствующему классу, так и от контекста объекта, инициировавшего активацию данного объекта (активатора). Если активированный объект является экземпляром неконфигурированного класса, то возможны два варианта. Если активированный объект и его активатор живут в одном апартаменте, то активированный объект помещается в контекст активатора. В противном случае активированный объект помещается в так называемый контекст по умолчанию своего апартамента. Для объектов, размещенных в контексте по умолчанию, недоступны никакие сервисы.
Итак, каждый объект в СОМ+ живет в некотором контексте. Различные контексты не пересекаются друг с другом и не пересекают границы апартаментов.
Понятие контекста тесно связано с понятием перехвата. Именно механизм перехвата обеспечивает учет семантики, определенной при задании атрибутов компонента. Don Box в статье "Windows 2000 Brings Significant Refinements to the COM(+) Programming Model", Microsoft System Journal, May 1999, так описывает схему перехвата
1. Компонент описывает свои требования используя атрибуты.
2. Во время создания объекта система проверяет — выполняется ли активатор (код, вызвавший CoCreateInstance) в среде, совместимой с конфигурацией класса?