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

Структура CORBA IDL файла выглядит следующим образом:

    module <identifier> {

         <type declarations>;

         <constant declarations>;

         <exception declarations>; 

         interface <identifier> [:<inheritance>] { 

           <type declarations>;

           <constant declarations>;

           <attribute declarations>;

           <exception declarations>;

           [<op_type>]<identifier>(<parameters>)

           [raises exception] [context]

           .

           .

           [<op_type>]<identifier>(<parameters>)

           [raises exception] [context]

           .

           .

  }

  interface <identifier> [:<inheritance>]

           .

           .

}

Репозитарий Интерфейсов (Interface Repositary), содержащий определения  интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в  сети и программировать их использование  в программах-клиентах.

Object Management Architecture

Осенью 1990 года OMG впервые опубликовала документ Object Management Architecture Guide (OMA Guide). Он был подкорректирован в сентябре 1992. Детали Common Facilities (Общие средства) были добавлены в январе 1995. Следующий рисунок показывает четыре основные элемента этой архитектуры:

Рисунок 6: OMG's Object Management Architecture

Object Request Broker определяет  объектную шину CORBA.

Common Object Services представляют  собой коллекцию служб, снабженных  объектными интерфейсами и обеспечивающих поддержку базовых функций объектов [7].

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

Application Objects -- это  прикладные бизнес-объекты и приложения, которые являются основными потребителями  всей CORBA инфраструктуры.

Object Request Broker

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

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 может производиться только путем создания новых интерфейсов.