Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Технология COM (Component Object Model)

Содержание:

Введение

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

COM - это не язык программирования, а подход (спецификация) к созданию программ, обеспечивающий взаимодействие программ любых типов. Компоненты COM объединяются друг с другом для создания приложений или систем компонентов. Компоненты можно менять во время выполнения, без перекомпиляции или перекомпоновки приложения. COM - это основа, на которой построены такие технологии Microsoft, как ActiveX, DirectX и OLE.

Цель курсовой работы – рассмотреть технология COM.

Задачи курсовой работы:

- дать понятие технологии;

- сравнить технологию с другими технологиями;

-

1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ТЕХНОЛОГИИ COM

1.1 Понятие технологии COM

Component Object Model ( COM) - компонентно-ориентированная ар­хитектура, которая позволяет создавать приложения и программные системы, пост­роенные из совокупности компонентов, разработанных различными производителями и на разных платформах. COM является основой, на которой строятся более высо­коуровневые приложения и сервисы. Среди них сервисы OLE, охватывающие различ­ные аспекты компонентных систем, включающие в себя сложные документы, элементы управления, передачу данных между приложениями и многое другое. Несмотря на по­пуляризацию в последнее время платформы .NET, при разработке современных при­ложений широко используются компоненты COM, созданные на базе языков програм­мирования, типа Visual Basic и Visual C++. Модель COM относится к широко приме­няемым средствам модульного программирования. Созданные на ее основе программы предоставляют большой набор интегрированных служб, легкодоступных инструментов и полезных приложений. Реализация компонент COM не зависит от языка програм­мирования, средства COM имеют бинарно-совместимую архитектуру компонентов. В п. 2-4 статьи будут рассмотрены примеры построения компонент COM на языке про­граммирования Visual C+—+, описаны варианты и особенности создания COM-объектов и применения их на практике, приведены анализ технологии COM и сравнение ее с дру­гими схожими технологиями, представлены некоторые примеры использования, особен­но COM-объектов для работы с видеокамерами и видеозахватом.

Технология COM.

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

    1. Основные понятия. Программный код компонента (Component code) опи­сывает работу, которую выполняет компонент. Например, если компонент предназначен для вычисления квадратного корня, то описывающий ее код будет называться про­граммным кодом компонента.

Интерфейс (Interface) позволяет программе обращаться к функциональным воз­можностям компонента. Он описывает те функции, которые могут быть вызваны про­граммой.

GUID ( Globally Unique Identifier) означает глобально-уникальные идентификаторы, которые назначаются каждому компоненту COM и вновь созданному интерфейсу. Они однозначно идентифицируют компонент в операционной системе. Когда компонент или интерфейс меняется, для них необходимо создавать новые идентификаторы. Иденти­фикатор является 128-битовым целым значением.

Бинарная совместимость (Binary compatible) позволяет компонентам COM соот­ветствовать требованиям, предъявляемым к стандартному бинарному коду (binary standard). Это означает, что независимо от языка, используемого для создания соб­ственного компонента COM, он будет совместим и пригоден для применения любыми другими компонентами COM. Платформа .NET является продолжателем данной тех­нологии.

    1. Версии компонента COM. Как было сказано ранее, каждый компонент COM получает уникальное значение - идентификатор GUID. Эти идентификаторы хранятся в системном реестре Windows. После создания компоненты COM и введения ее в эксплуатацию возникает вопрос, как же изменить интерфейс или код компоненты, если ее уже какая-то программа использует? Имеется простое решение - при каждом изменении компоненты она получает новый идентификатор. Это дает гарантию того, что если какая-то программа уже применяет имеющий на данный момент интерфейс, то она будет использовать именно его и далее. Однажды созданный интерфейс никогда не исчезает, а продолжает существовать. При модификации интерфейса в него мож­но добавлять новые функциональные возможности, но нельзя удалять старые. Отсюда возникает сложность - непомерное разрастание компонента со временем. Единствен­ным решением такой проблемы может стать изначально правильное проектирование интерфейса с тем, чтобы далее он оставался по возможности неизменным [1].

1.2 Интерфейсы СOM

Интерфейсы COM. Интерфейс COM позволяет приложениям и различным компонентам обращаться к функциям данного компонента COM. К функциям компо­нента можно обращаться с помощью таблицы виртуальных функций ( virtual function table), которая также называется vtable (виртуальная таблица) или VTBL [1]. Эта таб­лица содержит не реально существующие функции, а список указателей на функции. Компонент, которому необходимо получить доступ к функции другого компонента, об­ращается к VTBL. Клиенты не могут обращаться к таблице напрямую. Для этого при­меняется другой указатель, называемый указателем интерфейса (interface pointer), добавляющий промежуточный уровень доступа, который делает возможной реализа­цию данного интерфейса. Такая техника очень похожа на реализацию динамическо­го полиморфизма языка C+—+, где любой динамически полиморфный класс содержит указатель на таблицу виртуальных функций. Интерфейс не является классом – нельзя создать экземпляр интерфейса, так же как и экземпляр класса с чисто виртуальными функциями в языке C+—+. При создании компонента COM обязательно нужно реали­зовать интерфейс IUnknown. Если компонент должен быть доступен средствами языка сценариев, то нужно также реализовать интерфейс IDispatch или пользовательский интерфейс, который и будет нести основную функциональность компонента.

Таблица 1 - Предопределенные константы типа HRESULT

Константа

Описание

S_OK

Успешное завершение операции

S_FALSE

Успешное завершение операции. Отличается от S ОК тем, что подразу­мевает какую-то особенность при выполнении функции. Использование S FALSE не регламентируется строго, в каких случаях будет исполь­зовано значение S ОК, а в каких — S FALSE, зависит от конкретного сервера. Например, если функция должна вернуть список каких-либо объектов, она может вернуть S ОК, если список не пуст, и S FALSE, если ошибок не было, но список пустой

Е FAIL

Ошибка без указания причины

E_UNEXPECTED

«Катастрофическая» ошибка — непредвиденная ситуация, из-за которой операция не может быть выполнена

E_NOTIMPL

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

E OUTOFMEMORY

Нехватка памяти

E INVALIDARG

Неверный аргумент функции

E NOINTERFACE

Запрошен интерфейс, отсутствующий в сервере

E POINTER

Неверный указатель

E HANDLE

Неверный дескриптор

E ABORT

Операция прервана

E ACCESSDENIED

В доступе отказано

Интерфейс IUnknown наиболее важен по сравнению с остальными интерфейсами. Его должен реализовывать каждый компонент COM. Интерфейс IUnknown содер­жит три метода: QueryInterface, AddRef и Release. Метод QueryInterface применяется для выявления доступных интерфейсов компонента. В начале использования интер­фейса необходимо вызывать метод AddRef, при его завершении должен вызываться метод Release. Интерфейс IDispatch содержит функции, которые позволяют обращать­ся к методам и свойствам объектов COM. Он позволяет Visual Basic и другим языкам создания сценариев управлять свойствами и методами объекта.

Все методы интерфейса должны возвращать значение типа HRESULT за исключе­нием методов интерфейса IUnknown AddRef и Release, которые возвращают количество существующих ссылок на объект.

Тип HRESULT является одним из средств контроля ошибок в COM/DCOM. Он представляет собой 32-битное число, в котором кодируется результат операции. Старший бит этого числа равен 1, если была ошибка, и 0, если все прошло нормаль­но. Следующие 4 бита зарезервированы для дальнейшего использования. Следующие 11 бит показывают, где возникла ошибка (это значение обычно называется facility code, что можно приблизительно перевести как код устройства, если подразумевать здесь не только аппаратные, но и логические устройства). Младшие 16 бит кодируют соб­ственно ошибку.

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

    1. Контракт интерфейса. Каждый интерфейс предоставляет контракт ин­терфейса, описывающий интерфейс. Контракт интерфейса COM содержит следующие элементы:
  • идентификатор интерфейса;
  • сигнатура интерфейса (Interface signature);
  • семантика интерфейса.

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

Сигнатура интерфейса (interface signature), называемая также синтаксисом ин­терфейса (interface syntax), определяет такие показатели:

  • число и порядок методов в интерфейсе;
  • число, порядок и тип всех параметров каждого метода;
  • тип возвращаемого значения каждого метода.

Тип параметра указывает, является ли параметр входным (in), выходным (out) или же входным/выходным (in/out). Сигнатура интерфейса содержит определение типов, используемых в интерфейсе, и соглашения о вызовах функций (cdecl, Pascal, stdcall) [2].

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

    1. Выделение и освобождение памяти. Существуют три типа параметров, передаваемых в функции-элементы COM объекта:
  • параметры In, память для которых выделяет и освобождает вызывающая про­грамма;
  • параметры Out, выделяющиеся и освобождающиеся вызывающей программой с помощью стандартного средства выделения памяти COM;
  • параметры In-Out, которые первоначально выделяются вызывающей програм­мой, затем освобождаются и при необходимости повторно выделяются вызы­вающей программой. За конечное освобождение памяти ответственность несет вызывающая программа.
    1. Типы COM. Компоненты COM могут быть представлены в виде клиентов, серверов и элементов ActiveX.

Клиенты COM могут являться приложениями, которые управляют одним или несколькими объектами COM. Они могут использовать уже имеющиеся объекты, соз­давать новые, менять параметры объектов, вызывать методы.

Серверы COM - это объекты COM, которые могут существовать в том же процессе, что и их контроллер. Также их можно переместить в другой процесс. Объекты внутри­процессного сервера (in-of-process server) реализуются как модули DLL и исполняются внутри пространства процесса контроллера. Объекты внепроцессного сервера (out-of­process server) реализуются в виде исполняемых файлов и исполняются в отдельном пространстве процесса [1].

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

1.3 Порядок построения компонента

Реализация компонента COM начи­нается с .определения пользовательского интерфейса, который мы хотим реализовать. Также реализуются интерфейсы IUnknown и пользовательский. Кроме этого, для до­ступа к объекту потребуется создать класс-фабрику.

    1. Файл IDL. Пользовательские интерфейсы находятся с помощью языка опре­деления интерфейсов MIDL (Microsoft Interface Definition Language). Это декларатив­ный язык (declarative language), основанный на языке IDL фонда открытого программ­ного обеспечения [6]. Язык MIDL предоставляет средства для определения интерфей­сов языково-независимым способом. Он используется для генерации программного ко­да процедур RPC (Remote Procedure Call), управляющих взаимодействием с сервером COM при реализации заданного интерфейса. Синтаксис языка IDL похож на синтаксис языка C++.

Файл IDL содержит в себе три основных элемента:

  • Интерфейс. Клиенты применяют его для взаимодействия с сервером.
  • CoClass. Класс, реализующий данный интерфейс.
  • Библиотека типов. Это откомпилированный файл IDL, который используется для получения информации об интерфейсе.
    1. Определение пользовательского интерфейса. В рассматриваемом при­мере [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.
    1. Реализация интерфейсов. Файл 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 CoCreatelnstance(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).

Метод Createlnstance создает экземпляр объекта и возвращает указатель на тре­буемый интерфейс. Метод 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. Указатель на интерфейс инициализируем с помощью функции CoCreatelnstance. Функцией CoUninitialize COM деинициализируется.

2 АНАЛИЗ ТЕХНОЛОГИИ COM

2.1 Сравнение технологии COM

Сравнение 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 на практике. Во время разработки приложения Capturelt 1.0 [6] были использованы компоненты COM, которые содержали в себе реа­лизацию работы с потоковым видео. Все эти компоненты представляют собой библио­теку Direct Show компании Microsoft.

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

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

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

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

ЗАКЛЮЧЕНИЕ

Технология СОМ является одной из базовых технологий Windows и для того, чтобы понять ее назначение, необходимо рассмотреть основные предпосылки ее возникновения. Если попытаться кратко сформулировать ее цель – то это способ взаимодействия клиентских приложений и серверов или предоставление сервисов одним приложением другому. Таким образом, главной предпосылкой возникновения СОМ является именно взаимодействие приложений.

В работе рассмотрены теоретические основы технологии COM.

Дано следующее понятие данной технологии:

Технология COM (Component Object Technology) - объектно-ориентированная программная спецификация, предложенная Microsoft. COM предназначена для повышения надежности взаимодействия программных продуктов между собой. Данная технология не определяет структуру программного продукта, язык программирования и прочие детали реализации. COM является стандартом, который регламентирует модель программного объекта, соответствующий требованиям COM-технологии.

Представлено вработе сравнение с технологиями другими.

СПИСОК ЛИТЕРАТУРЫ

  1. Рофейл Э., Шохауд Я. COM и COM+. Полное руководство / пер. с англ. В. Рубцова, М. Граче­вой. Энтроп, 2000. 250 c.
  2. Таваре К., Фертитта К., Ректор Б. ATL 8. Внутреннее строение и применение / пер. с англ.; под ред. С. М. Молявко. М.: Изд. дом «Вильямс», 2007. 736 с.
  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.