Qualcuno può spiegare a me un servizio di Enterprise Bus in non buzzspeak?

Question

Alcuni dei nostri partner ci dicono che il nostro software deve interagire con un bus di servizio aziendale. Dopo una ricerca un po ', il mio istinto è di dire che questo è solo un modo per dire che dobbiamo avere un modo indipendente dalla piattaforma per passare i messaggi avanti e indietro. Sto solo cercando di farti un'idea di ciò che i nostri partner ci stanno dicendo. Ho ragione a respingere la richiesta dei nostri partner come se stessimo solo cercando di ottenere che il nostro software fosse più conforme al buzzword, o ci stanno dicendo qualcosa che dovremmo ascoltare (anche se codificati in buzzspeak)?

Answer 1

Sebbene ESB sia basato sulla messaggistica, non è "solo" messaggistica e non solo una parola d'ordine

Quindi, se si inizia con un semplice vecchio sistema di sincronizzazione asincrona, le prime reti tendono ad essere molto punto-punto. Dovevi collegare (cioè configurare attraverso alcune interfacce di amministrazione) ogni connessione e ogni coppia di destinazioni e se avevi il coraggio di spostare qualsiasi cosa intorno invariabilmente qualcosa si rompeva. Poiché i punti di connessione erano cablati a mano, queste reti non raggiungevano mai un'elevata densità di connessione. Il costo incrementale era troppo alto e non scalabile. C'era anche un sacco di controllo degli accessi e policy incorporati nella topologia. La mancanza di densità di connessione favorisce in realtà questo approccio alla sicurezza, anche se inibisce la flessibilità.

L'ESB tenta di affrontare questi problemi con ...

• risoluzione di run-time di destinazioni/servizi/risorse
• Località trasparenza
• any-to-any di connettività e di connessione massima densità
• Architettato per ridondanza, scalabilità orizzontale, failover
• Politica, controllo di accesso, regole esternalizzate dalla topologia
• logico livello di rete di messaggistica implementato in cima al livello di rete di messaggistica fisico
• namespace comune

Così, quando il cliente chiede di compatibilità ESB, vogliono cose come quanto sopra. Dal punto di vista delle applicazioni, questo implica anche ...

• Evitando affinità di messaggi quali i requisiti per elaborare in stretta sequenza o per affrontare le richieste solo a nodi specifici, invece di una destinazione di rete generica
• Capacità di risolvere destinazioni dinamicamente in fase di esecuzione (ad esempio, aggiungi un'altra istanza di una coda e inizia automaticamente a ricevere traffico, elimina uno e le rotte di traffico ai nodi rimanenti)
• Richiedenti e le app del fornitore disaccoppiate dal sapere dove si "vivono" l'un l'altro.Richiedente fa una connessione, indipendentemente dal numero di servizi che potrebbe essere necessario chiamare
• Autorizza dalla politica piuttosto che dalla topologia
• Service provider applicazioni in grado di riconoscere e gestire gonzi (come da JMS specifiche, vedere "duplicato funzionale" a causa di gestione delle sessioni)
• Possibilità di eseguire più istanze attive di un Application service Provider
• strumento le applicazioni dei service provider in modo da poter informarsi sullo stato della rete o eseguire un test senza l'invio di una transazione reale

All'altro la sua mano, se il tuo cliente non è in grado di articolare queste cose, potrebbe semplicemente voler controllare una casella che dice "funziona con ESB".

Answer 2

Dopo la ricerca di questo un po ', il mio istinto è quello di dire che questo è solo ronzio parlare per dire che abbiamo bisogno di avere un modo piattaforma indpendent per passare i messaggi avanti e indietro

Questo è circa la destra . A volte un ESB andrà un po 'oltre e includerà funzionalità aggiuntive come le garanzie di consegna dei messaggi, i messaggi di conferma/conferma e così via. La presenza di un ESB crea anche, in modo esplicito o implicito, un nuovo protocollo in cui non esisteva precedentemente, il che è un'altra considerazione importante. (Vale a dire, una sorta di standard o l'interfaccia deve essere impostato per quanto riguarda il formato dei messaggi.)

Ho ragione nel respingere richiesta dei nostri partner come solo cercando di ottenere il nostro software per essere più buzzword-compliant o ci stanno dicendo qualcosa che dovremmo ascoltare (anche se codificato in buzzspeak)?

Si dovrebbe sempre ascoltare i clienti, anche se inizialmente sembra sciocco. Di solito vale la pena almeno spendere gli sforzi per decidere cosa sta succedendo. Leggendo tra le righe, ciò che i tuoi partner probabilmente intendono è che vogliono che il tuo servizio si integri più facilmente con i loro servizi e prodotti.

Answer 3

Un bus di servizio aziendale gestisce la messaggistica tra i sistemi in modo standard. Ciò consente di comunicare con il bus nello stesso esatto modo su tutte le piattaforme e il bus gestisce la traduzione effettiva al singolo meccanismo di comunicazione necessario per l'endpoint specifico. Ciò significa che scrivi tutto il tuo codice per parlare al bus usando uno schema di messaggistica comune e il bus gestisce il tuo schema comune e lo traduce in modo che l'endpoint lo capisca.

Answer 4

Dopo la ricerca di questo un po ', la mia istinto è quello di dire che questo è solo ronzio parlare per dire che abbiamo bisogno di avere un modo piattaforma indpendent passare messaggi avanti e indietro

Sei corretto, in parte perché il termine ESB è sempre bella parola che si adatta bene con un'altra parola chiave, legittima o meno - che è governance (ovvero ti aiuta a gestire chi sta accedendo ai tuoi endpoint e a segnalare metriche - Metrics btw è quello che tutti gli abiti piace vedere, in modo che possa essere un collaboratore)

Un altro motivo che potrebbe desiderare un dispositivo neutra piattaforma è in modo che tutti i servizi che consumano sono sempre esposti come endpoint da una centrale posizione, anziché una risorsa macchina specifica. L'ESB rende irrilevanti gli effettivi endpoint fisici dei tuoi servizi, di cui non dovrebbero preoccuparsi in ogni caso, ma che lo consente a di spostare i servizi in giro, tuttavia essi consumano solo l'endpoint ESB.

Oltre a un repository centralizzato per Discovery, un ESB semplifica anche il controllo delle versioni affiancate dei servizi. Se avessi una scelta e la mia azienda avesse il budget, avremmo acquistato l'appliance x150 di IBM :(

In terzo luogo, un sacco di bus più avanzati, come il prodotto SoftwareAG se ricordo, è nativamente in grado di esporre dati legacy, come dai dati seduto su telai principali servizi senza la necessità di codifica tramite adattatori

non so se il loro intento è quello di sfruttare tutti i vantaggi di un ESB fornisce, o come ha detto lei, lo rendono buzzword compliant.

Answer 5

Proverò & manterrai libero il buzzword (ma è possibile che si insinui un acronimo in corso).

Quando servizi/applicazioni/mainframe/ecc ... vogliono integrarsi (quindi inviare messaggi l'uno all'altro) si può finire con un bel pasticcio. Un ESB nasconde quel casino dentro di sé (o se stesso) in modo che un'organizzazione possa fingere che non ci sia un disastro e che abbia qualcosa di gestibile. Quindi avvolge un intero carico di funzionalità attorno a questo per rendere questa casella ancora più allettante per le persone anziane di un'organizzazione che prenderà la decisione di acquistare un prodotto così costoso. Queste persone in genere vorranno introdurre una grande iniziativa che costa un sacco di soldi per dimostrare che stanno "facendo qualcosa" e sanno come spendere grandi somme di denaro. Se si tratta di un'iniziativa SOA, i venditori vari avranno detto loro che è necessario un ESB per far capire ai produttori cosa è funzionante la SOA (in genere una volta che il numero di servizi che potrebbero volere passa un numero insignificante).

Quindi un ESB è:

1. Un veicolo per i venditori per fare un sacco di soldi;
2. Un veicolo per consulenti per fare un sacco di soldi;
3. Un modo per gli alti dirigenti (direttori IT & simili) per dimostrare che possono spendere un sacco di soldi;
4. Una scatola per nascondere un casino;
5. Una PITA totale per un team tecnico con cui lavorare.

Answer 6

La spiegazione più semplice è quello di spiegare cosa prevede:

Per molti anni le aziende acquisite diverse piattaforme e tecnologie per realizzare funzioni specifiche nella loro attività da Finanza a HR. Questi sistemi dovevano comunicare tra loro per condividere i dati, così il middleware divenne la colla che consentiva loro di connettersi. Prima che l'azienda lo sapesse, stavano pagando per il supporto e la manutenzione su ciascuno di questi sistemi e sul middleware. Poiché i bisogni delle aziende cambiano, i reparti decidono di creare le proprie soluzioni personalizzate per soddisfare esigenze particolari piuttosto che cercare di rendere le soluzioni di invecchiamento sufficientemente flessibili per soddisfare le loro esigenze. Prima che lo sapessero, stavano pagando per supportare e mantenere sistemi legacy, middleware e soluzioni personalizzate. Con nuove leggi come Sarbanes Oxley, le aziende devono disporre di migliori informazioni disponibili a fini di reporting. Una singola vista richiede che catturino i dati da tutti i sistemi. Inoltre, i CIO sono ora sotto pressione per ridurre i costi e aumentare il servizio clienti. Una soluzione ovvia è l'eliminazione di sistemi ridondanti, supporto costoso e contratti di manutenzione, e soluzioni legacy ad alto costo che richiedono il supporto di specialisti. Il passaggio a una nuova piattaforma lo consente, ma è necessaria una transizione. Non ci sono soluzioni chiavi in ​​mano in grado di replicare ciò che fa l'azienda.Per soddisfare le esigenze di spostamento delle informazioni in giro con SOA perché consente l'accesso alle informazioni attraverso un'entità generica. Se chiedo AllEmployees dal bus di servizio, ottiene loro se proviene da 15 sistemi HR o 1. Quando i 15 sistemi HR diventano 1 sistema, la chiamata e il risultato non cambiano, proprio come è stato fatto dietro le quinte. Il concetto di bus di servizio standardizza il flusso di informazioni e consente ai responsabili IT di condurre transizioni dietro il bus senza alcun effetto a lungo termine sugli utenti a monte.