Технологии интеграции информационных систем на предприятии: OLE, CORBA, Web-решения и др

CORBA ORB предоставляет широкий набор распределенных middleware услуг. Шина ORB позволяет объектам находить друг друга прямо в процессе работы и вызывать друг у друга различные службы. Она является гораздо более тонкой системой, чем другие клиент/сервер middleware-системы, такие как RPC (Remote Procedure Calls) или MOM (Message-Oriented Middleware).

От RPC к ORB

Чем механизм вызовов CORBA отличается от механизма RPC? Да, эти механизмы похожи, но тем не менее между ними есть серьезные различия [5]. С помощью RPC можно вызвать определенную функцию. А с помощью ORB можно вызвать метод у определенного объекта. Разные объекты классов могут по-разному отвечать на вызов одного и того же метода. Так как каждый объект управляет своей собственной (в добавок личной) информацией, то метод будет вызван на сугубо конкретных данных.

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

Достоинства ORB

В теории, CORBA представляется как лучшая клиент/сервер middleware-система, но на практике она хороша лишь настолько, насколько хороши продукты, ее реализующие. К основным коммерческим ORB относятся: Orbix от фирмы IONA Technologies; DSOM от IBM; ObjectBroker от Digital; JOE от Sun; Visibroker от Visigenic и Netscape; ORB+ от HP.

Небольшой список тех выгод, которыми обладает каждая CORBA ORB [5]:

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

Отображение в языки высокого уровня. CORBA ORB позволяет вызывать методы у серверных компонент используя любой из некоторого списка языков высокого уровня -- C, C++, SmallTalk, Java и Ada. Совершенно неважно, на каком языке написаны объекты. CORBA отделяет интерфейсы от реализации и предоставляет языково-независимые типы данных, что позволяет осуществлять вызов методов, минуя границы какого-то конкретного языка программирования и конкретной операционной системы.

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

Прозрачность. ORB может выполняться как сам по себе (например на портативном компьютере), так и в окружении целого мира других ORB, с которыми она взаимодействует путем CORBA 2.0 IIOP (Internet Inter-ORB Protocol) протокола. ORB может осуществлять меж-объектное взаимодействие и для одного процесса, и для нескольких процессов, выполняющихся на одной машине, и для процессов, чье выполнение происходит в сети, под разными операционными системами. Реализация этих взаимодействий, однако, нисколько не затрагивает сами объекты. В общих чертах, при использовании технологии CORBA, разработчик не должен беспокоиться ни о таких вещах как расположение серверов, запуск (активирование) объектов, выравнивание размера переменных в зависимости от платформы и операционной системы, ни и о том, как осуществляется передача сообщений. Решение всех этих задач берет на себя продукт, поддерживающий стандарт CORBA.

Встроенная безопасность. Все свои запросы ORB дополняет некоторой контекстной информацией которая обеспечивает сохранность данных.

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

Object Services

CORBA Object Services представляет собой набор сервисов системного уровня, представимых в виде компонент с некоторыми определенными IDL-интерфейсами. Эти компоненты, в некотором смысле, дополняют функциональность ORB. Их можно использовать для создания, именования компонент и многого другого. На сегодняшний день OMG определил четырнадцать стандартных сервисов.

К сожалению, практически все коммерческие ORB не поддерживают ни один из сервисов, и лишь немногие (Visibroker) -- один, два.

Common Facilities

Common Facilities (общие средства) заполняют пространство между ORB и объектными службами с одной стороны, и прикладными службами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Object Services -- фундаментальные объектные интерфейсы, а задача Common Facilities -- поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Object Services. Таким образом, операции, представляемые Common Facilities, предназначены, в частности, для использования Object Services и прикладными объектами. Реализуется это посредством наследования стандартных Интерфейсов [7].

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

Application Objects

Объекты, если они участвуют в обмене с ORB, должны определятся с помощью IDL. Обычно приложения состоят из нескольких взаимодействующих бизнес-объектов. И, как правило, приложения-объекты строятся поверх предоставляемых ORB, Common Facilities и Object Facilities сервисов. Суть для заказчиков (или системных интеграторов) заключается в том, чтобы собрать разные бизнес-объекты в одну систему, при том, вне зависимости от производителя.

CORBA - наиболее развитая на сегодняшний день объектная технология распределенного программирования (www.corba.org). CORBA позволит Вам создавать распределенные в пространстве Сети компоненты, причем эти компоненты могут быть написаны на различных языках программирования (например, С и Java), работать на различных операционных системах (например, Linux и Windows NT), просто определяя интерфейсы друг друга и удаленно вызывая открытые методы объектов, из которых состоят Ваши компоненты. Стандарт CORBA разрабатывается крупнейшим на планете консорциумом OMG (www.omg.org) и есть достаточно много хороших реализаций стандарта для различных платформ и языков (часть реализаций представляются с открытыми исходными текстами (www.opensource.org), напр. www.OpenORB.org (Java), ORBit (C)). CORBA может стать основой для будущей технологии компонентного программирования.

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

Практически, для создания распределенных компонентов при программировании в CORBA выполняются обычно как минимум следующие шаги:

       Проектируются распределенные компоненты

       Описываются интерфейсы открытых объектов этих компонентов на языке IDL

       Создаются реализации компонентов (объекты и их клиенты)

       Тестирование компонентов в распределенной среде

       Распределяются компоненты по нужным точкам в Сети

Microsoft DCOM/COM+

Модель распределенных объектов DCOM (Distributed Component Object Model) - это объектное связующее ПО, предложенное корпорацией Microsoft. Оно было разработано на основе созданных ранее и весьма популярных технологий этой компании - OLE (Object Linking and Embedding), COM и ActiveX. Технология объектной компоновки увидела свет в конце 80-х годов и первоначально предназначалась для поддержки широко известной ныне прикладной модели, ориентированной на данные и строящейся на базе составных документов. В начале 90-х годов вышла редакция OLE 2.0, в которой была представлена модель объектов-компонентов (Component Object Model, COM). Эта редакция вскоре стала именоваться просто OLE и в конечном итоге включила в себя широкий спектр технологий, реализуемых поверх COM.

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

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

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

Узел-клиент может запросить объект DCOM (используя стандартные методы интерфейсов, реализуемые всеми объектами DCOM) через какой-либо конкретный интерфейс, идентифицируемый уникальным номером (UUID). Интерфейс считается постоянным: после того как он опубликован, его не разрешается изменять. Добавление новых функций в объект DCOM может производиться только путем создания новых интерфейсов.

В дальнейшем на базе технологий COM, DCOM, ActiveX и MTS (Microsoft Transaction Server) была создана технология COM+. Из-за того что эта технология не была по настоящему кросс-платформенной по причине привязанности к продуктам Microsoft (в частности, MTS), был создан протокол SOAP (Simple Object Access Protocol), который позволил компонентам общаться через Internet.

Хотя между технологиями CORBA и COM/DCOM имеются существенные различия, обе они поддерживают интеграцию компонентов.  И COM/DCOM, и CORBA основываются на собственных языках определения интерфейсов (IDL - Interface Difinition Language). Несмотря на одинаковые названия, эти языки различны и несовместимы. Многие другие разработчики также предлагали свои стандарты для работы с распределенными объектами, но те не получили столь широкого распространения.

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

OLE

Обзор

Из статьи Вы узнаете основные сведения об OLE, некоторые вещи относительно OLE 2 и OLE Automation. В статье рассказывается об использовании объекта TOLEContainer для построения OLE приложения в Delphi.

Основы OLE

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

Аббревиатура OLE обозначает Objects Linked and Embedded (Присоединенные И Встроенные Объекты - ПИВО J). Данные, разделяемые между приложениями называются OLE объектом. Приложение, которое может содержать OLE объекты, называют OLE контейнером (OLE Container). Приложение, данные из которого можно включить в OLE контейнер в виде OLE объекта, называют OLE сервером.

Например, MicroSoft Word может включать в документ графические объекты, аудио- и видеоклипы и множество других объектов (такой документ иногда называют составным документом - compound document).

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

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

В природе существует несколько видов OLE, отличающихся по способу активации OLE сервера. OLE версии 1 запускает сервер в отдельном окне. OLE 2 реализует то, что называется in-place activation and editing. В данном случае сервер запускается "внутри" приложения-клиента, модифицирует вид системного меню, линейки инструментов и др. Развитие идеи OLE привело к появлению OLE automation - приложение-клиент может выполнить часть кода сервера. Тип OLE объекта, помещенного в программу-клиент, определяется тем, какую версию OLE поддерживает сервер.

Объект TOLEContainer

Объект TOLEContainer находится на странице System Палитры Компонент и нужен для создания приложений OLE-контейнеров. TOLEContainer скрывает все сложности, связанные с внутренней организацией OLE и предоставляет программисту достаточно простой интерфейс. Построим простейшее приложение с использованием OLE объекта. Создайте новый проект и поместите на форму TOLEContainer, в Инспекторе Объектов дважды щелкните мышкой на свойство ObjClass или ObjDoc - появится стандартный диалог Windows "Insert Object" (см. рис.1)

Рис.: Стандартный диалог Windows для определения OLE объекта.

В этом диалоге есть список всех зарегистрированных в системе OLE-серверов (регистрация происходит при инсталляции программы). Тип OLE-объекта определяется как раз тем сервером, который Вы укажете. Если Вы создаете новый объект (Create New), то при нажатии кнопки OK запустится программа OLE-сервер, в которой и формируется новый объект. После выхода из программы-сервера новый OLE объект включается (embedded object) в программу. OLE объект можно создать используя уже имеющийся файл в формате одного из OLE-серверов. Для этого нужно выбрать пункт Create from File (см. рис.2)