COM - это Component Object Model, т.е. Компонентная Объектная Модель. Модель эта разработана фирмой Microsoft и служит разработчикам программного обеспечения уже более 10 лет.

COM не является единственной доступной в настоящее время объектной моделью, и даже не является самой развитой из имеющихся. Существуют альтернативные модели, например, CORBA, которая поддерживается OMG (Object Management Group) и реализована на различных аппаратных и программных платформах.

COM реализована в среде операционных систем семейства Microsoft Windows. COM имеет эталонную реализацию от Microsoft. Это обеспечивает высокую степень совместимости компонентов, написанных различными производителями ПО. Проблемы совместимости весьма актуальны, например, для той же CORBA, которая при ее отсутствии в принципе могла бы составить весьма существенную конкуренцию COM.
Объектная модель Microsoft возникла не сразу, она развивалась более 10 лет, время от времени меняя название. Аббревиатуры OLE, OLE2, COM, DCOM, COM+, ActiveX - это различные ипостаси COM.

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

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

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

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

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

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

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

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

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

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

Сравнение объектов C++ и СОМ

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

Другое важное свойство СОМ известно под названием независимости от местоположения (Location Transparency). Независимость от местоположения означает, что пользователь компонента, клиент, не обязательно должен знать, где находится определенный компонент. Клиентское приложение использует одинаковые сервисы СОМ для создания экземпляра и использования компонента независимо от его фактического расположения. Компонент может находиться непосредственно в адресном пространстве задачи клиента (DLL-файл), в пространстве другой задачи на том же компьютере (ЕХЕ-файл) или на компьютере, расположенном за сотни миль (распределенный объект). Технологии СОМ и DCOM (Distributed СОМ - распределенная СОМ) обеспечивают независимость от местоположения. Другими средствами, реализующими эту способность, являются сервисы распределенных объектов. Аналогичные возможности обеспечивает стандарт CORBA. Поскольку клиентское приложение взаимодействует с СОМ - компонентами, вне зависимости от их положения, одинаковым образом, интерфейс клиента тоже не меняется. Независимость от местоположения позволяет разработчику создавать масштабируемые приложения.

Основная особенность COM - это независимость от языка программирования. Нередко встречается ситуация, когда клиентское приложение, написанное на Visual Basic, использует компоненты, созданные посредством Visual C++. Для достижения этой независимости в COM имеются собственный механизм передачи параметров и собственная система типов, нейтральные по отношению к используемым языкам программирования.

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

Тип данных VARIANT знаком тем, кто имеет опыт работы с MS Visual Basic, поскольку из всех систем программирования из состава MS Visual Studio именно VB имеет наибольшую ориентацию в направлении СОМ. Переменная типа VARIANT может хранить практически что угодно: логическое, целочисленное или действительное значение, дату, указатели на них, на массив или интерфейс и т.п. Причем такая переменная хранит не только значение, но и «знает», к какому типу оно относится. Это позволяет наладить контроль типов на этапе выполнения, поскольку компилятор не знает, что на самом деле окажется в этой переменной в дальнейшем.

Физическая реализация типа VARIANT весьма проста. Если посмотреть ее описание на языке С, то мы увидим простую структуру с двумя полями: тег (VARTYPE vt), который хранит информацию о типе содержимого переменной (VARTYPE - это перечисление всевозможных «подтипов» VARIANT), и объединение (union), в котором собраны воедино все эти подтипы.

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

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

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

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

Разнообразие разновидностей COM возникло скорее из-за разнообразия решаемых задач, а не из-за каких-либо пороков, присущих самой модели.

Так, например, область ActiveX - это соответствующие элементы управления, которые выполняются в контексте вызвавшего их процесса (так называемые in-proc servers). Зачастую эти элементы имеют графический интерфейс (всевозможные кнопочки, окошки и т.п.), хотя это и не обязательно, попадаются элементы, лишенные визуального представления, вроде ADO. Типичный пример - палитра инструментов Visual Basic 6.0, изобилующая элементами управления ActiveX, которые достаточно перетащить мышкой на окно формы.

OLE Automation - другой раздел COM. Здесь клиент уже управляет самостоятельным приложением, которое выполняется в контексте собственного процесса, в изолированной области памяти. Разумеется, управлять таким способом можно далеко не каждым приложением. Оно должно быть написано специальным образом, в виде сервера Automation. К счастью, очень многие популярные приложения написаны именно как сервера COM, включая Microsoft Office, Microsoft Visio, программы семейства Corel Draw, интегрированная оболочка Visual Studio и т.д. Таким образом, у программиста появляется выбор реализовывать сложное оформление и вывод документа на печать самостоятельно или же воспользоваться для этой цели тем же MS Word, управляя им посредством OLE Automation.

Еще один пример - DCOM, т.е. Distributed COM, - распределенная разновидность COM, способная работать в локальной сети. Используя DCOM, можно, например, воспользоваться компьютером соседа и выполнить расчет таблицы в среде Excel, при этом будут задействованы ресурсы другого компьютера, останется только дождаться готового результата и получить его в свое распоряжение. Таким образом, можно строить распределенные приложения, в которых специально выделенные серверы приложений, оснащенные соответствующим образом, решают определенные задачи по запросам клиентов и выдают им готовые результаты.

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

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

Приложение, которое написано специальным образом и может управляться извне, называется «сервером автоматизации OLE» (Automation Server). Например, приложения из состава MS Office являются серверами автоматизации, что делает их намного полезнее обычного текстового редактора или табличного процессора. Также управляемыми через OLE Automation являются Visual Studio, MS Visio, пакет Corel Draw, почтовые программы и многие другие популярные приложения.

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

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

На практике необходимо начать с написания простейшего клиента, который обращается к услугам одного из готовых серверов, например, MS Excel. Проще всего это сделать в среде MS Visual Basic V6, хотя при хорошем знакомстве с С++ можно воспользоваться и им. Правда, VB скроет от программиста большинство деталей взаимодействия клиента и сервера, в то время как в С++ все они будут как на ладони.

Заключение

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

В среде СОМ большое значение имеет реестр Windows. Его роль состоит в управлении несколькими разделами, используемыми как СОМ, так и программами клиента. В СОМ широко используется понятие GUID -- уникального 128-разрядного числа, однозначно идентифицирующего интерфейсы и компоненты. В состав СОМ входят несколько Win32 API и большой набор объявлений интерфейсов.

Активная библиотека шаблонов (ATL) представляет собой структуру, облегчающую создание небольших СОМ компонентов. В ATL использованы новейшие средства создания шаблонов C++. Она снабжена также исходной программой, представляющей собой часть среды разработки Visual C++. Создание проекта начинается с определения способа реализации хранилища. В этом существенную помощь оказывает утилита ATL СОМ AppWizard. После этого для добавления определенных компонентов используется мастер объектов ATL. В состав ATL входят несколько классов, обеспечивающих реализацию по умолчанию наиболее общих потребностей СОМ. Класс CComModule обеспечивает основную поддержку по организации хранилища посредством реализации функций DllGetClassObject и DilCanUnloadNow. Благодаря компоненту ATL Registrar обеспечивается также поддержка саморегистрации, что облегчает обновление регистра Windows.

Литература

1. Том Армстрон "ActiveX-Создание Web-приложений"

2. http://www.microsoft.com

3. http://www.codenet.ru