Enterprise Service Bus, NET Service Bus, NServiceBus e le ruote del bus

Question

Enterprise Service Bus (ESB), .NET Service Bus (Windows Azure AppFabric Service Bus), NServiceBus, RhinoServiceBus, MassTransit e così via.

Sto cercando di capire che cosa ciascuna di queste tecnologie hanno in comune o non comune.

Ho frequentato la presentazione di Juval Löwy su .NET Service Bus prima di oggi e ha affermato che il .NET Service Bus potrebbe essere usato come la versione di un uomo povero di un ESB, quindi vorrei prendere quella a significare che il Service Bus .NET NON è un ESB, sono tutti gli altri un vero ESB?

Se uno qualsiasi degli altri sono un vero ESB ciò li renderebbe un vero ESB in contrasto con il .NET Service Bus?

Answer 1

Sono d'accordo con l'altro manifesto: ESB è un po 'come SOA, una definizione generale che viene utilizzato per lo più come un punto di vendita di marketing che come un rigoroso standard è necessario soddisfare

.

Da Wikipedia:

  

I commentatori sono d'accordo sul fatto   per definire un Enterprise Service Bus   (ESB) come uno stile architettonico, un   prodotto software, o un gruppo di   prodotti software. Anche se l'uso di un ESB   implica certamente l'adesione a una   particolare architettura, il termine   “Enterprise service bus” quasi sempre   denota l'infrastruttura software   che consente una tale architettura, e   in sostanza, l'ESB è considerato un   piattaforma per realizzare un servizio orientato   architettura.

     

Un ESB porta i concetti di flusso relativi   come trasformazione e instradamento verso   una Service-Oriented Architecture. Un   ESB può anche fornire un'astrazione   per gli endpoint.

ESB come termine sembra essere stato coniato da Dave Chappel, che è evangelista tecnico per Sonic Software (ed autore "Enterprise Service Bus" - O'Reilly (era?): Giugno 2004, ISBN 0-596-00675- 6). Ho letto il libro e ho partecipato a un paio di seminari di Chappell, e temo che il libro stesso non è molto di aiuto per aiutare a decidere se il prodotto X è un "vero" ESB.

In generale si dovrebbe cercare qualcosa sulla base messaggio (questo era l'originale intento, a quanto pare, anche se alcune altre aziende, come webMethods, usano il termine per il loro prodotto, che è più webservices-oriented).

L'idea è quella di avere tutti i "servizi" nella vostra infrastruttura IT in grado di ricevere e inviare messaggi gli uni agli altri. L'ESB fornisce il routing, e ha gli endpoint di interfaccia in modo che se l'applicazione originale ha lavorato - per esempio - invocando una pagina JSP tramite HTTP posta, si dispone di un piccolo programma che può ricevere un messaggio, utilizza il suo carico utile di pubblicarlo tramite HTTP, interpretare il risultato e costruire un messaggio di risposta con questi.

In sostanza, immaginate che invece di utilizzare WebServices per tutto, si utilizzano code di messaggi, la costruzione di stazioni di routing, e l'interfaccia tra le code di messaggi e altri sistemi. Si tratta di un ESB.

---

Questa è lungo, ma istruttivo: https://plus.google.com/112678702228711889851/posts / eVeouesvaVX

Answer 2

Credo che è necessario capire che l'ESB è più di un termine di marketing di un termine tecnico. Molti produttori stanno presentando le tecnologie sotto quella bandiera.

La cosa da guardare è il bus di stile architettonico, in cui le fonti di eventi e lavelli collaborano. NServiceBus, RhinoServiceBus, e MassTransit hanno il concetto di pubblicazione e la sottoscrizione di eventi costruiti in - .NET Servizio bus non

.

Le differenze tra i tre sopra sono più in forma che nella funzione -. Stabilità, la documentazione, comunità, etc

La speranza che aiuta.