По дисциплине: ” Автоматизированные системы управления предприятием” Технологии интеграции информационных систем на предприятии: ole, corba, Web-решения и др (стр. 3 из 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)
