Использование информационных технологий COM, DCOM, CORBA в качестве средств повышения эффективности управления предприятием

ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ ГОРОДА МОСКВЫ Государственное автономное образовательное учреждение среднего профессионального образования ПОЛИТЕХНИЧЕСКИЙ КОЛЛЕДЖ № 8

имени дважды Героя Советского Союза И. Ф. Павлова

(ГАОУ СПО ПК № 8 им. И.Ф. Павлова) КУРСОВАЯ РАБОТА Предмет: Разработка и эксплуатация информационных систем Тема: Использование информационных технологий COM, DCOM, CORBA в качестве средств повышения эффективности управления предприятием ИСПОЛНИТЕЛЬ: Намжиу Сергей Иванович Москва, 2013 г Содержание Введение Глава первая. Технология распределенных вычислений CORBA

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

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

Глава первая. Технология распределенных вычислений CORBA

Технология распределенных вычислений CORBA (Common Object Request Broker Architecture) предложена ассоциацией OMG (Object Management Group). Это инвариантная к приложениям и языку программирования компонентно-ориентированная (объектная) сетевая технология. Архитектура CORBA представлена на рис. 1.

Схематично взаимодействие компонентов в технологии CORBA можно представить следующим образом. Клиент обращается с запросом на выполнение некоторой процедуры или получение некоторых данных. Запрос направляется к посреднику, называемому ORB (Object Request Broker), который способен выполнить действия, необходимые для нахождения нужного объекта в сети и его подготовки к обработке запроса. В посреднике имеется предварительно сформированный каталог (реестр или репозитарий) интерфейсов процедур с указанием компонентов-исполнителей. Посредник перенаправляет запрос соответствующему исполнителю. Исполнитель может запросить параметры процедуры. После выполнения процедуры полученные результаты возвращаются клиенту.

Рис. 1. Архитектура CORBA

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

Для описания интерфейсов и для организации связи клиента с серверными компонентами используется язык IDL (предложенный OMG и не совпадающий с языком IDL в RPC). Язык IDL в CORBA позволяет описывать интерфейсы создаваемых компонентов. Описание, называемое метаданными, представляется в виде модуля метаданных, модуль включает заголовок, описания типов данных, интерфейсов и операций. В заголовке указывается идентификатор модуля. В части типов данных перечисляются атрибуты, возвращаемые значения, исключительные ситуации. Примерами типов данных могут служить типы базовые (например, float, double, char, boolean, struct), конструируемые пользователем (например, записи и массивы) и объектные ссылки, указывающие на интерфейсы компонентов. Описание интерфейсов начинается с ключевого слова interface, за которым следуют идентификаторы данного интерфейса и возможно наследуемых интерфейсов. Далее описываются операции (методы) в виде идентификаторов операций с возможными перечислениями параметров операций и указанием их принадлежности к входным или выходным данным.

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

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

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

Физически репозитарий интерфейсов является программным компонентом, имеющим собственный IDL-интерфейс. Через этот интерфейс различные приложения и получают данные о других CORBA-объектах.

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

Стабы используются для обеспечения взаимодействия клиента и сервера, функционирующих в разных адресных пространствах или на разных компьютерах (в том числе и в разных операционных системах). В терминологии CORBA они называются stub и skeleton. Stub (стаб) — это представитель сервера в адресном пространстве клиента (иногда для его обозначения используют и термин proxy). Skeleton (скелетон) — это представитель клиента в адресном пространстве сервера.

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

Клиентское приложение взаимодействует со stub-объектом, вызывая его методы (названия которых совпадают с названиями методов серверного объекта). В действительности stub-объект обращается к клиентской части Object Request Broker (ORB), обращающейся, в свою очередь, к специализированному сервису middleware — Smart Agent (он может функционировать на каком-либо из компьютеров сети), представляющему собой не что иное, как directory service — службу, обеспечивающую поиск доступного сервера, содержащего реализацию запрашиваемого клиентом объекта.

Когда сервер найден, в его адресном пространстве создается запрошенный серверный объект, содержащий, в свою очередь, skeleton-объект, которому ORB передает запрос клиента с помощью базового объектного адаптера Basic Object Adapter (BOA). BOA — это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Используя эту службу, skeleton регистрирует созданный серверный CORBA-объект с помощью Smart Agent, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента.

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

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

При реализации запроса брокер через объектный адаптер активирует соответствующий компонент. Далее клиент-серверное взаимодействие происходит через стабы.

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

именования — присваивает объектам уникальные имена, в результате пользователь может искать объекты в сети по имени;

жизненного цикла — обеспечивает создание, перемещение, копирование и удаление объектов (документов) в системе, в том числе составных объектов вместе со всеми ссылками и ассоциированными объектами;

обработки транзакций — осуществляет управление транзакциями (блокировка, фиксация и откат транзакций) из приложений или из ОС, что позволяет многим объектам в сети использовать одни и те же серверы;

событий — обеспечивает асинхронное распространение и обработку сообщений о событиях, происшедших при реализации процессов, что позволяет заинтересованным объектам координировать свои действия;

обеспечения безопасности — поддерживает целостность данных.

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

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

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

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

Interface (COM-интерфейс) — множество прототипов функций (методов), чисто определенных. Термин «чисто определенный метод» или «абстрактный метод» исходит теории объектно-ориентированного анализа, и означает, что в определении класса отсутствует реализация метода, а присутствует только его определение. От такого класса нельзя создавать объекты. Его предназначение — описать фундаментальные общности для всех производных классов;

COM object (COM-объект) — объект класса CoClass, который содержит реализацию COM интерфейса;

COM/ActiveX server (COM сервер или ActiveX сервер) — модуль, такой как EXE, DLL или OCX, который содержит машинный код COM или ActiveX объектов;

Class factory (фабрика классов) — объект, который может создавать COM-объекты из CoClass;

Type library (библиотека типов) — файл, содержащий информацию о типах данных, которые использует COM/ActiveX сервер.

Библиотека типов (type library) предоставляет информацию об используемых типах объектов и интерфейсах, которые предоставляются ActiveX-серевером. Библиотека типов по смыслу аналогична, например, заголовочному файлу (header) для разработок на языке C и любому другому модулю, содержащему информацию об используемых типах данных и объектах. Большинство информации подобного рода может быть записано в библиотеку типов. Получить информацию из библиотеки типов можно путем опроса запущенного объекта или же посредством загрузки непосредственно библиотеки типов. После создания библиотеки типов, к ней обеспечивается доступ через специальный тип интерфейсов: ITypeLib, ITypeInfo и ITypeComp. Интерфейс ITypeLib обеспечивает доступ к информации о типах в библиотеке типов, а также к описаниям конкретных объектов, которые, в свою очередь, могут быть получены через интерфейс ITypeInfo.

Библиотека типов содержит информацию о том, какой интерфейс, в каком COM-объекте содержится, количество и тип методов интерфейсов и их параметров. Эти описания включают в себя уникальные идентификаторы классов (CLSID) и их интерфейсов (IID), через которые осуществляется корректный доступ к объектам. В библиотеке типов также может содержаться следующая информация:

Описания пользовательских типов данных, связанных с пользовательскими интерфейсами;

Функции, которые экспортируются ActiveX-сервером, но которые не являются интерфейсными методами;

Информация об энумерованных типах данных (символьных константах);

Ссылки на описания типов в других библиотеках типов.

Использование библиотеки типов очень важно для объектов, которые предназначены для распространения и последующего использования многими пользователями. Также существует еще ряд причин использования библиотек типов:

Объекты, которые используют непосредственную привязку к vtable, должны быть описаны в библиотеке типов, т.к. ссылки в vtable формируются во время компиляции;

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

Элементы управления ActiveX должны иметь библиотеку типов, которая содержится непосредственно в DLL или OCX файле, содержащем код ActiveX-сервера;

Приложения, которые являются Automation-серверами, должны иметь библиотеку типов, для более удобно связывания с клиентами;

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

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

COM и DCOM — технологии, обеспечивающие взаимодействие между компонентами приложения и позволяющие развертывать распределенное приложение на платформе Windows. COM является моделью программирования на основе объектов, которая упрощает взаимодействие различных приложений и компонентов, а DCOM — это своего рода «клей», связывающий воедино разнообразные технологии, применяемые в распределенных приложениях. DCOM дает возможность двум или нескольким компонентам легко взаимодействовать друг с другом независимо от того, когда и на каком языке программирования они были написаны, а также где именно они находятся и в какой операционной системе работают.

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

Преимуществом DCOM является значительная простота использования. Если программисты пишут свои Windows-приложения с помощью ActiveX (предлагаемого Microsoft способа организации программных компонентов), то операционная система будет автоматически устанавливать необходимые соединения и перенаправлять трафик между компонентами, независимо от того, размещаются ли компоненты на той же машине или нет.

Способность DCOM связывать компоненты позволила Microsoft наделить Windows рядом важных дополнительных возможностей, в частности, реализовать сервер Microsoft Transaction Server, отвечающий за выполнения транзакций баз данных через Internet. Новая же версия COM+ еще больше упростит программирование распределенных приложений, в частности, благодаря таким компонентам, как базы данных, размещаемые в оперативной памяти.

Однако у DCOM есть ряд недостатков. Это решение до сих пор ориентировано исключительно на системы Microsoft. DCOM изначально создавалась под Windows. Хорошо известно, что Microsoft заключила соглашение с компанией Software AG, предмет которого — перенос DCOM на другие платформы.

В числе недостатков и то, что архитектура предусматривает использование для поиска компонентов в сети разработанной Microsoft сетевой службы каталогов Active Directory, появившейся в Windows начиная с версии 2000. Это приводит к зависимости пользователя от соотвествующих служб Microsoft и резко снижает безопасность использования такой технологии.

Глава вторая. Oсновные архитектурные принципы Основное назначение CORBA и COM — поддержка разработки и развертывания сложных объектно-ориентированных прикладных систем.

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

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

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

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

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

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

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

В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, использует механизм объектный вариант вызова удаленной процедуры (RPC, remote procedure call). Структура RPC — старейшей из технологий промежуточного программного обеспечения. Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу.

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

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

Строго говоря, рассуждая о вызове удаленных объектов и используя при этом аббревиатуру СОМ, мы не вполне точны. Взаимодействие объектов на разных узлах сети реализовано в расширенном варианте этой технологии, Distributed COM (DCOM), который, в свою очередь, базируется на объектном расширении спецификации DCE RPC. DCOM появилась в 1996 году вместе с операционной системой Windows NT 4.0.

Исходная же модель СОМ была представлена Мicrosoft в 1993 году как интеграционная схема для поддержки OLE, технологии построения составных документов в ОС Windows 3.1. Первоначально инфраструктура СОМ позволяла реализовывать компоненты, взаимодействующие в рамках одного адресного пространства или между процессами на одном компьютере, и представляла собой фактически средство динамической интеграции двоичных компонентов. Помимо OLE, модель СОМ послужила основой таких технологий Microsoft, как монитор транзакций Microsoft Transaction Server и архитектура интеграции прикладных компонентов ActiveX.

В отличие от СОМ, архитектура CORBA [1,2] с самого начала создавалась для распределенных объектных систем. Ее автором является не отдельно взятая фирма, а консорциум Object Management Group (сейчас в него входят более 800 компаний), поставивший своей целью разработать стандартную архитектуру для взаимодействия объектов в неоднородной сетевой среде.

Среди компаний, основавших OMG, были в основном производители компьютерных систем различного уровня и интеграторы с мировым именем, такие, например, как IBM, DEC, HP. Проблема развертывания приложений на смеси из самых разнородных платформ — от мэйнфреймов и Unix-компьютеров до персональных компьютеров — для них стояла очень остро. Консорциум OMG стремился объединить объектную технологию и принципы построения клиент-серверных распределенных систем, с тем чтобы предложить архитектуру, способную эффективно поддерживать взаимодействие приложений в сложной неоднородной корпоративной среде.

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

Ядром архитектуры CORBA (рис. 3) является брокер объектных запросов (Object Request Broker, ORB). Это объектная шина, по которой в стиле, напоминающем классический механизм RPC, происходит взаимодействие локальных и удаленных объектов. В отличие от СОМ, ORB не опирается непосредственно на механизм RPC, но работает по тем же принципам. Помимо самого вызова метода удаленного объекта, ORB отвечает за поиск реализации объекта, его подготовку к получению и обработке запроса, передачу запроса и доставку результатов клиенту.

Кроме того, CORBA включает в себя несколько групп реализаций объектов, а именно прикладные объекты, объектные службы, общие средства и домены. Прикладные объекты (Application Objects) представляют собой реализации объектов для конкретных пользовательских приложений, например, объекты для поддержки специфических бизнес-процессов. Реализации объектов, предоставляющие общие для любой объектно-ориентированной среды возможности, входят в категорию объектных служб (CORBA services): служба имен, служба событий, служба сохранения в долговременной памяти, служба транзакций и т. д. Общие средства (CORBA facilities) — это реализации объектов, необходимые для большого числа приложений, например, поддержка составных документов, потоков заданий и др. В CORBA есть также понятие домена; реализации объектов домена (CORBAdomains) предназначены для приложений вертикальных рынков — здравоохранения, страхования, финансового рынка, производственных отраслей и т. д.

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

Объектные модели

Итак, в моделях CORBA и COM клиент получает обслуживание от сервера объекта, запрашивая метод, заданный в интерфейсе объекта. Важной характеристикой обеих технологий является четкое разграничение интерфейсов, которые — суть абстрактный набор связанных методов, и конкретных реализаций этих методов. Клиенту доступно описание интерфейса объекта, через которое он получает доступ к методам, то есть функциональности данного объекта. Детали реализации методов от клиента полностью изолированы. Метод вызывается по ссылке, и реальные действия выполняются в адресном пространстве объекта.

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

В CORBA интерфейс объекта задается с помощью определенного OMG языка описания интерфейсов (Interface Definition Language, IDL). Тип объекта — это тип его интерфейса. Интерфейс идентифицируется именем, представленным цепочкой символов. В модели CORBA определен базовый тип для всех объектов — CORBA: Object. Объект поддерживает тип своего непосредственного интерфейса и, по принципу наследования, все его базовые типы.

В СОМ объект характеризуется своим классом. Класс — это реализация некоторого множества интерфейсов. Множественное наследование интерфейсов не поддерживается, вместо этого объект может иметь несколько интерфейсов одновременно. В СОМ интерфейс может определяться путем наследования другого интерфейса. Для всех интерфейсов существует базовый интерфейс — IUknown. Для того чтобы перейти от интерфейса базового типа к унаследованному интерфейсу или от одного из интерфейсов объекта к другому, клиент должен вызывать метод QueryInterface, определенный в базовом интерфейсе IUknown. Интересно отметить, что возможность описания нескольких интерфейсов для одного объекта должна появиться теперь и в CORBA; анонсированная в сентябре прошлого года версия CORBA 3.0 в числе важных нововведений содержит и концепцию Multiple Interface.

Для идентификации классов и интерфейсов СОМ используются те же универсальные уникальные идентификаторы (UUID), которые приняты для идентификации интерфейсов в спецификации DCE RPC. Можно применять и символьные обозначения интерфейса, но затем они должны быть транслированы в надлежащий идентификатор UUID. Объект в СОМ — это экземпляр класса. Клиент получает доступ к объекту с помощью указателя на один из его интерфейсов (interface pointer). Связь между классом и множеством поддерживаемых им интерфейсов достаточно произвольна. Не существует заранее заданного отношения между идентификатором класса и конкретным набором интерфейсов, и разные экземпляры класса могут поддерживать разные подмножества интерфейсов. Идентификатор класса ссылается на конкретную реализацию, и фактический набор интерфейсов для данной реализации становится окончательно известен только на стадии выполнения.

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

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

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

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

Различие между языками IDL по версии OMG и Microsoft — одно из наиболее значительных для двух объектных моделей. В CORBA язык описания интерфейсов — важнейшая часть архитектуры, основа схемы интеграции объектов. Все интерфейсы и типы данных определяются на IDL. Различные языки программирования поддерживаются благодаря заданным отображениям между описаниям типов данных на IDL в соответствующие определения на конкретном языке. CORBA IDL задает определения, которые могут отображаться в множество различных языков, не требуя при этом никаких изменений от целевого языка. Эти отображения реализуются компилятором IDL, который генерирует исходные коды на нужном языке. В настоящий момент поддерживается отображение в Си, Си++, SmallTalk, Ada95, Visual Basic, Кобол Cobol и Java. Сам IDL синтаксически напоминает декларации типов в Си++, но отнюдь не идентичен этому языку.

Если в модели интеграции объектов CORBA язык IDL играет фундаментальную роль, то Microsoft IDL (MIDL) — лишь один из возможных способов определения интерфейсов объекта. В спецификации СОМ подчеркивается, что эта модель реализует интеграцию на двоичном уровне, поэтому все спецификации и стандарты, относящиеся к уровню исходных текстов компонентов, к которым следует причислить и MIDL, рассматриваются как вспомогательные и не могут оказывать решающего влияния на общую архитектуру системы.

MIDL — не более чем полезный инструментарий для написания интерфейсов. В отличие от CORBA IDL, MIDL, являющийся расширением DCE RPC IDL, не определяет общего набора типов данных, доступных различным языкам программирования. На MIDL можно определить интерфейсы и типы данных, которые поймут программы на Си и Си++, но для Visual Basic и Java этого уже сделать нельзя. Проблему частично обещает решить новая спецификация СОМ+, которая предоставит возможности встраивания средств определения СОМ-интерфейсов в инструментарий для языков типа Visual Basic и Visual C++.

Обе объектные модели предусматривают ситуацию, когда у клиента уже в процессе выполнения программы возникает потребность использовать те или иные объекты. В этом случае у клиента не будет скомпилированных команд для вызова методов, поскольку интерфейс объекта не был известен на этапе компиляции. Поэтому ему потребуются специальные интерфейсы динамического вызова. В CORBA механизм DII (Dynamic Invocation Interface) опирается на Interface Repositоry, который содержит написанные на IDL определения типов данных и интерфейсов. Конкретная реализация такого репозитария зависит от разработчика брокера объектных запросов ORB. Помимо динамических вызовов, репозитарий интерфейсов в CORBA может использоваться для систематической организации и хранения данных определенного проекта. В СОМ те же функции выполняют интерфейс Dispatch и библиотеки типов Type Libraries.

CORBA и СОМ абсолютно по-разному подходят к проблемам идентификации (identity) объектов и их сохранения в долговременной памяти (persistance). CORBA вводит понятие объектной ссылки (object reference), которая уникальным образом идентифицирует объект в сети. Тем самым экземпляру объекта дается право на существование в течение некоторого времени. Объекты могут активироваться, сохраняться в долговременную память, позже вновь реактивироваться и деактивироваться, и при этом объектная ссылка будет указывать все время на одно и то же конкретное воплощение объекта. Для особо значимых объектов, предназначенных для длительного использования, объектные ссылки могут интегрироваться со службой каталогов или службой имен.

Механизм долговременного хранения, то есть сохранения состояния объекта в долговременной памяти для дальнейшей его реактивации, в CORBA абсолютно прозрачен для клиента. Клиент не имеет никаких легальных средств обнаружить: куда и каким образом сохраняется экземпляр объекта. Такой подход соответствует концепции сокрытия деталей реализации объекта от клиента.

В СОМ понятие объектной ссылки отсутствует. Ближайший аналог — это механизм moniker («кличка»), обеспечивающий преобразование символьного имени объекта в указатель интерфейса. Этот механизм действует для тех объектов, которые сохраняются в долговременной памяти. Два же активных объекта считаются идентичными, если для них совпадают указатели на интерфейс IUknown.

Для долговременного хранения в СОМ поддерживаются две модели. Первая и изначальная модель предоставляет клиенту возможность управлять хранением объекта. В интерфейсе объекта, предназначенного для долговременного хранения, поддерживаются возможные типы носителей. Если необходимо восстановить объект из долговременной памяти, клиент явным образом указывает, где был сохранен экземпляр объекта и запрашивает его активацию. Однако, такая модель эффективна, скорее всего, только в настольной среде или в небольшой локальной сети, где управление хранением документов, к примеру, может быть доверено пользователю файловой системы. Другой, более поздний вариант сохранения в долговременную память в СОМ предусматривает использование Microsoft Transaction Server (MTS), который обеспечивает управление хранением со стороны сервера.

Поддержка операционных систем, предлагаемые службы и масштабируемость

Помимо механизмов интеграции объектов, СОМ и CORBA предоставляют набор предопределенных объектных служб общего значения, без реализации которых, как правило, не обходится ни одна прикладная среда. Перечень и назначение одноименных служб в двух объектных архитектурах не идентичны. В СОМ предусмотрены такие общие службы, как защита (security), управление жизненным циклом (lifecycle managemеnt), информация о типах (type information), именование (naming), доступ к базам данных (database access), передача данных (data transfer), регистрация (registry) и асинхронное взаимодействие. В CORBA информация о типах и регистрация входят в число базовых функций брокера объектных запросов ORB. Служба именования в CORBA — это каталог, в котором заданы соответствия между объектами и их именами. В СОМ под именованием подразумевается схема преобразования имен в указатели на объект с помощью механизма moniker.

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

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

Службы СОМ и серверы MTS и MSMQ реализованы на платформах Windows 95 и Windows NT и тесно интегрированы со службами самих этих операционных систем. Подобная интеграция нацелена на создание на базе Windows гибкой и надежной среды разработки и исполнения объектно-ориентированных систем. Microsoft стремится сделать свою платформу максимально привлекательной для разработчиков приложений, но проявляет и определенную заботу об интеграции с унаследованными системами. Для этих целей существуют, например, средства OLE DB for AS/400, СОМ Transaction Integrator для CICS и IMS, предоставляющий доступ к системам оперативной обработки транзакций IBM, сервер Microsoft SNA.

Следуя общим принципам архитектуры CORBA, интерфейсы ее объектных служб (спецификация CORBAservices) написаны на IDL. Определено 15 общих служб CORBA: именования (naming); событий (events); жизненного цикла (life cycle); долговременного хранения объектов (persistent); транзакций (transactions); контроля за доступом к разделяемым ресурсам (concurrency control); отношений (relationsips); импорта/экспорта (externalization); запросов (query); лицензирования (licensing); свойств (property); времени (time); защиты (security); переговоров между объектами (object trader); сбора объектов (object collections).

Объектные службы CORBA следуют строгой согласованной модели. Наиболее значимые из них присутствуют по крайней мере в одной из многочисленных реализаций архитектуры. К самым распространенным относятся службы именования, управления жизненным циклом и событиями, которые были первыми из принятых OMG. Более поздние предложения OMG, например, служба транзакций, пока имеют более ограниченный спектр реализаций. Наименее успешными оказались реализации службы долговременного хранения, и ее спецификация будет заменена в CORBA 3.0 на новую — Persistent State Service (PSS). В этой версии появятся также новая служба именования Interoperable Naming Service для прозрачного поиска и вызова объектов, не зависящего от конкретной реализации ORB, и служба асинхронного обмена сообщениями Asynchronous Messaging.

До 1998 года реализации СОМ ограничивались NT и Windows 95. Сейчас Microsoft, как кажется, начинает поворачиваться лицом и к другим операционным системам. Правда, поначалу политика корпорации состояла в том, чтобы привлекать третьи фирмы к реализации СОМ на других платформах. Так, версия СОМ для Sun Solaris была разработана компанией Software AG. О своих намерениях перенести СОМ на платформу OpenVMS объявила Compaq. Однако, судя по последним заявлениям, Microsoft намерена в дальнейшем собственными силами решать проблемы переноса СОМ.

Мы уже упоминали об ограничениях языковой поддержки в СОМ. Новый вариант объектной модели, СОМ+, помимо реализации множественного наследования интерфейсов и новых возможностей времени выполнения, обещает предоставить языковые расширения, призванные упростить разработку компонентов СОМ на языках Java, Visual Basic и Visual C++. Правда, в отличие от CORBA, где трансляция описаний на IDL в конкретный язык осуществляется наиболее естественным для этого языка способом и не требует никаких его модификаций, в СОМ+ будут включены средства настройки языка для поддержки компонентов СОМ.

Если Visual Basic тесно привязан к операционным системам Microsоft, то Java по сути своей — многоплатформенный язык. В виртуальную Java-машину от Microsоft были добавлены средства поддержки СОМ. Благодаря этому объекты на Java без проблем отображаются в СОМ — но только при использовании Microsоft JVM. Чтобы преодолеть это ограничение, Microsоft надо либо реализовать виртуальные Java-машины для других платформ, либо обеспечить поддержку СОМ в Java, минуя JVM.

В CORBA изначально была заложена многоплатформенность и поддержка множества популярных языков программирования без необходимости каких-либо изменений в них. Поэтому реализации CORBA могут использоваться с произвольными компилятором, средствами разработки и операционной системой. По существу, объектный брокер запросов реализуется на большем числе платформ Microsoft, чем сама СОМ, включая Windows 3.1, Windows 95, Windows NT 3.5, Windows 4.0 и DOS. Cтандартно поддерживается значительный диапазон языков. Отображения объектов CORBA в другие языки, например, в тот же Visual Basic, пока не являются стандартными возможностями данной архитектуры, но наличествуют в некоторых реализациях.

Отображения CORBA-интерфейсов в Java не требуют никаких изменений от виртуальной Java-машины. Реализации компаний Iona, Sun и Visigenic предлагают службы CORBA времени выполнения, написанные на Java. Это означает, что в браузер можно загрузить апплет Java, который сможет обращаться к серверу CORBA без предварительной установки средств поддержки CORBA.

Зрелость и разнообразие объектных служб общего назначения, которые позволяют создать реально работающую объектную систему, и спектр поддерживаемых платформ — ключевые факторы при оценке масштабируемости объектной архитектуры. А масштабируемость — ключевая характеристика корпоративной системы. Обе модели предлагают широкий спектр общих служб, однако, СОМ, как и все детища Microsoft, не может похвастаться реальной многоплатформенностью. Это серьезный изъян для системы, которая претендует на роль фундамента для распределенных приложений в крупных организациях. Корпоративная система может охватывать тысячи пользователей, хранить терабайты данных и выполнять десятки тысяч транзакций в день.

Формальное описание архитектуры и проблемы реализации

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

CORBA определяется с помощью формализованной спецификации, написанной на языке IDL. Появлению очередной версии предшествуют четко организованный процесс адаптации нового стандарта, который обычно завершается быстрее, чем аналогичные процедуры в ISO. В результате CORBA может похвастаться значительным числом реализаций. Первоначальный вариант спецификации появился в 1991 году, и уже в 1992;м был выпущен коммерческий продукт — брокер объектных запросов DEC ObjectBroker.

Спецификация CORBA — это строго организованное описание, не обремененное деталями реализации, которые оставляются на долю разработчиков конкретных продуктов. Обилие реализаций от разных поставщиков с одной стороны стимулирует конкуренцию и, как следствие, совершенствование технологии, но с другой — порождает проблемы несовместимости разнородных продуктов. Так, спецификация CORBA включает определение Basic Object Adapter, который обеспечивает доступ к сервисам брокера объектных запросов со стороны сервера объекта. Эта часть спецификации оказалась слишком общей, так что разработчики получили слишком большую степень свободы в реализации собственных объектных адаптеров. В итоге, часто оказывалось невозможно перенести серверные компоненты архитектуры с одного ORB на другой. В новой спецификации переносимого объектного адаптера (Portable Object Adapter, POA) делается исправить этот недостаток.

Различные брокеры запросов взаимодействуют между собой по протоколу General Inter ORB Protocol (GIOP). В связи с активным переносом в среду Web критически важных корпоративных приложений наибольший интерес представляет реализация протокола GIOP на базе TCP/IP — протокол Internet Inter ORB Protocol (IIOP).

Спецификация СОМ разработана Microsoft, принадлежит Microsoft и контролируется только Microsoft. В отличие от CORBA, это не столь строго организованный документ. Деталей в описании достаточно, однако они не всегда уместны. Так, например, в спецификации подробно определяется модель Connectable Objects, которая лежит в основе механизма обработки событий в Visual Basic, но не имеет явной поддержки в самой СОМ. А раздел описания библиотеки типов, необходимого компонента для динамического вызова методов, не содержит практически никаких подробностей реализации, и разработчику приходится искать их в других источниках, например, в документации по SDK для ОС Windows.

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

Обе спецификации постепенно все больше и больше разрастаются. Так, постоянно растет число поддерживаемых API-интерфейсов в архитектуре СОМ. В CORBA становится все больше IDL-интерфейсов, описывающих новые службы. И это усложняет задачу поддержания документов в согласованном и удобном для использования виде, и для одной компании, как в случае СОМ, и тем более для целого конгломерата организаций, который представляет собой Консорциум OMG.

В CORBA, некоторые службы, например, Collections и Queries, перекрываются по реализуемым функциям, и существует сразу три стандарта, описывающих базовые концепции метамодели — Object Management Architecture, Meta-Object Facility и Business Object Facility.