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

Федеральное государственное образовательное  учреждение  
высшего профессионального образования

«СИБИРСКИЙ  ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ» 

Институт  космических и информационных технологий

Кафедра «Системы автоматики, автоматизированное управление и проектирование» 
 
 
 
 
 

Реферат 

По дисциплине: ” Автоматизированные системы управления предприятием”

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

Руководитель                                                            С.В. Ченцов

Студент  группы  ПУ06-02                                      Д.А. Тюхтев 
 

Красноярск 2010

Содержание:

  1. Введение ……………………………………………………………………………………..3
  2. Взаимодействие подсистем………………………………………………………………….4
  3. Основные стандарты поддержки промежуточного программного слоя OMG OMA.….5
  4. Технология  CORBA…………………………………………………………………………5
  5. Object Management Architecture……………………………………………………………..8
  6. Object Request Broker…………………………………………………………………….….8
  7. Microsoft DCOM/COM+…………………………………………………………………….11
  8. OLE……………………………………………………………………………………….…..13
  9. Интеграция в Web……………………………………………………………………………18
  10. XML…………………………………………………………………………………….…….18
  11. Web сервисы…………………………………………………………………………………..19
  12. Web – система хранения данных……………………………………………………………20
  13. Классификация технологий интеграции ………………………………………………….22
  14. Microsoft.NET как платформа интеграции…………………………………………………29
  15. Список использованных источников сети Internet……………………………………….30
 
 
 
 
 
 
 
 
 
 
 
 

Введение

Совершенствование многих решений в области информационной поддержки бизнеса идет рука об руку с развитием самой области высоких технологий. Уже давно бизнес не просто использует достижения IT, но и во многом определяет направление развития этой индустрии. Возможность быстрой обработки огромных массивов данных и доступность информации являются важнейшими факторами, определившими стремление бизнеса освоить новые технологии, предоставляющие столь существенные конкурентные преимущества тем, кто не поскупился на инвестиции в них. Взрывным развитием web-технологий мы всецело обязаны именно успешности гипертекстовой среды как платформы для построения систем электронной коммерции. Разрастающиеся потребности бизнеса требуют все более изощренных технологических решений. В общем, тот факт, что именно бизнес обеспечил полигон для испытания и развития новых идей в области IT, давно ни у кого не вызывает сомнений. К примеру, необходимость снижения стоимости разработки, поддержки и модернизации приложений, продиктованная бизнесом, потребовала разработки новых архитектурных концепций. Так, двухуровневая клиент-серверная архитектура доступа к большим централизованным базам данных уступила место более изощренной многоуровневой архитектуре построения распределенных приложений, которая позволяет вычленить бизнес-логику в отдельный уровень или бесконечно дробить его на подуровни-службы, даже физически вынесенные на отдельные машины. Благодаря этому подходу достигается существенный параллелизм и абстрагирование логики в обмен на сложности поддержки и обеспечения коммуникации между слоями.

Основная сложность  построения многослойных систем заключается в разнообразии платформ реализации различных слоев. За последние 30 лет развития этой области человеческой деятельности создано огромное количество программ, немалая часть которых до сих пор играет жизненно-важную роль в информационном обеспечении процессов, происходящих и в мелких частных фирмах и в крупных мультинациональных корпорациях. 15-20 лет назад основной аппаратной платформой для программного обеспечения были мэйнфремы, языком программирования COBOL, а СУБД IMS.

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

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

Взаимодействие  подсистем.

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

Возникает проблема интеграции с современными ИС. Вытекающий логически более общий вопрос взаимодействия подсистем сам по себе весьма интересен. 

Взаимодействие  подсистем базируется на трех принципах: 

1)  Идеология открытых систем, которая позволяет интегрировать ПО разных производителей. Требования к открытой информационной системе:  

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

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

2) Создание промежуточного  программного слоя как основной  метод интеграции ИС.  Промежуточный  слой (Middleware) - слой программного  обеспечения , который расположен  между операционной системой и средствами управления компьютерными сетями снизу и прикладными системами сверху. В 7-уровневой модели ISO/OSI это находится на 6-7 уровнях (представления и прикладного).

3) Архитектура  распределенных компонентов-объектов  как продолжение идеи промежуточного программного слоя.

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

Основные  стандарты поддержки  промежуточного программного слоя

OMG OMA

Потребность в  создании единых промышленных стандартов промежуточного программного слоя стала  одной из основных причин создания консорциума Object Management Group (OMG). Этот консорциум был основан в апреле 1989 года 11 компаниями, среди которых 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems и Unisys Corporation. На сегодняшний день его членами является более 800 компаний, среди которых такие гиганты ИТ-индустрии как IBM, Oracle, Microsoft.

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

На этой иделогической  платформе была разработана спецификация OMA - Object Management Architecture (Архитектура Управления Объектом). Ее ключевыми составляющими являются:

CORBA (Common Objects Request Broker Architecture - общая архитектура объектных  запросов) - отвечает за базовые  механизмы взаимодействия объектов в сети

Object Services (Объектные  сервисы) - системные службы для  поддержки разработки приложений

Common Facilities (универсальные  средства) - поддержка пользовательских  приложений

Application Objects (Объекты  Приложений) - собственно прикладные  приложения

Технология CORBA.

Введение  в CORBA

В конце 1980-х  и начале 1990-х годов многие ведущие  фирмы-разработчики были заняты поиском  технологий, которые принесли бы ощутимую пользу на все более изменчивом рынке  компьютерных разработок. В качестве такой технологии была определена область распределенных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использование и интеграцию кода, что было особенно важно для разработчиков. Цена за повторное использование кода и интеграцию кода была высока, но ни кто из разработчиков в одиночку не мог воплотить в реальность мечту о широко используемом, языково-независимом стандарте, включающем в себя поддержку сложных многосвязных приложений. Поэтому в мае 1989 была сформирована OMG (Object Managment Group). Как уже отмечалось, сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).  

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

CORBA специфицирует  инфраструктуру взаимодействия  компонент (объектов) на представительском  уровне и уровне приложений  модели OSI. Она позволяет рассматривать  все приложения в распределенной  системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют "реализацией объектов". Практика показывает, что большинство объектов одновременно исполняют роль и клиентов, и серверов, попеременно вызывая методы на других объектах и отвечая на вызове извне. Используя CORBA, тем самым, имеется возможность строить гораздо более гибкие системы, чем системы клиент-сервер, основанные на двухуровневой и трехуровневой архитектуре [6].

IDL

Язык OMG IDL (Interface Definition Language -- Язык Описания Интерфейсов) представляет собой технологически независимый синтаксис для описания интерфейсов объектов. При описании программных архитектур, OMG IDL прекрасно используется в качестве универсальной нотации для очерчивания границ объекта, определяющих его поведение по отношению к другим компонентам информационной системы. OMG IDL позволяет описывать интерфейсы, имеющие различные методы и атрибуты. Язык также поддерживает наследование интерфейсов, что необходимо для повторного использования объектов с возможностью их расширения или конкретизации.

IDL является чисто  декларативным языком, то есть  он не содержит никакой реализации. IDL-спецификации могут быть откомпилированы (отображены) в заголовочные файлы и специальные прототипы серверов, которые могут использоваться непосредственно программистом. То есть IDL-определенные методы могут быть написаны, а затем выполнены, на любом языке, для которого существует отображение из IDL. К таким языкам относятся C, C++, SmallTalk, Java и Ada.

Рисунок 5: CORBA IDL отображения в модели Клиент/Сервер 

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

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