Serviciu de autobuz pentru întreprinderi

Autobuz de serviciu întreprindere ( ESB ) este un middleware de calcul tehnica . Scopul său este mai presus de toate de a permite comunicarea aplicațiilor care nu au fost proiectate să funcționeze împreună (de exemplu, două pachete software integrate de gestionare de la editori diferiți).

Roy Schulte de la Gartner Inc. o descrie astfel: „ESB este o nouă arhitectură care valorifică serviciile web, sistemele orientate către mesaje, rutare inteligentă și transformare. ESB acționează ca o coloană vertebrală ușoară și omniprezentă a integrării prin care circulă serviciile software și componentele aplicației ” .

ESB poate fi considerat ca o nouă generație de integrare a aplicațiilor pentru întreprinderi (EAI) bazată pe standarde precum XML , Java Message Service (JMS) sau chiar servicii web. Diferența majoră cu EAI este că ESB oferă o integrare complet distribuită prin utilizarea containerelor de servicii. Aceste „mini-servere” conțin logica de integrare și pot fi abandonate oriunde în rețea.

Principii

ESB ca mediator între clienți și furnizorii de servicii se bazează pe următoarele principii:

Termenul ESB a fost folosit pentru prima dată de editorul Sonic Software (o filială a Progress Software Corporation). Într-un fel, ESB constituie o evoluție a EAI, în special din motive de performanță în caz de volume mari (tratamentele sunt potențial distribuite) și de siguranță (evitând potențialul „punct unic de defecțiune” al unei plăci. ), deși cele mai recente EAI / ESB s-au îmbunătățit cu privire la aceste două probleme.

Arhitectură

Compania de servicii de autobuz are, așa cum sugerează și numele său, o arhitectură de autobuz care o contrastează cu arhitectura hub și radială a primelor EAI . Acest lucru face din ESB o soluție foarte distribuită. Componentele acestei arhitecturi sunt ilustrate în figura următoare.

ESB are patru fundamente:

Poate fi adăugat la această arhitectură:

Utilizare caz

Utilizarea intra-aplicație

Acesta este un caz de utilizare limitat, aproape întotdeauna implementat cu un ESB open source, ușor și ușor de implementat. Se găsește în aplicații cu o mare nevoie de agilitate, care justifică costul suplimentar de performanță cauzat de trecerea printr-un ESB sau în aplicații care oferă o interfață multi-protocol (de exemplu, pentru pachetele software cu etichetă albă); modulul consumator de servicii se află apoi într-o altă aplicație / sistem.

Utilizare tactică

Utilizarea tactică corespunde unui ESB utilizat în cadrul unei entități / departamente pentru a face servicii reutilizabile disponibile pentru întreaga entitate. Serviciile expuse pot proveni de la:

  1. Aplicații noi bazate pe o arhitectură SOA internă (expunerea serviciilor prin standardele actuale)
  2. Aplicații existente în care o parte a codului aplicației este reutilizată pentru a expune servicii (expunerea serviciilor prin standardele actuale)
  3. De la sistemele legatarilor precum mainframele sau AS400 (servicii de expoziție prin conectori specifici)

Utilizarea strategică

Viziunea strategică corespunde utilizării ESB pentru a stabili comunicarea între silozuri, pentru a expune serviciile utilizate de procesele de afaceri transversale. La fel ca în viziunea tactică, serviciile pot proveni dintr-o varietate de surse, sau chiar din ESB tactică care poate exista în fiecare dintre silozuri.

Comunicare externă

În acest caz de utilizare, ESB este destinat să expună servicii pentru utilizare în afara afacerii. În acest tip de utilizare, aspectele de siguranță trebuie să facă obiectul unei atenții deosebite. Din acest motiv, este obișnuit să nu se utilizeze un ESB intern (tactic sau strategic), ci să se dedice un ESB pentru comunicări cu exteriorul. Un ESB pentru comunicații externe va fi de obicei plasat într-un DMZ .

Interesele ESB

Standardizarea conceptelor ESB-urile acceptă standarde precum XML , JMS , JCA , JMX și multe standarde referitoare la serviciile web . Aceasta implică o integrare mai rapidă, mai economică și mai flexibilă a sistemelor existente. Inteligenta de rutare Autobuzele ESB automatizează dirijarea tranzacțiilor comerciale pe baza conținutului documentului XML și a regulilor comerciale stabilite. Prin urmare, nu mai este necesar să programați această funcționalitate în codul aplicației. Arhitectura de servicii Funcționalitățile oferite de ESB-uri sunt implementate ca servicii specializate distincte (serviciu de transformare, serviciu de rutare inteligent, serviciu de înregistrare etc.). Aceste servicii implementate în containere mici pot fi implementate independent unul de celălalt, în mod selectiv. Arhitectură distribuită Arhitectura de servicii a ESB este distribuită cu mult mai multă modularitate decât o arhitectură monolitică, ceea ce face posibilă furnizarea unui răspuns precis și flexibil la nevoile de scalabilitate întâmpinate în problemele de scalabilitate . Fiabilitate ESB-urile permit construirea de arhitecturi fără punct individual de eșec (SPOF). Deci, atunci când un server cade, restul sistemului poate continua să funcționeze. Flexibilitatea implementării ESB-urile oferă capacitatea de a centraliza servicii de configurare, implementare și gestionare distribuite în întreaga întreprindere. În plus, permite scalarea și gestionarea serviciilor companiei independent una de cealaltă. Transparența implementărilor permite modernizarea, mutarea sau înlocuirea serviciilor fără a fi nevoie să modificați codul.

Standarde

ESB se poate baza pe următoarele standarde:

Standardul JBI este important, dar nu câștigă sprijinul tuturor jucătorilor (în special IBM și BEA). Din acest motiv, editorii își oferă adesea propriul container de servicii.

Produse proprietare

Produse gratuite

Vezi și tu

Note și referințe

  1. Enterprise Service Bus , David Chappell
  2. Definiție din Gartner Inc.
  3. „  Acasă - SRCI  ” , pe SRCI (accesat la 13 septembrie 2020 ) .
  4. http://wso2.com/products/enterprise-service-bus/
  5. https://blog.octo.com/apache-camel-un-framework-pour-les-integrer-tous/
  6. https://zato.io/
  7. „  CodePlex Archive  ” , pe CodePlex Archive (accesat la 13 septembrie 2020 ) .
  8. (în) „  NServiceBus  ” peste Particular Software (accesat la 13 septembrie 2020 ) .