Деревянко_БС ЭВМ

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

3.Универсальный маршалинг базируется системной DLL - oleout.dll, не требуется строить собственную DLL заглушки/прокси. Все параметры методов интерфейса должны

иметь variant – совместимый тип. Для С++ это большин-

ство основных типов: double, float, long, short и

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

1) каждый интерфейс в idl-файле надо снабдить атри-

бутом [oleautomation];

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

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

Пример:

ITypeLib * pTLib = NULL;

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

pTLib -> Release();

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

41

1.3.3. Построение локального СОМ-сервера

Здесь рассматриваются особенности разработки локального (EXE) сервера, по сравнению с внутрипроцессным сервером.

Сначала регистрируются фабрики класса. Для регистрации SCM предоставляет клиенту указатели на IClassFactory, беря информацию из таблицы объекта класса. Локальный сервер для каждой фабрики класса записывает информацию в таблицу объекта класса (class object table),

используя функцию CoRegisterClassObject().

Пример:

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

CoRegisterClassObject( CLSID_Coclass, //CLSID кокласса,

создаваемого данной фабрикой класса

(IClassFactory) &CarClassFactory,

// указатель на интерфейс фабрики класса

CLSCTX_LOCAL_SERVER, //объект

//кокласса может использоваться только //внешними клиентами,

//значение обязательно для локального

//или удаленного доступа.

REGCLS_MULTIPLEUSE, // несколько

//клиентов могут работать с одним сервером &regID //указатель на возвращаемый ID

);

Таких вызовов CoRegisterClassObject() должно быть столько, сколько объектов класса содержится в EXEсервере. Когда EXE-приложение заканчивает работу, нужно

42

сделать столько же вызовов CoRevokeClassObject(). SCM благодаря этому узнает, что объект класса стал недоступен. SCM удаляет фабрику класса из таблицы класса.

Единственный параметр этой функции – регистрационный ID, полученный последним параметром CoRegisterClassObject():

CoRevokeClassObject(regID);

В отличие от сервера DLL, EXE-сервер сам отвечает за свое удаление из памяти в случае активных объектов. Пока есть объекты, EXE-сервер сидит в памяти. Самый простой способ оставления программы в памяти – бесконечный цикл с выходом из цикла по получении сообщения (WM_QUIT). Это сообщение посылается, когда серверный счетчик для подсчета активных объектов и блокировок станет равным нулю.

Последний шаг – регистрация локального СОМсервера. Для этого после сборки EXE-сервера требуется изменить REG-файл: установить подключ LocalServer32 вме-

сто InprocServer32.

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

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

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

43

1.3.5. Безопасность в СОМ

Безопасность в СОМ основывается на модели безопасности NT. Каждый раз, когда пользователь регистрируется на рабочей станции, он задает свое имя и пароль. Система присваивает идентификатор доступа (security ID, SID) каждому пользователю, который может входить в локальные или глобальные группы, такие как Администраторы, Пользователи и Привилегированные пользователи. Утилита User Manager позволяет администратору системы изменять состав этих групп.

Идентификатор доступа SID может также использоваться для задания установок защиты данного ресурса. Информация о правах доступа хранится в управляющем списке полномочий по доступу (Discretionary Access Control List, DACL).

DACL применяется для установки следующих трех основных параметров защиты.

1.Аутентификация. Вы тот, за кого себя выдаете?

2.Управление доступом. Кто может использовать и/или запускать этот СОМ-сервер.

3.Назначение сервера.

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

Аутентификация – это действие по установлению личности DCOM-клиента. NT обеспечивает аутентификацию че-

рез Security Support Provider (SSP) в ОС Windows.

Аутентификация удаленного клиента происходит на уровне пакета. Пакет служит единицей измерения: как часто SSP должен проводить аутентификацию.

СОМ поддерживает следующие уровни аутентифика-

ции:

None – аутентификация клиента не производится;

Connect – аутентификация только при установлении связи по RPC;

44

Call – аутентификация для первого присланного пакета;

Packet – проверка клиента для каждого присланного пакета;

Packet Integrity – аутентификация и проверка признака появления ошибок при передаче данных.

Packet Privacy – уровень Packet Integrity и шифрова-

ние.

Управление доступом

Списки ACL могут создаваться для следующих категорий доступа:

Разрешение на доступ. Включенные в этот список ACL пользователи имеют право вызывать методы на удаленном сервере. Если пользователи отсутствуют в списке, то им не разрешается доступ к активному СОМ-серверу.

Разрешение на запуск. Пользователь имеет право запускать новые экземпляры СОМ-сервера. Любой пользователь из этого списка имеет также и разрешение на доступ.

Разрешение на конфигурирование. Задает, кто имеет право изменять указанные списки ACL для заданного

AppID.

Установка назначения сервера

При запуске сервера системе СОМ надо знать тип пользователя, запускающего сервер (назначение сервера). Это значение поля RunAs для AppID.

Интерактивный пользователь. Все СОМ-серверы запускаются под идентификатором зарегистрировавшегося пользователя. Это единственная установка,

45

содержит идентификатор интерфейса, указатель на него и код ошибки для данного вызова QueryInterface().

Эти структуры определяются в файле <wtypes.h> следующим образом:

type struct_COSERVERINFO

{

DWORD dwReserved1; // резерв (NULL) LPWSTR pwszName; // Имя компьютера COAUTHINFO *pAuthInfo;

// Установки аутентификации

DWORD dwReserved2; // резерв (NULL)

}COSERVERINFO

Поле LPWSTR определяет удаленный компьютер сер-

вера в форме UNC, DNS или IP – адреса. UNC (Universal Naming Convention) – это описание пути строкой формата

"\\сервер\общая_точка\…путь…\имя_файла.расширение".

typedef struct _MULTI_QI

{

const IID* pIID; // Идентификатор

//интерфейса, который хотим получить IUnknown* pItf; // Указатель на этот

//интерфейс

HRESULT h2; // Код ошибки для данного

// вызова QueryInterface() } MULTI_QI;

47

Пример клиента на DCOM.

void main( )

{

CoInitialize (NULL); COSERVERINFO csi = {0}; csi.pwszName = L"SERVERMACH";

//Должен быть Unicode

//Хотим получить 3 интерфейса

MULTI_QI qi[3] = {0}; qi[0].pIID = &IID_IEngine;

. . .

//Создаем удаленный CoCar

CoCreateInstanceEx(CLSID_CoCar, //СLSID объекта

NULL,

CLSCTX_REMOTE_SERVER, //CLSCTX csi, // информация о сервере 3, // Колич. элементов в массиве qi qi); // Массив типа MULTI_QI

//Запоминаем полученные указатели интерфейсов

IEngine* pEngine = (IEngine*) qi[0].pItf;

// Можно проверить полученный HRESULT

. . .

pEngine -> GetMaxSpeed();

. . .

}

48

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

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

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

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

реализация IUnknown, (и QueryInterface());

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

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

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

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

предоставление минимального IDL-кода.

1.3.7. Потоковые модели СОМ

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

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

49

ты данных от повреждения в Win32 могут использоваться такие средства, как критические сегменты, диспетчеры (mutex) или семафоры.

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

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

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

иполучит доступ к содержащимся в нем СОМ-объектам.

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

Для управления доступом к объектам сервера в модели СОМ введено понятие «апартамент» (apartment). Апартамент

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

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

Чтобы обеспечить более быстрый доступ в случае мно-

50