Везде противопоставляются подходы REST vs MessageBus.
Все популярные нынче шины работают по принципу pub-sub. Клиенты подключаются к шине и слушают сообщения. Это создает связь получателя с отправителем сообщения, но дает возможность гарантированной доставки, множество получателей и прочие плюшек.
REST API с другой стороны позволяет получателю ничего не знать об отправителе, но отправитель начинает зависеть от доступности получателя и сделать множество получателей становится сложнее.
Существует ли шина\боркер\оркестратор, который может совмещать оба подхода:
1) Получаель выстывляет REST API и ничего не знает об отправителе
2) Отправитель вызывает REST эндпоинт оркестратора
3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время
4) Окрестратор сам считает количество повторов и выбрасывает сообщение в случае невозможности доставки через N повторов
5) На стороне окрестратора можно настроить сохраннеие последовательности вызовов
6) (опционально) На стороне оркестратора можно выполнить преобразование тела и заголовков запроса по простым правилам
7) Оркестратор может в высокую доступность
8) Оркестратор умеет работать с разными схемами аутентификации HTTP как для входящих вызовов, так и исходящих
9) Настраивается оркестратор без программирования на языке высокого уровня, но возможно написание плагинов.
Что-то похожее на biztalk\SAP PI, только лековесное и желательно опенсорсное.
Здравствуйте, gandjustas, Вы писали:
G>Все популярные нынче шины работают по принципу pub-sub. Клиенты подключаются к шине и слушают сообщения. Это создает связь получателя с отправителем сообщения, но дает возможность гарантированной доставки, множество получателей и прочие плюшек.
Я не уверен, что существует связь. Как раз наоборот, оба развязаны, связаны только с брокером.
G>REST API с другой стороны позволяет получателю ничего не знать об отправителе, но отправитель начинает зависеть от доступности получателя и сделать множество получателей становится сложнее. G>Существует ли шина\боркер\оркестратор, который может совмещать оба подхода: G>1) Получаель выстывляет REST API и ничего не знает об отправителе G>2) Отправитель вызывает REST эндпоинт оркестратора G>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время G>4) Окрестратор сам считает количество повторов и выбрасывает сообщение в случае невозможности доставки через N повторов G>5) На стороне окрестратора можно настроить сохраннеие последовательности вызовов G>6) (опционально) На стороне оркестратора можно выполнить преобразование тела и заголовков запроса по простым правилам G>7) Оркестратор может в высокую доступность G>8) Оркестратор умеет работать с разными схемами аутентификации HTTP как для входящих вызовов, так и исходящих G>9) Настраивается оркестратор без программирования на языке высокого уровня, но возможно написание плагинов.
Чем все это отлично от reverse proxy L7, всяческих lb и nginx наконец?
Здравствуйте, gandjustas, Вы писали:
S>>Чем все это отлично от reverse proxy L7, всяческих lb и nginx наконец? G>nginx и всяческие LB умеют в гарантированную доставку?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Чем все это отлично от reverse proxy L7, всяческих lb и nginx наконец? G>>nginx и всяческие LB умеют в гарантированную доставку?
S>А почему нет?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>А почему нет? G>>Ссылку?
S>1) тут что-то велосипедят -- https://exactly-once.github.io/posts/exactly-once-http/
Я спрашиваю про готовый сервер.
S>2) какие есть обоснования невозможности этого сделать через L7\http ?
Например необходимость хранить сообщения в какой-то базе межу повторами.
Тут, наверное, самому.
S>>2) какие есть обоснования невозможности этого сделать через L7\http ? G>Например необходимость хранить сообщения в какой-то базе межу повторами.
Если нагрузка большая то ой, иначе ОЗУ -- чем не база?
Здравствуйте, gandjustas, Вы писали:
G>Везде противопоставляются подходы REST vs MessageBus.
Не везде . Я традиционно склоняю всех к REST+MessageBus. "Запросы" к сервису — через rest. Асинхронные уведомления от сервиса — через message bus (с известными данными о том, куда подписаться). В этом случае сервис может ничего не знать о своих клиентах. Клиенты могут использовать REST вместе с опросом на наличие изменений (polling). А могут слушать очередь на предмет интересующих их уведомлений, это будет более эффективно.
G>Это создает связь получателя с отправителем сообщения, но дает возможность гарантированной доставки, множество получателей и прочие плюшек.
Не факт, что создает. На Rabbit можно много разных логических схем городить. Получатель может просто декларировать очередь (queue). Тогда отправитель будет отвечать за маршрутизацию чего у него там есть в нужную очередь (или очереди).
G>Существует ли шина\боркер\оркестратор, который может совмещать оба подхода:
Почти все требования (кроме надежной доставки) реализуют API Gateways. А надежная доставка не нужна. Смотрите:
G>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время
Не нужно. Либо отправитель уже реализует надежную доставку до оркестратора (и тогда оркестратору не нужно ничего повторять). Либо отправитель надежной доставки не реалиует. Но это обозначает, что сообщения терять допустимо и дополнительную работу на оркестраторе можно не делать.
А еще очень часто отправителю нужно знать, было ли его "сообщение" (в REST вообще обмениваются не сообщениями, а представлениями состояния объектов) обработано каким-либо образом или нет. И если не обработано (произошла гонка и конкуретное обновление, например) — предпринять какие-то меры.
G>4) Окрестратор сам считает количество повторов и выбрасывает сообщение в случае невозможности доставки через N повторов
Выбрасывает — это в смысле "выбрасывает в мусор"? Просто больше я ничего другого не вижу. Отправитель уже давным давно ушел и ему никак не ответить.
Но вот что меня еще больше волнует, так это как этот пункт сочетается с предыдущим? Этот пункт (4) утверждает, что оркестратор может терять сообщения. Зачем тогда все сложности с попыткой гарантированной доставки в пункте 3?
G>5) На стороне окрестратора можно настроить сохраннеие последовательности вызовов
Это очень сложно в ситуации с "зависимыми entities" (когда связные сущности меняются неявно в результате изменения других). А могут ведь быть и явные групповые операции еще. Из более-менее простого я вижу только возможность доставлять сообщения строго последовательно. Но это не будет работать для больших нагрузок.
G>Существует такое? Или я слишком много хочу?
Называется API Gateway. Например, статья приводит несколько реализаций (на качество статьи я не смотрел, только на список решений). В целом API Gateway решают (с разной степенью успешности) те проблемы, которые я не откомментировал. Если вам все же очень хочется их решить — можно сделать два простеньких сервиса. Один будет предоставлять REST для отправки сообщений в message bus. Второй будет слушать сообщения и маршрутизировать их в web hook (aka вызов rest).
Здравствуйте, maxkar, Вы писали:
G>>Существует ли шина\боркер\оркестратор, который может совмещать оба подхода: M>Почти все требования (кроме надежной доставки) реализуют API Gateways. А надежная доставка не нужна. Смотрите:
G>>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время M>Не нужно. Либо отправитель уже реализует надежную доставку до оркестратора (и тогда оркестратору не нужно ничего повторять). Либо отправитель надежной доставки не реалиует. Но это обозначает, что сообщения терять допустимо и дополнительную работу на оркестраторе можно не делать.
В том и дело, что я хочу функцию надежной доставки возложить на этот брокер, а не городить его в каждом приложении. Тем более я сильно сомневаюсь в квалификации среднего программиста, что он может без ошибок сделать надежную доставку.
Без надежной доставки остальное все не очень нужно.
M>Но вот что меня еще больше волнует, так это как этот пункт сочетается с предыдущим? Этот пункт (4) утверждает, что оркестратор может терять сообщения. Зачем тогда все сложности с попыткой гарантированной доставки в пункте 3?
Это вообще нормальная практика, что сообщение выбрасывается из очереди если не удалось его доставить за N попыток.
G>>5) На стороне окрестратора можно настроить сохраннеие последовательности вызовов M>Это очень сложно в ситуации с "зависимыми entities" (когда связные сущности меняются неявно в результате изменения других). А могут ведь быть и явные групповые операции еще. Из более-менее простого я вижу только возможность доставлять сообщения строго последовательно. Но это не будет работать для больших нагрузок.
Вообще без разницы честно говоря. Я описал тот минимальный функционал который хочу видеть. Ни один пункт из него выкинуть нельзя.
G>>Существует такое? Или я слишком много хочу? M>Называется API Gateway. Например, статья приводит несколько реализаций (на качество статьи я не смотрел, только на список решений).
Без надежной доставки смысла нет.
M>Если вам все же очень хочется их решить — можно сделать два простеньких сервиса. Один будет предоставлять REST для отправки сообщений в message bus. Второй будет слушать сообщения и маршрутизировать их в web hook (aka вызов rest).
А почему нет одного сервера, который это делает?
Я понимаю что наколхозить такой сервер можно из подручных средств. Но вот готового решения, кроме тяжелых и дорогих, не видел.
Здравствуйте, gandjustas, Вы писали:
G>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время
Что значит "через некоторое время". Сессия между отправителем и оркестратором все еще доступна? Когда и как вернуть ответ отправителю?
G>4) Окрестратор сам считает количество повторов и выбрасывает сообщение в случае невозможности доставки через N повторов
Просто удаляет? Когда и как уведомить отправителя?
G>5) На стороне окрестратора можно настроить сохранение последовательности вызовов
Что значит последовательность вызовов?
Сохранили, но какой-то запрос в середине так и не удалось отправить. Что делаем с оставшимися запросами?
Даже если все запросы обработаны без ошибок, часто отправитель в принципе не может сформировать следующий запрос, пока не получит ответ предыдущего — у него просто не будет данных для этого. Например, в ответе должна прийти ссылка, которую нужно дергать, или какой-нибудь id. Когда и как уведомить отправителя?
G>Существует такое? Или я слишком много хочу?
Итого.
Если нужно синхронное промежуточное звено, то оно существует — Sharov говорил про reverse proxy. Их можно гибко настроить для балансировки, обработки отказов, преобразований и т.п. В nginx вроде даже можно на lua логику балансировки писать.
Если же предполагается асинхронность, то как минимум отправитель должен уметь обрабатывать асинхронные ответы. Но это уже не REST API.
Здравствуйте, gandjustas, Вы писали:
G>В том и дело, что я хочу функцию надежной доставки возложить на этот брокер, а не городить его в каждом приложении.
А не получится "не городить". Всегда есть проблема надежно доставить сообщение от отправителя для брокера. В момент генерации сообщения может не оказаться сети. Узел брокера может внезапно умереть. На машину с отправителем сразу после коммита в базу данных (или другое persistence storage) может случайно упасть метеорит и докатывать сообщение в брокер придется уже кому-то другому. Именно это и есть основная проблема — надежно доставить от первой точки до существующего решения. А дальше распространение сообщения по цепочке — уже вопрос удобства реализации.
G>Тем более я сильно сомневаюсь в квалификации среднего программиста, что он может без ошибок сделать надежную доставку.
Значит нужно выбирать одно из решений, которое позволяет упросить кодирование. И/или учить разработчиков его использовать, следить на ревью кода и т.д. Если "из коробки" — это распределенные транзакции. Понадобится соответствующая поддержка от драйвера базы (или инфраструктуры) и от драйвера брокера. Очевидно, что если брать готовую библиотеку, в ней вряд ли будет rest. Да и для вас нет никакой разницы от того, что у нее внутри.
Можно городить свой удобный велосипед. Под чутким руководством средние программисты такое пишут, проверял. Велосипед в моем стиле работает через основную базу (туда временно пишутся недоставленные сообщения). Библиотека отправки сообщений требует открытую транзакцию, посылает сообщения после коммита. Имеет задачу/поток по периодической докатке сообщений в брокера.
Причем вся эта магия с брокером работает только для ситуаций, когда можно отправить сообщение и забыть про него. К сожалению, во многих случаях нужно надежно продолбиться к конкретному сервису, получить от него ответ и обработать. Там брокер не особо поможет (хотя да, можно и вокруг брокера нагородить...). А вот возможность запрашивать pending операции и повторять их — полезно. Так что обработка повторных отправок входит в обязательный набор навыков разработчика REST.
M>>Но вот что меня еще больше волнует, так это как этот пункт сочетается с предыдущим? Этот пункт (4) утверждает, что оркестратор может терять сообщения. Зачем тогда все сложности с попыткой гарантированной доставки в пункте 3? G>Это вообще нормальная практика, что сообщение выбрасывается из очереди если не удалось его доставить за N попыток.
Это нормальная практика для ситуаций, когда нужно стримить котиков по интернет (ничего не имею против котиков). Ограничение числа попыток автоматически обозначает, что сообщения могут теряться. Поэтому разговор может идти только о количестве девяток (или просто значащих цифр) в надежности доставки отдельно сообщения.
В кровавом энтерпрайзе с реальными деньгами такое "отправили и фиг с ним" редко проходит. Как минимум — нужно отправлять такие сообщения в dead letters и потом вручную разбираться.
Плюс есть большая проблема с N. Точнее, с интервалом между первой и последней попытками отправки сообщения. Если это меньше часа — есть хороший шанс потерять сообщения, когда ляжет инфраструктура (сеть, kubernetes, маршрутизация, что там еще любят техопсы). Ляжет cloud provider в отдельной зоне. В потребителе сообщений будет баг, при котором определенные типы сообщений не могут быть обработаны (это, кстати, классный сценарий слить много сообщений в /dev/null до того, как проблема будет обнаружена). А если интервал большой, то какая разница, сколько именно раз повторится сообщение? Опять же, в типичном скучном бизнес-приложении есть большие запасы по нагрузке. В норме (стабильный операционный режим) у вас недоставленных сообщений будет вообще 0. Поэтому банальные мониторинги на очередь повторов/количество запущенных повторов/количество повторов отдельного сообщения дадут повод расставить сигналы (alerts) и в случае срабатывания неторопясь разобраться, почему же до получателся все еще не доходит.
Нет, есть сценарии где недоставленные сообщения — это нормальный и ожидаемый режим работы. Но таких мало относительно общей массы.
M>>Это очень сложно в ситуации с "зависимыми entities" G>Вообще без разницы честно говоря.
А зачем вы тогда ниже жалуетесь, что все решения — сложные?
M>>Если вам все же очень хочется их решить — можно сделать два простеньких сервиса. Один будет предоставлять REST для отправки сообщений в message bus. Второй будет слушать сообщения и маршрутизировать их в web hook (aka вызов rest). G>А почему нет одного сервера, который это делает? G>Я понимаю что наколхозить такой сервер можно из подручных средств. Но вот готового решения, кроме тяжелых и дорогих, не видел.
Как раз по причинам, описанным выше. Нужно надежно доставлять сообщения от отправителя до брокера или следующего сервиса. Если эта проблема решена, дальше по цепочке "синхронных" вызовов как раз не обязательно делать надежную доставку (первый сервис все равно крутить будет до победного конца). Клиенту/отправителю во многих случаях нужен ответ а не просто отправка сообщений.
У вас в сценарии вообще получается странная система. У вас надежность доставки между отправителем и брокером получается гораздо выше, чем между брокером и получателем. Иначе зачем вам все эти повторы доставки при сравнимых вероятностях отказа и без наличия надежной доставки до брокера/оркестратора? Ну ладно, я не отрицаю, может и такое где-то быть. Но на общем фоне — это совсем мизер. Поэтому решать такую редкую задачу никому и не интересно.
Есть и еще один момент. Типичный REST API все-таки предполагает не самую тривиальную обработку. Т.е. разные ответы, гонки состояний, разные форматы выдачи, чтение и запись данных. У вас в ваших требованиях все проще. Сообщения нужно получать, отвечать не обязательно. Там просто смысла нет никакого городить полноценный REST. Взяли брокер, написали ему слушатель (или RPC для брокера) и все. А вот когда функциональности не хватит — можно будет реализовывать что-то более сложное.
Кстати, касательно темы Rest vs Kafka. Там основная причина выбора шины сообщений — это наличие нескольких потребителей сообщения и очень слабая связность между отправителем и получателем. Отправителей не волнует, есть ли вообще получатели. Rest создает излишнюю связность — отправитель будет вынужден знать своих получателей (и их набор может меняться), а это исходя из условиях задачи не нужно. Если бы это были не получатели, а "критичные для работы зависимости", rest мог бы быть лучшим решением. И да, в обоих решениях в отправителе там нужно городить надежную доставку.
G>Без надежной доставки остальное все не очень нужно.
вообще, голый Rest Http и надёжная доставка- вещи несовместимые, поэтому народ обычно городит какие-то свои костыли либо на уровне протоколов: AMQP over HTTP with JSON
вообще, составь максимально полный каталог того, чего тебе нужно, и прошерсти весь опенсорс а потом и коммерческие решения на предмет соответствия именно твоим хотелкам, такое с пол-пинка не сделать;
или можно зайти с другой стороны и начать со знакомства с чем-то коммерческим (у них обычно документация и маркетинговые презентации чётче и складнее) , типа NServiceBus, а потом после составления каталога можно продолжить с бесплатным, где всё, что в каталоге накопилось, тоже есть
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время
Б>Что значит "через некоторое время". Сессия между отправителем и оркестратором все еще доступна? Когда и как вернуть ответ отправителю?
Не доступна, ответ не нужен. В большинстве случаев такое имет смысл для PUT и DELETE, иногда для POST.
G>>4) Окрестратор сам считает количество повторов и выбрасывает сообщение в случае невозможности доставки через N повторов Б>Просто удаляет? Когда и как уведомить отправителя?
Если быть точным — складывает в список "dead messages". Так собственно все очереди делают.
G>>5) На стороне окрестратора можно настроить сохранение последовательности вызовов Б>Что значит последовательность вызовов?
Если у тебя пишли вызовы 1, 2 и 3 в таком порядке, 1 не получилось отправить получателю, то 2 и 3 ждут когда отправится 1.
Б>Сохранили, но какой-то запрос в середине так и не удалось отправить. Что делаем с оставшимися запросами?
Ждут пока не отправится или пока запрос не вывалится из очереди.
Б>Даже если все запросы обработаны без ошибок, часто отправитель в принципе не может сформировать следующий запрос, пока не получит ответ предыдущего — у него просто не будет данных для этого. Например, в ответе должна прийти ссылка, которую нужно дергать, или какой-нибудь id. Когда и как уведомить отправителя?
Как же тогда существуют очереди типа того же RabbitMQ или Kafka? там ведь тоже отправитель не уведомляется никак по-умолчанию.
Уведомить отправителя как угодно, от "никак" до веб-хуков или очередей. Это нерелевантно вопросу.
Б>Если нужно синхронное промежуточное звено, то оно существует — Sharov говорил про reverse proxy. Их можно гибко настроить для балансировки, обработки отказов, преобразований и т.п. В nginx вроде даже можно на lua логику балансировки писать.
Нет, не синхронное. Я об этом несколько раз сказал.
Б>Если же предполагается асинхронность, то как минимум отправитель должен уметь обрабатывать асинхронные ответы. Но это уже не REST API.
Почему же? Для запросов PUT и DELETE в подавляющем большинстве случаев не надо получать ответ, достаточно чтобы запрос выполнился. Для некоторых POST запросов также.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>В том и дело, что я хочу функцию надежной доставки возложить на этот брокер, а не городить его в каждом приложении. M>А не получится "не городить".
Получится. Я напомню что такие продукты существуют. Но они дорогие и тяжеловесные.
Мне в одном проекте даже довелось использовать.
M>Всегда есть проблема надежно доставить сообщение от отправителя для брокера. В момент генерации сообщения может не оказаться сети. Узел брокера может внезапно умереть. На машину с отправителем сразу после коммита в базу данных (или другое persistence storage) может случайно упасть метеорит и докатывать сообщение в брокер придется уже кому-то другому. Именно это и есть основная проблема — надежно доставить от первой точки до существующего решения. А дальше распространение сообщения по цепочке — уже вопрос удобства реализации.
Госпади, как же люди с очередями работают типа rabbitmq... Они ведь тоже могут оказаться недоступны.
Давайте вопрос доступности брокера оставим за кадром.
G>>Тем более я сильно сомневаюсь в квалификации среднего программиста, что он может без ошибок сделать надежную доставку. M>Значит нужно выбирать одно из решений, которое позволяет упросить кодирование.
Так в этом и вопрос, существует ли такое решение? Я знаю пару очень дорогих. А дешевых\беслатных не видел к сожалению.
M>Можно городить свой удобный велосипед. Под чутким руководством средние программисты такое пишут, проверял. Велосипед в моем стиле работает через основную базу (туда временно пишутся недоставленные сообщения). Библиотека отправки сообщений требует открытую транзакцию, посылает сообщения после коммита. Имеет задачу/поток по периодической докатке сообщений в брокера.
Велосипеды не обсуждаем. Очевидно их можно нагородить.
M>Причем вся эта магия с брокером работает только для ситуаций, когда можно отправить сообщение и забыть про него. К сожалению, во многих случаях нужно надежно продолбиться к конкретному сервису, получить от него ответ и обработать. Там брокер не особо поможет (хотя да, можно и вокруг брокера нагородить...).
Тем не менее использование очередей очень популярно. Внезапно там не надо синхронно получать ответ.
M>В кровавом энтерпрайзе с реальными деньгами такое "отправили и фиг с ним" редко проходит. Как минимум — нужно отправлять такие сообщения в dead letters и потом вручную разбираться.
Так обычно и происходит. Удаленные из очереди складываются в отдельный список "мертвых" сообщений.
M>Плюс есть большая проблема с N. Точнее, с интервалом между первой и последней попытками отправки сообщения. Если это меньше часа — есть хороший шанс потерять сообщения, когда ляжет инфраструктура (сеть, kubernetes, маршрутизация, что там еще любят техопсы). Ляжет cloud provider в отдельной зоне. В потребителе сообщений будет баг, при котором определенные типы сообщений не могут быть обработаны (это, кстати, классный сценарий слить много сообщений в /dev/null до того, как проблема будет обнаружена). А если интервал большой, то какая разница, сколько именно раз повторится сообщение? Опять же, в типичном скучном бизнес-приложении есть большие запасы по нагрузке. В норме (стабильный операционный режим) у вас недоставленных сообщений будет вообще 0. Поэтому банальные мониторинги на очередь повторов/количество запущенных повторов/количество повторов отдельного сообщения дадут повод расставить сигналы (alerts) и в случае срабатывания неторопясь разобраться, почему же до получателся все еще не доходит.
Поэтому во всех взрослых (корпоративных) системах задержка растет экспоненциально. От миллисекунд до часов.
M>Нет, есть сценарии где недоставленные сообщения — это нормальный и ожидаемый режим работы. Но таких мало относительно общей массы.
Если системы не связаны, то может быть и достаточно много. Но это скорее мера защиты получателя от бомбардировк необрабатываемыми сообщениями, а не нормальный режим работы.
M>>>Это очень сложно в ситуации с "зависимыми entities" G>>Вообще без разницы честно говоря. M>А зачем вы тогда ниже жалуетесь, что все решения — сложные?
В том решении, которое я хочу видеть не продполагается "зависимых entities". Представьте себе rabbitmq, но сообщения доставлюся REST запросами на указанные эндпоинты получателя и отправляются также REST запросами на эндпоинты очереди. Вот такое решение хочу видеть. Готовое. Без самописных велосипедов и своих протоколов.
Здравствуйте, takTak, Вы писали:
G>>Без надежной доставки остальное все не очень нужно.
T>вообще, голый Rest Http и надёжная доставка- вещи несовместимые, поэтому народ обычно городит какие-то свои костыли либо на уровне протоколов: T>AMQP over HTTP with JSON
Это требует подключение получателя к очереди и отдельная обработка входящих. А хочется чтобы этого не было. Получатель — обычный rest и не зает об очереди.
T>или можно зайти с другой стороны и начать со знакомства с чем-то коммерческим (у них обычно документация и маркетинговые презентации чётче и складнее) , типа NServiceBus, а потом после составления каталога можно продолжить с бесплатным, где всё, что в каталоге накопилось, тоже есть
Я по этому пути прошел. Использовал BizTalk и SAP PI, они умеют делать что я написал. Я пытался нагуглить решение, как описал, но ничего близкого не нашел.
Здравствуйте, gandjustas, Вы писали:
G>Что-то похожее на biztalk\SAP PI, только лековесное и желательно опенсорсное. G>Существует такое? Или я слишком много хочу?
Сам не работал с таким, но возможно речь про Enterprise Serivice Bus?
Open source вариантов хватает: Apache ServiceMix, Mule ESB, Fuse ESB, Talend ESB
. Я традиционно склоняю всех к REST+MessageBus. "Запросы" к сервису — через rest. Асинхронные уведомления от сервиса — через message bus (с известными данными о том, куда подписаться). В этом случае сервис может ничего не знать о своих клиентах. Клиенты могут использовать REST вместе с опросом на наличие изменений (polling). А могут слушать очередь на предмет интересующих их уведомлений, это будет более эффективно.
