Стили взаимодействия приложений

Взаимодействие приложений

Критерии выбора стиля взаимодействия

• Надёжность Выбранный способ взаимодействия должен гарантированно обеспечивать доставку данных от одного приложения к другому.
• Степень связанности приложений При интеграции приложений нужно минимизировать зависимости между ними — уменьшить их связанность. Изменение функциональности одного приложения может привести к нарушению взаимодействия. Низкая связанность необходима, чтобы каждое приложение могло развиваться, не нарушая работоспособности другого.
• Простота реализации взаимодействия Архитектор ПО и команда разработки должны учитывать трудозатраты на интеграцию и соотносить их с качеством полученного решения. Иногда самый простой вариант оказывается самым эффективным, но часто для реализации наилучшего решения приходится прибегать к более сложным и трудозатратным способам интеграции.
• Выбор технологии Некоторые способы интеграции требуют применения специализированного аппаратного и программного обеспечения. Использование дополнительного ПО увеличивает стоимость решения, а также требует от команды разработки дополнительных навыков работы с этим ПО.
• Формат данных При проектировании взаимодействия необходимо учитывать формат данных, которыми обмениваются приложения. Приложения должны поддерживать одинаковые форматы данных или использовать специальное ПО, которое позволяет обмениваться данными в разных форматах.
• Своевременность доставки данных Интеграцию нужно реализовать так, чтобы временной разрыв между передачей данных одной системы и получением этих данных другой системой сократился до минимума. Чем дольше процесс передачи данных, тем выше риск того, что данные успеют устареть.
• Общая функциональность Приложения могут обмениваться не только данными, но и функционалом. Заимствование функций требует особого подхода к проектированию интеграции посредством вызова удалённых процедур.
• Режим взаимодействия Проектируя взаимодействие, нужно определить, блокирует ли его результат дальнейшие действия по сценарию, в рамках которого это взаимодействие было инициировано. То есть может ли приложение продолжить работу, не дожидаясь ответа другого приложения.

Режимы взаимодействия

• Синхронный.
• Асинхронный.

Преимущества и недостатки режимов взаимодействия

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

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

Стили взаимодействия

• Передача файлов (File Transfer) Приложение создаёт файлы с данными, которые необходимы другим приложениям, и использует файлы, созданные другими приложениями.
• Общая база данных (Shared Database) Данные, необходимые разным приложениям, хранятся в одной базе данных.
• Удалённый вызов процедур (Remote Procedure Invocation — RPI или Remote Procedure Call — RPC). Каждое приложение описывает для других приложений процедуры, которые можно вызвать удалённо (например, с другого компьютера), чтобы обменяться данными или дать указания.
  Процедурой называют часть программного кода, которая выполняет некоторую функцию. Под вызовом процедуры понимают выполнение функции.
• Обмен сообщениями (Messaging) Приложения связаны общей системой обмена сообщениями, с помощью которой обмениваются данными и дают друг другу указания.

Передача файлов

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

• Ненадёжность Если система-отправитель не выложит файл, система-получатель не получит его.
• Увеличение времени доставки данных Для системы-получателя усложняется задача по организации оперативного и своевременного получения данных. Кроме того, отсутствует возможность проанализировать валидность файла до тех пор, пока он не будет загружен и разобран.

Общая база данных

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

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

Удалённый вызов процедур

• Простота и понятность взаимодействий Механика взаимодействия в данном случае сводится к простому взаимодействию между сервером и клиентом. Чтобы переписать и доработать код взаимодействия при замене одного из его участников, понадобятся минимальные усилия.

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

Обмен сообщениями

• Слабая связанность Слабая связанность достигается за счёт асинхронной передачи сообщений. Приложение-отправитель передаёт данные и продолжает работать, не дожидаясь ответа от приложения-получателя. Приложение-получатель обрабатывает сообщения в своём темпе, а не когда они были отправлены.
• Масштабируемость Если сообщения появляются в очереди быстрее, чем получатель успевает их обработать, можно запустить несколько экземпляров приложения-получателя и дать им параллельно читать сообщения из одной очереди.
• Надёжность Стиль позволяет гарантировать, что данные будут доставлены от приложения «А» к приложению «Б» без потерь.
• Возможность передавать бОльшие объёмы данных, чем при других стилях взаимодействия.

• Это самый сложный для реализации стиль взаимодействия.
• Высокая стоимость реализации взаимодействия за счёт необходимости использовать дополнительное программное обеспечение.

Подведём итоги

• Синхронное взаимодействие — блокирующее взаимодействие, при котором клиент не может продолжить выполнение работы, пока не получит ответ.
• Асинхронное взаимодействие — не блокирующее взаимодействие, при котором клиент может продолжать работу после отправки запроса.

1. Передача файлов (File Transfer) Приложение создаёт файлы с данными, которые необходимы другим приложениям, и использует файлы, созданные другими приложениями.
2. Общая база данных (Shared Database) Данные, необходимые разным приложениям, хранятся в одной базе данных.
3. Удалённый вызов процедур (Remote Procedure Invocation — RPI или Remote Procedure Call — RPC) Каждое приложение описывает для других приложений все процедуры, которые можно вызвать удалённо (например, с другого компьютера), чтобы обменяться данными или дать указания. Процедурой называют часть программного кода, которая выполняет некоторую функцию. Под вызовом процедуры понимают выполнение функции.
4. Обмен сообщениями (Messaging) Приложения связаны с общей системой обмена сообщениями, с помощью которой обмениваются данными и дают указания друг другу.