Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
Дня использования прямого указателя при вызове из другого апартамента необходимо обмануть СОМ. Этот прием называется Free-Threaded Marshaler (FTM). Вот его суть.
При проектировании объекта с потоковой моделью Both нужно предусмотреть агрегацию этим объектом одного специального уже реализованного в СОМ объекта, поддерживающего специальным образом реализованный стандартный интерфейс IMarshaler.
При использовании пары функций
CoMarshaIinterThreadInterfaceInStream
и
CoGetInterfaceAndReieaseStream
система вначале проверяет — не поддерживает
Упомянутый выше агрегируемый объект реализует интерфейс IMarshal следующим образом. Прежде всего проверяется — выполняется ли маршалинг в рамках одного процесса, или между различными процессами или машинами. В первом случае в объект-поток записывается прямой указатель на запрашиваемый интерфейс, который и получает вызывающий поток при демаршализации указателя на интерфейс. Во втором случае запускается стандартный процесс маршалинга указателя на интерфейс с формированием прокси.
Создать агрегируемый объект, реализующий marshal, можно с помощью функции
CoCreateFreeThreadedMarshaleг.
При использовании описанного приема нужно соблюдать определенные ограничения. Объект с FTM не должен использовать прямые указатели на другие объекты, которые не используют FTM. Причина понятна. При нарушении указанного ограничения некоторый поток может получить косвенным образом прямой указатель на объект из другого апартамента, чья потоковая модель может отличаться от Both. Использование этого указателя может привести к краху всего приложения.
• При демаршализации указателя на интерфейс уничтожается объект-поток
Это означает, что если указатель на некоторый объект нужен потокам в нескольких различных апартаментах, то мы должны несколько раз вызывать пару функций
CoMarshaInterThreadInterfaceInStream
и
CoGetInterfaceAndReleaseStream.
Было бы удобно иметь одно общее дл\ всего процесса хранилище представленных в нейтральной относительно апартамента форме маршалированных указателей на пользующиеся успехом объекты. Тогда любой поток, которому нужен указатель на объект из другого апартамента, мог бы получить копию маршалированного указателя и демаршалировать его в своем апартаменте, получив соответствующий прокси.
Такая технология реализована в СОМ и называется Global Interface Table (GIT). В классе с GUID CLSID_StdGiobalInterfасеTаЫе реализован интерфейс IGlobalInterfасеаЫе, методы которого позволяют зарегистрировать новый указатель на некоторый интерфейс в этой таблице, получить его из таблицы, удалить указатель из таблицы. При этом автоматически происходит маршализация указателя на интерфейс при его регистрации в таблице и демаршализация при получении из таблицы.
А теперь в заключении рассмотрим механизм вызова метода через границу апартамента.
Начнем с механизма вызова объекта в STA.
При вызове объекта из STA вызов, пришедший из канала, преобразуется в сообщение, которое становится в очередь сообщений, связанную с данным STA. Поток, живущий в STA, выбирает из очереди очередное сообщение, которое через оконную процедуру попадает в стаб нужного интерфейса, где вновь преобразуется в вызов, который и выполняется объектом. Следующее сообщение из очереди выбирается после обработки предыдущего. Тем самым обеспечивается синхронизация вызовов объектов из STA.
Тут, однако, имеется одна тонкость. При выполнении вызова объект из этого STA может вызвать некоторый метод объекта из другого апартамента, тот из следующего и т. д. На каком-то этапе цепочка вызовов может вернуться в апартамент, где эта цепочка начиналась. Этот новый вызов в форме сообщения встанет в очередь, но очередь не двигается, т. к. поток, живущий в этом апартаменте, послал вызов за пределы своего апартамента и ждет ответа.
Для решения указанной проблемы используется следующий подход. Все такие цепочки вызовов отслеживаются (все вызовы из одной цепочки имеют одинаковый GUID). Когда в очередь приходит новый вызов с GUID, совпадающим с GUID выполняемого вызова, поток выходит из состояния ожидания и начинает выполнять вновь пришедший вызов.
В случае вызова объекта из МТА все значительно проще.
Нет никаких сообщений и их очередей. Для обработки пришедшего из канала вызова из пула связанных с МТА рабочих потоков выбирается произвольный поток. Когда этот поток должен сделать вызов за пределы апартамента, он входит в состояние ожидания, не отслеживая зависимость вновь поступающих вызовов от обрабатываемого им вызова. В пуле найдется поток, который обработает вновь пришедший вызов, и наш заснувший поток когда-нибудь получит ответ и продолжит обработку вызова.
Технология СОМ+ от Microsoft
СОМ+ можно назвать версией СОМ для Windows 2000. Но, на самом деле, это не просто очередная версия некоторого продукта. СОМ представляет собой модель компонентного программирования для локальных приложений. DCOM, хотя и предоставила возможность размещения клиента и сервера на различных машинах, является той же самой СОМ. Но СОМ+ — это уже компонентная модель для приложений, действующих на уровне предприятия. Кроме возможности удаленного вызова, которая уже была в COM/DCOM, данная модель расширяет традиционную СОМ прежде всего предоставлением важных сервисов, без которых создание распределенного приложения является крайне трудным, если не невозможным. Эти сервисы перечислены ниже
• Обеспечивают надежность приложения:
? Безопасность
В отличие от локального приложения, в работу с распределенным приложением вовлечены многие конечные пользователи, которые, с точки зрения администратора системы, должны иметь различные права доступа к данному приложению. В СОМ+ решаются следующие вопросы:
— Аутентификация клиента
Тот ли он, за кого себя выдает?
— Авторизация клиента
Какие операции может выполнять данный клиент?