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

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

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

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

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

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

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

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

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

Дата добавления: 2015-10-24