Интернет-журнал 'Домашняя лаборатория', 2007 №6 - Вязовский

некоторый метод объекта из другого апартамента, тот из следующего и т. д. На каком-то этапе цепочка вызовов может вернуться в апартамент, где эта цепочка начиналась. Этот новый вызов в форме сообщения встанет в очередь, но очередь не двигается, т. к. поток, живущий в этом апартаменте, послал вызов за пределы своего апартамента и ждет ответа.

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

В случае вызова объекта из МТА все значительно проще.

Нет никаких сообщений и их очередей. Для обработки пришедшего из канала вызова из пула связанных с МТА рабочих потоков выбирается произвольный поток. Когда этот поток должен сделать вызов за пределы апартамента, он входит в состояние ожидания, не отслеживая зависимость вновь поступающих вызовов от обрабатываемого им вызова. В пуле найдется поток, который обработает вновь пришедший вызов, и наш заснувший поток когда-нибудь получит ответ и продолжит обработку вызова.

Технология СОМ+ от Microsoft

СОМ+ можно назвать версией СОМ для Windows 2000. Но, на самом деле, это не просто очередная версия некоторого продукта. СОМ представляет собой модель компонентного программирования для локальных приложений. DCOM, хотя и предоставила возможность размещения клиента и сервера на различных машинах, является той же самой СОМ. Но СОМ+ — это уже компонентная модель для приложений, действующих на уровне предприятия. Кроме возможности удаленного вызова, которая уже была в COM/DCOM, данная модель расширяет традиционную СОМ прежде всего предоставлением важных сервисов, без которых создание распределенного приложения является крайне трудным, если не невозможным. Эти сервисы перечислены ниже

• Обеспечивают надежность приложения:

♦ Безопасность

В отличие от локального приложения, в работу с распределенным приложением вовлечены многие конечные пользователи, которые, с точки зрения администратора системы, должны иметь различные права доступа к данному приложению. В СОМ+ решаются следующие вопросы:

— Аутентификация клиента

Тот ли он, за кого себя выдает?

— Авторизация клиента

Какие операции может выполнять данный клиент?

— Передача полномочий

Часто в распределенной системе вызов некоторого метода, выполненный конечным пользователем, приводит к формированию цепочки вызовов одними объектами других объектов. В начале цепочки используются полномочия конечного пользователя. Но чьи полномочия будут использованы далее? о Транзакции

♦ Транзакции обеспечивают целостность данных в распределенной системе. Заметим, что СУБД обеспечивают механизм транзакций, но только в рамках одной базы данных. Здесь же в одну распределенную транзакцию могут быть вовлечены различные независимые хранилища данных,

♦ Синхронизация

В СОМ синхронизация доступа к объектам из разных потоков осуществляется с помощью использования механизма апартаментов. Практика программирования показывает, что редкие программисты проектируют потоко-безопасные компоненты, которые могут жить в таких апартаментах как МТА и NA. Как правило, используется STA, и доступ ко всем объектам, живущим в одном STA, синхронизируется самой системой посредством очереди сообщений. СОМ+ идет на встречу реальным предпочтениям программистов, предлагая возможность задавать синхронизацию доступа к объектам декларативным образом. При этом, даже объекты, живущие в МТА или NA, могут быть защищены от параллельного обращения,

♦ Очереди (асинхронная коммуникация)

В СОМ вызовы всех объектов синхронны. Иными словами, поток, сделавший вызов некоторого метода некоторого объекта, продолжает работу только после получения ответа. Исключением является поток в STA, который может выйти из состояния ожидания ответа для обработки вызова, пришедшего извне и принадлежащего к той же цепочке вызовов, что и вызов, ответ на который ожидается. Такая синхронная модель очевидно не сработает при временном выходе из строя сервера, в котором живет вызываемый объект. Решением указанной проблемы является асинхронная коммуникация. Вызов ставится в некоторую очередь вызовов, а вызывающий поток продолжает свою работу. Вызов из очереди извлекается и передается для выполнения серверу тогда, когда он станет доступным.

• Обеспечивают масштабируемость приложения:

♦ Свободно связанные события

В СОМ+ реализуется новая по отношению к СОМ модель событий. Становится возможным публикация некоторой информации одними объектами и подписка на получение этой информации другими. Сервис событий обеспечивает необходимый механизм для реализации этой модели,

♦ Пул объектов и активация по необходимости

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

♦ Базы данных в памяти

Некоторые таблицы из баз данных, которые часто используются только для чтения, могут размещаться в оперативной памяти машин среднего уровня (уровень бизнес-логики в Windows DNA архитектуре),

♦ Динамическое выравнивание нагрузки

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

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

Использование декларативного подхода в данном случае имеет ряд преимуществ по сравнению с процедурным:

• Уменьшается время на разработку приложения

• Повышается надежность кода

Автоматически сгенерированный код надежнее созданного программистом, т. к. он прошел более объемное тестирование

• Уменьшается степень зависимости приложения от конкретной версии платформы (СОМ+)

Пока не изменена семантика, приписанная атрибутам, данное приложение будет работать со всеми последующими версиями платформы.

Атрибуты фактически уже приписывались компонентам и приложению уже в СОМ. Например, каждому классу приписывался его уникальный CLSID, путь к серверу (DLL или EXE файлу), потоковая модель (ThreadingModel). Однако возможности реестра ограничены, и для хранения большого числа дополнительных атрибутов, появившихся в СОМ+, используется дополнительная база данных — так называемый СОМ+ каталог. Имеется менеджер каталога, у которого есть доступ как к реестру системы, так и к каталогу. Разработчик и администратор получают доступ к каталогу через утилиту Component Services, или через иерархию предоставляемых системой объектов.

В данном курсе вопросы администрирования специально рассматриваться не будут. Используя Component Services несложно задать необходимый набор атрибутов для нового приложения. Единственное, что для этого необходимо — понимание имеющихся в СОМ+ сервисов. Именно их изучению и будет