Ограничения и границы

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

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

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

• Границы объектной модели
  Хотя объектно-ориентированное программирование само по себе уже превратилось в своеобразный стандарт де-факто на разработку систем, используемые объектные модели не совпадают по множеству параметров. Так, модели объектного программирования для языков Java и C++ имеют несколько отличий, которые далеко не сразу бросаются в глаза, что сильно препятствует интеграции создаваемых с их помощью приложений.

• Границы сети
  Распределенные приложения должны справляться с любыми задачами организации сетевого доступа и коммуникаций, сохраняя при этом прозрачность сети.
• Ограничения языка программирования
  Фирмы, разрабатывающие ПО, выбирают тот или иной язык программирования, руководствуясь самыми разными соображениями: уровнем квалификации своих сотрудников, инструментарием, использовавшимся при создании унаследованного программного обеспечения, требований заказчиков и др. Прикладные программы, написанные на одном языке, должны "уметь" взаимодействовать с приложениями, написанными на другом.

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

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

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

Используя брокеры ORB, язык IDL и протокол IIOP, архитектура CORBA полностью решает проблему связывания программных компонентов в неоднородной вычислительной среде. Однако такое решение не является единственным.

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

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

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

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

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

Представители Microsoft утверждают, что с выходом в свет их нового продукта - сервера транзакций (Transaction Server) - модель DCOM станет полноценной системой масштаба предприятия, поддерживающей службы именования, событий, защиты, транзакций и жизненного цикла объектов. Мы надеемся, что безконфликтное сосуществование моделей CORBA и DCOM рано или поздно будет достигнуто; кстати, OMG уже рассматривает вопрос взаимодействия COM/CORBA.

Заключение

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

Литература

1. Энн Мак-Крори "Что такое унаследованные системы?": Computerworld, США, 1998.
2. Е.Зиндер "Реинжиниринг + информационные технологии = новое системное проектирование": Корпорация LVS: Открытые Системы, 1996, №1.
3. Б.А.Позин "Современные средства программной инженерии для создания открытых прикладных информационных систем": РосНИИ ИТ и АП: СУБД, 1995, №1.
4. Ian Sommerville "Software Engineering": Addison-Wesley, 1996.
5. Смирнов А.В., Юсупов Р.М. "Технология параллельного проектирования: основные принципы и проблемы внедрения": Анализ и проектирование, 1997, №2.
6. Александр Громов, Мария Каменнова "Особенности реализации больших проектов": Computerworld, 1996, №22.
7. С. Кузнецов "Введение в информационные системы": СУБД, 1997, №2.
8. М.Ш. Левин "Комбинаторное проектирование систем": Анализ и проектирование, 1997, №4.
9. Наталья Дубова "Интегрированные системы управления распределенной корпорацией": Открытые Системы, 1998, №1.
10. Калиниченко Л.А., Когаловский М.Р. "Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA": СУБД, 1996, №2.
11. Джошуа Гринбаум "Достоинства и недостатки приложений масштаба предприятия": Computerworld, 1996, №31
12. Питер Кин "Впереди - перегрузки!": Computerworld, Директору информационной службы, 1998, №9.
13. Геннадий Бережной "Проблемы создания больших информационных систем": PCworld, 1998, №8.
14. Ю. Пуха "Объектные технологии построения распределенных информационных систем": СУБД, 1997, №3.
15. Д.О. Брюхов, В.И. Задорожный, Л.А. Калиниченко, М.Ю. Курошев, С.С. Шумилов "Интероперабельные информационные системы: архитектуры и технологии": СУБД, 1995, №4.
16. К.В.Ахтырченко "Применение технологии CORBA при построении распределенных информационных систем: Лаборатория информационного моделирования НИИВЦ МГУ: СУБД, 1998, №1-2.
17. Глеб Ладыженский "Распределенные информационные системы и базы данных": Jet Infosystems, CIT Forum, 1996.
18. Сергей Кузнецов "Переносимость и интероперабельность информационных систем и международные стандарты": Jet Infosystems, CIT Forum, 1996.
19. К. В. Ахтырченко, В. В. Леонтьев "Распределенные объектные технологии в информационных системах": СУБД, 1997, №5-6.
20. Ахтырченко К.В., Аристархов А.А. "Опыт применения технологий CORBA, Java(RMI) при построении информационных систем с многозвенной архитектурой": CIT Forum, 1999.
21. Dave Ensor, Ian Stevenson "Oracle Design": O'Relly, 1997
22. Роберт Орфали, Дан Харки, Джери Эдвардс "Основы CORBA": изд. Малип, Москва, 1999
23. Сергей Дунаев "Интранет технологии": Диалог-МИФИ, Москва, 1997

Три подхода к интеграции информационных систем

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

Итак:

1. Интеграция на уровне данных. Суть данного подхода заключается в следующем: приложения работают независимо друг от друга, каждое использует свой набор данных. В случае необходимости осуществляется обмен данными между приложениями. При этом, если обмен данными осуществляется путем вызова сервисов или отправки/получения сообщений, то в качестве среды для обмена можно использовать сервисную шину предприятия - Enterprise Service Bus (ESB). Если же обмен данными производится в основном между базами данных, используемыми тем или иным приложением, то можно использовать решение класса Extract, Transform, Load (ETL). При этом некоторые реализации ETL, например Oracle Data Integration (ODI), могут использовать в качестве источников и приемников данных веб-сервисы и системы класса Message-oriented Middleware (MOM).

2. Интеграция на уровне бизнес-процессов. Суть данного подхода заключается в следующем: приложения выставляют сервисы, являющиеся интерфейсами к бизнес-логике данных приложений. Взаимодействие между приложениями реализовано в рамках бизнес-процесса, на отдельных шагах которого осуществляется вызов того или иного сервиса. Реализуется данный подход с помощью сервисной шины предприятия (ESB), которая занимается виртуализацией сервисов, предоставляемых приложениями, и решений класса Business Process Management System (BPMS), как правило основанных на языках BPEL или BPMN, которые реализуют логику процесса.

3. Интеграция на уровне композитных приложений. Бизнес-логика отдельного приложения строится путем вызова сервисов, предоставляемых как данным приложением, так и другими системами. Таким образом на одном шаге бизнес-процесса могут взаимодействовать несколько сервисов, в то время как при интеграции на уровне бизнес-процессов на одном шаге процесса вызывается один сервис. Реализация композитных приложений осуществляется с помощью использования технологий Java Business Integration (JBI, JSR 208) или Service Component Architecture (SCA). В качестве SCA -контейнеров можно использовать Oracle WebLogic, Oracle SOA Suite или Apache Tuscany.

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

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