.



   

 Каталог

Корпоративные порталы
Информационные порталы
Экспертные порталы
Порталы приложений
Порталы совместной работы
Порталы управления знаниями
Порталы интеграции корпоративных систем

Методологии
Системы поддержки принятия решений (Decision Support Systems — DSS)
Data Warehouse - хранилища данных
Data Mart - Витрины данных
OLAP (On-Line Analytical Processing) - интерактивная аналитическая обработка
Business Intelligence (BI) - бизнес-интеллект
Интеллектуальный анализ данных (Data Mining)
Управление знаниями (Knowledge Management)

Корпоративные сети
Экстранет (Extranet , Экстрасеть)
Защита корпоративных сетей
Интернет (Internet)
Интранет (Intranet)

О проекте

             

Портал о Корпоративных порталах
Консалтинг, создание, внедрение и поддержка

УслугиЭнциклопедияСтатьиРесурсыИсторияНовости
Главная > Статьи > Корпоративные порталы > Порталы интеграции корпоративных систем

Интеграция приложений: методы взаимодействия, топология, инструменты. Часть 3

Алексей Добровольский

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

Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств. 

Выбор средств интеграции

Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно. 

Советы общего плана

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

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

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

Совет конкретный

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

Отдельно про Web-сервисы

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

Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Web-сервисы «захлебываются», когда за одно взаимодействие между интегрированными системами нужно передавать уже сотню килобайт. (Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают.)

Далее представьте, что в процессе взаимодействия множества информационных систем необходимо провести согласованные изменения в некоторых из них, то есть выполнить логическую транзакцию, затрагивающую несколько систем. Если для интеграции используются Web-сервисы, то такой возможности нет: в своем «исходном» варианте Web-сервисы не поддерживают заключение в рамки одной транзакции несколько вызовов методов одного или нескольких сервисов. Поставщики интеграционного программного обеспечения в этом случае обычно предлагают использовать так называемые «компенсационные операции» (на каждую операцию предусмотреть отменяющую ее операцию). Скажем, если из трех участвующих в логической транзакции приложений два смогли выполнить какую-то операцию, а одно — нет, то в двух системах нужно выполнить действия отката, отменяющие результат успешно выполненных операций. В теории подход хорош, но, во-первых, никто не гарантирует успех компенсационной операции, а во-вторых, некоторые системы (например, финансовые) не допускают удаления данных, внесенных в базу.

Предварительный стандарт WS-Transactions, призванный решить данную проблему, существует, но отсутствуют его полноценные реализации. Так, корпорация IBM заявила о поддержке этого стандарта в своих интеграционных продуктах, основанных на WebSphere Application Server, но с массой ограничений; самое главное из которых — все взаимодействующие Web-сервисы должны работать под управлением WebSphere Application Server. Аналогичная ситуация и у Microsoft в .Net 3.0, что выхолащивает смысл Web-сервисов — простоту межплатформного взаимодействия.

Но самое печальное в ситуации с Web-сервисами — не отсутствие реализаций стандартов, сдерживающих их применение для интеграции приложений. Плохо то, что после реализации всех необходимых стандартов Web-сервисы рискуют потерять то, благодаря чему они стали столь популярны, — простоту создания, развертывания, поддержки. Поддержка WS-Transactions, WS-Attachments и других стандартов, расширяющих возможности Web-сервисов, может резко усложнить их создание, отладку и развертывание.
 


30.09.2006



Кроме этой статьи Вы можете посмотреть по тематеке текущего раздела:
2 статьи в разделе "Энциклопедия"
6 статей в разделе "Статьи".
2 статей в разделе "История".
__________________
Версия для печати

 


 
 

        Поиск

   
        Расширенный поиск

Статьи

Мозаика

Web-службы и EAI: полная гармония отношений?

И-нтеграторы

Интеграция приложений: методы взаимодействия, топология, инструменты. Часть 4

Интеграция приложений: методы взаимодействия, топология, инструменты. Часть 2

Интеграция приложений: методы взаимодействия, топология, инструменты

Энциклопедия

EAIP (Enterprise Application Integration Portal) – Корпоративный портал интеграции разнородных корпоративных информационных систем компании

Ресурсы

Интеграция: новое решение старых проблем

Когда нужна интеграция?

Аналитические решения: понимание трех составляющих

Интеграция корпоративных приложений: основные понятия

CorPortal.ru Все права защищены. Инспро

Рейтинг@Mail.ru
!