Сервисная шина и очереди сообщений

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали — теперь это улица Марии Ульяновой, а дом 25 по этой улице — хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…


Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.

Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.

Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли

Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример – моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе – MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр.  Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато  программисты продолжают работать)

Сервисная шина и очереди сообщений: 6 комментариев

  1. Стандарты – это ДА, звучит Мощно 🙂 А где полет фонтазии, развитие, если все упирается в стандарты …? Шаг в сторону и растрел на месте ? 🙂

    Отбросим шутки в сторону …
    Создадим отказоустойчивую ОС, программные продукты, единую учебную базу. Регламенты по плановой замене оборудования внедрим в жизнь. И … всех ИТ-ников: манагеров, админов, архитекторов и т.д. уволим, чтобы занимались полезным делом – писали книги, создавали живой продукт …. автомобили и самолеты, например 🙂

  2. На мой взгляд, здесь какое-то ограниченное толкование смысла ESB, которая обеспечивает в первую очередь интероперабельность взаимодействия/коммуникаций систем, посредством передачи сообщений (и не важно, очереди это или запрос-ответы). Вопросы консистентного состояния бизнес-объектов с которыми связаны эти коммуникации – задача выше уровня: приложения и бизнес-протоколы, всякие алгоритмы типа монотонного чтения – очевидно, что REST тут не причём, это только один из вариантов представления (в купе например с if-modified-since), который не решает все задачи (начиная с проблемы синхронности своей работы).

  3. Проблема глубже, чем кажется …

    Пример из жизни.
    В одной очень крупной Компании г.Москвы несколько лет назад была организована БД документооборота в Lotus Notes.
    С переходом c MS Office 2000 на MS Office 2003 документы из той базы у пользователей начали открываться с видимыми правками, о чем позаботилась компания Microsoft, принудительно внедрив данную функциональность. Можно говорить о том, что документы, перед размещением в базе, нужно предварительно подготавливать (принимать все правки, перед их размещением в базе и т.д.), но факт на лицо – неприятность, которая была решена при заметном усилии службы ИТ Компании(найдено обходное решение). Другой пример (возможно слухи) “В новой версии ПО перестали открываться документы старых версий (вендор ограничил функционал) ПО”.

    Выходы
    1. В настоящее время “ИТ должно творчески подходить к выбору программных решений и стараться использовать как можно стандартов”, например хранить документы в pdf, jpg и т.д. 🙂
    2. Проблема с многообразием решений решается путем стандартизации решений на уровне Компании. Корпоративные стандарты, такие как “Стандарт (Регламент для банков) на оборудование, передаваемую, хранимую информацию, ОС, ИС, ПО и т.д.”

    1. насчёт “творческого подхода” – использовать Wiki для коллективной разработки и сопровождения документов. Тогда не придётся пересылать документы, важнейшее значение будет приобретать ссылка и возможность захода на неё. Уже сейчас какой-нибудь Confluence интегрирован и с pdf, и с Word.

  4. Максим, добрый день!
    Возможно не совсем в тему вопрос, но где-то его нужно задать 🙂

    Могли бы Вы посоветовать хорошую книгу по Enterprise Service Bus, в которой бы на концептуальном уровне разбиралось что это такое, чем полезно бизнесу, чем полезно ИТ, лучшие практики, возможно конкретные продукты?
    Чувствую, наша компания, не избежит сего чуда, и придет рано или поздно к шине..

    Литературы много и хотелось бы получить совет от человека, который наверняка уже много по этой теме перечитал, что действительно стоит прочтения (можно на английском языке)

    Буду очень благодарна

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *