Добрынин В.Ю. Технологии компонентного программирования

Подождите немного. Документ загружается.

CoJournalFactory::CoJournalFactory()

{

m_refCount = 0;

g_objCount++;

}

CoJournalFactory::~CoJournalFactory()

{

g_objCount--;

}

//IUnknown

STDMETHODIMP_(ULONG) CoJournalFactory::AddRef()

{

return ++m_refCount;

}

STDMETHODIMP_(ULONG) CoJournalFactory::Release()

{

if (--m_refCount == 0)

{

delete this;

return 0;

}

else

return m_refCount;

}

STDMETHODIMP CoJournalFactory::QueryInterface(REFIID riid, void** ppv)

{

if(riid == IID_IUnknown)

{

*ppv = (IUnknown*)this;

}

else if(riid == IID_IClassFactory)

{

*ppv = (IClassFactory*)this;

}

else

{

*ppv = NULL;

return E_NOINTERFACE;

}

((IUnknown*)(*ppv))->AddRef();

return S_OK;

}

//IClassFactory

STDMETHODIMP CoJournalFactory::CreateInstance(

LPUNKNOWN pUnkOuter, REFIID riid, void** ppv)

{

if(pUnkOuter != NULL)

{

return CLASS_E_NOAGGREGATION;

}

CoJournal* pJournalObj = NULL;

HRESULT hr;

pJournalObj = new CoJournal;

hr = pJournalObj->QueryInterface(riid, ppv);

if (FAILED(hr))

delete pJournalObj;

return hr;

}

STDMETHODIMP CoJournalFactory::LockServer(BOOL fLock)

{

if (fLock)

++g_lockCount;

else

--g_lockCount;

return S_OK;

}

Заканчивая разговор о фабрике класса нужно заметить, что для нее не нужно задавать GUID.

Се

ве

в п

оцессе клиента

Итак, для активации некоторого COM объекта необходимо создать фабрику класса для соответствующего класса и получить

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

IClassFactory. Далее, используя этот интерфейс, можно создать любое число экземпляров этого

кокласса и получить указатели на любые реализуемые коклассом интерфейсы. Но как создать фабрику класса?

Все, что достаточно знать клиенту о коклассе, это его глобальный идентификатор (GUID). Зная этот идентификатор, клиент

может воспользоваться функцией

CoGetClassObject, которая заставит менеджер управления сервисом найти и загрузить нужный

сервер (в котором ``живет'' нужный кокласс), активизировать фабрику класса для этого кокласса и возвратить клиенту указатель

на интерфейс IClassFactory.

Всю необходимую информацию менеджер получает из реестра системы. Подробнее это будет обсуждаться далее, пока

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

идентификатору кокласса можно узнать тип сервера, в котором этот кокласс ``живет'' (сервер в процессе клиента, сервер в другом

процессе на этой

же машине или сервер на удаленной машине), путь к серверу (для серверов на данной машине) или путь к

удаленной машине (для сервера на удаленной машине).

Далее работа менеджера зависит от типа сервера.

Пока мы строим сервер в процессе клиента, реализуемый в виде dll. Для этого, при работе в Visual C++, можно создать пустое

рабочее

пространство проекта Win32 DLL с именем PubInProcServer. В этом проекте нужно создать (или перенести созданные в

другом месте) классы

CoBook, CoJournal, CoBookFactory, CoJournalFactory. Там же должны находиться файлы с

определениями интерфейсов

IPub, IBook, IJournal, файл с GUID для всех интерфейсов и коклассов iid.h и (как советует

Э.Трельсен в книге [3]) следующий файл iid.cpp

// iid.cpp : гарантирует автоматический вызов <initguid.h>

// перед "iid.h"

#include <windows.h>

#include <initguid.h>

#include "iid.h"

Теперь нужно создать файл, имя которого совпадает с именем проекта - PubInProcServer.cpp:

#include "CoBookFactory.h"

#include "CoJournalFactory.h"

ULONG g_lockCount = 0;

ULONG g_objCount = 0;

STDAPI DllCanUnloadNow()

{

if (g_lockCount == 0 && g_objCount == 0)

return S_OK;

else

return S_FALSE;

}

STDAPI DllGetClassObject( REFCLSID rclsid,

REFIID riid, void** ppv)

{

HRESULT hr;

CoBookFactory* pBookFact = NULL;

CoJournalFactory* pJournalFact = NULL;

if (rclsid == CLSID_CoBook)

{

pBookFact = new CoBookFactory;

hr = pBookFact->QueryInterface(riid, ppv);

if (FAILED(hr))

delete pBookFact;

return hr;

}

else if (rclsid == CLSID_CoJournal)

{

pJournalFact = new CoJournalFactory;

hr = pJournalFact->QueryInterface(riid, ppv);

if (FAILED(hr))

delete pJournalFact;

return hr;

}

else

return CLASS_E_CLASSNOTAVAILABLE;

}

В файле PubInProcServer.cpp определяются и инициализируются нулем две глобальные переменные g_lockCount, g_objCount

- соответственно счетчики числа блокировок сервера в памяти и числа активных объектов.

Далее дается реализация двух экспортируемых из dll функций -

DllGetClassObject и DllCanUnloadNow. Используя первую, менеджер управления сервисом (из COM) сможет активизировать

фабрику класса запрашиваемого кокласса и получить указатель на интерфейс

IClassFactory соответствующей фабрики класса. Вторая функция используетя менеджером на этапе принятия решения об

удалении сервера из памяти.

Рассмотрим подробнее реализацию функции DllGetClassObject.

Эта функция получает в качестве аргументов ссылку на GUID нужного кокласса, ссылку на желаемый интерфейс фабрики класса

этого кокласса (обычно

IID_IClassFactory) и в качестве выходного параметра возвращает указатель на запрашиваемый

интерфейс. Возвращаемое функцией значение типа

HRESULT говорит об успехе или неудаче операции. В последнем случае можно

выяснить причину неудачи. Для проверки успешности операции можно использовать определенные в COM макроопределения

SUCCEEDED() и FAILED(), анализирующие старший бит возвращенного значения типа HRESULT.

Реализация функции

DllCanUnloadNow тривиальна.

Обычно dll сервер экспортирует еще две функции:

DllRegisterServer и DllUnregisterServer. Эти функиции должны

обеспечить саморегистрацию сервера в реестре. В данном курсе этот вопрос не рассматривается, и регистрация разрабатываемого

сервера будет проведена вручную с помощью редактора реестра.

Далее надо включить в проект стандартный DEF-файл

PubInProcServer.def, который перечисляет экспортируемые функции :

LIBRARY "PUBINPROCSERVER"

EXPORTS

DllGetClassObject @1 PRIVATE

DllCanUnloadNow @2 PRIVATE

Здесь название библиотеки должно совпадать с названием проекта. PRIVATE используется для того, чтобы компоновщик не

поместил имена этих функций в библиотеку импорта, т.к. они будут использоваться только COM.

Регистрация сервера в реестре

Теперь сервер готов, но для его использования необходимо внести некоторые данные в реестр системы. Сделаем это, используя

редактор реестра -

regedit.exe. Для внесения минимальной информации о сервере внесем в реестр следующие данные:

z CLSID и соответствующие ProgID и путь к серверу

Программный идентификатор (ProgID) используется некоторыми программами как некоторая замена CLSID (требуется

только локальная уникальность). Формат для ProgID -

имя_сервера.имя_кокласса. Для CoBook это PubInProcServer.CoBook.

Под ключем

HKEY_CLASSES_ROOT нужно найти ключ CLSID и под ним создать раздел {49F00760-7238-11d5-98C7-

000001223694}

. Это CLSID для кокласса CoBook. Для задания соответствующего ProgID следует для данного раздела

создать подраздел с именем ProgID и в качестве значения для параметра по умолчанию взять

PubInProcServer.CoBook.

Аналогично, под ключем

HKEY_CLASSES_ROOT CLSID нужно еще создать раздел {49F00761-7238-11d5-98C7-

000001223694}

. Это CLSID для кокласса CoJournal. Для задания соответствующего ProgID следует для данного раздела

создать подраздел с именем ProgID и в качестве значения для параметра по умолчанию взять

PubInProcServer.CoJournal.

Для задания пути к серверу (один сервер для двух коклассов), надо под ключем

HKEY_CLASSES_ROOT CLSID {49F00760-7238-11d5-98C7-000001223694} создать раздел InProcServer32 и в качестве

параметра по умолчанию задать полный путь к dll серверу.

Это же повторяется для CLSID кокласса

CoJournal.

z ProgID и соответствующий CLSID

Под ключем

HKEY_CLASSES_ROOT надо создать разделы

PubInProcServer.CoBook и PubInProcServer.CoJournal. Для каждого из построенных разделов создать подразделы

CLSID, где В качестве значения параметра по умолчанию задаются CLSID соответствующих коклассов.

Клиент

Теперь можно реализовать клиента для сервера PubInProcServer. Для этого можно в Visual C++ создать проект консольного

приложения

PubClient, куда перенести файлы iid.h, iid.cpp и все файлы с описаниями интерфейсов. Тем самым, клиент должен знать все

GUID используемых коклассов и их интерфейсов (не обязательно всех в данном классе, но всех, используемых данным

клиентом).

Сам клиент реализован в файле

PubClient.cpp

// PubClient.cpp -- клиент для сервера PubInProcServer

#include "IBook.h"

#include "IJournal.h"

#include "iid.h"

#include <iostream.h>

define MAX_ID 100 // максимальное число публикаций

int main()

{

CoInitialize(NULL); // инициализация COM

IClassFactory* pBF = NULL;

IClassFactory* pJF = NULL;

IBook* pIBook = NULL;

IJournal* pIJournal = NULL;

BSTR bstr;

char* pszText;

HRESULT hr;

int nNewID = 0;

IPub* aIPub[MAX_ID]; // массив указателей на

// публикации

bstr = SysAllocString(L"");

// Активация фабрики класса CoBookFactory и получение

// указателя на интерфейс IClassFactory этой фабрики (pBF)

hr = CoGetClassObject(CLSID_CoBook, CLSCTX_INPROC_SERVER,

NULL, IID_IClassFactory, (void**)&pBF);

if(FAILED(hr)) // в случае неудачи -- выход

return 0;

// Активация фабрики класса CoJournalFactory и получение

// указате на интерфейс IClassFactory этой фабрики (pJF)

hr = CoGetClassObject(CLSID_CoJournal, CLSCTX_INPROC_SERVER,

NULL, IID_IClassFactory, (void**)&pJF);

if(FAILED(hr)) // в случае неудачи -- выход

return 0;

// Активация нового экземпляра кокласса CoBook

hr = pBF->CreateInstance(NULL, IID_IBook, (void**)&pIBook);

// В случае успеха -- ввод данных

if (SUCCEEDED(hr))

{

SysReAllocString(&bstr, L"A.W.Troelsen");

pIBook->SetAuthor(bstr);

SysReAllocString(&bstr, L"COM and ATL 3.0");

pIBook->SetTitle(bstr);

pIBook->SetYear(2000);

aIPub[nNewID++] = pIBook;

}

// Активация нового экземпляра кокласса CoJournal

hr = pJF->CreateInstance(NULL, IID_IJournal,

(void**)&pIJournal);

// В случае успеха -- ввод данных

if (SUCCEEDED(hr))

{

SysReAllocString(&bstr,

L"The Journal of the Graph Theory");

pIJournal->SetTitle(bstr);

pIJournal->SetYear(2001);

pIJournal->SetNumber(1);

aIPub[nNewID++] = pIJournal;

}

// Активация нового экземпляра кокласса CoJournal

hr = pJF->CreateInstance(NULL, IID_IJournal,

(void**)&pIJournal);

// В случае успеха -- ввод данных

if (SUCCEEDED(hr))

{

SysReAllocString(&bstr, L"SIGIR");

pIJournal->SetTitle(bstr);

pIJournal->SetYear(1999);

pIJournal->SetNumber(12);

aIPub[nNewID++] = pIJournal;

}

// Удаление фабрик классов

pBF->Release();

pJF->Release();

// Вывод информации о всех публикациях

if(nNewID)

for(int id = 0; id < nNewID; id++)

{

SysFreeString(bstr);

aIPub[id]->GetInfo(&bstr);

pszText = (char*)malloc(2*SysStringLen(bstr));

wcstombs(pszText, bstr, 2*SysStringLen(bstr));

MessageBox(NULL, pszText, "Publication",

MB_OK|MB_SETFOREGROUND);

free(pszText);

}

// Удаление всех публикаций

if(nNewID)

for(int id = 0; id < nNewID; id++)

{

aIPub[id]->Release();

}

SysFreeString(bstr);

CoUninitialize(); // Завершение работы с COM

return 0;

}

Несколько замечаний к приведенной программе.

COM функция

CoGetClassObject имеет следующие параметры:

z Ссылка на идентификатор создаваемого кокласса

z Тип запрашиваемого сервера

CLSCTX_INPROC_SERVER означает, что запрашивается сервер в процессе клиента. Для локального сервера надо задать

CLSCTX_LOCAL_SERVER, и для удаленного - CLSCTX_REMOTE_SERVER. Можно комбинировать эти флаги для автоматического

выбора наиболее близкого сервера.

z В третьем параметре задается информация об удаленной машине при использовании удаленного сервера.

z Идентификатор запрашиваемого интерфейса

z Возвращаемый указатель на запрашиваемый интерфейс

Функция

MessageBox() используется для вывода информации о публикации в окне сообщений. Эту информация клиент получает

с сервера вызывае метод

GetInfo(). Память под возвращаемую BSTR-строку сервер выделяет сам, а клиент отвечает за ее

освобождение. Перед передачей информации в окно сообщений выполняется преобразование

BSTR-строки в ANSI-строку.

зык описания интерфейсов и библиотека типов

Теперь обратимся к вопросам о языковой независимости и прозрачности местоположения. Как уже ранее упоминалось, это

принципиальные для COM требования.

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

языке программирования (в частности, C++ и Visual Basic). Однако описанные ранее интерфейсы (файлы IPub.h, IBook.h и

IJournal.h) представлены на C++. Это означает, что любой

разработчик, желающий реализовать эти интерфейсы в своем коклассе,

должен использовать именно C++. Более неприятно, что и любой клиент, желающий использовать построенные таким образом

компоненты, также должен быть написан на C++.

Прозрачность местоположения означает, что код клиента не должен меняться в зависимости от того, где размещен используемый

клиентом компонент (либо это dll, загружаемая в адресное

пространство клиента, либо это exe-сервер, исполняемый в другом

процессе на той же машине, где исполняется клиент, либо компонент установлен на удаленном компьютере). Конечно, клиент

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

использоваться тот сервер, связь с которым для

этого клиента будет наиболее быстрой. В случае исполнения сервера и клиента в

разных процессах необходимо обеспечить передачу данных между этими процессами. Прозрачность местоположения означает,

что COM берет это на себя.

Что нужно для обеспечения независимости от языка и прозрачности местоположения? Нужно описать все интерфейсы и классы

некоторым стандартным образом, сделав эти описания

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

обеспечит языковую независимость. Для обеспечения прозрачности местоположения нужно иметь возможность автоматически

формировать посредников, обеспечивающих взаимодействие клиента и сервера, выполняющихся в различных процессах. В COM

такой посредник на стороне клиента называется прокси, а посредник на стороне сервера называется заглушкой. Они реализуются

в виде компонент,

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

непосредственного взаимодействия друг с другом (в одном адресном пространстве). В действительности прокси и заглушка

реализуют удаленный вызов процедур, используя протокол LRPC или RPC соответственно при расположении на одной или

азличных машинах.

Итак, C++ не годится для описания интерфейсов в связи с тем, что в этом языке много неоднозначностей, которые, конечно,

успешно разрешаются компилятором с C++, но в которых не смогут разобраться компиляторы с других языков. Нужен

специальный язык, на котором можно однозначно описать все интерфейсы и классы. Это язык описания интерфейсов IDL -

Interface Definition Language, первоначально описанный

в спецификации DCE (Distributed Computing Environment -

распределенная среда вычислений) от Open Software Foundation и далее расширенный Microsoft. На нем описываются все

коклассы и все реализуемые в них интерфейсы, которые будут входить в создаваемый компонент. При этом нет необходимости

описывать ранее описанные интерфейсы (например, стандартные). Достаточно включить их описания с помощью ключевого

слова

import. Наряду с описанием коклассов и интерфейсов надо описать так называемую библиотеку типов. Именно эта

библиотека и будет решать проблему языковой независимости. Она будет в бинарном виде хранить информацию о всех

интерфейсах и классах данного компонента в форме, доступной для чтения компиляторами со всех поддерживающих COM

языков.

Далее idl-файл с описанием интерфейсов, классов и библиотеки типов транслируется транслятором MILD (Microsoft IDL) в

совокупность файлов, содержащих объявления на C++/C всех интерфейсов, определения GUID для всех интерфейсов и классов,

коды прокси и заглушки, а также формируется в бинарном виде библиотека типов. Используя эти файлы можно построить dll для

прокси и заглушки. При реализации клиента или сервера на C++/C можно использовать полученные файлы

с описаниями

интерфейсов и определениями GUID, при использовании других языков программирования, будет использоваться библиотека

типов.

Далее приведен файл

PubInProcServerTypeInfo.idl, дающий описания на IDL интерфейсов, классов и библиотеки типов для

проекта

PubInProcServer.

import "oaidl.idl";

//IPub

[object,

uuid(9A5DE9A0-7225-11d5-98C7-000001223694),

helpstring("Base publication")]

interface IPub : IUnknown

{

HRESULT SetTitle([in] BSTR bstrTitle);

HRESULT SetYear([in] int nYear);

HRESULT GetInfo([out, retval] BSTR* pbstrInfo);

};

//IBook

[object,

uuid(9A5DE9A1-7225-11d5-98C7-000001223694),

helpstring("Book")]

interface IBook : IPub

{

HRESULT SetAuthor([in] BSTR bstrAuthor);

}

//IJournal

[object,

uuid(9A5DE9A2-7225-11d5-98C7-000001223694),

helpstring("Journal")]

interface IJournal : IPub

{

HRESULT SetNumber([in] int nNumber);

}

[uuid(68A702C2-8283-11d5-98C7-000001223694),

version(1.0),

helpstring("PubInProcServer with TypeLib")]

library PubInProcServer

{

importlib("stdole32.tlb");

[uuid(49F00760-7238-11d5-98C7-000001223694)]

coclass CoBook

{

[default] interface IBook;

};

[uuid(49F00761-7238-11d5-98C7-000001223694)]

coclass CoJournal

{

[default] interface IJournal;

};

Видно, что данный файл весьма похож на заголовочный файл в C++. Основное отличие - наличие атрибутов в квадратных

скобках.

Конструкция

import "oaidl.idl"; обеспечивает импорт ряда стандартных описаний (в том числе, интерфейса IUnknown). Далее

идут описания всех реализуемых в компоненте пользовательских интерфейсов:

IPub, IBook и IJournal.

Описанию каждого интерфейса предшествует совокупность атрибутов, начинающаяся с атрибута

object. Именно этот атрибут

говорит о том, что далее идет описание интерфейса COM, а не интерфейса RPC, для описаний которых и создавался

первоначально IDL.

Атрибут

uuid используется для задания GUID соответствующего интерфейса.

Атрибут helpstring позволяет приписать описываемому интерфейсу некоторую строку, которая будет храниться в библиотеке

типов и может использоваться различными программами для представления пользователю информации о семантике данного

интерфейса.

При описании методов интерфейсов используются атрибуты

in, out, retval, позволяющие указать направление передачи

значения параметра. Атрибут

in назначается по умолчанию и означает, что значение данного параметра передается серверу.

Напротив, атрибут

out говорит о необходимости передачи значения параметра клиенту. Атрибут retval означает, что для

данный параметр является возвращаемым значением для соответствующей функции при использовании, например, Visual Basic.

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

После описания всех интерфейсов описывается библиотека типов (ключевое слово

library). В качестве атрибутов для

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

guidgen.exe), номер

версии и

helpstring.

Оператор

importlib("stdole32.tlb") должен быть первым среди всех операторов библиотеки. Он задает импорт стандартной

двоичной библиотеки типов

stdole32.tlb.

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

uuid задается его

GUID и перечисляются все его интерфейсы (последние в иерархии интерфейсов). Один из интерфейсов каждого кокласса

объявляется как интерфейс по умолчанию (с помощью атрибута default). Это необходимо для Visual Basic. При инициализации

экземпляра данного класса именно ссылка на интерфейс по умолчанию будет возвращена клиенту. При отсутствии атрибута

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

В данном примере отражены далеко не все возможности языка IDL и некоторые из них будут обсуждены далее. А сейчас

рассмотрим использование сформированного idl-файла.

Добавим файл

PubInProcServerTypeInfo.idl в проект PubInProcServer и откомпилируем. В результате будут получены

несколько файлов. Для сервера в процессе клиента, который мы реализуем в данное время, прокси и заглушка не нужны. В связи

с этим включим в проект из всех файлов, сгенерированных транслятором MILD, только PubInProcServerTypeInfo.h,

содержащий определения всех интерфейсов на C++/C, и файл

PubInProcServerTypeInfo_i.c, содержащий определения уникальных идентификаторов для всех интерфейсов и коклассов.

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

определявшие интерфейсы и GUID. Это файлы

IPub.h, IBook.h, IJournal.h, iid.h, iid.cpp. Во всех оставшихся файлах

надо удалить ссылки на удаленные файлы. В файлы

CoBook.h, CoJournal.h надо добавить строку

#include "PubInProcServerTypeInfo.h"

Аналогичные изменения необходимо сделать в клиенте CoPubClient.

Последнее действие - добавление новых данных в реестр. Именно, надо зарегистрировать библиотеку типов -

PubInProcServerTypeInfo.tlb. Для этого в реестр системы необходимо внести следующую информацию:

z Под ключом HKEY_CLASSES_ROOT TypeLib надо создать раздел

{68A702C2-8283-11d5-98C7-000001223694} - GUID библиотеки типов.

z Для нового раздела создать подраздел 1.0 - номер версии. В качестве значения параметра по умолчанию можно взять

название компонента -

PubInProcServer.

z Для только что созданного раздела 1.0 создать подраздел 0 - идентификатор языка (естественного).

z Для только что созданного раздела 0 создать 3 подраздела:

{ Win32 - в качестве значения параметра по умолчанию надо указать путь к библиотеке типов (к файлу

PubInProcServerTypeInfo.tlb)

{ FLAGS - значение параметра по умолчанию ``0''

{ HELPSTRING - значение параметра по умолчанию - путь к файлу помощи (если таковой имеется)

z И последнее, ссылку на библиотеку типов надо разместить под ключами

HKEY_CLASSES_ROOT CLSID {49F00760-7238-11d5-98C7-000001223694} и

HKEY_CLASSES_ROOT CLSID {49F00761-7238-11d5-98C7-000001223694}. Для этого под указанными ключами создаются

разделы

TypeLib, где в качестве значения параметра по умолчанию указывается GUID библиотеки типов для компонента, в

котором размещены оба класса.

Теперь компонент, созданные в проекте

PubInProcServer, включает библиотеку типов PubInProcServerTypeInfo.tlb и,

следовательно, может использоваться клиентами, реализованными на других языках, поддерживающих COM. Например, в Visual

Basic достаточно установить ссылку на библиотеку типов нашего компонента и можно создавать экземпляры коклассов CoBook и

CoJournal, получая по умолчанию ссылки на интерфейсы IBook и IJournal.

Для проверки того, что сформированная библиотека типов

PubInProcServerTypeInfo.tlb действительно содержит всю информацию, содержавшуюся ранее в idl-файле

PubInProcServerTypeInfo.idl, можно воспользоваться OLE/COM Object Viewer, с помощью которого можно увидеть все классы

из компонента

PubInProcServer, их интерфейсы, методы этих интерфейсов и их сигнатуры.

Далее надо иметь ввиду, что разработка любого компонента должна начинаться с формирования соответствующего idl-файла.

Нарушение этого требования в данном случае определялось методическими задачами.

Библиотека типов доступна для чтения не только OLE/COM Object Viewer. Имеются интерфейсы

ITypeLib и ITypeInfo с

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

библиотеке типов.

Интерфейс

ITypeLib используется при получении информации общего характера о библиотеке типов. Интерфейс ITypeInfo

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

Рассмотрим следующую задачу - по заданному GUID библиотеки типов вывести описание (helpstring) для всех описанных в

библиотеке объектов.

// test.cpp -- чтение библиотеки типов PubInProcServerTypeInfo.tlb

#include <iostream.h>

#include <windows.h>

const GUID LIBID_PubInProcServer =

{0x68A702C2,0x8283,0x11D5,

{0x98,0xC7,0x00,0x00,0x01,0x22,0x36,0x94}};

int main()

{

int count;

HRESULT hr;

char* pszName, *pszDoc;

BSTR bstrName, bstrDocString;

ITypeLib* pTypeLib;

CoInitialize(NULL);

hr=LoadRegTypeLib(LIBID_PubInProcServer, 1, 0, LANG_NEUTRAL,

&pTypeLib);

if(SUCCEEDED(hr))

{

count = pTypeLib->GetTypeInfoCount();

for (int index=-1; index < count; index++)

{

hr = pTypeLib->GetDocumentation(index,

&bstrName, &bstrDocString, NULL, NULL);

if (SUCCEEDED(hr))

{

pszName = (char*)malloc(2*SysStringLen(bstrName));

wcstombs(pszName, bstrName, 2*SysStringLen(bstrName));

cout << index << " : " << pszName;

free(pszName);

if (SysStringLen(bstrDocString)>0)

{

pszDoc = (char*)malloc(2*SysStringLen(bstrDocString));

wcstombs(pszDoc, bstrDocString,

2*SysStringLen(bstrDocString));

cout <<" : " << pszDoc;

free(pszDoc);

}

cout << endl;

SysFreeString(bstrName);

SysFreeString(bstrDocString);

}

pTypeLib->Release();

}

CoUnitialize();

return 0;

}

Для определенности рассматривается библиотека типов, сформированная по IDL-файлу PubInProcServerTypeInfo.idl. В

константе

LIBID_PubInProcServer задается GUID данной библиотеки типов.

Функция

LoadRegTypeLib() загружает библиотеку типов с заданным GUID и, в случае успеха, в параметре pTypeLib возвращает

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

ITypeLib. В данном случае нам достаточно этого интерфейса, так как интересующая нас информация

является информацией общего характера о библиотеке типов. Второй (старший номер версии) и третий (младший номер версии)

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

версией; если такой нет, то загружается библиотека, у которой

старший номер версии равен запрашиваемому, а младший -

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

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

естественный язык.

В регистре всему этому соответствует ключ

HKEY_CLASSES_ROOT TipeLib

{68A702C2-8283-11d5-98C7-000001223694} 1.0 0 win32

значением которого является путь к файлу

PubInProcServerTypeInfo.tlb.

В данной программе вызываются всего два метода из всего множества методов интерфейса

ITypeLib:

z GetTypeInfoCount()

Возвращает число описаний типов в библиотеке

z GetDocumentation()

По номеру описания типа позволяет получить имя типа, его описание (helpstring), идентификатор контекста помощи и путь

к файлу помощи. Подставляя NULL вместо определенного возвращаемого параметра, можно отказаться от получения

соответствующей информации. Нумерация описанных в библиотеке типов начинается с нуля. Для получения информации о

самой библиотеки нужно положить индекс равным -1.

Вся строковая информация в библиотеке типов хранится в строках типа

BSTR. Функция GetDocumentation сама выделяет под них

память, а клиент должен ее освободить

SysFreeString(bstrName);

SysFreeString(bstrDocString);

Для перехода к ANSI строкам приходится выделять буфер подходящего размера и выполнять преобразование из BSTR в ANSI с

помощью

wcstombs.

Результат работы программы:

-1 : PubInProcServer : PubInProcServer with TypeLib

0 : CoBook

1 : IBook : Book

2 : IPub : Base publication

3 : CoJournal

4 : IJournal : Journal

Под индексом -1 приведены имя самой библиотеки типов (как она была описана в IDL) и соответствующая строка документации

(helpstring).

Под индексами от 0 до 4 идут имена типов - коклассов и их интерфейсов. Строка документации приводится только для тех из

них, для которых она имеется в IDL-файле.

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

документации, включенной в библиотеку типов.

Следовательно, можно организовать поиск компонент с нужной функциональностью на основе задания одного или нескольких

ключевых слов.

Прозрачность местоположения

DLL сервер в суррогатном процессе

Как уже не раз говорилось ранее, один из важнейших принципов COM - прозрачность местоположения. Иными словами, на код

клиента не должно оказывать влияние конкретное местоположение сервера (конечно при условии, что этот сервер

зарегистрирован в реестре системы).

Ранее мы построили и зарегистрировали сервер в процессе клиента

PubInProcServer и самого клиента PubClient. Сервер,

загружаемый в процесс клиента, обладает как положительными, так и отрицательными свойствами. К положительным можно

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

тому, что клиент ``вылетает'' при сбое сервера.

В рамках архитектуры COM наряду с сервером в процессе клиента можно строить локальный сервер (

исполняется в отдельном

процессе на машине клиента) и удаленный сервер (исполняется на удаленном компьютере). При наличии уже реализованного

сервера в виде сервера в процессе клиента, его можно превратить в сервер, исполняемый вне процесса клиента, загружая в

специальный процесс - DLL суррогат. Имеется стандартный DLL суррогат (

dllhost.exe), который можно использовать для этой

цели.

В рамках COM+ использование DLL суррогата наиболее предпочтительно, так как именно в этом случае сервер сможет

использовать все сервисы, предоставляемые COM+. Однако, при этом необходимо конфигурировать сервер, определив ряд

связанных с ним атрибутов в новой структуре данных - каталоге. Эти вопросы будут рассмотрены позже при изучении COM+.

Итак, далее

мы рассмотрим размещение сервера PubInProcServer в суррогатном процессе.

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

связанных с идентификатором приложения - AppID.

Здесь мы уже приближаемся к идеологии COM+. В архитектуре COM на верхнем уровне стоит сервер, который может содержать

несколько классов, каждый из которых реализует несколько интерфейсов. При этом уникальные идентификаторы (GUID)

назначаются только

классам, интерфейсам, библиотекам типов, но не серверам. В COM+ на верхнем уровне находится

приложение, которое может содержать несколько классов (размещенных, конечно, в серверах), которые, в свою очередь,

еализуют несколько интерфейсов.

В отличие от сервера, приложение имеет уникальный идентификатор AppID, что позволяет связывать с ним различные атрибуты.

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

В качестве GUID для приложения можно взять GUID одного из классов, входящих в состав приложения. Например, первого

класса, описанного в idl-файле.

Для занесения информации о AppID надо в реестре под ключом

HKEY_CLASSES_ROOT AppID завести новый раздел с GUID данного приложения. В этом разделе можно задавать различные

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

DllSurrogate и с пустым

значением. Это означает, что приложение с данным AppID должно выполняться в стандартном суррогатном процессе

(

dllhost.exe).

Теперь надо связать все входящие в приложение классы с данным AppID. Для этого под ключом

HKEY_CLASSES_ROOT CLSID clsid_данного_класса надо завести дополнительный строковый параметр AppID со значением

равным

AppID нашего приложения. Это надо повторить для всех классов нашего приложения.

Клиент

PubClient был жестко ориентирован на работу с сервером в процессе клиента. Эта ориентация задавалась при активации

фабрики класса. Например,

hr = CoGetClassObject(CLSID_CoBook, CLSCTX_INPROC_SERVER,

NULL, IID_IClassFactory, (void**)&pBF);

Параметр CLSCTX_INPROC_SERVER задает использование именно сервера в процессе клиента. Для загрузки сервера в суррогатный

процесс достаточно заменить этот параметр на

CLSCTX_LOCAL_SERVER для обоих задействованных в приложении классов: CoBook

CoJournal.

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

(

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

только путь к DLL, реализующей сервер в процессе клиента - параметр

InProcServer32. Однако, для данного класса имеется и

параметр

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

данное приложение, система обнаруживает, что требуется загрузка сервера в суррогатный процесс - параметр

DllSurrogate.

Стандартный маршалинг

Итак, клиент будет размещен в одном процессе, а сервер в другом. Как же будут осуществляться вызовы методов, передача

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

сервер находились в одном адресном пространстве.

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

заглушки.

В COM прокси является объектом, который агрегирован в еще один объект - менеджер прокси. Менеджер прокси загружен в

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

интерфейс удаленного объекта имитируется своим прокси и все эти прокси агрегированы менеджером прокси. Таким образом,

клиент может напрямую вызывать

методы удаленного объекта как и в случае сервера в пространстве клиента. Конечно,

реализация методов удаленного объекта не полная. Реально прокси принимает вызов клиента, кодирует и пакетирует его и

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

пакеты принимает заглушка, в чьи функции входит распаковка

вызова и передача его серверу. Таким образом, и для сервера

создается иллюзия того, что клиент находится в одном с ним адресном пространстве.

Процесс упаковки, передачи и распаковки при вызове метода удаленного объекта и называется маршалингом. В COM имеется

три типа маршалинга:

z Пользовательский маршалинг

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

передачи данных. Для реализации пользовательского маршалинга надо реализовать станартный интерфейс

IMarshal,

выбрать и реализовать протокол передачи данных.

z Стандартный маршалинг

Здесь используются прокси и заглушки, взаимодействующие друг с другом по протоколу ORPC (Object RPC). Причем, если

для описания интерфейсов используется IDL, от программиста не требуется писать какой-либо код. Компилятор с IDL -

Microsoft IDL (MIDL) генерирует несколько файлов с кодами прокси и заглушки. Используя их можно построить DLL,

которая после регистрации и обеспечит маршалинг для описанных в IDL-

файле интерфейсов.

z Универсальный маршалинг

В этом случае не нужно даже строить DLL заглушки/прокси. Эта DLL строится ``на лету''. Необходимые условия:

{ в методах интерфейсов используются параметры только так называемых variant-совместимых типов (некоторое

подмножество типов, допустимых в IDL);

{ в IDL файле интерфейсы описаны с атрибутом oleautomation;

{ имеется зарегистрированная библиотека типов, в которой описаны интерфейсы;

{ информация об интерфейсах включена в реестр под ключом

HKEY_CLASSES_ROOT Interface.

Возможность универсального маршалинга связана с тем, что для всех стандартных интерфейсов код маршалинга уже

существует. При использовании упомянутого ограниченного набора типов этот код может использоваться для

автоматического

ми

ования кода ма

шалинга нового инте

рф

ейса.