Предпосылки возникновения технологии COM и область её использования

Содержание:

ВВЕДЕНИЕ

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

В то же время применение модуля, скомпилированного из исходного кода, написанного на одном языке, в программном коде на другом языке представляет собой определенные затруднения. Для решения данной задачи компанией Microsoft в 1993 году была предложена технология COM

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

Модель COM относится к широко приме­няемым средствам модульного программирования. Созданные на ее основе программы предоставляют большой набор интегрированных служб, легкодоступных инструментов и полезных приложений. Реализация компонент COM не зависит от языка програм­мирования, средства COM имеют бинарно-совместимую архитектуру компонентов.

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

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

- раскрыть предпосылки возникновения технологии COM и указать область её использования;

- охарактеризовать ключевые составляющие технологии COM

- провести сравнительный анализ технологии COM со смежными технологиями;

- выделить достоинства и недостатки технологии COM.

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

1. Предпосылки возникновения технологии COM и область её использования

1.1. История возникновения технологии COM

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

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

Чтобы яснее представить себе проблему взаимодействия приложений Windows, вспомним следующее. Каждый процесс в 32-разрядной Windows имеет свое адресное пространство размером в 4Гб и, по этой причине, один процесс не имеет никакой возможности получить доступ к данным или функциям другого процесса, так как любой адрес в процессе ссылается на свое адресное пространство.

В логической и хронологической последовательности взаимодействие приложений Windows реализовалось с использованием следующих технологий [12]:

1. Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки.

2. Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows.

3. Dynamic Data Exchange (DDE) – динамический обмен данными.

4. Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов.

5. OLE2.0 – OLE на базе COM.

6. Distributed COM (DCOM) – распределенная модель компонентных объектов.

7. COM+ – новейшая технология COM.

Может возникнуть вопрос, зачем вообще приложениям необходимо взаимодействовать друг с другом? «Если некоторому приложению необходимо, допустим, использовать электронные таблицы Excel, то почему бы ему не подключить соответствующую библиотеку DLL? Естественно, можно, и это уже было первым подходом к решению обсуждаемой проблемы» [8, с.84]. Однако такой подход имеет свои недостатки, главным из которых является проблема сопровождения. Если разрабатывалась новая версия какой-либо функции DLL, то перестают работать приложения, которые используют старую версию библиотеки. Если новую версию функции снабдить новым именем, то необходимо разрабатывать новую документацию и включать в библиотеку обе версии функции. Несложно себе представить, в какой конгломерат превратится библиотека в течение весьма небольшого промежутка времени и насколько сложно будет ориентироваться в многочисленных версиях функций».

Проиллюстрируем главную идею технологии ODBC можно на примере всё той же Excel. Так как это приложение должно быть способно считывать данные из БД различных форматов, необходимо или разрабатывать различные версии Excel для каждой из БД (Excel для Access, Excel для Oracle и т.д.) или заблаговременно подключать все необходимые библиотеки к Excel. Компанией Microsoft выбрала другой путь, создав промежуточный программный слой, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемые в форме DLL. Таким образом, ODBC располагается между приложением и источниками данных различных форматов.

Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями. Вся идеология Windows основана на обработке сообщений (messages) и любые приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема, однако, состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений, и собственно сообщения Windows не позволяют передавать сравнительно большие объемы данных. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Главными недостатками DDE является сложность программирования, ненадежность и то обстоятельство, что приложения должны знать формат передаваемых данных.

«Технологию внедрения и связывания объектов OLE1.0 фирма Microsoft представила в 1991 г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений» [1, с.43].

До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в другой документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место.

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

Перечислим недостатки технологии OLE [1, с.45]:

1. Так как базовым механизмом OLE является DDE, который по своей природе асинхронен, то после вызова любой функции возврат управления происходит немедленно и требуется ожидать, в цикле, завершения требуемой операции.

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

3. Связи OLE легко разрываются при перемещении файлов.

4. Пользователю неудобно редактировать данные в отдельном окне.

1.2. Применение технологии COM

Технология COM в настоящее время широко применяется при разработке программного обеспечения, интеграции программных продуктов в единые информационные системы. Целью разработки COM-технологии являлось стремление к интеграции программного обеспечения через стандартизацию механизмов взаимодействия программных модулей между собой. На основе данной технологии, которая является масштабируемой, разработано огромное число технологий, которые стали стандартами в разнообразных сферах применения информационных технологий – от управления технологическими процессами в промышленности до домашних персональных компьютеров. Массовое применение COM отчасти связано с мощью ее разработчика, фирмы Microsoft. С этим приходится считаться, и каждый программный продукт, выпущенный под платформу Windows, для достижения коммерческого успеха обязан соответствовать инновациям Microsoft.

Технология COM выступает объектно-ориентированной программной спецификацией, предложенной Microsoft. COM предназначена для повышения надежности взаимодействия программных продуктов между собой. Данная технология не определяет структуру программного продукта, язык программирования и прочие детали реализации. COM является стандартом, который регламентирует модель программного объекта, соответствующий требованиям COM-технологии. Программный объект, созданный согласно спецификации COM называется COM-объектом. Данная технология определяет механизм взаимодействия COM-объектов между собой. COM относится к так называемым двоичным стандартам, т.к. прилагается к оттранслированному в двоичный код программному объекту. Взаимодействие COM-объектов обеспечивается набором предопределенных подпрограмм, называемыми интерфейсами, доступ к которым обеспечивается через уникальные идентификаторы интерфейсов GUID (Global Unique Interface Identifyer), уникальность которых гарантирует операционная система. Такой механизм схож с использованием указателей при доступе к объектам в объектно-ориентированных языках программирования, что дает возможность прозрачного управления объектами, т.к. доступ к ним обеспечивается через указатели. COM-технология расширяет этот механизм, перенося применение указателей (в виде GUID) для доступа к объектам на уровень операционной системы. Таким образом, COM-объекты могут быть прозрачно друг для друга модифицироваться, т.к. доступ к объектам обеспечивается через GUID. COM-технология включает в себя также библиотеку, в которой содержится набор стандартных интерфейсов, которые определяют ядро функциональности COM, и небольшой набор API функций, разработанных для создания COM-объектов и управления ими [1, с.53].

«Архитектура COM является расширяемой, и на ней базируются другие технологии Microsoft, такие как OLE и ActiveX. Эти технологии в настоящее время являются расширениями операционной системы, и определяют свои собственные правила работы и предлагают свои библиотеки для создания объектов и для управления объектами на основе данных технологий»⁶. Используя COM как основу, разработчики программного обеспечения получают возможность создавать свои собственные расширения таким образом, что программные объекты созданные, по правилам COM-технологии могут работать с другими COM-объектами через унифицированный механизм взаимодействия, который предлагает COM.

COM использует такое понятие как «класс», которое по смыслу означает то же самое, что и в объектно-ориентированных средствах разработки. COM-объект является объектом COM-класса (COM class). COM-классы, для различия с классами в объектно-ориентированных языках, с помощью которых может создаваться приложение, обычно называются соклассами (CoClass) [7].

2. Основы технологии COM

2.1. Основные понятия технологии COM

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

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

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

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

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

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

2.2. Основные свойства, отличающие COM от ООП. Концепции технологии COM

Технология объектно-ориентированного программирования основа-на на том, что приложение разбивается на объекты, которые взаимодей-ствуют друг с другом внутри программы (рис. 2.1).

Рисунок 2.1 - Программа, сконструированная в ООП [2, с.5]

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

В COM-технологии объекты помещаются в отдельные исполняемые блоки (рис. 2.2), которыми могут являться динамически компонуемые библиотеки (DLL) или приложение (EXE).

Рисунок 2.2 - Программа, сконструированная по архитектуре COM [2, с.6]

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

Технология COM основана на следующих основных концепциях.

1. Уникальность и контекстная независимость компонент. В сис­теме не должно быть компонентов с одинаковым способом обращения и разными смысловыми назначениями.

2. Инкапсуляция. Реализация компонентов COM должна быть скры­та. Это необходимо для того, чтобы была независимость от языков программирования.

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

Преимущество СОМ заключается в том, что это позволяет каждому разработчику сконцентрироваться на разработке своих компонент, которые могут обмениваться информацией независимо от языка программирования или инструментальных средств реализации. Более того, техноло­гия COM дает гибкие возможности динамической настройки и модификации программного продукта с учетом желаний пользователя и особенностей операционной системы [2, с.6].

2.3. Интерфейсы COM

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

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

Таблица 2.1 - Предопределенные константы типа HRESULT [10, с.54]

Константа	Описание
S_OK	Успешное завершение операции
S_FALSE	Успешное завершение операции. Отличается от S_OK тем, что подразу­мевает какую-то особенность при выполнении функции. Использование S_FALSE не регламентируется строго, в каких случаях будет исполь­зовано значение S_OK, а в каких – S_FALSE, зависит от конкретного сервера. Например, если функция должна вернуть список каких-либо объектов, она может вернуть S_OK, если список не пуст, и S_FALSE, если ошибок не было, но список пустой
E_FAIL	Ошибка без указания причины
E_UNEXPECTED	«Катастрофическая» ошибка – непредвиденная ситуация, из-за которой операция не может быть выполнена
E_NOTIMPL	Функция не реализована. Если по какой-то причине разработчик сервера не считает нужным реализовывать какие-либо функции интерфейса, он пишет их так, чтобы они в любом случае возвращали это значение
E_OUTOFMEMORY	Нехватка памяти
E_INVALIDARG	Неверный аргумент функции
E_NOINTERFACE	Запрошен интерфейс, отсутствующий в сервере
E_POINTER	Неверный указатель
E_HANDLE	Неверный дескриптор
E_ABORT	Операция прервана
E_ACCESSDENIED	В доступе отказано

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

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

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

Каждый интерфейс предоставляет контракт ин­терфейса, описывающий интерфейс. Контракт интерфейса COM содержит следующие элементы:

- идентификатор интерфейса;

- сигнатура интерфейса (Interface signature);

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

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

- число и порядок методов в интерфейсе;

- число, порядок и тип всех параметров каждого метода;

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

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

2.4. Выделение и освобождение памяти

Существуют три типа параметров, передаваемых в функции-элементы COM объекта:

- параметры In, память для которых выделяет и освобождает вызывающая про­грамма;

- параметры Out, выделяющиеся и освобождающиеся вызывающей программой с помощью стандартного средства выделения памяти COM;

- параметры In-Out, которые первоначально выделяются вызывающей програм­мой, затем освобождаются и при необходимости повторно выделяются вызы­вающей программой. За конечное освобождение памяти ответственность несет вызывающая программа [3, с.121].

2.5. Типы COM

Компоненты COM могут быть представлены в виде клиентов, серверов и элементов ActiveX.

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

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

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

2.6. Портативность и коммуникабельность COM. Регистрация COM-серверов.

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

Связь клиента с сервером берёт на себя операционная система, кото­рая содержит системную базу данных, называемую системным реест­ром, где прописывается название COM-сервера, уникальный номер компонента CLSID и другая информация.

Реестр имеет иерархическую структуру в виде дерева, где узлами являются разделы, а листьями - данные.

Для просмотра и редактиования реестра можно использовать стандартную программу regedit.exe редактор реестра (рис. 2.3).

Рисунок 2.3 - Редактор реестра [2, с.12]

Данные об объектах COM хранятся в подразделе CLSID раздела HKEY_CLASSES_ROOT. В этом разделе перечислены CLSID всех компонентов, установленных в системе. Каждый CLSID содержит параметр по умолчанию, называемый «дружественным» именем компонента. В разделе описания компонента есть подраздел LocalServer32 (для внешних COM-серверов) или InprocServer32 (для внутренних COM-серверов), содержащих имя приложения или DLL, в которых находится компонент.

Имя файла и CLSID - это наиболее важные данные для нормального функционирования, но для некоторых, более сложных компонентов COM, хранится и другая информация. Например, это номер библиотеки типов, поддерживаемой данным COM-сервером (TypeLib), номер версии COM-сервера (Version), программное имя (ProgID) и т. п.

Чтобы зарегистрировать встроенный COM-сервер в системном реестре, необходимо вызвать функцию DllRegisterServer, находящуюся внутри DLL-модуля COM-сервера. Это можно сделать в приложении, предва-рительно загрузив DLL, или с помощью стандартной утилиты Windows RegSvr32.exe, выполнив команду:

RegSvr32 -s <имя сервера>

При удалении встроенного сервера из системы необходимо запустить функцию DllUnregisterServer. В Windows удаление сервера осуществляется командой:

RegSvr32 -u <имя сервера>

Для регистрации внешних COM-серверов требуется запустить приложение, включив в командную строку запуска ключ /regserver, a для удаления нужно использовать ключ /unregserver. Встроенный COM-сервер регистрируется и при первом запуске приложения без всяких дополнительных ключей в командной строке, но после этого сервер будет продолжать работать.

3. Анализ технологии COM

3.1. Сравнение COM со смежными технологиями

3.1.1. CORBA

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

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

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

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

- независимость от платформы: компоненты могут выполняться на различных ап­паратных и операционных платформах, взаимодействуя друг с другом в рамках единой системы;

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

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

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

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

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

3.1.2. Компоненты .NET

Приложения .NET состоят из компонент. Все .NET-объекты имеют такие важные атрибуты как свойства, методы и события, кото­рые определяют концепцию объектно-ориентированного программирования. Если речь идет о программировании на Visual Basic, то важным вопросом остается реализация программного интерфейса, который будут использовать другие программисты в сво­их приложениях. Б´ольшую часть времени разработки будут занимать проектирование объектов и написание соответствующего программного кода.

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

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

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

Компонента является библиотекой с расширением dll. Во время исполнения такая библиотека подгружается к исполняемому модулю. Обычно компоненты компилируют­ся и тестируются как отдельные проекты, а не в составе использующих их модулей. После компиляции компонент может быть добавлен во многие проекты [9, с.11].

3.1.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 [4].

3.2. Достоинства и недостатки COM

Достоинства­ми технологии COM являются комплексность и универсальность подходов в рамках COM-модели.

COM очень прост для простых небольших приложений и чрезвычайно сложен как инструмент создания комплекс­ных систем. Он содержит большое количество «узких» мест – недостаточно гибкую стандартную схему маршалинга, отсутствие состояния объектов, низкую устойчивость к сбоям. Технология не является объектно-ориентированной в классическом смысле этого слова, что в общем случае не способствует простоте ее применения [6].

Технология часто критикуется за неоправданную сложность, конкретно [5]:

- необходимость использования двух языков программирования (.idl для описания интерфейсов и, обычно, C++ для написания реализаций). Необходимость возникает только при создании собственных интерфейсов, и не возникает в случае, если разработчик ограничил себя использованием готовых интерфейсов.

- необходимость «прокладочного» кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе С++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых Microsoft разработал библиотеку смарт-пойнтеров — comdef.h, _com_ptr_t<Interface>, эта библиотека делает использование COM-объектов тривиальным).

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

- инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной «поверхности уязвимости» с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster).

- инфраструктура remoting использует по умолчанию (вслед за DCE RPC) динамически назначаемые номера TCP- и UDP-портов, что делает её крайне сложной в настройке при наличии межсетевых экранов.

- обработка ошибок. В COM принято использовать 32-битные коды ошибки HRESULT, которые имеют значения вроде 0x80070123, и совершенно не читаемы человеком (хотя в последнее время все они легко ищутся поисковыми машинами Интернета).

Кроме того, runtime type information в COM, известная под названием type libraries, поддерживается только для т. н. Automation-compatible интерфейсов, имеющих огромные ограничения на типы параметров (массивы — только SAFEARRAY, строки — только BSTR, никаких произвольных структур, только числа, дата/время, массивы, строки и ссылки на другие Automation-compatible объекты).

Заметно, однако, что многие из этих недостатков являются платой за достоинство COM — независимость от языка программирования и исполняющей среды, и не существуют в «истинно объектных» языках, таких, как C#, или же (прекращенная) реализация Java компании Microsoft. Эти языки предоставляют и полную runtime type information, и отсутствие необходимости регистрации, и возможность написания как интерфейсов, так и классов стандартным для языка образом, без «прокладок» вроде ATL. Так, в MS J++ любой класс Java тривиально публиковался внешнему миру как класс COM, достаточно было лишь регистрации. То же существует и в C#.

С противоположной стороны, «истинно объектные» языки либо вообще не способны стыковаться с компонентами из других объектных языков и требуют написания всей системы (и нижележащих подсистем и фреймворков) «сверху донизу» на одном языке в одной исполняющей среде (Java, Objective C), либо же налагают такое же требование хотя и не на язык, но на исполняющую среду (.NET, языки C#, C++ managed и VB.NET).

Более новые аналогичные технологии (например, в мире .NET) пытаются решить эти проблемы. Там обычно стек remoting полиморфен и кастомизируем, что дает возможность самостоятельно выбирать формат вопросов/ответов и транспортный протокол (по умолчанию используется уже не DCE RPC, а SOAP, в качестве формата данных — XML, а в качестве транспорта — HTTP, который не полагается на динамические номера портов).

Использование механизма позднего связывания может существенно снизить производительность по сравнению, например, с вызовом экспортируемой функции из динамической библиотеки. Однако этот механизм применяется только в скриптовых языках, и только в том случае, если язык не поддерживает объявление ссылок на объекты как ссылок на COM-интерфейсы из type libraries (в виде Dim obj As Excel.Workbook), а поддерживает только абстрактные COM-объекты (в виде Dim obj As Object). Кроме того, такой же подход применяется в Objective C и Cocoa.

ЗАКЛЮЧЕНИЕ

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

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

Достоинства­ми технологии COM являются комплексность и универсальность подходов в рамках COM-модели. COM очень прост для простых небольших приложений и чрезвычайно сложен как инструмент создания комплекс­ных систем. Он содержит большое количество «узких» мест – недостаточно гибкую стандартную схему маршалинга, отсутствие состояния объектов, низкую устойчивость к сбоям. Технология не является объектно-ориентированной в классическом смысле этого слова, что в общем случае не способствует простоте ее применения.

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

Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed СОМ -распределенная СОМ).

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Армстронг Т. ActiveX - Создание Web-приложений. – Киев: BHV, 2004.
2. Артемов М.А. Основы COM-технологий. - Волгоград: ВГУ, 2011. – 85 с.
3. Близнюк А.В. Создание и применение компонентов COM // Вестник Санкт-Петербургского университета. Прикладная математика. Информатика. Процессы управления. 2010. № 1. С. 117-128.
4. Компонентная объектная модель JavaBeans. URL: http://www.javaportal.ru/java/articles/javabeans.html
5. Основы технологии COM. URL: http://bourabai.kz/alg/com/gl09.htm
6. Подборка статей о COM. URL: http://www.developing.ru/com/index.html
7. Раздел COM/DCOM/COM+ на сайте RSDN. URL: http://rsdn.org/summary/247.xml
8. Роберт Дж. Оберг. Технология COM+. Основы и программирование 2000 First Edition. — М.: «Вильямс», 2000. — 480 с.
9. Роберт Дж. Оберг, Питер Торстейнсон. Архитектура .NET и программирование на Microsoft Visual C++. — М.: «Вильямс», 2009. —650 с.
10. Рофейл Э., Шохауд Я. COM и COM+. Полное руководство / пер. с англ. В. Рубцова, М. Граче­вой. Энтроп, 2000. - 250 c.
11. Сравнение COM и CORBA. URL: http://kunegin.narod.ru/ref3/corba5/12.htm
12. Технология COM. URL: http://cubook.supernew.org/7-articles/290-tekhnologiya-com