На этом шаге мы рассмотрим назначение апартаментов и особенности взаимодействия сервера и клиента.
Windows - многозадачная и многопоточная среда с вытесняющей многозадачностью. Применительно к СОМ это означает, что клиент и сервер могут оказаться в различных процессах или потоках приложения, а к серверу может обращаться множество клиентов, причем в непредсказуемые моменты времени. Технология СОМ решает эту проблему введением концепции апартаментов (apartments), в которых и выполняются СОМ-клиенты и СОМ-серверы. Апартаменты бывают одпопоточиые (Single Threaded Apartment, STA) и многопоточные (Multiple Threaded Apartment, MTA). Напомним, чем они отличаются друг от друга.
STA
При создании однопоточного апартамента СОМ неявно создает окно и при вызове любого метода СОМ-сервера в этом апартаменте посылает окну сообщение при помощи функции PostMessage. Таким образом, организуется очередь вызовов методов, и каждый из них обрабатывается только после того, как обработаны все предшествующие вызовы. Ниже перечислены основные достоинства одноиоточного апартамента.
- Программист может не заботиться о синхронизации методов. Гарантируется, что до окончания выполнения текущего метода не будет вызван никакой другой метод объекта.
- Программист может не заботиться о синхронизации доступа к полям класса, реализующего объект. Поскольку одновременно может выполняться только один метод, одновременный доступ к полю из двух методов невозможен.
В то же время, если приложение создало несколько потоков, в каждом из которых имеется STA, при доступе к глобальным разделяемым данным для этих данных требуется синхронизация, например, с использованием критических секций.
Недостатки одионоточного апартамента напрямую вытекают из его реализации.
- Дополнительные (и иногда излишние) затраты на синхронизацию при вызове методов.
- Невозможность отклика на вызов метода, пока не исполнен предыдущий. Например, если текущим является метод, требующий одну минуту на исполнение, то до его завершения СОМ-объект будет недоступен.
Тем не менее STA, как правило, является наиболее подходящим выбором для реализации СОМ-сервера. Использовать МТА есть смысл только в том случае, если STA не подходит для конкретного сервера.
МТА
Многопоточный апартамент не реализует автоматически синхронизацию и свободен от связанных с этим ограничений. Внутри него может быть создано сколько угодно потоков и объектов, причем каждый объект не привязывается к какому-то конкретному потоку. Это означает, что любой метод объекта может быть вызван в любом из потоков МТА. В это же самое время в другом потоке может быть вызван любой другой (либо тот же самый) метод СОМ-объекта по запросу другого клиента. СОМ автоматически ведет пул потоков внутри МТА и при вызове со стороны клиента находит свободный поток и в нем вызывает метод нужного объекта. Таким образом, даже если выполнение метода требует длительного времени, для другого клиента он может быть вызван без задержки в другом потоке. Очевидно, что СОМ-сервер, работающий в МТА, обладает потенциально более высоким быстродействием и доступностью для клиентов, однако он значительно сложнее в разработке, поскольку даже локальные данные объектов не защищены от одновременного доступа и требуют синхронизации.
Нейтральный апартамент
Для поддержки серверов СОМ+ в Windows 2000/XP добавлена еще одна модель потоков - модель нейтральных потоков (neutral-threaded model) и соответствующий тип апартамента - нейтральный апартамент (neutral apartment). COM+ автоматически создает один такой апартамент на приложение для объектов, имеющих модель нейтральных потоков. Объекты с этой моделью при вызове клиентом, находящимся в одном процессе с сервером, вызываются в потоке клиента. Таким образом минимизируются затраты на переключение потоков. Модель нейтральных потоков рекомендуется для компонентов СОМ+, не имеющих пользовательского интерфейса.
Передача интерфейсов и параметров
Таким образом, СОМ-клиент и СОМ-сервер могут выполняться как в одном апартаменте, так и в разных, расположенных в различных процессах или даже на разных компьютерах. Встает вопрос - как же клиент может вызывать методы сервера, если они находятся в общем случае в другом адресном пространстве? Эту работу берет на себя СОМ. Для доступа к серверу в другом апартаменте клиент должен запросить у СОМ создание в своем апартаменте представителя, реализующего запрошенный интерфейс. Такой представитель в терминах СОМ называется прокси (proxy) и представляет собой объект, экспортирующий запрошенный интерфейс. Одновременно СОМ создает в апартаменте сервера стаб (stub), принимающий вызовы от прокси и транслирующий их в вызовы сервера. Таким образом, клиент в своем апартаменте может рассматривать прокси в качестве сервера и работать с ним так, как будто сервер создан в его апартаменте. В то же время сервер может рассматривать стаб как расположенного с ним в одном апартаменте клиента. Всю работу по организации взаимодействия между прокси и стабом берет на себя СОМ. При вызове со стороны клиента прокси получает от него параметры, упаковывает их во внутреннюю структуру и передает в апартамент сервера. Стаб получает параметры, распаковывает их и производит вызов метода сервера. Аналогично осуществляется передача параметров обратно. Эти процессы называются маршалингом (marshalling) и демаршалингом (unmarshalling) соответственно. При этом апартаменты клиента и сервера могут иметь разные модели потоков и физически находиться где угодно. Разумеется, такой вызов означает значительные накладные расходы по сравнению с вызовом сервера в "своем" апартаменте, однако это единственный способ обеспечить корректную работу любых клиентов и серверов. Чтобы избежать накладных расходов, сервер надо создавать в том же апартаменте, в котором расположен клиент. Для корректного создания прокси в клиентском апартаменте СОМ требуется узнать "устройство" сервера. Сделать это можно несколькими способами.
- Реализовать на сервере интерфейс IMarshal и при необходимости прокси в виде библиотеки DLL, которая будет загружена на клиенте. Подробности реализации описаны в документации СОМ и MSDN.
- Описать интерфейс на языке IDL (Interface Definition Language - язык определения интерфейсов) и при помощи компилятора MIDL корпорации Microsoft сгенерировать библиотеку DLL, реализующую прокси и стаб.
- Сделать сервер совместимым с технологией OLE Automation. В этом случае СОМ самостоятельно создает прокси, используя описание сервера из его библиотеки типов - специального двоичного ресурса, описывающего СОМ-интерфейс. При этом в интерфейсе допустимы только совместимые с OLE Automation типы данных.
На следующем шаге мы рассмотрим инициализацию COM.
