1.3.2. Виды маршалинга в модели сом

Имеется три основных способа обмена информацией между процессами.

1. Пользовательский маршалинг. Реализуется стандартный интерфейс IMarshal, не используется ORPC, программист самостоятельно разрабатывает программы обмена. Это сложный способ обмена.

2. Стандартный маршалинг. Используется протокол ORPC. Требуется построить и зарегистрировать DLL для заглушки/прокси с помощью компилятора MIDL. MIDL за программиста пишет весь код стандартного маршалинга. Заглушки/прокси используются только для пересылки данных пользовательских интерфейсов. Данные стандартных интерфейсов передаются с помощью системной ole32.dll.

3. Универсальный маршалинг (маршалинг библиотеки типов) базируется на другой системной DLL заглушки/прокси - oleout.dll. Все параметры методов интерфейса должны иметь variant – совместимый тип. Для С++ это большинство основных типов: double, float, long, short и др.

При использовании универсального маршалинга не требуется строить собственную DLL заглушки/прокси.

Особенности построения сервера при универсальном маршалинге:

1. каждый интерфейс в idl-файле надо снабдить атрибутом [oleautomation];

2. зарегистрировать в реестре системы интерфейсы и библиотеку типов сервера *.tlb.

Чтобы автоматически зарегистрировать интерфейсы, определенные в библиотеке типов сервера, и саму библиотеку типов, используется функция LoadTypeLibEx().

Пример:

ITypeLib * pTLib = NULL;

LoadTypeLibEx (L"CarServerInfo.tlb",REGKIND_REGISTER, &pTLib);

pTLib -> Release();

Три этих строчки загружают библиотеку типов и записывают в системный реестр 8 строк.

9. Построение удаленного СОМ-сервера .

Удаленный СОМ-сервер строится с использованием технологии Distributed COM (DCOM).

DCOM предоставляет клиенту возможность доступа к серверу, расположенному на другом компьютере.

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

При удаленной активизации SCM машины клиента читает локальный реестр. Поле RemoteServerName под ключом AppID содержит имя машины, где зарегистрирован сервер. В результате локальный SCM обращается к удаленному SCM, который в свою очередь начинает искать путь к серверу в реестре собственного компьютера. Контакты между SCM производятся на основе протокола ORPC (object RPC).

10. Библиотека активных шаблонов (ATL).

Программы, использующие СОМ, требуют много обслуживающих кодов. В программах СОМ есть много похожих фрагментов (коды для DLL-серверов, фабрики классов, реализация интерфейсов и т.п.).

Библиотека активных шаблонов (Active Template Library, ATL) содержит шаблоны, макросы и классы С++, облегчающие разработку СОМ-серверов. Возможности ATL:

• поддержка кодов хранилищ компонентов для DLL- и EXE-серверов;

• реализация IUnknown, включая QueryInterface();

• обеспечение по умолчанию фабрики класса для каждого кокласса;

• поддержка разработки более сложного объекта класса;

• поддержка саморегистрации сервера (без возни с REG-файлами);

• поддержка дополнительных возможностей СОМ.

Назначение некоторых ATL-файлов, содержащих исходный код, описано в табл.1.2.

Таблица 1.2

Назначение некоторых ATL-файлов

Заголовочные Файлы	Назначение файлов
<atlwin.h> <atlwin.cpp> <atlhost.h>	Поддержка окон и диалогов.
<atlctl.h> <atlctl.cpp>	Поддержка разработки элементов управления ActiveX.
<atliface.idl> <atliface.h>	IDL – код для интерфейсов СОМ и заголовочный файл, сгенерированный MIDL.
<atlbase.h> <atlcom.h>	Основные файлы ATL.

Эти файлы содержатся в каталоге ATL\Include среды MS Visual Studio. В большинстве случаев нужные файлы включаются в проект автоматически.

Разработка проекта ATL начинается с вызова ATL СОМ AppWizard'а, который используется для создания хранилища компонентов для СОМ-сервера. После этого вызывается ATL Object Wizard, чтобы вставить некоторое количество коклассов в хранилище. После получения построенной стандартной инфраструктуры, необходимой для большинства приложений, требуется вручную дописать сгенерированный мастером код под нужды приложения. Требуется определить СОМ-интерфейсы в синтаксисе IDL.

Мастер ATL СОМ AppWizard вызывается в пункте меню File| New после задания имени ATL-проекта (например, ИМЯ).

В группе переключателей Server Type задается один из трех типов сервера:

• Dynamic Link Library (DLL) – внутрипроцессный DLL-сервер. Экспортируемые функции DLL представляются через DEF-файл;

• Executable (EXE) – локальный внепроцессный сервер;

• Service (EXE) – служба NT, локальный или удаленный сервер.

Если указан тип DLL, то на этой же вкладке выбирается, следует ли работать с MFC (Microsoft Foundation Classes), c MTS (Microsoft Transaction Server), c прокси/заглушками.

Если СОМ-сервер использует только variant – совместимые типы, то можно пользоваться универсальным маршалингом, и заглушки/прокси не потребуется. Они не потребуются и тогда, когда интерфейсы задаются с атрибутом [oleautomation].

AppWizard генерирует следующие файлы:

stdax.h, stdax.cpp служат для включения основных файлов ATL в текущий проект

ИМЯ.cpp экспортируемые функции DLL, используется класс CComModule,

объявляется OBJECT_MAP

ИМЯ.def объявляет экспортируемые функции DLL

ИМЯ.idl IDL-файл проекта, пока пустой оператор library

ИМЯ.h сгенерированный MIDL-файл

ИМЯps.mk make-файл и def-файл для создания DLL

ИМЯps.def прокси/заглушки (proxy/stub)

resource.h, ИМЯ.rc файлы минимальных ресурсов проекта

Все файлы *.срр в проектах ATL должны в первой строке содержать:

#include "stdafx.h"

Файл ИМЯ.срр реализует DLL-экспорты для сервера. Каждый из экспортов DLL реализован с помощью ATL-класса CСomModule. Методы класса CComModule используют карту объектов (object map) при создании фабрик класса, а также при регистрации и удалении кокласса из системы. Каждый кокласс, содержащийся в сервере, должен быть занесен в карту.

В начале файла ИМЯ.срр определяется глобальный экземпляр класса CComModule с именем _Module и карта объектов.

#include "stdafx.h"

. . .

CComModule _Module;

BEGIN_OBJECT_MAP(objectMAP)

OBJECT_ENTRY(CLSID_ATLCoCar, CATLCoCar)

END_OBJECT_MAP()

Далее располагаются экспортируемые функции DLL, в том числе функции саморегистрации. Функции саморегистрации автоматически вызываются в проекте ATL в процессе сборки DLL или ЕХЕ. Поэтому на рабочем компьютере СОМ-серверы всегда доступны для тестирования. Если же приходится переносить сервер на другую машину, то регистрацию можно сделать либо с помощью утилиты regsvr32.exe, либо с помощью инсталляционной программы. ЕХЕ-серверы с помощью утилиты regsvr32.exe не регистрируются. Вместо нее вызывается API реестра Win32 для внесения в реестр или удаления из него требуемых записей.

11. Потоковые модели СОМ. Обеспечение безопасности в технологии СОМ.

Для каждого ЕХЕ-файла, загруженного в память Win32, выделяется отдельная изолированная область (процесс). Каждый процесс имеет как минимум один главный поток (thread), который является точкой входа в программу WinMain() или main().

Поток – это последовательность действий внутри процесса. Каждый поток конкурирует с другими потоками за доступ к ресурсам процесса. Каждый поток в процессе получает локальную память, но работает также и с глобальными данными. При разработке многопотоковых приложений возникает проблема синхронизации доступа к общим данным. Для защиты данных от повреждения в Win32 могут использоваться такие средства, как критические сегменты, диспетчеры (mutex) или семафоры.

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

В ATL по умолчанию предоставляется критический сегмент, описываемый структурой CRITICAL_SECTION.

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

С другой стороны, СОМ-клиент не должен беспокоиться о том, является ли объект потокоустойчивым или нет.

Для управления доступом к объектам сервера в модели СОМ введено понятие “апартамент” (apartment). Апартамент – это концепция, определяющая контекст выполнения действий в процессе. Апартаменты в модели СОМ присутствуют в двух вариантах: однопотоковые (STA) и многопотоковые (МТА). При задании модели апартамента для СОМ-объекта фактически дается инструкция системе СОМ, каким образом оперировать с объектами в различных потоковых окружениях.

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

Чтобы обеспечить более быстрый доступ в случае многих потоков, модель СОМ поддерживает многопотоковый апартамент (МТА).

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

Апартаменты создаются библиотеками функций СОМ. Желаемый тип апартамента клиент указывает при создании кокласса. Для указания апартамента должна быть предварительно задана константа препроцессора _Win32_DCOM.

Режим работы системы СОМ с внутрипроцессными объектами задается в реестре в подключе InproсServer32 в поле Threading Model. Поле Threading Model может принимать одно из четырех значений:

none (не задано) – объект располагается в самом первом созданном в процессе STA (главный STA). Объект в главном STA абсолютно потокоустойчив.

Apartment – объекты будут загружены в какой-нибудь STA процесса. Потокоустойчивость данных также гарантируется. Использование глобальных и статических данных должно быть запрограммировано безопасным в смысле потоков образом.

Free – свободная потоковая модель (МТА). Объекты следует проектировать потокоустойчивыми.

Both – объект может работать в STA или в МТА, в зависимости от структуры клиента. Объекты должны быть абсолютно потокобезопасными.

Эти режимы задаются с помощью мастера ATL Object Wizard на вкладке Attributes (Single соответствует none).

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

если процесс имеет несколько STA, и объект в одном STA запрашивает доступ к объекту в другом STA, загружаются заглушки и прокси;

если объект в единственном процессе МТА хочет работать с объектом в STA, загружаются заглушки и прокси.

12. Облачные вычисления. Основные особенности и возможные проблемы.