Характеристика СОМ-сервера

Содержание:

Введение

Во многих областях науки и производства используется активно программное обеспечение (ПО), являющееся неотъемлемой составляющей коммерческих и специальных информационно-управляющих систем (ИУС),. Но в силу многих причин создать абсолютно безупречный, совершенный программный продукт чрезвычайно сложно [1].

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

Функционирование системы независимо от скрытых ошибок отдельных версий обеспечивается посредством мультиверсионности исполнения программных компонентов. При этом к основному достоинству этого программного обеспечения относится то, что произойти сбой системы может только в единственном случае - в случае сбоя существенного числа модулей. В информационно-управляющих системах мультиверсионное программирование предполагает, что в функционально эквивалентных модулях возникновение сбоя происходит в различных точках, за счет этого можно сбой обнаружить и исправить. Основой мультиверсионного программного обеспечения является независимость сбоев различных модулей [2].

Теоретические основы технологии «СОМ»

• 1. Сущность и назначение технологии «СОМ»

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

Выделяют две основные черты компонентов:

1. динамически связанная - связь компонента и приложения (связь между вызовом функции в приложении, ее кодом в теле компонента) осуществляется не на этапе компоновки приложения, а непосредственно во время выполнения.

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

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

Модификация или расширение компонента (приложения) сводится к замене одного из его компонентов новой версией.

Если приложение состоит из компонентов, оно может быть распределенным, к этому располагают 2 особенности:

3. приложение уже разделено на составные части, которые могут находиться в частности на различных ЭВМ;

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

Приложения, использующие компонент, являются клиентом для данного компонента, при этом компонент подключается к приложению клиенту при помощи единого стандартного интерфейса. В современных версиях Windows в качестве такого интерфейса используется технология СОМ.

Оба эти определения имеют право на существование COM (Component Object Model) - модель многокомпонентных объектов, позволяющая приложению манипулировать удаленными программными объектами, точнее вызывать те или иные функции (методы) этих объектов так, как будто эти объекты находятся «рядом».

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

 Рис.1. Схема СОМ – стандарта

Интерфейс СОМ включает в себя набор функций, которые реализуются компонентами и используются клиентами. Интерфейсом СОМ является определенная структура, содержащая в памяти массив указателей на функции, имеющиеся в компонентах, зарегистрированных в системе. Для организации взаимодействия между частями распределенного приложения, расположенного на различных ЭВМ, технология СОМ использоваться не может. Связано это с тем, что у ЭВМ, работающих раздельно нет общей области памяти, в которой мог бы располагаться интерфейс СОМ. Для организации распределенного взаимодействия компонентов используется технология DCOM (Distributed Component Object Model) (модель распределенных многокомпонентных объектов).

DCOM - программная архитектура, используемая для организации взаимодействия программных компонентов, расположенных на нескольких компьютерах сети (рис.2).

Рис.2. Схема DCOM - стандарта

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

• 1. Характеристика СОМ-сервера

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

- внутренний (In-process server); 

- локальный (Local server) или сервер вне процесса (Out-of-process server); 

- удаленный (Remote server). 

Внутренний сервер представляет собой библиотеку DLL, запущенную вместе с клиентом в одном процессе. Например, внедренный на Web-страницу элемент управления ActiveX, который можно просматреть при помощи Internet Explorer или Netscape Navigator. Элемент управления ActiveX в данном случае загружен на клиентскую машину, поэтому он находится в одном процессе с и обозревателем Web. С сервером внутри процесса приложение-клиент связывается при помощи прямых вызовов СОМ-интерфейса. На рис. 3. Изображено схематично взаимодействие клиента с внутренним сервером. 

Рис. 3. Схема взаимодействия клиента с внутренним сервером 

При этом экспортировать внутренний СОМ-сервер должен следующие функции: 

1. function DllRegisterServer: HResult; stdcall; 
2. function DllUnregisterServer: HResult; stdcall; 
3. function DllGetClassObject (const CLSID, IID: TGUID; var Obj): HResult; stdcall; 
4. function DllCanUnloadNow: HResult; stdcall; 

В модуле comserv эти функции уже реализованы, необходимо только добавить их в описание exports реализуемого проекта. 

Функция DllRegisterServer используется в системном реестре Windows для регистрации DLL СОМ-сервера. При регистрации в системном реестре СОМ-класса создается раздел в HKEY_CZASSES_ROOT\CLSID\ {XXXXXXXX-XXXX-XXXX-xxxx-xxxxxxxx}, где число, записанное вместо символов х, представляет собой CLSID данного СОМ-класса. В данном разделе для внутреннего сервера происходит создание дополнительного подраздела inProcserver32., в котором указывается путь к DLL внутреннего сервера (рис. 4). 

Рис. 4. Путь в окне редактора системного реестра к локальному СОМ-серверу 

Для удаления всех разделов, подразделов и параметров, созданных созданы в системном реестре функцией при регистрации DLL СОМ-сервера, применяется функция DllRegisterServer. - DllUnregisterServer - применяется

Для конкретного СОМ-класса возвращает фабрику класса функцияDllGetclassObject.

Применение функции DllcanUnloadNow позволяет определить: возможно ли выгрузить DLL СОМ-сервера из памяти в настоящий момент времени. Функция проверяет наличие указателей данной DLL на любой СОМ-объект,. При отрицательном варианте, т. е. DLL выгрузить нельзя, возвращает значение S_FALSE. При положительном варианте, означающем, что данной DLL не используется ни один СОМ-объект, функция возвращает значение SJTRUE. 

Локальный сервер является ЕХЕ-приложением, запущенным на одном компьютере вместе с клиентом, но в другом процессе. В качестве примера можно рассмотреть связанный с документом Microsoft Word лист электронной таблицы Microsoft Excel. Работают эти два разных приложения на одном компьютере. Для соединения с клиентом локальные серверы используют СОМ. 

Когда клиент и сервер находятся в различных приложениях, а также, когда они находятся на разных компьютерах в сети, СОМ использует внутренний (внутрипроцессный) прокси (In-process proxy) для реализации процедуры удаленного вызова. Прокси располагается в одном процессе вместе с клиентом, поэтому, с точки зрения клиента, вызов интерфейсов осуществляется так же, как и в случае, когда клиент и сер'вер находятся внутри одного процесса. Задача прокси заключается в том, чтобы перехватывать вызовы клиента и перенаправлять их туда, где запущен сервер. Механизм, который позволяет клиенту получать доступ к объектам, расположенным в другом адресном пространстве или на другом компьютере, называется маршалинг (marshaling). 

Функции маршалинга: 

- принимать указатель интерфейса из процесса сервера и делать указатель прокси в процессе клиента доступным; 

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

Для любого вызова интерфейса клиент помещает аргументы в стек, вызывает необходимую функцию СОМ-объекта через указатель интерфейса. Если вызов объекта произошел не внутри процесса, вызов проходит через прокси. Прокси упаковывает аргументы в пакет маршалинга и передает получившуюся структуру удаленному объекту. Заглушка (stub) объекта распаковывает пакет маршалинга, выбирает аргументы из стека и вызывает необходимую функцию СОМ-объекта. 

Таким образом, маршалинг - это процесс упаковки информации, а демаршалинг - процесс распаковки информации. 

Тип маршалинга зависит от объектной принадлежности СОМ. Объекты могут использовать стандартный механизм маршалинга, предоставляемый интерфейсом IDispatch. Стандартный маршалинг позволяет устанавливать связь при помощи стандартного системного удаленного вызова процедуры (Remote Procedure Call, RFC). 

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

Рис. .5. Схема взаимодействия клиента с сервером в разных процессах на одном компьютере 

В системном реестре Windows регистрируется локальный СОМ-сервер так же, как и внутренний СОМ-сервер. 

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

Также удаленный сервер может работать с помощью прокси. Заключается между локальным и удаленным сервером различие в работе в типе используемой межпроцессной связи. При этом СОМ применяется при использовании локального сервера, DCOM– интерфейс – в случае удаленного сервера. На рис. 6 показано, как осуществляется взаимодействие клиента и удаленного сервера.

Рис. 6. Схема взаимодействия клиента с сервером на разных компьютерах 

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

Типичным СОМ-клиентом является диспетчер автоматизации (Automation Controller), представляющий собой часть приложения, которая знает какой тип информации необходим ему от разных объектов сервера, и она запрашивает данную информацию по мере надобности. 

Использование технологии «СОМ»

• 1. Расширения СОМ 

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

Технология ActiveX представляет собой технологию, использующую компоненты СОМ, особенно элементы управления. Она была создана для того, чтобы работа с элементами управления была более эффективной, что является при работе с приложениями Internet/Intranet, в которых на компьютер клиента элементы управления должны быть загружены, прежде чем они будут использоваться, особенно необходимым. 

Технология ActiveX не является единственным расширение СОМ. В табл. 1 представлены некоторые из используемых в настоящее время расширений СОМ. 

Таблица 1 -Список расширений СОМ

	Расширение СОМ	Краткое описание
	Серверы автоматизации (Automation servers)	Серверы автоматизации- это объекты, которыми можно управлять из других приложений во время работы приложения. Таким образом, автоматизация- это способность приложения программно контролировать объекты других приложений
	Диспетчеры автоматизации или СОМ-клиенты (Automation Controllers, COM Clients)	Диспетчеры автоматизации- это клиенты серверов автоматизации. Они позволяют разработчику или пользователю писать сценарии для управления серверами автоматизации
	Элементы управления ActiveX (ActiveX Controls)	Элементы управления ActiveX предназначены для серверов внутри процесса (in-process COM servers). Элементы ActiveX обычно используются путем встраивания в приложение-клиент
	Библиотеки типов (Type Libraries)	Библиотеки типов представляют собой статичные структуры данных, которые часто сохраняются как файлы ресурсов. Они содержат детализированную информацию об объекте и его интерфейсах. Клиенты серверов автоматизации и элементы управления ActiveX используют данную информацию и всегда считают ее доступной
	Страницы активного сервера (Active Server Pages)	Активные серверные страницы- это компоненты ActiveX, которые позволяют вам создавать динамически изменяющиеся Web-страницы
	Активные документы (Active Documents)	Активные документы - это объекты, которые поддерживают связывание и внедрение, визуальное редактирование, перенос (drag-and-drop). В качестве примера таких документов можно представить документы Microsoft Word и книги Microsoft Excel
	Визуальные межпроцессные объекты (Visual Cross-process Objects)	Визуальные межпроцессные объекты- это визуальные объекты, которыми можно управлять из других процессов

Причем в табл. 1 перечислены не все из имеющихся расширений СОМ. Доработка старых и создание новых, более совершенных технологий межпрограммного взаимодействия идет постоянно. 

На рис. 7 представлена диаграмма, которая показывает связь некоторых расширений СОМ и их связь с технологией СОМ. 

Рис. 7. Технологии, основанные на СОМ 

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

Приведенной ниже табл.2 дано краткое описание особенностей каждого из вышеприведенных расширений СОМ объектов. 

Таблица 2 - Особенности объектов СОМ

	СОМ-объект	Визуальность	Процесс	Связь	Библиотека типов
	Активный документ (Active Document)	Обычно визуальный	Внутренний или локальный	OLE	Нет
	Автоматизация (Automation)	Может быть как визуальным, так и невизуальным	Внутренний, локальный или удаленный	Автоматический маршалинг при помощи интерфейса IDispatch	Требуется для автоматического маршалмнга
	Элемент управления ActiveX (ActiveX Control)	Обычно визуальный	Внутренний	Автоматический маршалинг при помощи интерфейса IDispatch	Требуется
	Произвольный объект интерфейса	По выбору	Внутренний	Не требуется маршалинг	Рекомендуется
	Произвольный объект интерфейса	По выбору	Внутренний, локальный или удаленный	Автоматический маршалинг в зависимости от библиотеки типов, в противном случае-ручной маршалинг	Рекомендуется

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

Базовая программная модель технологий COM и COM+ является идентичной. Компоненты разрабатываются в одинаковом порядке: описываются интерфейсы, для обеспечения автоматизации реализуется IDispatch, реализуется код для регистрации, т. е. в рамках новой парадигмы делается то же, что делалось и ранее. Однако в дополнение к этому появились новые сервисы, значительно расширяющие возможности приложений.

• 1. IUnknown  - основной СОМ-интерфейс 

Интерфейс IUnknown позволяет обеспечить механизм учета ссылок (счетчик ссылок на СОМ-объект). Метод интерфейса IUnknown AddRef выполняется при передаче указателя на интерфейс. Завершая работу с интерфейсом, метод Release, который уменьшает счетчик ссылок вызывает приложение-клиент. 

При вызове метода Querylnterface интерфейса Iunknown идентификатор интерфейса (параметр IID), имеющий тип TGUID, передается в метод. Параметр метода out возвращает либо ссылку на запрашиваемый интерфейс, либо значение NH. Результатом вызова метода может быть одно из значений, перечисленных в табл. 3. 

Таблица 3.1. Возвращаемые методом Queryinterface значения

	Значение	Описание
	S_OK	Интерфейс поддерживается
	E_NOINTERFACE	Интерфейс не поддерживается
	E_UNEXPECTED	Неизвестная ошибка

Указатель интерфейса - это 32-битный указатель на экземпляр объекта, являющийся указателем на реализацию каждого метода интерфейса. Через массив указателей (vtable) на эти методы доступна реализация методов. Применение массива vtable аналогично механизму поддержки виртуальных функций в Object Pascal. Наглядное представление работы указателей СОМ-интерфейса представлено на рис. 8. 

Рис. 8. Схема работы указателя СОМ-интерфейса 

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

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

По запросу клиента услугу от СОМ-объекта, осуществляется передаяа идентификатор класса (CLSID) СОМ-объекту. CLSID - это GUID, который применяется при обращении к СОМ-объекту. СОМ-сервер после передачи CLSID должен обеспечить так фабрику класса, которая создает экземпляры СОМ-объектов. 

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

• ищется бинарный файл, содержащий сервер COM;
• файл загружается в память;
• создается экземпляр компонента и передается указатель интерфейса IUnknown, реализованный в этом компоненте.

Обычно для создания экземпляра сервера COM клиент вызывает WinAPI функцию CoCreateInstance, которая имеет такую сигнатуру:

WINOLEAPI CoCreateInstance(REFCLSID rclsid

, LPUNKNOWN pUnkOuter , DWORD dwClsContext , REFIID riid , LPVOID* ppv);

Параметр rclsid – это идентификатор CLSID требуемого компонента. Параметр riid – идентификатор требуемого интерфейса. В параметр ppv присваивается указатель интерфейса.

Функция CoCreateInstance непосредственно не создает экземпляр компонента, а передает указатель на реализацию интерфейса IClassFactory, которая отвечает за построение объектов классов компонента. При реализации интерфейса IClassFactory определяются функции:

• HRESULT CreateInstance(IUnknown* unkOuter, REFIID riid, void** ppvObject);
• HRESULT LockServer(BOOL lock).

Метод CreateInstance создает экземпляр объекта и возвращает указатель на требуемый интерфейс. Метод LockServer сохраняет сервер в памяти для последующего быстрого выполнения.

В методе CreateInstance создается экземпляр объекта с помощью оператора new. В самой реализации компонента он удаляется в методе Release при достижении счетчиком значения 0. Также вызывается метод QueryInterface и запрашивается требуемый интерфейс. Если объект не поддерживает требуемый интерфейс, то вызов завершается ошибкой, и клиент получает значение типа HRESULT с кодом ошибки. Метод LockServer увеличивает или уменьшает переменную locks, которая отвечает за удержание объекта в памяти.

Рассмотрим создание файла DLL. Для окончательного создания сервера COM нужно добавить несколько дополнительных функций API:

• DllMain – точка входа DLL, которая вызывается системой, когда поток или процесс начинает использование DLL. Это позволяет выполнить любую инициализацию и последующую очистку. Данная функция соответствует функции main исполняемых файлов с расширением exe.
• DllGetClassObject – вызывается с помощью функции CoGetClassObject для возврата указателя на интерфейс IClassFactory.
• DllCanUnloadNow – функция возвращает константуS_OK, если количество фиксаций сервера равно 0, в противном случае возвращает S_FALSE.
• DllRegisterServer – используется для регистрации сервера COM в операционной системе. В системах Win32 это означает добавление соответствующих записей в системный реестр Windows.

DllUnregisterSever – применяется для отмены регистрации сервера COM. В системах Win32 это достигается удалением соответствующих записей из системного реестра Windows.

В файле MySrvDll.cpp из примера [6] экземпляр класса CMyClassFactory определен с помощью синглтона Мейерса [3, 4]. Это единственный экземпляр данного класса, используемый для создания объектов компонента COM.

Функции OpenKey, CreateKey, SetValue и DeleteKey применяются для управления регистрацией и отменой регистрации построенного нами сервера COM. Функция DllGetClassObject проверяет запрашиваемый идентификатор CLSID. Если он равен CLSID_MyComponent, то она использует глобальный экземпляр CMyClassFactory для запроса требуемого интерфейса (riid) и возврата результата. Функции DllRegisterServer и DllUnregisterServer управляют добавлением или удалением требуемых ключей и их значений в системном реестре. Фукция DllRegisterServer создает ключ системного реестра в разделе HKEYS_CLASSES_ROOT_CLSID. Название этого ключа является идентификатором CLSID компонента, заключенным в скобки. Для него установлено значение имени нашего компонента MyComponent. Внутри нового ключа создан подчиненный емуключ InprocSever32. В нем установлено значение пути к файлу DLL. Ключ ThreadingModel установлен в значение Apartment. Для экспорта вышеуказанных функций создан текстовый файл MySrvDll.def. В нем определены экспортируемые функции DLL:

LIBRARY "MyComponent"

EXPORTS

DllCanUnloadNow PRIVATE

DllGetClassObject PRIVATE

DllRegisterServer PRIVATE DllUnregisterServer PRIVATE

Функции API, предназначенные для использования в системе COM, экспортируются как PRIVATE.

После сборки проекта необходимо зарегистрировать сервер COM, вызвав команду regsvr32 и передав в качестве параметра имя DLL. Программа Regsvr32.exe загрузит модуль DLL и вызовет функцию DllRegisterServer для создания требуемых записей в системном реестре [1].

• 1. Сравнение COM с другими похожими технологиями.

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

Наиболее известным конкурентом технологии COM является архитектура брокеров объектных запросов Common Object Request Broker Architecture (CORBA), которую развивает Консорциум OMG [8].

Функции CORBA и COM – это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов:

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

CORBA и COM отличаются, однако сходны в том, каким образом в них достигается реализация базовых принципов. Это клиент-серверные технологии, в которых функциональность объекта предоставляется клиенту посредством обращения к абстрактным интерфейсам. Интерфейс определяет набор методов, которые реализуют функции, присущие данному классу объектов. Интерфейс дает клиентувозможность только вызывать тот или иной метод, скрывая от него все детали его реализации. В обеих технологиях взаимодействие междуклиентским процессом и сервером объекта, т. е. процессом, который порождает и обслуживает экземпляры объекта, использует механизм объектного варианта вызова удаленной процедуры (remote procedure call – RPC). Он реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу.

Для того чтобы реализовать этусхему, на стороне клиента и на стороне сервера поддерживаются специальные компоненты, носящие название клиентский и серверный суррогаты (client stub и server stub). Для того чтобы вызвать ту или иную функцию, клиент обращается к клиентскому суррогату, который упаковывает аргументы в сообщение-запрос и передает их на транспортный уровень соединения. Серверный суррогат распаковывает полученное сообщение и в соответствии с переданными аргументами вызывает нужную функцию или нужный метод объекта, если речь идет об объектном варианте RPC. В СОМ клиентский суррогат называется proxy, а серверный – stub. В CORBA клиентский суррогат не имеет специального названия, а серверный обозначают термином skeleton [8].

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

клиента и сервера на различных платформах. Одной из последних технологий для распределенных вычислений является Windows Communication Foundation (WCF) от компании Microsoft. Тотальное принятие стандартных способов реализации распределенных вычислений поменяло мир разработки приложений. К примеру, функции, представляемые в настоящее время, включают в себя безопасность, координацию распределенных транзакций и надежные соединения. Полезные изменения в программировании сервисов должны быть отражены в инструментах, используемых разработчиками. WCF призван предоставить управляемый подход к распределенным вычислениям, широкой функциональной совместимости и прямую поддержку сервисов.

WCF упрощает разработку связанных приложений с помощью новой, ориентированной на сервисы, модели. Он поддерживает множество стилей для разработки распределенных приложений, создавая слоистую архитектуру. В основе архитектура каналов WCF дает асинхронную, нетипизированную передачусообщений. Над этим надстраивается архитектура для защищенного, надежного, транзакционного обмена данными, дающего большие возможности передачи и кодировки данных. WCF включает в себя возможности сериализации, которая позволяет избежать стыковки и версионирова-ния, и предоставляет интеграцию и функциональную совместимость с существующими распределенными системами .NET, такими как очередь сообщений (MSMQ), COM+, ASP.NET, сетевые сервисы, улучшенные сетевые сервисы (WSE).

Заключение

В общих чертах, СОМ-сервер должен выполнять следующее: 

- регистрировать данные в системном реестре Windows для связывания модуля сервера с идентификатором класса (CLSID); 

- предоставлять фабрику СОМ-класса, создающую экземпляры СОМ-объектов; 

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

Для создания СОМ-объектов и СОМ-серверов Delphi предоставляет мастера, который значительно упрощает процедуру.

DirectShow – это API, позволяющий Windows-приложениям управлять широким спектром устройств аудио/видео ввода, включающий (но не ограниченный) DV камеры, веб-камеры, DVD-устройства, карты TV-тюнеров. Оно поддерживает также различные форматы, от WAV и AVI до Windows Media. DirectShow, кроме этого, расширяемо, оно дает возможность поддерживать устройства третьих производителей, форматы и компоненты обработки [9].

Аудио- и видеопотоки могут быть обработаны самыми разными способами. Они могут быть скомбинированы, проанализированы, перемешаны, скопированы, сгенерированы, изменены и т. д. В DirectShow все эти операции скрыты в фильтрах – COM-объектах, имеющих стандартное поведение. Фильтры, читающие файлы, расщепляющие бинарные данные на разные (например, аудио и видео) потоки-демультиплексоры, фильтры-компрессоры и фильтры-декомпрессоры, фильтры, отображающие аудио- или видеоданные, фильтры-драйверы устройств – все это фильтры, которые знают, как они должны взаимодействовать, кроме обработки данных, с другими фильтрами для передачи потоковых данных. Приложения соединяют такие фильтры в необходимом порядке [9]. Библиотека реализована на языке С++.

Приложение CaptureIt 1.0 реализовывалось также на С++. Существенным неудобством для создания приложения является очень жесткая связь междуклиентом и компонентом (объект не может быть удален, пока клиент явно не укажет, что объект больше не нужен). Это является основным неудобством работы с COM.

Приложение CaptureIt 2.0 [6] полностью переписано под платформу.NET, но работа с COM-компонентами, тем не менее, остается. При программировании в .NET проблем с технологией COM возникает не много. Для использования компонент нужно всего лишь объявить интерфейс компоненты и используемые его функции. Возникают дополнительные проблемы при проталкивании NET-объектов в вызываемые из интерфейса функции. Также следует не забывать об освобождении интерфейса после его использования.

Список использованных источников

1. Рофейл Э., Шохауд Я. COM и COM+. Полное руководство / пер. с англ. В. Рубцова, М. Грачевой. –М.: Энтроп, 2015. - 250 c.
2. Таваре К., Фертитта К., Ректор Б. ATL 8. Внутреннее строение и применение / пер. с англ.; под ред. С. М. Молявко. - М.: Изд. дом «Вильямс», 2016. - 736 с.
3. Мейерс С. Эффективное использование С++ / пер. с англ. - М.: Изд-во ДМК, 2015. - 256 с.
4. Александреску А.Современное проектирование на С++. - М.: Изд. дом «Вильямс», 2015. - 220 c.
5. MSDN. URL: http://msdn.microsoft.com/ru-ru/default.aspx.
6. Сайт проекта CaptureIt. URL: http://rus.captureit.ru/.
7. Wikipedia. URL: http://ru.wikipedia.org/.
8. Сравнение COM и CORBA. URL: http://kunegin.narod.ru/ref3/corba5/12.htm.
9. DirectShow по-русски. URL: http://directshow.wonderu.com/first.

Список использованных источников