Основные протоколы интеграции приложений

Даже самые простые современные бизнес-процессы осуществляются с помощью сторонних приложений. Такие программы интегрируются в систему предприятия и могут выполнять самые разные задачи начиная от простой формы обратной связи до целого комплекса действий. Обеспечить правильную передачу данных внутри системы помогают основные протоколы интеграции приложений – наборы правил, согласно которым осуществляется взаимодействие.

Типы интеграции

Выделяют 3 типа интеграции:

1. Оборудование+оборудование – самый простой тип. Здесь обмен данными происходит между конкретными устройствами, то есть информация фиксируется на одном объекте и передается на другой.
2. Оборудование+софт. Здесь данные с устройства передаются в систему, где пользователь уже принимает решение, что делать с полученными данными.
3. Софт+софт – интеграция данных в систему по протоколам связи.

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

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

Кроме типа интеграции приложений следует учесть и другие, не менее важные факторы, с которыми предстоит работать в будущем:

• Данные. Работа с ними будет осуществляться в любом случае независимо от масштабов интеграции. Данные должны не просто храниться, но и оперативно передаваться между приложениями и преобразовываться.
• Процессы. Любые операции с данными в системе проводятся четко определенными действиями – процессами.
• Агрегация. Все данные и процессы в интегрируемых приложениях агрегируются. Это позволяет объединить необходимые процессы, когда это необходимо и выстроить структуру работы пользователей с этими процессами.

Типы связи

Любой контакт между приложениями внутри системы происходит по принципу «запрос-ответ». Чтобы выполнить какое-то действие, необходимо отправить запрос соответствующему приложению и дождаться отклика.

Взаимодействие между приложениями внутри системы осуществляется с помощью вызовов. Независимо от того, насколько связанными или автономными будут команды, процессы будут одинаковыми. Именно поэтому важно, чтобы соблюдалось правильное распределение этих процессов. Для этого используют внутрипроцессные протоколы AMQP, HTTP или двоичный TCP.

Типы связи определяются исходя из сценария и целей основных протоколов интеграции приложений.

Синхронные и асинхронные протоколы

HTTP относят к синхронному типу протоколов. Взаимодействие происходит следующей схеме – отправляется запрос и ожидается ответ на него. Ключевым моментом является ответное сообщение от HTTP-сервера. Дальнейшие действия возможны только после получения ответа.

Протокол AMQP относится к асинхронным. В данном случае достаточно просто отправить сообщение. Дожидаться ответа нет необходимости.

Количество получателей

Тип связи также может быть определен количеством получателей. Например, Command обрабатывается только одним получателем. Другие запросы могут быть адресованы сразу нескольким сервисам. В данном случае используется шина или брокер сообщений, которые правильно перенаправят запросы в точки назначения.

Вполне возможен комбинированный тип связи. Часто используется синхронный протокол HTTP (HTTPS) для контакта с одним приложением. Для взаимодействия с другими приложениями применяют асинхронные протоколы сообщений.

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

Часто представители крупного бизнеса в целях сохранения коммерческой тайны заказывают написание проприетарных протоколов. Однако в процессе интеграции приложений и их дальнейшего использования обнаруживается, что такие протоколы могут быть несовместимы с определенными процессами и запросами внутри сети. В большинстве случаев компании все же переходят на HTTP.

Функции протоколов

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

Основные протоколы интеграции приложений должны выполнять 4 основных функции.

Обмен файлами

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

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

Прямой вызов исполняемых файлов

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

Прямое обращение к базе данных

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

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

Вызов веб-сервера

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

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

На самом деле наличие определенной скорости обработки информации основных протоколов – второстепенный фактор. Намного актуальнее вопрос целостности передачи данных и безупречности исполнения функции «запрос-ответ».

Архитектура

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

Выделяют 2 главных архитектурных типа:

1. SOA – Сервис-ориентированная архитектура. Здесь взаимодействие между приложениями осуществляется по определенному шаблону. Крупные приложения передают конкретные функции другим, более мелким приложениям. Этот тип архитектуры остро нуждается в наличии централизованного управления. Дело в том, что любые изменения в одном из сервисов могут прервать работу всех остальных.
2. Микросервисная архитектура. Отличается от SOA наличием общей системы связи. Благодаря этому обмен данными между приложениями происходит существенно быстрее. Каждый сервис внутри системы – это автономное приложение, которое можно обновлять или масштабировать. Несмотря на то, что все сервисы внутри системы работают с одними данными, модернизация любого из приложений не повлияет на работу остальных.

Микросервисный архитектурный тип сегодня активно используется в процессе интеграции приложений. Одним из самых известных архитектурных стилей такого типа является REST API.

REST API и HTTP

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

REST API – технология, благодаря которой осуществляется связь между сервером и приложениями. С помощью протокола HTTP REST API получает и модифицирует данные и перенаправляет вызовы внутри сети.

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

REST API с помощью протокола HTTP или его зашифрованной версии HTTPS позволяет как отправлять запросы к серверу, так и получать от него ответы. Именно поэтому сервис активно используется при интеграции приложений.

Внешне запрос HTTP-протокола выглядит как привычный адрес какого-либо интернет-ресурса. Например, http://website.com/adress. Адрес сервера прописывается в первой части запроса – http://website.com. /address – путь к конкретному ресурсу.

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

• GET-запросы показывают информацию, данные доступны только для чтения, их нельзя изменить или удалить.
• POST-запрос позволяет создать новую запись.
• PUT-запрос позволяет редактировать уже существующие данные.
• DELETE-запрос удаляет информацию.

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

REST API сегодня является самым популярным решением для взаимодействия интегрированных приложений. Все благодаря тому, что протокол HTTP легко реализуется во всех операционных системах и языках программирования.

Часто REST сравнивают с еще одним протоколом интеграции – SOAP.

SOAP

Simple Object Access Protocol – один из самых простых и распространенных протоколов передачи данных. Все сообщения, генерируемые через SOAP закодированы в формате XML. Передача осуществляется через HTTP.

Востребованность протокола достигнута за счет его удобного и несложного функционала:

• простая XML-кодировка данных;
• возможность добавлять дополнительные инструменты, например, функции безопасности, трассировки;
• широкий формат применения для нескольких языком программирования.

Структура SOAP-сообщения включает в себя 4 элемента:

1. Корневой элемент «envelope». Он идентифицирует SOAP-сообщение в формате XML.
2. «Header» – заголовок сообщения. Здесь содержатся атрибуты, направленные конкретному приложению в системе. Это своего рода команда на исполнение:
   1. mustUnderstand – обязательное (1) или опциональное (0) распознавание заголовка сообщения;
   2. actor – конечная точка для сообщения;
   3. encodingStyle – кодировка элемента. 
3. «Body» – тело. В данном элементе может содержаться как сам запрос, так и ответ.
4. «Fault» – ошибка – опциональный элемент. Активируется в момент возникновения ошибки в процессе передачи сообщения. Может появиться как отдельное информационное сообщение, так и с дополнительными элементами, которые содержат подробности ошибки и ее причины.

Несмотря на свою простоту, SOAP имеет ряд недостатков:

• передача сообщений только в формате XML;
• схема работы возможна только по принципу «один запрос – один ответ»;
• сообщения имеют очень большой объем;
• любые изменения в описании сервиса могут повлечь ошибки в работе приложений.

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

Различия REST и SOAP

И REST, и SOAP сегодня остаются самыми предпочитаемыми сервисами интеграции. Важно понимать, в каких именно случаях следует их использовать:

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

В таблице отражены основные различия между REST, и SOAP. Эти характеристики обязательно нужно учитывать при выборе основных протоколов интеграции.

Интеграция приложений – сложный процесс как для небольшого предприятия, так и для акул бизнеса. И тем, и другим важно не упустить ни одной детали еще в процессе разработки проекта будущей интеграции.

Основные протоколы интеграции приложений – свод правил, от соблюдения которых зависит скорость и качество обмена данными внутри системы. Форматы файлов, их содержимое, способы обработки – каждый фактор может повлиять на рабочие процессы. Поэтому важно не только выбрать нужные сервисы для интеграции, но и правильно настроить их взаимодействие. Современные архитектурные стили API — SOAP и REST, самые востребованные современные архитектурные стили на базе протокола HTTP. Именно они отвечают максимальному числу требований к условиям передачи данных между сервисами.