Подходы к межсистемной интеграции

Интеграция Корпоративных Приложений (продолжение)

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

• Передача файлов (file transfer) – приложения выгружают необходимую информацию в файлы установленного формата, после чего эти файлы передаются и загружаются другими системами.
• Разделяемая БД (shared database) – несколько приложений работают на одной и той же БД.
• Удалённый вызов процедур (remote procedure call) – приложения предоставляют механизмы для экспорта функциональности, например, используя удалённый вызов процедур (RPC), XML-RPC или подобные механизмы, посредством которых функциональность одного приложения становиться напрямую доступна другому приложению.
• Передача сообщений (messaging) – каждое из интегрируемых приложений подсоединяется к общей системе обмена сообщениями, которая позволяет обмениваться данными и командами в виде сообщений.

Рассмотрим немного подробнее каждый из них.

Интеграция путём обмена файлами

Этот способ интеграции, как правило, довольно просто реализуется и достаточно популярен на практике. Всё что необходимо сделать для его реализации это заставить интегрируемые приложения экспортировать данные во внешний файл и, соответственно, импортировать данные из внешнего файла. На данный момент этого, часто, не трудно добиться, так как многие приложения поддерживают экспорт и импорт информации во внешние файлы. Если же это не так, то, часто СУБД, лежащая в их основе, может быть использована для получения данных во внешний файл и загрузку данных из внешнего файла.

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

Тем не менее, при всей своей привлекательности, интеграция на основе обмена файлами обладает рядом существенных недостатков.

• Плохая масштабируемость – это особенно критично, когда рассматривается масштабируемость по количеству интегрируемых приложений, каждый из которых может требовать свой формат файлов, что приводит к большому количеству форматов и преобразований между ними которые необходимо поддерживать. Более того, проблема с маршрутизацией файлов (кому какой файл посылать), может оказаться трудноразрешимой в случае с сильно распределённым решением.
• Относительно большая задержка при передаче данных. Данные должны быть регулярно экспортированы, пересланы и периодически импортированы. Это осложняет построение критичных ко времени интеграционных решений.
• Плохая управляемость, защищённость и отказоустойчивость такого решения. Так как не используется, как правило, никаких средств для централизованного управления обмена файлами, централизованного назначения прав доступа, не используются средства обеспечения гарантированной доставки.

Интеграция с помощью разделяемой базы данных

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

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

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

Интеграция с помощью удалённого вызова процедур

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

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

К недостаткам подхода можно так же отнести следующее:

• Сильная связанность по формату команд, передаваемых параметров и возвращаемых значений сильно усложняет независимое развитие приложений, входящих в общее интеграционное решение.
• Затруднённая управляемость такого решения, так как довольно сложно оказывается правильно разграничить доступ к той или иной функциональности, большое количество связей (потенциально каждый с каждым) приводит к плохой управляемости в случае большого количества приложений.
• Гетерогенность решения – приложения, хоть и пользуясь общим принципом RPC могут использовать разные его вариации и нижележащие технологии, что ещё более осложняет применение подобного решения.

Дата добавления: 2014-01-05