Bus di servizio aziendale, Bus di servizio .NET, NServiceBus e le ruote sul bus

Question

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

Sto cercando di capire cosa hanno in comune o meno queste tecnologie in comune.

Ho partecipato alla presentazione di Juval Löwy su .NET Service Bus in data odierna e ha affermato che .NET Service Bus potrebbe essere utilizzato come versione di un ESB di un utente povero, quindi prendo questo per indicare che il servizio .NET. Il bus NON è un ESB, gli altri sono un vero ESB?

Se uno degli altri è un vero ESB, cosa li renderebbe un vero ESB rispetto al Bus di servizio .NET?

Answer 1

Sono d'accordo con l'altro poster: ESB è un po 'come SOA, una definizione generale che viene utilizzata principalmente come un punto di vendita di marketing che come uno standard rigoroso che è 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 certamente implica 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 una piattaforma a realizzare un'architettura orientata ai servizi.

Un ESB presenta i concetti relativi al flusso come la trasformazione e il routing su un'architettura orientata ai servizi. 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 in sé non sia di grande aiuto nell'aiutarti a decidere se il prodotto X è un ESB "vero".

In generale si dovrebbe cercare qualcosa basato sul messaggio (questo era l'intento originale, apparentemente, anche se alcune altre società, come webMethods, usano il termine per il loro prodotto, che è più orientato ai servizi web).

L'idea è di avere tutti i "servizi" nella propria infrastruttura IT in grado di ricevere e inviare messaggi a vicenda. L'ESB fornisce il routing e ha endpoint di interfaccia in modo che se l'applicazione originale ha funzionato, ad esempio, invocando una pagina JSP tramite post HTTP, si dispone di un piccolo programma che può ricevere un messaggio, utilizzare il suo payload per postarlo tramite HTTP, interpretare il risultato e creare una risposta al messaggio con questi.

In pratica, si immagini che invece di utilizzare i servizi Web per tutto, si utilizzano code di messaggi, si creano stazioni di instradamento e si interfacciano tra code di messaggi e altri sistemi. Questo è un ESB.

---

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

Answer 2

Penso che sia necessario capire che ESB è più un termine di marketing che un termine tecnico. Molti venditori presentano tecnologie con questo banner.

La cosa da guardare è il Bus Architectural Style, nel quale collaborano fonti e lavandini. NServiceBus, RhinoServiceBus e MassTransit hanno il concetto di pubblicazione e sottoscrizione di eventi integrati: il servizio .NET Bus non funziona.

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

Speranza che aiuta.