Интеграция приложений: методы взаимодействия, топология, инструменты. Часть 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-сервисов — простоту межплатформного взаимодействия.