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

В Москве с 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 на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато  программисты продолжают работать)