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

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

Так как люди эти далекие от мира IT и смотрят на IT-шников в лучшем случае как на чудиков, которые говорят на марсианском, я объясняю эти вещи на простых и понятных примерах.

И так как я уже устал повторять одно и тоже, то решил переложить эти мысли в статью и создать уже осознанное знание.

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

Итак, заходит как-то раз менеджер в бар....

Интеграция через шину.

Большинство людей бывало в баре и, скорее всего, легко назовет его главные составляющие - это барная стойка и, собственно, сам бармен.

Барная стойка представляет из себя высокий деревянный стол и расположенные на нем краны. Собственно барная стойка и представляет из себя лучший аналог шины данных, на которой располагаются краны с пивом - это опубликованные сервисы. А бармен - это управляющий механизм. Общая схема взаимодействия показана на Рисунке 1.

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

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

Наше законодательство максимально простое в данное случае - любой напиток после 18 лет. Однако в IT-мире всё не всегда так просто и потому разные сервисы могут требовать разный уровень доступа.

Если бы доступ к пиву крепостью меньше 4 градусов был бы разрешен с 16 лет, от 4 до 10 градусов с 18 лет, а напиткам крепче 10 градусов от 21 года, то процесс явной авторизации встречался бы гораздо чаще, т.к. разница во внешности в этом диапазоне не очевидна.

Преимущества работы через шину в данном случае в том, что бармен один и осуществляет процедуру авторизации на все представленные сервисы (краны).

Следующей важной функцией бармена является определение параметров контракта на сервис (рис 2). В типовом баре всегда есть стандартный набор посуды в который разливаются напитки - 0,33; 0,5; 1 литр. После авторизации бармен уточняет какой напиток вас интересует, какой объем стакана и их количество. После чего напиток наливается и выдается вам, затем происходит оплата (аккаунтинг, но на нем мы останавливаться не будем). Крайне редко можно встретить бар, в который можно прийти со своей тарой и попросить налить напиток в нее.

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

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

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

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

Минусы - это сложность поддержания, необходимость упаковывать всех в одну логику, а так же производительность. Если открыть все краны разом не факт, что давление будет достаточным. Можно конечно, поставить дополнительные насосы и решить эту проблему, но при этом, если такие нагрузки случаются не часто, то у вас будет избыточная мощность, которая большую часть времени будет простаивать. А ведь ее нужно обслуживать и поддерживать в рабочем состоянии, что приводит к дополнительным затратам.

Интеграция типа точка-точка.

Исходя из плюсов и минусов шины, для некоторых IT-ландшафтов шина не применяется. В виду различных причин: нет денег, мало IT-систем, нет компетенций, у IT-шников ещё много сил и задора и прочее.

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

В баре целый зоопарк холодильников, от советских ЗиЛов до современных со встроенными терминалами оплаты по биометрии. У каждого холодильника своя система авторизации, на ЗиЛах стоит всем известная Галя с пачкой ключей таблеток и открывает нужный холодильник, только если ее попросить, на каких-то происходит считывание электронного паспорта, а какие-то считывают лицо пользователя и обращаются в МВД для определения возраста и в банк для проверки наличия денег на карте (рис 5).

Если вам кажется, что это надуманная история и IT-ландшафт так не выглядит, боюсь вас разочаровать это достаточно типовая ситуация и при том не только и не столько для России, а в Европе или США это вполне себе реальная ситуация. Рядом со старыми системами, написанными на Коболе, могут стоять вполне себе современные системы написанные на C#, Python или Java.

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

А теперь представим себе ситуацию, когда вам захотелось очень популярного пива, которое представлено только в одном холодильнике(высоконагруженной системе). Как часто бывает в таких ситуациях - при подходе к холодильнику, вы скорее всего столкнетесь с очередью (рис.6).

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

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

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

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

Минусы появляются при большом масштабе IT-ландшафта, если у вас много систем и к ним идет множество различных запросов, поддерживать всё это разнообразие становится сложно и затратно. Гибкость решения перестает перекрывать сложность решения.

Интеграция типа DB-link

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

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

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

Почему этот способ является наименее популярным и в здравом уме не используется ни в жизни и не в IT?

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

Ещё одним существенным недостатком является тот факт, что в двух способах описанных выше, мы рассматривали односторонний поток данных от источника к потребителю. Обратный доступ от потребителя к данным не предоставлялся, если это не было спроектировано.

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

Потому db-link может применяться в тестовых средах, когда вам нужно быстро перекачивать некритичные данные. Иногда могут использоваться в промышленных решениях, когда нужна максимальная производительность и вторжение извне кажется мало вероятным. Однако даже в таких случаях от подобного рода решений стараются всё-таки избавиться.

Плюсы реализации максимальная производительность и простота реализации.

Минусы слабая защита от несанкционированных действий пользователей и высокий риск потери всех данных.

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