Технологии интеграции информационных систем на предприятии: 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 можно  описать и атрибуты компоненты, и  родительские классы которые, она наследует, и вызываемые исключения, и, наконец, методы, определяющие интерфейс, причем с описанием входных и выходных параметров.