Сущность технологии СОМ. Библиотека программиста

class GorillaClass : public IApe

{

public:

// class objects are singletons, so don't delete

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

// так что не удаляйте их

IMPLEMENTUNKNOWNNODELETE (GorillaClass)

BEGININTERFACETABLE(GorillaClass)

IMPLEMENTSINTERFACE(IApe)

ENDINTERFACETABLE()

// IApe methods

// методы IApe

STDMETHODIMP EatBanana(void);

STDMETHODIMP SwingFromTree(void);

STDMETHODIMP getWeight(long *plbs);

};

Если для данного класса C++ может существовать лишь один экземпляр (так ведут себя все объекты классов в СОМ), то в любом заданном экземпляре может быть только одна горилла (gorilla). Для некоторых областей одноэлементных множеств достаточно. В случае с гориллами, однако, весьма вероятно, что клиенты могут захотеть создавать приложения, которые будут использовать несколько различных горилл одновременно. Чтобы обеспечить такое использование, объект класса не должен экспортировать интерфейс IApe , а вместо этого должен экспортировать новый интерфейс, который позволит клиентам создавать новых горилл и/или находить известных горилл по их имени. Это потребует от разработчика определить два класса C++: один для реализации объекта класса и другой для реализации действительных экземпляров класса. Для реализации гориллы класс C++, который определяет экземпляры гориллы, будет реализовывать интерфейс IApe:

class Gorilla : public IApe

{

public:

// Instances are heap-based, so delete when done

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

IMPLEMENTUNKNOWN()

BEGININTERFACETABLE()

IMPLEMENTSINTERFACE(IApe)

ENDINTERFACETABLE()

// IApe methods

// методы IApe

STDMETHODIMP EatBanana(void);

STDMETHODIMP SwingFromTree(void);

STDMETHODIMP getWeight(long *plbs):

};

Второй интерфейс понадобится для определения тех операций, которые будет реализовывать объект класса Gorilla:

[object, uuid(753A8AAC-A7FF-11d0-8C30-0080C73925BA)]

interface IApeClass : IUnknown

{

HRESULT CreateApe([out, retval] IApe **ppApe);

HRESULT GetApe([in] long nApeID, [out, retval] IApe **ppApe);

[propget]

HRESULT AverageWeight([out, retval] long *plbs);

}

Получив это определение интерфейса, объект класса будет реализовывать методы IApeClass или путем создания новых экземпляров С++-класса Gorilla (в случае CreateApe), или преобразованием произвольно выбранного имени объекта (в данном случае типа integer) в отдельный экземпляр (в случае GetApe):

class GorillaClass : public IApeClass

{

public: IMPLEMENTUNKNOWNNODELETE(GorillaClass)

BEGININTERFACETABLE(GorillaClass)

IMPLEMENTSINTERFACE(IApeClass)

ENDINTERFACETABLE()

STDMETHODIMP CreateApe(Ape **ppApe)

{

if ((*ppApe = new Gorilla) == 0) return EOUTOFMEMORY;

(*ppApe)->AddRef();

return SOK;

}

STDMETHODIMP GetApe(long nApeID, IApe **ppApe)

{

// assume that a table of well-known gorillas is

// being maintained somewhere else

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

// поддерживается где-нибудь еще

extern Gorilla *grgWellKnownGorillas[];

extern int gnMaxGorillas;

// assert that nApeID is a valid index

// объявляем, что nApeID – допустимый индекс

*ррАре = 0;

if (nApeID > gnMaxGorillas || nApeID < 0) return EINVALIDARG;

// assume that the ID is simply the index into the table

// допустим, что ID – просто индекс в таблице

if ((*ppApe = grgWellKnownGorillas[nApeID]) == 0) return EINVALIDARG;

(*ppApe)->AddRef();

return SOK;

}

STDMETHODIMP getAverageWeight(long *plbs)

{

extern *grgWellKnownGorillas[];

extern int gnMaxGorillas;

*plbs = 0;

long lbs;

for (int i = 0; i < gnMaxGorillas; i++)

{

grgWellKnownGorillas[i]->getWeight(&lbs);

*plbs += lbs;

}

// assumes gnMaxGorillas is non-zero

// предполагается, что gnMaxGorillas ненулевой

*plbs /= gnMaxGorillas;

return SOK;

}

};

Отметим, что в этом коде предполагается, что внешняя таблица известных горилл уже поддерживается – или самими копиями Gorilla, или каким-нибудь другим посредником (agent).

Активация

Клиентам требуется механизм для поиска объектов класса. В силу динамической природы СОМ это может привести к загрузке библиотеки DLL или запуску обслуживающего процесса (server process). Эта процедура вызова объекта к жизни называется активацией объекта.

В СОМ имеется три модели активации, которые можно использовать для занесения объектов в память, чтобы сделать возможными вызовы методов. Клиенты могут попросить СОМ связать объект класса с данным классом. Кроме того, клиенты могут попросить, чтобы СОМ создала новые экземпляры классов, определенные с помощью CLSID. Наконец, клиенты могут попросить СОМ вызвать к жизни перманентный (persistent) объект, состояние которого определено как постоянное. Из этих трех моделей только первая (связывание с объектом класса) является абсолютно необходимой. Две другие модели являются просто оптимизациями обычно применяющихся способов активации. Дополнительные, определенные пользователем, модели активации могут быть реализованы в терминах одного (или более) из этих трех примитивов.

Каждая из описанных трех моделей активации пользуется услугами имеющегося в СОМ диспетчера управления сервисами SCM (Service Control Manager) [1]. SCM является основной точкой рандеву для всех запросов на активацию в каждой отдельной машине. Каждая хост-машина, поддерживающая СОМ, имеет свой собственный локальный SCM, который переадресовывает удаленные запросы на активацию на SCM удаленной машины, где этот запрос будет трактоваться как локальный запрос на активацию. SCM используется только для того, чтобы активировать объект и привязать к нему начальный указатель интерфейса. Как только объект активирован, SCM более не связан с вызовом методов клиента и объекта. Как показано на рис. 3.1, под Windows NT SCM реализован в службе RPCSS (Remote Procedure Call Service System – система сервиса удаленного вызова процедур). Службы SCM объявляются в программы как высокоуровневые типы моникеров [2] и как низкоуровневые API-функции, причем все они реализованы в библиотеке СОМ (как это называется в Спецификации СОМ). Под Windows NT большая часть библиотеки СОМ реализована в OLE32.DLL. Для повышения эффективности библиотека СОМ может использовать локальный или кэшированный режим, чтобы избежать ненужных запросов службы RPCSS со стороны IPC (interprocess communication – межпроцессное взаимодействие).

Напомним, что главным принципом СОМ является разделение интерфейса и реализации. Одной из деталей реализации, скрытых от клиента, является местонахождение реализации объекта. Невозможно определить, не только на каком хосте был активирован объект, но и был ли локальный объект активирован в клиентском процессе или в отдельном процессе на локальной машине. Это дает разработчикам объектов очень большую гибкость при решении того, как и где использовать реализации объектов, учитывая такие проблемы, как устойчивость к сбоям (robustness), обеспечение безопасности, распределение нагрузки и производительность. Клиент имеет возможность во время активации указать свои предпочтения относительно того, где будет активирован объект. Многие клиенты, однако, выражают свое безразличие к данному вопросу. В таком случае этот выбор сделает SCM, исходя из текущей конфигурации нужного класса.