Enterprise Service Bus, .NET Service Bus, NServiceBus и колеса на шине

Question

Enterprise Service Bus (ESB), .NET Service Bus (Windows Azure AppFabric Service Bus), NServiceBus, RhinoServiceBus, MassTransit и так далее.

Я пытаюсь понять, что общего у каждой из этих технологий или нет.

Ранее я посетил презентацию Ювала Леви о .NET Service Bus, и он заявил, что .NET Service Bus может использоваться как версия ESB для бедного человека, поэтому я бы это понял, что. НЕ является ESB, является ли кто-либо из других настоящим ESB?

Если кто-либо из них является истинным ESB, что делает их настоящим ESB в отличие от .NET Service Bus?

Answer 1

Я согласен с другим автором: ESB немного похож на SOA, общее определение, которое используется в основном как точка продаж для маркетинга, а не как строгий стандарт, которому вы должны соответствовать.

Из Википедии:

Комментаторы не согласны с тем, определить Enterprise Service Bus (ESB) как архитектурный стиль, программный продукт, или группа программные продукты. Во время использования ESB безусловно, подразумевает приверженность конкретная архитектура, термин «Сервисный автобус предприятия» почти всегда обозначает инфраструктуру программного обеспечения что позволяет такую ​​архитектуру, и по сути, ESB считается Платформа для реализации сервис-ориентированных архитектура.

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

ESB как термин, по-видимому, был придуман Дейвом Чаппелем, который является (был?) Техническим евангелистом Sonic Software (и автором "Enterprise Service Bus" - O'Reilly: июнь 2004 г., ISBN 0-596-00675- 6). Я прочитал книгу и посетил несколько семинаров Чаппелла, и я боюсь, что сама книга не очень поможет вам решить, является ли Продукт X «истинным» ESB.

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

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

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

---

Это долго, но поучительно: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

Answer 2

Я думаю, вы должны понимать, что ESB - это скорее маркетинговый термин, чем технический. Многие поставщики представляют технологии под этим баннером.

Необходимо обратить внимание на стиль архитектуры шины, в котором взаимодействуют источники и приемники событий. NServiceBus, RhinoServiceBus и MassTransit имеют концепцию публикации и подписки на встроенные события, а .NET Service Bus - нет.

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

Надеюсь, это поможет.