CC BY
141
Сер. 10. 2010. Вып. 1
ВЕСТНИК САНКТ-ПЕТЕРБУРГСКОГО УНИВЕРСИТЕТА
ИНФОРМАТИКА
УДК 004.82 А. В. Близнюк
СОЗДАНИЕ И ПРИМЕНЕНИЕ КОМПОНЕНТОВ COM
1. Введение. Component Object Model (COM) - компонентно-ориентированная архитектура, которая позволяет создавать приложения и программные системы, построенные из совокупности компонентов, разработанных различными производителями и на разных платформах. COM является основой, на которой строятся более высокоуровневые приложения и сервисы. Среди них сервисы OLE, охватывающие различные аспекты компонентных систем, включающие в себя сложные документы, элементы управления, передачу данных между приложениями и многое другое. Несмотря на популяризацию в последнее время платформы .NET, при разработке современных приложений широко используются компоненты COM, созданные на базе языков программирования, типа Visual Basic и Visual C++. Модель COM относится к широко применяемым средствам модульного программирования. Созданные на ее основе программы предоставляют большой набор интегрированных служб, легкодоступных инструментов и полезных приложений. Реализация компонент COM не зависит от языка программирования, средства COM имеют бинарно-совместимую архитектуру компонентов. В п. 2-4 статьи будут рассмотрены примеры построения компонент COM на языке программирования Visual C+—+, описаны варианты и особенности создания COM-объектов и применения их на практике, приведены анализ технологии COM и сравнение ее с другими схожими технологиями, представлены некоторые примеры использования, особенно COM-объектов для работы с видеокамерами и видеозахватом.
2. Технология COM.
2.1. Обзор. Давно изучены и разработаны способы переиспользования кода, описывающего некоторую функциональность в рамках одного языка программирования, одной платформы, одного компилятора. Применение модуля, скомпилированного из исходного кода, написанного на одном языке, в программном коде на другом языке было затруднено. Для решения данной задачи компания Microsoft предложила технологию COM - компонентную объектную модель [1]. Компонент - это независимая часть программного обеспечения, предназначенная для выполнения какой-то определенной работы. Функциональность компонента может быть использована в любой программе. Нет необходимости дублировать код по разным программам, в которых требуется
Близнюк Алексей Владимирович — аспирант 3-го курса кафедры информатики математикомеханического факультета Санкт-Петербургского государственного университета. Научный руководитель: проф. В. О. Сафонов. Научное направление: обработка графических изображений. E-mail: bliznyuk_a_v@mail.ru.
© А. В. Близнюк, 2010
применять одну и ту же функциональность. В то же время компонент можно заменить, отредактировать, исправить. Модель COM представляет собой набор шаблонов и рекомендацию для создания бинарно-совместимых компонентов программного обеспечения, позволяющая строить компоненты, которые могут обмениваться информацией независимо от языка программирования или инструментальных средств, выбранных для их построения.
2.2. Основные понятия. Программный код компонента (Component code) описывает работу, которую выполняет компонент. Например, если компонент предназначен для вычисления квадратного корня, то описывающий ее код будет называться программным кодом компонента.
Интерфейс (Interface) позволяет программе обращаться к функциональным возможностям компонента. Он описывает те функции, которые могут быть вызваны программой.
GUID ( Globally Unique Identifier) означает глобально-уникальные идентификаторы, которые назначаются каждому компоненту COM и вновь созданному интерфейсу. Они однозначно идентифицируют компонент в операционной системе. Когда компонент или интерфейс меняется, для них необходимо создавать новые идентификаторы. Идентификатор является 128-битовым целым значением.
Бинарная совместимость (Binary compatible) позволяет компонентам COM соответствовать требованиям, предъявляемым к стандартному бинарному коду (binary standard). Это означает, что независимо от языка, используемого для создания собственного компонента COM, он будет совместим и пригоден для применения любыми другими компонентами COM. Платформа .NET является продолжателем данной технологии.
2.3. Версии компонента COM. Как было сказано ранее, каждый компонент COM получает уникальное значение - идентификатор GUID. Эти идентификаторы хранятся в системном реестре Windows. После создания компоненты COM и введения ее в эксплуатацию возникает вопрос, как же изменить интерфейс или код компоненты, если ее уже какая-то программа использует? Имеется простое решение - при каждом изменении компоненты она получает новый идентификатор. Это дает гарантию того, что если какая-то программа уже применяет имеющий на данный момент интерфейс, то она будет использовать именно его и далее. Однажды созданный интерфейс никогда не исчезает, а продолжает существовать. При модификации интерфейса в него можно добавлять новые функциональные возможности, но нельзя удалять старые. Отсюда возникает сложность - непомерное разрастание компонента со временем. Единственным решением такой проблемы может стать изначально правильное проектирование интерфейса с тем, чтобы далее он оставался по возможности неизменным [1].
2.4. Интерфейсы COM. Интерфейс COM позволяет приложениям и различным компонентам обращаться к функциям данного компонента COM. К функциям компонента можно обращаться с помощью таблицы виртуальных функций (virtual function table), которая также называется vtable (виртуальная таблица) или VTBL [1]. Эта таблица содержит не реально существующие функции, а список указателей на функции. Компонент, которому необходимо получить доступ к функции другого компонента, обращается к VTBL. Клиенты не могут обращаться к таблице напрямую. Для этого применяется другой указатель, называемый указателем интерфейса (interface pointer), добавляющий промежуточный уровень доступа, который делает возможной реализацию данного интерфейса. Такая техника очень похожа на реализацию динамического полиморфизма языка C++, где любой динамически полиморфный класс содержит
указатель на таблицу виртуальных функций. Интерфейс не является классом - нельзя создать экземпляр интерфейса, так же как и экземпляр класса с чисто виртуальными функциями в языке C++. При создании компонента COM обязательно нужно реализовать интерфейс IUnknown. Если компонент должен быть доступен средствами языка сценариев, то нужно также реализовать интерфейс IDispatch или пользовательский интерфейс, который и будет нести основную функциональность компонента.
Интерфейс IUnknown наиболее важен по сравнению с остальными интерфейсами. Его должен реализовывать каждый компонент COM. Интерфейс IUnknown содержит три метода: Querylnterface, AddRef и Release. Метод Querylnterface применяется для выявления доступных интерфейсов компонента. В начале использования интерфейса необходимо вызывать метод AddRef, при его завершении должен вызываться метод Release. Интерфейс IDispatch содержит функции, которые позволяют обращаться к методам и свойствам объектов COM. Он позволяет Visual Basic и другим языкам создания сценариев управлять свойствами и методами объекта.
Предопределенные константы типа HRESULT
Константа Описание
S ок Успешное завершение операции
S_FALSE Успешное завершение операции. Отличается от S ОК тем, что подразумевает какую-то особенность при выполнении функции. Использование S FALSE не регламентируется строго, в каких случаях будет использовано значение S ОК, а в каких — S FALSE, зависит от конкретного сервера. Например, если функция должна вернуть список каких-либо объектов, она может вернуть S ОК, если список не пуст, и S FALSE, если ошибок не было, но список пустой
Е FAIL Ошибка без указания причины
E_UNEXPECTED «Катастрофическая» ошибка — непредвиденная ситуация, из-за которой операция не может быть выполнена
E_NOTIMPL Функция не реализована. Если по какой-то причине разработчик сервера не считает нужным реализовывать какие-либо функции интерфейса, он пишет их так, чтобы они в любом случае возвращали это значение
Е OUTOFMEMORY Нехватка памяти
Е INVALIDARG Неверный аргумент функции
Е NOINTERFACE Запрошен интерфейс, отсутствующий в сервере
Е POINTER Неверный указатель
Е HANDLE Неверный дескриптор
Е ABORT Операция прервана
Е ACCESSDENIED В доступе отказано
Все методы интерфейса должны возвращать значение типа HRESULT за исключением методов интерфейса IUnknown AddRef и Release, которые возвращают количество существующих ссылок на объект.
Тип HRESULT является одним из средств контроля ошибок в COM/DCOM. Он представляет собой 32-битное число, в котором кодируется результат операции. Старший бит этого числа равен 1, если была ошибка, и 0, если все прошло нормально. Следующие 4 бита зарезервированы для дальнейшего использования. Следующие 11 бит показывают, где возникла ошибка (это значение обычно называется facility code, что можно приблизительно перевести как код устройства, если подразумевать здесь не только аппаратные, но и логические устройства). Младшие 16 бит кодируют собственно ошибку.
Существуют предопределенные константы типа HRESULT, часть которых показана в таблице. Константы могут быть разными на различных платформах, поэтому в целях совместимости лучше пользоваться их символьными именами, а не значениями.
2.5. Контракт интерфейса. Каждый интерфейс предоставляет контракт интерфейса, описывающий интерфейс. Контракт интерфейса COM содержит следующие элементы:
• идентификатор интерфейса;
• сигнатура интерфейса (Interface signature);
• семантика интерфейса.
Каждый интерфейс имеет идентификатор GUID, который служит его программным именем. Он является кодом ID, уникально идентифицирующим контракт, определенный интерфейсом. После того, как интерфейс, сконструированный с ID, компилируется в бинарный вид и вводится в действие, свойства, заданные в элементах интерфейса, изменять нельзя.
Сигнатура интерфейса (interface signature), называемая также синтаксисом интерфейса (interface syntax), определяет такие показатели:
• число и порядок методов в интерфейсе;
• число, порядок и тип всех параметров каждого метода;
• тип возвращаемого значения каждого метода.
Тип параметра указывает, является ли параметр входным (in), выходным (out) или же входным/выходным (in/out). Сигнатура интерфейса содержит определение типов, используемых в интерфейсе, и соглашения о вызовах функций (cdecl, Pascal, __stdcall) [2].
Семантика интерфейса - это описание поведения каждого метода, контекста и порядка, в котором интерфейс должен или может быть вызван, коды ошибок, специфические для данного метода, и возможные коды успешного завершения.
2.6. Выделение и освобождение памяти. Существуют три типа параметров, передаваемых в функции-элементы COM объекта:
• параметры In, память для которых выделяет и освобождает вызывающая программа;
• параметры Out, выделяющиеся и освобождающиеся вызывающей программой с помощью стандартного средства выделения памяти COM;
• параметры In-Out, которые первоначально выделяются вызывающей программой, затем освобождаются и при необходимости повторно выделяются вызывающей программой. За конечное освобождение памяти ответственность несет вызывающая программа.
2.7. Типы COM. Компоненты COM могут быть представлены в виде клиентов, серверов и элементов ActiveX.
Клиенты COM могут являться приложениями, которые управляют одним или несколькими объектами COM. Они могут использовать уже имеющиеся объекты, создавать новые, менять параметры объектов, вызывать методы.
Серверы COM - это объекты COM, которые могут существовать в том же процессе, что и их контроллер. Также их можно переместить в другой процесс. Объекты внутри-процессного сервера (in-of-process server) реализуются как модули DLL и исполняются внутри пространства процесса контроллера. Объекты внепроцессного сервера (out-ofprocess server) реализуются в виде исполняемых файлов и исполняются в отдельном пространстве процесса [1].
Элементы ActiveX реализуются в виде внутрипроцессного сервера, который можно использовать в любом контейнере OLE. Они отличаются от внутрипроцессного сервера COM тем, что ActiveX элементы имеют пользовательский интерфейс.
3. Построение и использование COM средствами VC+—+.
3.1. Порядок построения компонента. Реализация компонента COM начинается с определения пользовательского интерфейса, который мы хотим реализовать. Также реализуются интерфейсы IUnknown и пользовательский. Кроме этого, для доступа к объекту потребуется создать класс-фабрику.
3.2. Файл IDL. Пользовательские интерфейсы находятся с помощью языка определения интерфейсов MIDL (Microsoft Interface Definition Language). Это декларативный язык (declarative language), основанный на языке IDL фонда открытого программного обеспечения [6]. Язык MIDL предоставляет средства для определения интерфейсов языково-независимым способом. Он используется для генерации программного кода процедур RPC (Remote Procedure Call), управляющих взаимодействием с сервером COM при реализации заданного интерфейса. Синтаксис языка IDL похож на синтаксис языка C++.
Файл IDL содержит в себе три основных элемента:
• Интерфейс. Клиенты применяют его для взаимодействия с сервером.
• CoClass. Класс, реализующий данный интерфейс.
• Библиотека типов. Это откомпилированный файл IDL, который используется для получения информации об интерфейсе.
3.3. Определение пользовательского интерфейса. В рассматриваемом примере [6] файл MySrv.idl содержит определение интерфейса с помощью языка IDL. Оператор import применяется для взятия определений интерфейсов из файла oaidl.idl. Он подобен директиве #include языка C+—+. В квадратных скобках перечисляются атрибуты, которые относятся к описанию интерфейса, идущего ниже. Атрибут object сообщает компилятору IDL, что эта информация является определением скорее интерфейса COM, чем интерфейса RPC. Идентификатор GUID, определенный с помощью атрибута uuid, - уникальный идентификатор интерфейса. Директива importlib напоминает директиву import, но импортирует бинарные (откомпилированные) библиотеки типов. Всем библиотекам типов требуется директивой importlib импортировать библиотеку базовых типов, определенную в файле Stdole32.tlb.
С помощью программы guidgen.exe необходимо создать три идентификатора и заменить ими имеющиеся в файле MySrv.idl [6]. Копировать готовые идентификаторы необходимо в формате реестра (Registry Format).
Файл idl компилируется с помощью программы midl.exe. При компиляции генерируются следующие файлы:
• прокси-файл интерфейса (interface proxy file) mysrv_p.c, в котором содержится программный код передачи интерфейса IMyInterface между процессами, определенный в файле IDL из примера [6];
• файл заголовка mysrv.h, содержащий интерфейс и определения типов C++. Он также объявляет символьные константы для идентификаторов интерфейса ID и класса компонентов CLSID. Из примера это IID_IMyInterface и CLSID_MyComponent;
• файл mysrv_i.c, содержащий определения GUID для идентификаторов IID, CLSID и LIBID, объявленных в файле заголовка;
• бинарная версия файла IDL.
3.4. Реализация интерфейсов. Файл MyComponent.h из примера [6] содержит реализацию интерфейса IUnknown и пользовательского. Заголовочный файл windows.h включен для использования некоторых функций WinAPI. Также включен
файл mysrv.h, сгенерированный компилятором IDL. Этот файл содержит определение интерфейса. Класс CMyComponent наследуется от интерфейса и реализует его.
Поле refCount служит для подсчета ссылок на объект класса CMyComponent и инициализируется в конструкторе значением 0. Макросы STDMETHOD и STDMETHOD_ применяются для объявления функций с описанием соглашения о вызовах функций и типом возвращаемого значения. Макрос STDMETHOD описывает возвращаемое значение как HRESULT. Макрос STDMETHOD_ определяет возвращаемое значение в первом параметре. Для функций AddRef и Release он применяется, так как эти функции возвращают значение счетчика ссылок, а не HRESULT. В зависимости от платформы макросы могут быть определены по-разному, поэтому описание функций без использования макросов было бы некорректным.
С помощью метода QueryInterface клиент запрашивает конкретный интерфейс. Метод проверяет наличие такого интерфейса в компоненте и, если он найден, присваивает в указатель, переданный в метод. Сравнивается передаваемый параметр riid с идентификатором интерфейсов IUnknown и MyInterface. Также метод QueryInterface вызывает функцию AddRef для увеличения количества ссылок на объект. Функции AddRef и Release используют функции WinAPI InterlockedIncrement и InterlockedDecrement для получения монопольного доступа к переменной refCount при обеспечении безопасности многопоточности (thread-friendly). Если бы применялся простой инкремент refCount++, то конкурирующие потоки могли бы создать проблемы при использовании функций AddRef и Release [2].
Метод HelloWorld является единственным в пользовательском интерфейсе, который вызывает диалоговое окно с надписью «Hello World!».
3.5. Фабрика классов для интерфейса. Создание объекта 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, которая отвечает за удержание объекта в памяти.
3.6. Создание файла 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].
3.7. Создание клиентского приложения. Клиентское приложение можно создать как Win32 консольный проект, где в функции main будет происходить обращение к серверу COM:
#include "stdafx.h"
#include <iostream>
#include <windows.h>
#include "..\MyComponent\mysrv.h"
#include
"..\MyComponent\mysrv_i.c"
int _tmain(int argc, _TCHAR* argv[])
{
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
IMyInterface* my = NULL;
HRESULT hr = CoCreateInstance(CLSID_MyComponent , NULL
, CLSCTX_INPROC_SERVER , IID_IMyInterface , reinterpret_cast<void**>(&my));
if (FAILED(hr))
std::cout << "Com failed";
else
{
my->HelloWorld();
my->Release();
}
CoUninitialize(); return 0;
}
Для доступа к интерфейсу IMyInterface нужен файл mysrv.h, сгенерированный компилятором MIDL; для доступа к идентификаторам CLSID и IID - файл mysrv_i.c, также сгенерированный компилятором MIDL. COM инициализируется вызовом функций CoInitialize. Указатель на интерфейс инициализируем с помощью функции CoCreateInstance. Функцией CoUninitialize COM деинициализируется.
4. Анализ технологии COM.
4.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).
4.2. Компоненты .NET. Приложения .NET состоят из компонент. Все .NET-объекты имеют такие важные атрибуты как свойства, методы и события, которые определяют концепцию объектно-ориентированного программирования. Если речь идет о программировании на Visual Basic, то важным вопросом остается реализация программного интерфейса, который будут использовать другие программисты в своих приложениях. Большую часть времени разработки будут занимать проектирование объектов и написание соответствующего программного кода.
Обычно реализация простого объектно-ориентированного приложения .NET заключается в создании класса, добавлении необходимых полей, методов и свойств и использовании этого класса в различных модулях приложения. Компонентное программирование максимально выделяет такую концепцию. Несмотря на то, что компонентный подход подразумевает также написание классов, компоненты, используемые в различных приложениях, идут перед ними.
Компонент - особый тип исполняемого .NET модуля. На такой компонент обычно имеются ссылки из других приложений, которые его используют. Во многих интернет-сервисах компоненты применяются для работы с данными, графикой, текстом. В локальных приложениях компоненты играют ту же роль, что и в Интернете, но в более сокращенном варианте.
Компоненты предоставляют программный интерфейс, используемый приложениями. Он обладает набором методов, свойств, классов. Другими словами, компонент компилируется из набора классов, по средствам которых предоставляются необходимые методы и свойства.
Компонента является библиотекой с расширением dll. Во время исполнения такая библиотека подгружается к исполняемому модулю. Обычно компоненты компилируются и тестируются как отдельные проекты, а не в составе использующих их модулей. После компиляции компонент может быть добавлен во многие проекты [5].
4.3. JavaBeans. Еще одним инструментом разработки компонентных модулей служит технология JavaBeans - классы в языке Java, написанные по конкретным
правилам. Они применяются для объединения нескольких объектов в один (bean) для удобной передачи данных.
Спецификация Sun Microsystems определяет JavaBeans как «универсальные программные компоненты, которые могут управляться с помощью графического интерфейса» («reusable software components that can be manipulated visually in a builder tool»).
JavaBeans обеспечивает основу для многократно используемых, встраиваемых и модульных компонентов программного обеспечения. Компоненты JavaBeans могут принимать различные формы, но наиболее широко они применяются в элементах графического пользовательского интерфейса. Одна из целей создания JavaBeans - взаимодействие с похожими компонентными структурами. Например, Windows-программа при наличии соответствующего моста или объекта-обёртки может использовать компонент JavaBeans так, будто бы он является компонентом COM или ActiveX [7].
4.4. Достоинства и недостатки COM. COM очень прост для простых небольших приложений и чрезвычайно сложен как инструмент создания комплексных систем. Он содержит большое количество «узких» мест - недостаточно гибкую стандартную схему маршалинга, отсутствие состояния объектов, низкую устойчивость к сбоям. Технология не является объектно-ориентированной в классическом смысле этого слова, что в общем случае не способствует простоте ее применения. Достоинствами технологии являются комплексность и универсальность подходов в рамках COM-модели.
4.5. Использование COM на практике. Во время разработки приложения CaptureIt 1.0 [6] были использованы компоненты COM, которые содержали в себе реализацию работы с потоковым видео. Все эти компоненты представляют собой библиотеку Direct Show компании Microsoft.
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+. Полное руководство / пер. с англ. В. Рубцова, М. Грачевой. Энтроп, 2000. 250 c.
2. Таваре К., Фертитта К., Ректор Б. ATL 8. Внутреннее строение и применение / пер. с англ.; под ред. С. М. Молявко. М.: Изд. дом «Вильямс», 2007. 7З6 с.
3. Мейерс С. Эффективное использование С+—И / пер. с англ. М.: Изд-во ДМК, 2008. 256 с.
4. Александреску А.Современное проектирование на С+—+. М.: Изд. дом «Вильямс», 2008. 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.
Статья рекомендована к печати член-кор. РАН, проф. Г. А. Леоновым.
Статья принята к печати 24 сентября 2009 г.
