Schimb de date cu magistrala de serviciu între diferite sisteme. Ce este ESB, Enterprise Service Bus. Sincron sau asincron

ESB (Autobuz de servicii pentru întreprinderi)- poate fi tradus literal ca „autobuz de serviciu pentru întreprinderi”. ESB descrie un produs software foarte real al cărui scop este de a simplifica invocarea unui serviciu prin gestionarea tuturor interacțiunilor de-a lungul căii de la consumatorul de servicii la furnizor și înapoi. Cele două capabilități ESB cele mai frecvent citate sunt traducerea mesajelor și rutarea mesajelor. ESB într-o arhitectură SOA are sarcina critică de a asigura interoperabilitatea între sistemele de servicii slab cuplate din rețea. Analiștii Gartner definesc ESB ca un nou tip de middleware care se integrează funcţionalitate alte tipuri de middleware deja existente. Enterprise Service Bus acceptă serviciile Web prin implementarea SOAP (Simple Object Access Protocol) și folosind specificațiile WSDL (Web Services Description Language) și UDDI (Universal Description, Discovery and Integration). Descriere universală, descoperire și integrare).

Funcțiile de bază ale ESB

Furnizarea de interfețe de interacțiune
Trimiterea și rutarea mesajelor
Conversia datelor
Senzori de evenimente
Managementul politicilor

Arhitectura ESB

Miezul arhitecturii ESB este ideea de a partaja o infrastructură de integrare comună în toate aplicațiile de întreprindere bazate pe mesagerie. Toate aplicațiile interacționează printr-un singur punct, care, dacă este necesar, asigură siguranța apelurilor, conversiei datelor și tranzacțiilor. În acest caz, scopul integrării aplicației este de a crea un singur modul (sau adaptor) care este responsabil pentru „conectarea” aplicației la ESB. Procesarea ulterioară a mesajelor și direcționarea lor către alte sisteme sunt efectuate independent de către ESB, pe baza regulilor de afaceri stabilite. Această abordare oferă o flexibilitate excelentă, ușurință de scalare și migrare, astfel încât dacă una dintre aplicațiile conectate la magistrală este înlocuită, nu este nevoie să le reconfigurați pe celelalte.

Avantaje și dezavantaje

Avantajele ESB sunt:

Organizarea cazarii sistemele existente făcut mai repede și mai ieftin.
Flexibilitate crescută.
ESB se bazează pe standarde general acceptate.
Disponibilitatea unui număr mare de configurații pentru integrare.

Dezavantajele ESB includ:

Complexitatea implementării
Necesită resurse mari.

Dezvoltarea Enterprise Service Bus

Caracteristica distinctivă a serviciilor Web este că consumatorul are capacitatea de a comunica dinamic cu furnizorul de servicii. Toate acestea se întâmplă datorită a două funcționalități principale:

Detectabilitate. Furnizorii de servicii web pot fi colectați în directoare întreținute automat. Astfel, consumatorului i se oferă posibilitatea de a răsfoi un astfel de director pentru a găsi furnizorul serviciului dorit.
Despre sine. Un serviciu Web este capabil să se descrie într-un mod care poate fi citit de mașină. Astfel, este posibil să recunoaștem doi sau mai mulți furnizori ai aceluiași serviciu, chiar dacă aceștia sunt implementați în moduri complet diferite, deoarece interfețele lor descriptive îndeplinesc aceeași descriere.

Această funcționalitate a serviciilor Web este fundamental diferită de abordările de integrare existente în care interfețele au fost definite în momentul compilării și în momentul în care consumatorul a comunicat cu furnizorii. Formatele mesajelor nu au fost exprimate descriptiv, nu au putut fi impuse să respecte acest format, deci s-au bazat pe acord intern, astfel încât destinatarul nu a putut procesa structura creată de expeditor.

Autodescrierea serviciilor Web a făcut integrarea mai ușoară prin declararea interfețelor de urmat. Datorită descoperirii dinamice a serviciilor, consumatorul a fost eliberat de dependența de un anumit furnizor cu adresa specifica Cu toate acestea, această oportunitate și-a creat și propriile probleme. A fost destul de dificil să rezolvi problema conectării consumatorului la furnizor o dată pentru totdeauna în timpul compilării și, eventual, a căutării unui nou furnizor cu fiecare apel în timpul execuției. Apoi, ESB a propus o altă opțiune - să permită unui consumator să contacteze dinamic un serviciu proxy o dată, putând, în același timp, să folosească mai mulți furnizori și viitori furnizori prin acel serviciu proxy. Toate acestea înseamnă că ESB pune la dispoziția consumatorilor servicii de apel și le permite consumatorilor să găsească servicii în mod programatic.

Service Gateway

Așa-numita poartă de serviciu este piatra de temelie a unui ESB sincron. Acesta acționează ca un intermediar între furnizorii de servicii și consumatori, asistând în același timp la procesarea apelurilor sincrone folosind un broker. Acest gateway oferă acces la toate serviciile cunoscute și la serviciile proxy ale fiecăruia dintre ele, deci este un fel de „single window” pentru un consumator care dorește să apeleze orice serviciu de la orice furnizor pe care gateway-ul îl cunoaște. Atunci când serviciile Web sunt coordonate de un gateway, ele au capacitatea de a se auto-descrie. Fiecare serviciu își expune interfața folosind WSDL, care constă din următoarele patru părți:

Tipurile de porturi sunt un set de operațiuni pe care le efectuează un serviciu Web.
Mesaje - adică formatul cererilor și răspunsurilor
Tipuri - tipuri de date care sunt utilizate de serviciul Web
Comunicatii - adresa pentru apelarea operatiunii

Serviciile Web Gateway, sau mai precis serviciile lor proxy, sunt de asemenea detectabile. Gateway-ul oferă această oportunitate sub forma unui serviciu UDDI. Pentru a găsi adresa de apel de serviciu, consumatorul solicită serviciului UDDI al gateway-ului o listă de furnizori pentru operațiunea WSDL dorită și primește înapoi adresa serviciului proxy gateway pentru acea operațiune.

Autobuz de mesaje

Modelul Message Bus este baza unui ESB asincron. O magistrală de mesaje este o colecție de canale de mesaje care sunt configurate ca perechi de canale cerere-răspuns. Fiecare pereche reprezintă un serviciu care poate fi invocat de către un consumator folosind magistrala. Consumatorul trimite un mesaj la coada de cereri a serviciului și apoi ascultă coada de răspuns pentru a obține rezultatul. Consumatorul nu știe de fapt cine oferă serviciul. Furnizorii de servicii sunt, de asemenea, conectați la magistrala de mesaje și îl ascultă pentru mesaje de solicitare. Atunci când există mai mulți furnizori de servicii, există concurență între aceștia și între consumatori pentru a primi o anumită cerere. Sistemul de mesaje executat de magistrala de mesaje funcționează ca un manager de mesaje și distribuie cererile către furnizorii de servicii, optimizând această distribuție în funcție de încărcare, întârzieri ale rețelei etc. După ce furnizorul primește cererea, execută serviciul și pune rezultatul într-o coadă. răspunsurile la coada de mesaje, adică furnizorul și consumatorul nu își cunosc niciodată locația celuilalt. Această magistrală de mesaje este esența ESB.

Dacă efectuați un audit al infrastructurii IT în acest moment, un diagnostic tipic va arăta cam așa:

1) Infrastructura IT existentă conține prea multe interconexiuni (uneori ascunse și prost documentate) între sisteme și, prin urmare, necesită o mulțime de aprobări și modificări atunci când se fac modificări, chiar și minime.

2) Nu există o unitate de control unică responsabilă cu actualizarea și furnizarea datelor din diverse sisteme informaționale.

3) Nu există control asupra proceselor de schimb: nu există un mediu unificat pentru schimbul de date între sisteme de informare.

4) Există o „Grădina Zoologică Tehnologică”: o varietate de sisteme de informații și protocoale de schimb de date utilizate, mulți conectori (deseori dezvoltați la comandă sau independent), etc.

Soluția la un set de astfel de probleme constă în trecerea la construirea unei infrastructuri IT bazată pe conceptul de Arhitectură Orientată pe Servicii (SOA), al cărei element cheie este Integration Service Bus. Anvelopa este software, care vă permite să combinați un număr mare de platforme și aplicații, precum și să organizați interacțiunea dintre acestea pe baza serviciilor. În același timp, tehnologiile pe care sunt implementate sistemele și serviciile acestora nu contează, poate fi JAVA, .NET sau altă platformă.

O magistrală de integrare oferă de obicei următoarele funcții:

Transformarea mesajelor, precum și transmiterea mesajelor, redirecționarea algoritmică, așteptarea și urmărirea;

Lucrul cu mesaje în moduri: sincron, asincron, punct la punct, publicare-abonare;

Suport pentru mesaje XML și SOAP;

Abilitatea de a conecta mai multe sisteme prin adaptoare gata făcute și API-uri pentru scrierea de adaptoare noi;

Orchestrarea (plasarea automată, coordonarea și managementul) serviciilor.

Conceptual, arhitectura care utilizează Integration Service Bus arată astfel:

Figura 1 Arhitectura folosind o magistrală de integrare

La introducerea unui bus de integrare, integrarea noilor sisteme - atât achiziționate, cât și dezvoltate independent - este extrem de simplificată. Serviciile nu mai sunt aplicații monolitice, ci sunt împărțite în servicii unice. De exemplu: serviciul compus „luați în considerare o cerere de împrumut” poate fi împărțit în următoarele „servicii unitare”:

Introduceți detaliile clientului
Verificați dacă există o înregistrare pentru un anumit client
Obțineți o listă de conturi de clienți
Obțineți o listă a serviciilor utilizate de client
Obțineți date agregate despre istoricul plăților împrumutului
Obțineți date pentru raport
Obțineți soldul contului
Calculați ratingul de credit
Generați un raport pentru examinare de către manager
Actualizați detaliile contului
Generați o notificare pentru un client

Rețineți că unele „servicii unitare” pot fi utilizate în operațiunile altor componente, ceea ce adaugă integritate sistemului, îl face mai ușor de întreținut și reduce riscul.

De exemplu, portalul pentru clienți al unei bănci combină rapoarte de cont curent, rapoarte de plată ipotecară și extrase de card de credit pe o singură pagină. În același timp, datele de cont, datele de plată ipotecară și datele cardului de credit pot fi preluate din diferite sisteme. Pe baza datelor CRM, pe aceeași pagină poate fi afișată o ofertă potențial interesantă specific pentru un anumit client.

Ca urmare a implementării magistralei de integrare, se realizează transparența schimbului de date în cadrul proceselor de afaceri existente și implementate, este posibilă creșterea eficienței și productivității angajaților și departamentelor, precum și îmbunătățirea calității clienților. satisfacție și reduce costurile de creare și întreținere a infrastructurii IT a Băncii.

Următoarea ilustrație arată cum se modifică interacțiunea sistemelor IT ale băncii după implementarea magistralei de integrare.

Desen2 Arhitectura IT a băncii înainte și după implementarea autobuzului

În prezent, alegerea pe piața autobuzelor de integrare este destul de largă. Sunt prezentate atât sistemele comerciale, cât și produsele open source. cod sursa. Dintre producătorii de autobuze de integrare care sunt lideri în implementare în Rusia, putem evidenția IBM și Oracle; TIBCO poate fi inclus printre principalii furnizori străini.

Să luăm în considerare implementarea autobuzelor de integrare în mai multe bănci internaționale mari.

Chinatrust Commercial Bank folosește un autobuz de integrare pentru a-și susține produsele și serviciile. Arhitectura orientată spre servicii bazată pe magistrala de integrare integrează mai mult de șaptezeci de sisteme pe mai multe platforme, precum: sistem bancar automatizat, sistem bancar în rețea, sistem ipotecar, sistem de loterie, sistem de automatizare a fluxului de lucru, meniu vocal interactiv etc. În timp real, au devenit disponibile servicii precum agregarea de date, rezumatul contului, transferurile de intrare și de ieșire, transferuri, notificări (funcționalitatea de comunicare pe bază de evenimente este activată) și altele. Costurile pentru integrarea de noi sisteme au scăzut în medie cu 30..40%.

În prezent, magistrala de integrare a băncii suportă 100.000 de tranzacții zilnice în sectorul corporativ și 50.000 în retail. Numărul de tranzacții bancare online a crescut de la 150.000 la 1.200.000 pe zi.

Banca din Singapore și Malaezia OCBC și-a stabilit recent un obiectiv pe cinci ani de a crește eficiența operațională cu 25% și de a reduce costul dezvoltării de noi interfețe software cu 30%. Primul serviciu bazat pe SOA a fost lansat în 2006. După șase luni, funcționau 116 servicii unitare, fiecare dintre acestea putând fi utilizată în servicii compozite. 50 de servicii individuale au făcut parte din mai multe componente. Pentru a sprijini procesele de integrare, banca a creat un Centru de Competență de Integrare. OCBC consideră că SOA joacă un rol cheie în atingerea obiectivelor sale declarate.

În Japonia, concurența în domeniul internet banking este extrem de mare. Sumishin Net Bank, Ltd. stabilește un obiectiv de a oferi o gamă largă de produse pe piață într-o perioadă mai scurtă de timp decât alte instituții financiare. Pentru a atinge acest obiectiv, banca a trebuit să respecte strict standardele tehnice impuse sectorului bancar japonez și, în același timp, dezvoltă avantaje competitive. O arhitectură orientată spre servicii a fost dezvoltată folosind zece produse software, inclusiv magistrala de integrare. În doar 18 luni de la lansarea noii linii de servicii, în bancă au fost investiți aproximativ 600 de miliarde de yeni (aproximativ 6 miliarde de dolari) și au fost deschise 400.000 de conturi. Sa obținut o flexibilitate incredibilă în adăugarea de noi servicii. Costul dezvoltării lor a scăzut semnificativ.

În Rusia, autobuzele de integrare sunt utilizate în multe întreprinderi mari, inclusiv operatorii de telecomunicații, sectorul bancar, precum și într-un complex de sisteme de guvernare electronică. Federația Rusă. Implementarea autobuzelor de integrare este de obicei realizată integratori de sistem. În special, compania noastră AMT-GROUP, care conform cnews.ru este inclusă în Top 20 de companii rusești care furnizează servicii IT băncilor, are experiență de succes în lucrul cu autobuze de integrare și implementarea acestora în diverse domenii de activitate, inclusiv în sectorul bancar. . Specialiștii noștri au o experiență vastă în crearea de arhitecturi orientate spre servicii bazate pe magistralele de integrare, inclusiv auditarea proceselor de afaceri și automatizarea ulterioară a acestora, crearea de conectori pentru sisteme integrate și optimizarea mediului de lucru.

Articolul folosește materiale din surse deschise:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Estima:

4 15

În timpul integrării sisteme corporative Apare sarcina de a gestiona datele de referință. Pentru a rezolva această problemă, este adesea folosit Master Data Management (MDM). MDM este un depozit care conține date de referință „de referință”, așa-numitele „înregistrări de aur”. Directoarele din MDM conțin date curate, complete și consecvente.

MDM este adesea folosit ca platformă pentru gestionarea centralizată a directoarelor. Datele de referință sunt introduse și validate în MDM, iar de acolo sunt replicate în sistemele IT. Această abordare are mai multe probleme

Crea model de referinta date care se potrivesc tuturor sistemelor nu sunt atât de ușoare.
Datele de referință devin deconectate de la aplicații.
Replicarea datelor din MDM necesită adesea modificări majore ale sistemului. Pentru sistemele out-of-the-box, astfel de modificări pot fi foarte costisitoare.

O altă abordare este aceea că fiecare sistem de afaceri stochează directoare local și organizează introducerea datelor. La schimbul de mesaje între sisteme, magistrala de integrare realizează transformarea din formatul unui sistem în formatul altuia. În același timp, are loc o transformare a datelor de referință.

Transformare pe magistrala de integrare.

Folosim a doua abordare. Toate interacțiunile dintre sistemele de afaceri au loc prin intermediul magistralei de integrare. Autobuzul (în cazul nostru, Oracle Service Bus) transformă mesajul pe care sistemul Furnizorului îl trimite într-un mesaj pe care sistemul Consumatorului îl înțelege. Această transformare include maparea valorilor directoarelor.

Datele despre cum sunt mapate directoarele între sisteme sunt stocate într-o bază de date relațională, în cazul nostru Oracle. Tabelele vor înregistra cum se obține o valoare într-un alt sistem dintr-o valoare de director dintr-un sistem. Adică un fel de structură:

(sistem_sursă, valoare_sursă, valid_de la, valid_către, sistem_țintă, valoare_țintă)

Datele din directoare se modifică foarte rar, dar sunt folosite foarte des. Pentru a nu accesa de fiecare dată baza de date, directoarele sunt stocate în cache pe magistrală, și într-un format pe care magistrala îl poate folosi imediat.

Pentru memorarea în cache folosim . Acesta este un produs foarte, foarte plătit. Cu toate acestea, în acest caz, toate mega-funcțiile sale nu sunt utilizate, așa că poate fi înlocuită cu o soluție gratuită (de exemplu, hazelcast). Puteți citi mai multe despre coerență. De asemenea, o licență pentru coerență este inclusă în diverse suite Oracle.

Utilizarea unui cache are avantaje evidente:

datele sunt stocate în memorie
datele sunt stocate în formă serializată
datele pot fi indexate
sincronizarea cu baza de date poate fi efectuată asincron

Cache-ul este distribuit și sincronizarea între noduri se face chiar de Coherence. Când un server este adăugat sau eliminat, clusterul reechilibrează datele între noduri.

Schema Distributed Cache Map este utilizată pentru datele de referință. Când Oracle Service Bus pornește, în interiorul JVM-ului este creat un cache care păstrează datele în memorie. Fiecare server fizic are un server de coerență care stochează directoare (în memorie și pe disc) și este sincronizat cu baza de date.

În timpul transformării, fluxul de lucru osb accesează coerența prin înștiințare Java. Poate fi accesat și printr-un apel Enterprise Java Bean.

Cu acest articol aș dori să deschid o serie dedicată IBM WebSphere ESB (denumit în continuare ESB) în contextul dezvoltării acestui produs. Și, în primul rând, va trebui să vă familiarizați mai mult cu tehnologiile de acest gen.
Enterprise service bus (enterprise service bus) este un middleware care oferă mesagerie centralizată și unificată bazată pe evenimente între diferite sisteme de informații bazate pe principiile arhitecturii orientate spre servicii.
Desigur, puteți construi un sistem corporativ bazat pe această abordare fără software special (poate fi nevoit să dezvoltați ceva general) și să numiți produsul rezultat un autobuz de servicii. Dar produsul de la IBM are nu numai un aparat gata făcut pentru mesagerie centralizată și controlul acestui proces, ci și un set complet de capabilități pentru dezvoltarea aplicațiilor flexibile orientate spre servicii, special pentru ESB. Ca rezultat, putem evidenția următoarele capacități și avantaje ale IBM WebSphere ESB:

Ordinea și uniformitatea legăturilor arhitecturale
Management centralizat
Configurarea aplicației pe partea serverului
Implementarea tehnologiei Service Component Architecture (SCA) în spiritul principiilor arhitecturii orientate către servicii
Independenta de protocol a codului programului dezvoltat
Opțiuni extinse de configurare a magistralei și a aplicațiilor

În același timp, ESB oferă control tranzacțional, conversie de date, siguranță și livrare garantată a mesajelor. Accesul la toate serviciile de service printr-un singur punct vă permite să configurați centralizat comunicarea serviciului. De asemenea, puteți gestiona centralizat evenimentele de eșec pentru gestionarea în bloc a erorilor.
Topologia clasică de asamblare ESB este un cluster care oferă scalabilitate orizontală și toleranță la erori. Conform recomandărilor oficiale, creșterea numărului de membri ai clusterului crește performanța mai eficient decât creșterea puterii serverului într-o topologie autonomă. În plus, clusterul poate fi repornit (sau o parte din acesta poate eșua) fără a opri serviciul.
În mod obișnuit, ESB este utilizat ca nivel de servicii în IBM BPM, dar poate juca un rol principal în construirea unui model de interacțiune între sistemele corporative ca un dispozitiv de integrare puternic (adică ESB ca supliment pentru IBM WebSphere Application Server) .
Acest lucru, de fapt, este cerut de la ESB, deoarece este un „punct de colectare a serviciilor” - dacă aveți nevoie de un serviciu care să funcționeze cu alte servicii (eventual externe), atunci cel mai logic loc pentru a face integrarea între aceste servicii este activat. ESB. Pentru servicii externe sau eterogene, îl puteți încheia cu un serviciu ESB. Să ilustrăm pe scurt comoditatea utilizării „locuințelor unice” pentru servicii:

Ordin
Cu cât sistemul este mai mare, cu atât ordinea și uniformitatea sunt mai importante. Dacă vorbim despre un complex de sisteme ale unei întreprinderi mari, atunci poate fi numit cu siguranță un sistem marime mare. Desigur, puteți găsi oricând un administrator care are în cap o diagramă a interacțiunii a sute de servere, sau o grămadă de volume de documentație fără legătură pentru fiecare modul software, care descrie ce și cum interacționează.

Dar este mult mai ușor să ai un serviciu (ESB) care să permită ca toate interacțiunile să aibă loc prin el însuși. Cu această abordare, o parte a arhitecturii de interacțiune din orice subsistem este deja clară - nu există mizerie în conexiunile dintre sisteme, servere și aplicații: totul este conectat la ESB și ESB este conectat la tot.

Management centralizat
Este întotdeauna mai convenabil să configurați sistemele central - fie că este vorba de configurare, adaptare la servere în mișcare, asigurarea toleranței la erori, distribuția sarcinii, gestionarea erorilor sau monitorizare și analiză.

De exemplu, atunci când mutați un server de baze de date, nu trebuie să intrați în configurația tuturor serverelor și setărilor de aplicații existente. aplicatii specificeîn special, este suficient să existe o variabilă de mediu în ESB, care specifică adresa bazei de date, iar apoi modificările vor trebui făcute doar la un moment dat.
Sau, dacă unul dintre sistemele externe a fost indisponibil o lungă perioadă de timp și nicio solicitare nu ar trebui să fie pierdută, puteți utiliza serviciul pentru procesarea evenimentelor eșuate pentru a „arunca” mesaje nelivrate atunci când este convenabil.
Dacă trebuie să reglați numărul de solicitări simultane către orice sistem sau să monitorizați aceste solicitări, să analizați încărcarea, să căutați blocaje, trebuie să mergeți la centrul de control al mesageriei - la consola serverului ESB.

Configurare partea serverului
O „casa unică” pentru servicii, din perspectiva configurației, atinge mai multe obiective utile. În primul rând, aceasta reutilizare configurație (similară cu reutilizarea codului și a modulelor, care este atât de utilă în SOA), deoarece module și aplicații diferite pot folosi aceiași parametri de conexiune la baza de date, resurse, parametri de autentificare, variabile de mediu etc.

În al doilea rând, atunci când configurați pe partea serverului, mediul de operare al aplicației este cel care o poate influența în mare măsură, ceea ce vă permite să transferați aplicații între diferite circuite (de testare și producție), să reglați și chiar să remediați erori fără a face modificări aplicației.

Profitând de toate aceste beneficii, aplicațiile devin cameleonice - sunt atât de flexibile încât devin parte din mediul în care operează, oferind totuși funcționalități importante.

Dar flexibilitatea aplicațiilor care rulează pe IBM WebSphere ESB nu se limitează la mediul în care rulează. Capacitățile de dezvoltare au o contribuție imensă la acest lucru. Deoarece sistemele nu trebuie doar să fie disponibile, unde să ruleze, ci și să fie dezvoltate și rafinate, aceste puncte interesante nu pot fi ratate:

SCA
Această arhitectură se bazează pe principiul că o componentă își oferă funcționalitatea ca un serviciu care este disponibil pentru alte componente. Într-un singur modul componentele sunt blocuri de programe(cod java) care implementează complet unele funcționalități descrise de interfața corespunzătoare. Logica de execuție a componentelor este implementată prin legarea acestora într-o structură bazată pe interfețe și referințe (Partner Reference).

Această structură a modulului este foarte convenabilă de dezvoltat, testat, dezvoltat, schimbat și menținut. Atomicitatea funcționalității implementate în componente vă permite să operați componentele ca un întreg fără a coborî la nivelul de cod. Pe de altă parte, este logic necesar datorită implementării componentelor într-un context tranzacțional.
Fiecare componentă are interfețe a căror implementare o asigură. Astfel, atunci când conectați componente împreună, nu este nevoie să le cunoașteți caracteristicile interne - este suficient ca acestea să implementeze interfețele necesare.
Folosind această arhitectură, este, de asemenea, posibil să se rezolve toate sarcinile care necesită lucru paralel, fără gestionarea „manuală” a firelor (de exemplu, puteți efectua apeluri asincrone către mai multe componente cu un răspuns întârziat).
Componentele non-java, cum ar fi tipurile Export și Import, vă permit să furnizați servicii pentru uz extern sau utilizați servicii externe respectiv; Componenta Flux de mediere oferă acces la nivel scăzut la mesajele schimbate între alte componente și permite diverse transformări atunci când lucrați cu interfețe eterogene.
Pe lângă interfețe, cadrul IBM Business Object oferă capabilități foarte utile. Obiectele de afaceri (BO), reprezentate prin diagrame xsd, sunt folosite ca obiecte pentru transferul de date în interfețe, atât între componente, cât și pentru comunicarea între module. Ele sunt direct integrate, de exemplu, într-o schemă wsdl pentru descrierea serviciilor web. Adică, de exemplu, dacă modulul „A” își oferă funcționalitatea sub forma unui serviciu web, pentru a-l utiliza, modulul „B” trebuie doar să conecteze o interfață și BO gata făcute și va putea funcționa pe deplin. cu un astfel de serviciu fără a crea obiecte java suplimentare pentru transmiterea datelor. BO este, de asemenea, convenabil de utilizat atunci când faceți schimb de date cu o bază de date, dacă aceste date sunt utilizate de alte componente (acest lucru, desigur, contravine modelului „DAO”, dar elimină obiectele java inutile și operațiunile de rescriere a datelor „înainte și înapoi” ).

Independența de protocol a codului programului
După cum puteți vedea, independența de protocol a codului este obținută prin utilizarea componentelor Export și Import. Deoarece comunicarea cu aceste componente are loc prin interfețe și referințe, codul programului este complet independent de protocolul utilizat pentru interacțiune. Aceeași funcționalitate poate fi disponibilă cu ușurință pe orice număr de protocoale acceptate și pe orice interfață necesară. Figura următoare arată adăugarea unui export cu legare SCA la o componentă care își expune deja interfața ca HTTP, JMS și serviciu web.

Avantajele sunt evidente - flexibilitate, versatilitate, reutilizare a codului, viteza de dezvoltare și modificare.
Apropo, legarea SCA folosește un protocol special și este destinat comunicării între module din același server/cluster. Comunicarea prin această legare este mai puțin intensivă în resurse și mai rapidă decât alte protocoale.

Configurare
Configurarea serverului și a aplicațiilor se realizează prin consola IBM a serverului.
ESB, ca IBM WebSphere în general, are destul de multe capacități și artefacte specifice. De exemplu, atunci când utilizați aceleași importuri și exporturi, puteți configura punctele finale ale serviciilor corespunzătoare „din zbor”. Pentru apelurile de service, puteți configura seturi de politici cu diverse reguli (de exemplu, puteți instala suport pentru mecanismul WS-AT, care vă permite să apelați un serviciu web în aceeași tranzacție în care rulează clientul; dar tranzacționalitatea este o problemă). subiect pentru un articol complet), setați parametrii de autentificare, conectați certificate etc.
Prin configurare, puteți configura unele mecanisme de răspuns automat la situații excepționale (de exemplu, repetarea automată a execuției componentelor în cazul unor erori). Puteți configura urmărirea componentelor sau puteți modifica nivelurile de înregistrare din mers. Un serviciu de gestionare a evenimentelor de eșec este, de asemenea, disponibil, care poate fi utilizat în mod deliberat pentru tratarea erorilor în bloc.
Și, desigur, puteți configura o mulțime de alte lucruri conform specificației Java2EE, care este, uneori destul de strict, implementată în IBM Application Server.

Toate cele de mai sus stabilesc ESB ca un dispozitiv de integrare convenabil, puternic și flexibil, deși nu întotdeauna ușor de învățat. În viitor, trebuie doar să înveți cum să-l folosești.

Următoarele imagini sunt folosite în articol:

În opinia mea, există două abordări pentru construirea unui bus de integrare a întreprinderii:

„din sisteme integrate”;

„din procesele implementate”.

Să ne uităm la aceste abordări mai detaliat.

Abordarea „sisteme integrabile”.

În acest caz, magistrala de integrare este considerată ca un fel de transport care realizează rutarea și negocierea protocoalelor de schimb de mesaje. Toate mesajele trec de-a lungul lanțului: canal de intrare al adaptorului de sistem sursă -> router -> canal de ieșire al sistemului de recepție. Tipul de comunicare dintre aceste componente și tehnologiile specifice depind de faptul dacă mesajele care provin de la un sistem sursă pot avea mai multe sisteme de destinație, de sarcina așteptată și de abordarea pentru asigurarea integrității datelor (folosind o tranzacție comună pentru toate sistemele sursă sau datele sunt transferate la fiecare sistem sursă în propria tranzacție).

Dependență de sisteme, nu de tipuri de mesaje. De obicei, numărul de sisteme integrate este de câteva ori mai mic decât numărul de tipuri de mesaje transmise.

Ușurință în conectarea noilor sisteme de recepție: pentru a conecta un nou sistem de recepție, introduceți pur și simplu datele în tabelul de rutare.

Ușurința implementării unui sistem de monitorizare pentru o soluție de integrare: datele pentru sistemul de monitorizare pot fi generate într-un singur loc - în router (acest punct, totuși, poate fi acceptat numai cu rezervări, deoarece există date care sunt generate numai în adaptoare a sistemelor integrate).

Ușurință în sprijinirea soluției. Deoarece toate mesajele trec printr-un singur router, toată logica pentru transmiterea mesajelor și urmărirea dependențelor dintre mesaje poate fi implementată într-un singur loc - în acest router.

Partajarea sistemului între dezvoltatori. Deoarece nucleul sistemului și toate adaptoarele sunt independente unele de altele (comunicarea este asigurată doar prin interfețe dedicate și descrise), sarcinile dezvoltării lor pot fi împărțite între programatori, ceea ce permite paralelizarea procesului de creare și implementare a unei soluții de integrare.

Soluția este aplicabilă numai pentru implementarea logicii unificate de transmitere a mesajelor, de exemplu. dacă există reguli de urmărire și transformare a dependenței comune tuturor sau majorității mesajelor. Dacă tipuri diferite mesajele au o logică complet diferită pentru urmărirea dependențelor și gestionarea schimburilor, fie va trebui să fie transferat la adaptoare, ceea ce neutralizează avantajul 4, fie va fi imposibil de implementat.

Această schemă este potrivită pentru implementarea schimbului asincron. În cazul schimbului sincron sau mixt, complexitatea implementării acestei abordări crește semnificativ.

Poate exista o scădere a performanței soluției. De exemplu, dacă un mesaj trebuie transmis către fiecare dintre sistemele de destinație într-o tranzacție separată, este necesar să se separe sistemul sursă, nucleul și sistemele destinație cu cozi. Aceste cozi pot deveni un blocaj al sistemului.

Abordare bazată pe proces

În acest caz, fiecare proces de afaceri care necesită schimb de date între mai multe sisteme este luat în considerare separat. Instrumente de autobuz acest schimb. Evenimentul care declanșează procesul de schimb este primirea unui mesaj de la sistemul sursă. Un mesaj primit de la un sistem sursă este transmis către unul sau mai multe sisteme destinatare și nu sunt implementate doar funcții de transport, ci și rezultatul procesării mesajului este monitorizat și mesajul transmis este corelat cu altele.

Această abordare are următoarele avantaje:

Flexibilitate. Această abordare vă permite să implementați propria logică de schimb separată pentru fiecare tip de mesaj. Această logică poate fi destul de netrivială.

Complexitatea implementării schimbului asincron și sincron este aproximativ aceeași.

Independența firelor, sau mai degrabă, în acest caz este mai corect să vorbim despre procese. Deciziile tehnice luate în timpul implementării unui proces de schimb nu afectează complexitatea implementării altuia.

Această abordare are următoarele dezavantaje:

Dependență de tipurile de mesaje. De obicei, numărul de tipuri de mesaje este de multe ori mai mare decât numărul de sisteme integrate. Când conectați un nou sistem sursă la magistrală, este necesar să direcționați mesajele după tip și să implementați propriul proces de schimb pentru fiecare tip de mesaj.

Dacă aceeași logică de schimb trebuie implementată pentru mai multe tipuri de mesaje, atunci este posibilă duplicarea setărilor de cod și/sau magistrală.

Procesele de transmitere a mesajelor depind de adaptoarele de sistem și pot depinde unele de altele, precum și de procesele de servicii. Prezența unor astfel de dependențe reduce gradul de paralelizare a procesului de dezvoltare și implementare a unei soluții de integrare. Dezvoltatorii unor componente depind de rezultatele muncii dezvoltatorilor altor componente ale soluției de integrare.

Alegerea abordării se efectuează în conformitate cu următorul algoritm:

Primiți de la analiști o listă și o descriere a sistemelor integrate și a tipurilor de mesaje.

Primiți de la analiști o listă și o descriere a proceselor de afaceri care implică sisteme care necesită integrare.

Dacă procesele sunt banale și există mult mai puține sisteme decât tipuri de mesaje, schimbul este predominant asincron și este necesar și transferul unui mesaj pe mai multe sisteme - alegem prima abordare. Noi decidem asupra politicii de gestionare a tranzacțiilor.

Dacă procesele implică predominant schimb sincron, iar procesele sunt complexe, de exemplu. trecerea mesajului depinde de rezultatele prelucrării acestuia în sistemele receptoare, apoi alegem a doua abordare. Un argument în favoarea acestei abordări poate fi și faptul că numărul de tipuri de mesaje este comparabil cu numărul de sisteme integrate.

Este necesar să înțelegem clar că aceste metode de implementare nu sunt dogme; nu este necesar să alegeți doar prima abordare sau doar a doua. Ele pot fi întotdeauna combinate, autobuze moderne de servicii pentru întreprinderi ( E.S.B.) vă permit să faceți acest lucru.

Mi-a placut mesajul -