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

Enterprise Service Bus (ESB),.NET Service Bus (служебная шина Windows Azure AppFabric), NServiceBus, RhinoServiceBus, MassTransit и т.д.

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

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

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

Ответ 1

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

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

Комментаторы не согласны с тем, для определения служебной шины предприятия (ESB) как архитектурный стиль, программного продукта или группы программных продуктов. Хотя использование ESB безусловно, подразумевает приверженность особая архитектура, термин "служебный автобус" почти всегда обозначает программную инфраструктуру что позволяет такую архитектуру и по существу, ESB считается платформу для реализации сервис-ориентированных архитектура.

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

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

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

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

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

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

Ответ 2

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

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

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

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