корпоративная сервисная шина что это
ESB (Enterprise Service Bus) — дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).
Содержание
Основные функции ESB
Архитектура ESB
Основа архитектуры ESB — это идея использования общей интеграционной инфраструктуры всеми корпоративными приложениями на базе обмена сообщениями. Все приложения взаимодействуют через одну точку, которая, в случае необходимости, обеспечивает сохранность обращений, преобразование данных и транзакции. При этом целью интеграции приложения является создание единственного модуля (или адаптера), который отвечает за «подключение» приложения к ESB. Последующую обработку сообщений и их маршрутизацию в другие системы, ESB выполняет на основании установленных бизнес-правил самостоятельно. Этот подход обеспечивает превосходную гибкость, простоту масштабирования и переноса, поэтому в случае замены одного из приложений подключенного к шине, перенастраивать остальные не нужно.
Достоинства и недостатки
Достоинствами ESB является:
К числу недостатков ESB относят:
Разработка Enterprise Service Bus
Отличительной чертой Web-служб является то, что потребитель имеет возможность динамически связываться с провайдером службы. Все это происходит благодаря двум главным функциональным возможностям:
Самоописание Web-служб облегчило интеграцию с помощью объявления интерфейсов, которым нужно было следовать. Благодаря динамическому обнаружению службы, потребитель был освобожден от зависимости от конкретного провайдера с определенным адресом, однако, и эта возможность создала свои собственные проблемы. Достаточно тяжело было решить вопрос связи потребителя с провайдером раз и навсегда во время компиляции и потенциальным поиском нового провайдера при каждом вызове во время исполнения. Тогда ESB предложила другой вариант — дать возможность потребителю один раз динамически связаться с прокси-службой, имея при этом возможность использовать нескольких провайдеров и провайдеров, которые могут появиться в будущем, через эту прокси-службу. Все это говорит о том, что ESB делает службы доступными для их вызова потребителями и дает возможность потребителям найти службы программным способом.
Шлюз служб
Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:
Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI-службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL-операции и получает обратно адрес прокси-службы шлюза для этой операции.
Шина сообщений
Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений — это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.
Корпоративная сервисная шина что это
Есть мнение, что использование Apache Kafka в качестве корпоративной сервисной шины (ESB, Enterprise Service Bus) является антипаттерном. Сегодня мы проясним это категоричное утверждение и рассмотрим, как корректно реализовать ESB с помощью Kafka на практическом примере шины данных в компании Avito.ru.
Что такое ESB и чем это отличается от брокера сообщений
Таким образом, брокер сообщений является частью ESB-решения, которое в целом обеспечивает мониторинг и контроль маршрутизации обмена сообщениями между сервисами на основе контента, разрешая конфликты между ними. Также ESB позволяет управлять развертываниями и версиями сервисов. Поэтому постановка вопроса «Apache Kafka vs ESB» не совсем корректна: Кафка дополняет ESB, выступая в качестве масштабируемой отказоустойчивой стриминговой платформы, что особенно актуально для высоконагруженных распределенных Big Data систем [2].
Apache Kafka для разработчиков
Код курса
DEVKI
Ближайшая дата курса
Длительность обучения
32 ак.часов
Стоимость обучения
72 000 руб.
Шина данных и Apache Kafka: рекомендации и антипаттерны
Именно в таком ключе перед разработчиками компании Avito и была поставлена задача создания корпоративной шины данных (service data bus), реализацию которой мы рассмотрим далее. Этот кейс был наглядно представлен сотрудником компании Антоном Суховым на 5-м Backend-митапе Авито в декабре 2019 года [4].
Кафка и шина данных на пример Авито: self-service для эффективной интеграции
Основными бизнес-требованиями к корпоративной шине данных в Авито были следующие [4]:
Из требований к решению наиболее значимыми считались:
С учетом этих требований было решено проектировать систему следующим образом:
При том смещение (offset) может указывать на самую старую запись (oldest), самую новую (newest), или вычисляться по метке времени (timestamp).
Сравнение ESB-решений, популярных на российском рынке
Содержание
В конкурентной борьбе побеждает тот, кто умеет быстро масштабироваться, быстро реализовывать партнёрские проекты и вкладывать в рост минимум средств. Традиционное представление об интеграциях диаметрально противоположно этим приоритетам. Сроки и стоимость реализации непонятны, эффект непредсказуем, вместо ожидаемого преимущества — неопределённость.
Парадигма low-code гораздо ближе к приоритетам бизнеса. Программное обеспечение, которое работает в этой парадигме, позволяет ускорить разработку и внедрение новых систем, интеграций и фич в разы.
Один из продуктов, работающих в парадигме low-code, — ESB-система (сокр. от англ. enterprise service bus, рус. «сервисная шина предприятия»). ESB — это набор программного обеспечения, которое работает как единый центр для обмена сообщениями между информационными системами и приложениями. Сервисная шина позволяет легко настраивать маршруты движения сообщений, хранит историю сообщений, фиксирует путь каждого из них.
ESB не требует сложной и длительной разработки каждый раз, когда нужно соединить системы, которые изначально не спроектированы для совместной работы. Более того, бóльшая часть работы обеспечивается визуальными средствами разработки. При интеграции главным становится бизнес-анализ, а не технические аспекты этой интеграции.
ESB — это не монолитная система, а слой в IT-инфраструктуре компании, который состоит из нескольких продуктов. Каждый из них берёт на себя одну или несколько функций сервисной шины. В этой статье мы разложим слой ESB по функциям и расскажем, как эти функции реализованы в продуктах, популярных на российском IT-рынке.
Из чего состоит слой ESB
Студия — графическая среда для разработки быстрых интеграций. Системы, параметры, действия визуализированы и максимально понятны. Функционала студии хватает на бóльшую часть действий, таких как передача и получение информации, преобразование и сбор атрибутов из одних потоков в другие. Здесь же можно задать параметры, которые ESB-шина должна отслеживать, считать ошибкой интеграции и пр. Если в рамках интеграции нужно уникальное действие, его можно написать парой строк на традиционных языках (например, Java) или специально разработанных.
Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.
Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.
В этой статье мы разберём, как реализованы компоненты ESB в решениях, которые чаще всего предлагают на российском рынке: Talend, Mule, WSO2, Red Hat Fuse. Иногда разработчики дополняют список брокерами сообщений Apache Kafka (плюс Kafka Connect) и RabbitMQ, но эти два решения не являются ESB и рассматривать их в рамках данного разбора нецелесообразно.
Укажите свою почту, и мы будем присылать вам еженедельный анонс новых статей.
+ — студия есть в «коробке».
± — студия есть, но она сложнее в настройке и требует постоянного участия разработчиков, что идёт вразрез с парадигмой low-code.
Как видите, внутреннее логирование в ESB-системах реализовано практически идентично — с небольшими особенностями, индивидуальными для каждого из продуктов.
Дополнительно предусмотрено логирование во внешних системах, которые подключаются через коннекторы. Бизнес-аналитик должен прописать ключевые события в рамках интеграции, чтобы сообщения об этих событиях попадали в логи.
Логирование во внешней системе даёт ESB дополнительную гибкость. Скорее всего, у бизнеса масштаба enterprise в IT-архитектуре уже есть компонент для логирования, и системы не будут дублировать функции друг друга.
Резюме
Talend, Mule, WSO2 позволяют решить проблему скорости проведения интеграций и соответствуют парадигме low-code.
Red Hat Fuse по функционалу близка к предыдущим трём продуктам, но уже не может считаться low-code решением: даже для рядовых операций здесь нужен именно разработчик. Однако в ней сохраняется принцип самодокументируемости.
Apache Kafka и RabbitMQ являются не ESB-системами, а брокерами сообщений. Их недостаточно, чтобы создать полноценный слой ESB, они не дают никаких преимуществ в плане упрощения интеграций и масштабирования, но при этом могут стать частью слоя ESB.
Понятно, что каждое внедрение индивидуально и должно учитывать особенности бизнеса, продуктовую и IT-стратегию. Но из существующих решений именно low-code позволяет быстрее всего проводить цифровую трансформацию, масштабироваться, интегрироваться с партнёрами. Поэтому компаниям, которые заинтересованы в быстром росте с сопутствующей оптимизацией затрат на разработку, мы рекомендуем именно low-code решения: ESB, BPMS, CRM.
Отдельно обозначим, что само внедрение low-code ESB происходит не мгновенно. Как и всякая масштабная интеграция, оно требует времени и ресурсов: затрат на команду разработчиков, на серверы (при необходимости) и т. д. В этом low-code решения ничем не отличаются от привычных. Экономия на разработке начинается только после их внедрения.
Корпоративная сервисная шина что это
Среди лучших практик интеграции сложных информационных систем — построение логических витрин данных, а также создание централизованных инфраструктур обмена данными при помощи MDM-систем и корпоративных сервисных шин (ESB, Enterprise Service Bus). Наши решения, в том числе система АрхиГраф.MDM, пригодны для использования в составе операционной системы специального назначения Astra Linux Special Edition, а также Alt Linux.
Зачем нужна интеграционная шина?
Любая компания, использующая больше двух программных продуктов, работающих с пересекающимися наборами информации, знает, какова цена отсутствия связи между ними. Не синхронизированные списки клиентов или номенклатуры товаров и другой информации между ERP, CRM иными корпоративными приложениями, несут постоянные потери времени, ресурсов, репутации компании. Единственным правильным решением подобной проблемы является внедрение корпоративной сервисной шины (ESB), в связке с системой управления мастер-данными (MDM).
Решения, основанные на регулярных выгрузках и преобразовании информации (ETL), сервисно-ориентированной архитектуре (SOA), дают лишь временное решение подобных проблем, имеют множество недостатков, ограничивают возможности роста ИТ-инфраструктуры.
Внедрение интеграционной шины
При внедрении интеграционной шины возникает задача мэппинга (сопоставления) структуры сведений об одних и тех же объектах, присутствующих в разных информационных системах. Решать эту задачу необходимо путем создания общей, нейтральной по отношению к каждому приложению, информационной модели. Такая модель может быть наиболее эффективно реализована при помощи семантических технологий. Для достижения оптимальных результатов внедрения требуется, чтобы разработкой модели занимался профессиональный архитектор данных.
Важной частью проекта по внедрению является реализация коннекторов (программных интерфейсов) для всех приложений, участвующих в обмене данными. Наши специалисты имеют опыт разработки и подключения коннекторов для широкого круга ПО на различных платформах.
Проекты по интеграции мы выполняем совместно с партнерами на основе решений IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse, а также шины «Бизнес Семантика».
Часто проект по внедрению интеграционной шины выполняется в рамках общего реинжиниринга информационной архитектуры предприятия.
Корпоративная сервисная шина — «бюджетный» подход к решению задач интеграции
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab
Продолжая знакомить читателя с различными подходами к интеграции, мы решили остановиться на относительно новой и весьма привлекательной технологии — корпоративной сервисной шине (Enterprise Service Bus, сокр. ESB).
Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.
Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня (middleware), который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция). Многие корпоративные сервисные шины также поддерживают другие стили обмена информацией, включая гарантированную доставку и «публикацию и подписку» (publish and subscribe). Сервисы, предоставляемые этими шинами, обладают «добавленной стоимостью», которой не располагают межплатформенное обеспечение, предназначенное для упрощенного обмена сообщениями, — они обеспечивают проверку сообщений, трансформацию, маршрутизацию на основе содержания, безопасность, обнаружение сервисов для сервис-ориентированной архитектуры, балансирование нагрузки и регистрацию. Некоторые сервисы встроены в основание шины, другие — исполняются в модулях расширения (plug-in). Кроме того, шины поддерживают язык XML и другие форматы сообщений.
Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, «бюджетные», решения.
Действительно, сегодня наблюдается усиления спроса на интеграционные технологии. И если раньше развертывание продуктов EAI было связано с достижением стратегических целей и, следовательно, окупалось в долгосрочной перспективе, задачи, с которыми в настоящий момент приходится сталкиваться компаниям, носят тактический характер и требуют новых подходов. «Современные бизнес-реалии» привлекли внимание к областям, где поставщики EAI традиционно слабы — к трансформации, программной обработке, ориентированной на разработчиков (например, на Java) и интеграции к внешним технологиям. Все это и «подготовило благоприятную почву» для появления новой категории продуктов — ESB.
Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): «Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB».
Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как «бюджетные» интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа — это продукты, предназначенные для рынка Web-сервисов, наконец последние — это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.
Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру. Например, в IBM корпоративную сервисную шину считают «архитектурной моделью» (architectural pattern).
Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов:
На данный момент на обозначенные вопросы нет окончательных ответов.
Вместе с тем стоит подчеркнуть, что несмотря на отсутствие ясности в отношении корпоративной сервисной шины, совершенно очевидно, что благодаря тому, что ESB опирается на открытые стандарты, она позволяет существенно сократить затраты на покупку и реализацию.
Заметим, что слово «сервисная» в термине «корпоративная сервисная шина» является центральным. Так, аналитики Forrester Research рассматривают ESB как «слой промежуточного программного обеспечения, с помощью которого можно получить доступ к набору основных (многократно используемым) бизнес-сервисам». SOA позволяет представить большую часть функциональности как «сервис» в корпоративной сервисной шине, которая переправляет, преобразовывает и проверяет входные и выходные данные в формате XML, получаемые из этих сервисов.
ESB и XML
Было бы несправедливо, если бы мы не подчеркнули особую роль XML — XML является основанием для интеграции. Если принять тот факт, что XML скорее «алфавит», чем просто язык, становится понятным, что для полной реализации интеграции требуется «дирижировать» бизнес-процессами, управлять преобразованием XML, а также проверять и пересылать сообщения XML по организации. Все эти функциональные возможности составляют основу корпоративной сервисной шины.
XML может обеспечить исчерпывающее представление набора данных. Популярность этого языка можно объяснить его высокой гибкостью и расширяемостью. Действительно, синтаксис XML позволяет модернизировать и разрабатывать специализированные XML-схемы для обработки различных данных.
Вместе с тем стремительный рост объемов данных, подлежащих передаче, создает серьезные сложности для функционирования корпоративной информационной структуры. Так, первые интеграционные проекты, в которых использовались возможности XML, явились «живым» доказательством перспективности этого языка, однако сейчас наблюдается определенные проблемы при увеличения количества, размера и сложности XML-документов. Ниже перечислены основные причины существующих сложностей (недостаточной масштабируемости):
Для решения проблемы недостаточной масштабируемости рекомендуется использовать архитектуру обработки, которая поддерживает следующие функции:
Приведенные выше функции могут быть реализованы с помощью корпоративной сервисной шины — причем без специального кодирования и конфигурирования.
В чем отличие сервисной шины предприятия(ESB) от брокеров сообщений (например RabbitMQ)?
В результате, можно разрешить проблему неудовлетворительной производительности.
Заключение
Судя по публикациям в зарубежных Интернет-изданиях и оценкам аналитиков ведущих исследовательских компаний, корпоративная сервисная шина уже больше не является просто новой технологией с большим потенциалом. Действительно, по прогнозу Gartner, в 2005 году большинство крупных компаний будут использовать ESB. В IDC же полагают, что корпоративная сервисная шина должна «революционизировать» информационные технологии и сделать возможным гибкую и масштабируемую распределенную обработку данных.
Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), «ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты».
И все же неопределенность с многозначностью термина «корпоративная сервисная шина» пока сохраняется. Сегодня ESB означает любую технологию, необходимую для реализации SOA. Именно такой точки зрения придерживаются в компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированная архитектуры. В этой связи аналитики ZapThink предупреждают, что если в 2005 году не будет выработано реального и конкретного определения корпоративной сервисной шины, термин ESB «навсегда уйдет из лексикона SOA». Что касается же самой SOA, то о ней речь пойдет в следующей статье.
Публикации
Что такое ESB и SOA¶
An excellent description of system-of-systems thinking
Nick Coghlan, Core Python Developer
Also available in Català, Deutsch, English, Français, italiano, Nederlands, Português, Türkçe and 中文.
Аббревиатура ESB и связанная с ней SOA — могут стать причиной путаницы. ESB расшифровывается как Enterprise Service Bus. SOA — Service Oriented Architecture.
Эти названия мало о чем говорят, поэтому далее приведена более полная информация простым языком, без излишней корпоративной лексики.
Вся правда¶
Давайте представим, что происходит, когда Вы входите в фронтенд-приложение Вашего банка:
С большой долей вероятности можно сказать, что все эти кусочки информации принадлежат к разным системам и приложениям, каждое из которых предоставляет данные через какой-то интерфейс (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV или любой другой):
Вопрос состоит в том, как Вы можете заставить фронтенд-приложение общаться с системами 1-5? Ну, никак.
Это фундаментальная основа для уверенности в том, что такие окружения могут масштабироваться за пределы нескольких систем. Вы не заставляете их общаться напрямую друг с другом.
В схеме, представленной ниже, каждое обращение к сервису, который предоставлен другой системой, показано линией с разной толщиной и стилем:
Заметьте, мы даже не показали ни одного высокоуровневого процесса (App1 вызывает App2 и либо App3, либо App5, в зависимости от того, был ли предыдущий ответ от App6 успешным, для того, чтобы App4 могло позже взять данные, которые были сгенерированы App2, но только если App1 не запрещает этого и т. д.).
Также, заметьте, мы не говорим о серверах — каждая из систем может работать на 10 физических серверах, так что как минимум 60 физических компонентов будут обмениваться информацией друг с другом.
Тем не менее, некоторые вопросы становятся очевидными.
Как разделить интерфейсы? Как планировать выгрузку? Как скоординировать обновления или запланированный простой, если каждое приложение управляется разными командами разработчиков, вендоров или отделов и половина исходных разработчиков уже покинула компанию?
Если Вы думаете, что можете управлять 6-ю приложениями, как на счет 30?
А сможете справиться с 400? А с 2000? Каждое приложение может быть своей уникальной экосистемой, требующей десятка серверов или других устройств для работы, так что это — 20 000 движущихся частей, распределенных по континентам с всяческими техническими и культурными границами. И все эти части постоянно и без остановки хотят обмениваться сообщениями все время без каких бы то ни было простоев, вообще. (Мы избавим Вас от схемы.)
Есть отличное название для такой ситуации — беспорядок.
Как Вы можете исправить ситуацию?¶
Первым делом стоит признать, что ситуация вышла из-под контроля. Это позволяет искать решение без ощущения сильного чувства вины. Хорошо, это произошло, Вы не знали, как сделать лучше, но есть шанс, что все это можно исправить.
Это может принести за собой организационные изменения в подходе к IT, но иной шаг — это вспомнить, что системы и приложения созданы не просто для обмена данными. Они созданы для поддержки бизнес-процессов, вне зависимости от самого бизнеса, будь это банковская сфера, аудио записи, радиолокационные устройства, что угодно.
Когда Вы четко определите для себя эти два пункта, Вы сможете начать проектирование или редизайн Ваших систем вокруг сервисов.
Сервис — это что-то интересное, многократно используемое и атомарное, что предоставляется одной системой другим приложениям, которые хотят использовать его, но, при этом, сервис никогда не выставлен напрямую в режиме один к одному. Это самое короткое и осмысленное описание из всех возможных.
Если данная функциональность системы удовлетворяет этим трем требованиям:
тогда велик шанс, что система может и должна быть представлена другим системам как сервис, но никогда не соединяться напрямую.
Давайте обсудим подход IRA на нескольких примерах.
