Является ли NServiceBus ESB или облегченной ESB? или это больше похоже на WCF с надежным/надежным обменом сообщениями? Мне кажется, это больше похоже на фреймворк для обмена сообщениями, чем на ESB.
просто хочу какой-нибудь указатель, так как я только начал изучать различные продукты ESB и то, что они могут делать или нет.
NServiceBus определенно является ESB. Полная остановка.
Корпоративная служебная шина, шина, означающая вещь, которая по своей конструкции позволяет компонентам системы распределяться и работать независимо. Сам автобус тоже раздается. Сбой одного компонента или службы не влияет на доступность других компонентов, подключенных к шине.
Противоположностью автобуса является брокер. Брокер представляет собой единую точку отказа в системе. Такие вещи, как MS BizTalk, являются брокерами, а не ESB.
ОБНОВЛЕНИЕ
Чтобы немного рассказать о корпоративной поддержке в NSB
, поддерживается шаблоны обмена сообщениями — это односторонняя отправка и забвение (надежное и срочное), коррелированный запрос-ответ, публикация-подписка. Все остальное можно построить поверх этого.
– транзакционная обработка сообщений и автоматическая повторные попытки
— балансировка нагрузки с помощью дистрибьютор
— настраиваемый аудит и мониторинг с помощью счетчиков производительности
— встроенный длительный процесс управления
списком продолжается... превращая NServiceBus в ESB
Некоторые продукты брокера сообщений могут быть развернуты в «федеративном режиме», что делает эти развертывания децентрализованными. Тип децентрализованного развертывания хорошо согласуется со стилем архитектуры шины. Так что, думаю, зависит. Однако централизованное развертывание — это всего лишь брокер корпоративных служб, а не шина.
Нет, я бы не стал рассматривать NServiceBus как продукт ESB, и в целом это не инструмент EAI.
Если нам нужно найти сравнение с другими инструментами, NServiceBus ближе к JMS API (например, spring-jms) и AMQP. Это платформа, помогающая вам взаимодействовать с очередями сообщений и реализовывать общие шаблоны обмена сообщениями в вашем приложении (например, публикация/подписка, запрос/ответ, недоставленные буквы, «сага») с использованием удобного синтаксиса программирования.
Принимая во внимание, что продукт ESB, традиционно известный в индустрии EAI, представляет собой платформу, которая облегчает интеграцию многих разнородных приложений в корпоративную среду. Хотя разные продукты ESB предлагают разные функции, все они имеют определенные общие функции, которые делают их полезными, основными из которых являются их широкий набор коннекторов для различных открытых и проприетарных протоколов и сервисов (включая очереди сообщений, а также другие вещи, например, WS). -*, sftp, SAP, Siebel, rdbms, xmpp, websockets/comet, corba, edi), а также полный набор готовых к использованию шаблонов корпоративной интеграции (согласно «черной книге»), чтобы у вас не было реализовать их самостоятельно, чтобы организовать сложную интеграционную логику, такую как преобразования, преобразования, маршрутизация, приоритизация, бизнес-правила, применение политик, проверки, обнаружение дубликатов, ETL и обычное перемещение данных между приложениями.
NServiceBus не предоставляет функций, отдаленно связанных с выполнением какой-либо работы по интеграции, и никогда не предназначался для этого. Это то, что вы могли бы использовать для реализации шаблонов обмена сообщениями в своем приложении, но это не то, что вы выбрали бы для проекта EAI.
Ну, я думаю, что nServicebus, безусловно, является ServiceBus, но не уверен, что вы можете назвать его «Enterprise» ServiceBus, не тратя на это сотни тысяч. А если серьезно, вам нужно подумать, действительно ли вам нужен ESB или нет. Большинство из них обещают богатство, но приносят много накладных расходов, и может быть очень трудно осознать ценность. Я использовал WSO2 на большом предприятии, где это был один из трех наших ESB. Очень предприимчивый, управляемый командой OPs, и настоящая боль, потому что нам пришлось иметь дело с другой командой, чтобы настроить и запустить нашу систему. Другие проблемы включают так называемые функции, такие как маршрутизация сообщений или перевод сообщений. Конечно, продукт может делать эти вещи, но он выводит вас из среды разработки и дает вам больше забот. Код и/или конфигурация распределяются по большему количеству мест, больше вещей для управления большим количеством вещей, которые могут пойти не так. Это то, что мне нравится в nServiceBus: он очень доступен для разработчиков. Еще одна реализация, которая мне нравится, — Azure ServiceBus. Очевидно, что он не такой полнофункциональный, и, вероятно, это не то, что вы ищете, но мне нравится доступность для разработчиков и характер самообслуживания, и это те черты, на которые я бы обратил внимание.
Служебная шина предприятия — это составной шаблон SOA. Если вы заглянете в книги Томаса Эрла, то увидите шаблоны, которые включает ESB.
NServiceBus, насколько мне известно (ограничено), действительно применяет некоторые из этих шаблонов - ожидается, что остальные (например, централизация правил и централизация политик) будут реализованы пользователем. По этому определению BizTalk также является ESB.
Важно помнить, что использование NServiceBus, Biztalk или чего-либо еще не делает вас SOA. На самом деле, при неправильном использовании вы можете оказаться привязанным к поставщику, нарушив первый принцип SOA — нейтральность поставщика.
Ваш вопрос немного открытый. Вероятно, было бы лучше указать, какие функции вам требуются от ESB, а затем спросить, поддерживает ли их NSB.
ОБНОВЛЕНИЕ
Я кормлю, я должен обновить свой ответ в ответ на ответ Криса.
Хотя это удобно, ошибочно и бесполезно создавать две категории, Bus и Broker, как утверждает Крис.
Служебная шина обеспечивает нейтральную для транспорта и платформы опосредованную связь между службами и их потребителями. В соответствии с этим определением продукты, использующие модель брокера сообщений, также могут использоваться в качестве служебной шины.
Служебная шина корпоративного обеспечивает это подключение, но также может добавлять посредничество корпоративного уровня, например:
Я думаю, поэтому, когда вы выбираете набор инструментов, вы должны в первую очередь решить, какие функции вам нужны, а затем вы можете выбрать продукт, который больше всего соответствует вашим потребностям.
