Enterprise Service Bus, .NET Service Bus, NServiceBus i koła w magistrali

Question

Enterprise Service Bus (ESB), .NET Service Bus (Windows Azure AppFabric Service Bus), NServiceBus, RhinoServiceBus, MassTransit i tak dalej.

Próbuję zrozumieć, co każda z tych technologii ma lub nie jest wspólna.

Dzisiaj wczoraj brałem udział w prezentacji Juval Löwy na temat usługi .NET Service Bus i oświadczyłem, że usługa .NET Service Bus może być używana jako wersja ESB dla biednych ludzi, dlatego uważam, że usługa .NET Autobus NIE jest ESB, czy któryś z pozostałych to prawdziwy ESB?

Jeśli którakolwiek z pozostałych jest prawdziwą ESB, co uczyniłoby z nich prawdziwą ESB w przeciwieństwie do .NET Service Bus?

Answer 1

Zgadzam się z drugim plakatem: ESB jest trochę jak SOA, ogólna definicja, która jest używana głównie jako punkt sprzedaży marketingowej niż jako surowy standard, który musisz spełnić.

Z Wikipedii:

Komentatorzy zgadzają się nad tym, czy zdefiniować Enterprise Service Bus (ESB) jako stylu architektonicznego, produkt oprogramowania, lub grupy oprogramowania. Chociaż użycie ESB pewno oznacza przyleganie do konkretnej architektury, określenie „bus usług przedsiębiorstwa” prawie zawsze oznacza infrastrukturę oprogramowania który umożliwia taką architekturę i w istocie, ESB jest uważany za platforma realizować zorientowaną na usługi architekturę .

ESB wprowadza koncepcje związane z przepływem , takie jak transformacja i routing do architektury w ramach architektury zorientowanej na usługi. An error occurred. ESB może również dostarczyć abstrakcję dla punktów końcowych .

ESB jak wydaje się termin został ukuty przez Dave Chappel, który jest ewangelisty techniczną dla Sonic Software (i autora "Enterprise Service Bus" - O'Reilly (był): czerwca 2004, ISBN 0-596 -00675-6). Przeczytałem tę książkę i wzięłam udział w kilku seminariach Chappell i obawiam się, że sama książka nie jest zbyt pomocna w podjęciu decyzji, czy produkt X jest "prawdziwym" ESB.

Generalnie powinieneś poszukać czegoś opartego na wiadomościach (to był pierwotny zamiar, widocznie, nawet jeśli niektóre inne firmy, takie jak webMethods, używają terminu dla swojego produktu, który jest bardziej zorientowany na usługi webservices).

Chodzi o to, aby wszystkie "usługi" w twojej infrastrukturze IT były w stanie odbierać i wysyłać wiadomości do siebie nawzajem. ESB zapewnia routing i ma punkty końcowe interfejsu, więc jeśli oryginalna aplikacja działała - na przykład - poprzez wywołanie strony JSP za pomocą posta HTTP, masz mały program, który może odbierać wiadomości, użyć swojego ładunku do wysłania go przez HTTP, zinterpretuj wynik i utwórz z nimi odpowiedź na komunikat.

Zasadniczo, wyobraź sobie, że zamiast używać usług WWW do wszystkiego, używasz kolejek komunikatów, budujesz stacje routingu i interfejs między kolejkami komunikatów i innymi systemami. To jest ESB.

---

To jest długa, ale pouczający: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

Answer 2

Myślę, że trzeba zrozumieć, że ESB to raczej termin marketingowy niż termin techniczny. Wielu dostawców prezentuje technologie pod tym banerem.

Należy spojrzeć na styl architektury Bus, w którym współpracują źródła zdarzeń i pochłaniacze. NServiceBus, RhinoServiceBus i MassTransit mają koncepcję publikowania i subskrybowania wbudowanych zdarzeń - usługa .NET Service Bus nie.

Różnice między trzema wyżej są w formie niż w funkcji - stabilność, dokumentacji, społeczności itp

nadzieję, że pomoże.