Почему без интеграции ИТ‑систем все усилия по цифровизации умножаются на ноль.

В статье разберём четыре подхода, которые компании выбирают, когда доходит до интеграций ИТ‑систем: классические «точка‑точка» (они же «спагетти‑код»), брокеры сообщений вроде Kafka и RabbitMQ, Open Source‑решения и готовые ESB‑платформы. Посмотрим на примерах, как каждый из них работает в бою, какие грабли ждут на каждом пути, и почему «бесплатно» на входе часто оборачивается очень дорогим сопровождением.

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

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

SOAP никуда не делся. Продаёте авиабилеты, значит ходите в Amadeus, Sabre и Travelport по SOAP. Интегрируетесь с банком, госпорталом, страховым бэкендом, биллингом оператора или почти любым корпоративным продуктом, купленным до 2015-го: там контракт это WSDL, а на проводе <soap:Envelope>. Подписи WS-Security, вложения MTOM, SOAP 1.1 рядом с 1.2, soap:Fault при ошибке: этот мир жив, он приносит деньги и не переезжает на REST по вашей вежливой просьбе.

В .NET вызывать его стало неудобно. WCF как полноценный фреймворк ушёл. CoreWCF есть, но во всех опубликованных версиях висит незакрытая крипто-уязвимость, так что затащить его значит поменять одну проблему на другую. dotnet-svcutil генерит клиент из WSDL на этапе сборки, но это кодогенерация, приклеенная сбоку, а не шаг интеграции. А хостинг SOAP-эндпоинта, WS-Security руками или проводка MTOM обычно заканчиваются кучей конфигурации System.ServiceModel, которую никто не хочет держать.

redb.Route.Soap идёт другим путём. SOAP становится обычным шагом пайплайна в вашем же .NET-процессе. Вызвал сервис, получил типизированный ответ. Поднял эндпоинт, отдал тело маршруту, вернул ответ. Всё in-box: HttpClient, общий Kestrel-хост и System.Security.Cryptography.Xml для WS-Security. Ни WCF, ни рантайма System.ServiceModel, ни уязвимой зависимости, ни отдельного шлюза. Разберём, как это используется и почему нативный коннектор внутри ESB бьёт codegen-клиента или отдельную коробку.

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу направлением интеграции и развитием платформы Digital Q.Integration в «Диасофт».

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg