Bus de integrare pentru monitorizarea cabinetului serverului. Principalele caracteristici ale sistemului. Apel direct sincron
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) - liant software, oferind mesaje centralizate și unificate bazate pe evenimente între diferite sisteme de informare bazat 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
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.
De obicei, ESB este folosit ca nivel de serviciu în IBM BPM, dar poate juca un rol principal în construirea unui model de interacțiune. sisteme 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
Cum dimensiune mai mare sistem, cu atât ordinea și uniformitatea sunt mai importante în el. 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 bază de date, nu trebuie să intrați în configurația tuturor serverelor de aplicații existente și, în special, în setările aplicațiilor specifice - este suficient să aveți o variabilă de mediu în ESB, care specifică baza de date. adresa, 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 este reutilizarea configurației (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Și așa mai departe. 
Î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. În cadrul unui modul, componentele sunt blocuri software (cod java) care implementează complet o anumită funcționalitate descrisă 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, prin interconectarea componentelor, nu este nevoie să le cunoaștem caracteristici interne– este suficient 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 în consecință; Componenta Flux de mediere oferă acces la nivel scăzut la mesajele schimbate între alte componente și permite diverse transformări atunci când se lucrează 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 niciun obiect java suplimentar 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 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ă. Următoarea figură 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 cadrul aceluiaș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:
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 singură unitate de control 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 sistemele informaționale.
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. Un autobuz este un software care vă permite să combinați un număr mare de platforme și aplicații, precum și să organizați interacțiunea dintre ele 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, plăți ipotecare și extrase de card de credit pe o singură pagină. În același timp, datele contului, datele de plată ipotecare și datele cardului de credit pot fi preluate din diferite sisteme. Pe baza datelor CRM, informații potențial interesante special pentru a acestui client oferi.
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 satisfacției clienților și reducerea costurilor 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 acceptă 100.000 de tranzacții zilnice în sectorul corporatistși 50.000 în comerțul cu amănuntul. Numărul tranzacțiilor 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, au funcționat 116 servicii de unitate, 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. A fost dezvoltată o arhitectură orientată spre servicii folosind zece produse software, inclusiv o magistrală 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. S-a 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 magistralelor de integrare este de obicei realizată de integratori de sistem. În special, compania noastră AMT-GROUP, inclusă în Top 20 conform cnews.ru companiile rusești– furnizori de servicii IT pentru bănci, 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
ESB (Autobuz de servicii pentru întreprinderi)- poate fi tradus literal ca „autobuz de serviciu de întreprindere”. ESB descrie un foarte real software, al cărui scop este de a simplifica invocarea unui serviciu prin gestionarea tuturor interacțiunilor de-a lungul căii de la consumatorul serviciului la furnizor și înapoi. Cele două cele mai des menționate Capabilitati ESB sunt conversia ș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 (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.
- Disponibilitate cantitate mare configuratii 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. Ele nu au putut fi impuse să urmeze 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 a fi dependent de un anumit furnizor pentru o anumită adresă, cu toate acestea, această caracteristică și-a creat 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. Poarta de acces 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.
Integrarea sistemelor informatice folosind o magistrală de servicii de întreprindere (ESB)
Printre cele mai bune practici de integrare a sistemelor informaționale complexe se numără construcția de magazine de date logice, precum și crearea de infrastructuri centralizate de schimb de date folosind sisteme MDM și bus-uri de servicii enterprise (ESB, Enterprise Service Bus). Soluțiile noastre, inclusiv sistemul ArchiGraph.MDM, sunt potrivite pentru utilizare ca parte a sistem de operare scop special Astra Linux Ediție specială, precum și Alt Linux.
De ce este nevoie de un autobuz de integrare?
Orice companie care folosește mai mult de două produse software care funcționează cu seturi de informații suprapuse cunoaște costul necomunicarii între ele. Listele de clienți nesincronizate sau liniile de produse și alte informații între ERP, CRM și alte aplicații corporative provoacă pierderi constante de timp, resurse și reputația companiei. Singura soluție corectă la această problemă este implementarea unei magistrale de servicii enterprise (ESB), împreună cu un sistem de gestionare a datelor de bază (MDM).
Soluțiile bazate pe încărcare și transformare regulată a informațiilor (ETL) și arhitectură orientată pe servicii (SOA) oferă doar o soluție temporară la astfel de probleme, au multe dezavantaje și limitează potențialul de creștere al infrastructurii IT.
Implementarea magistralei de integrare
La implementarea unei magistrale de integrare apare sarcina de a mapa (compara) structura informatiilor despre aceleasi obiecte prezente in diferite sisteme informatice. Această problemă trebuie rezolvată prin crearea unui model informațional general care să fie neutru în raport cu fiecare aplicație. Un astfel de model poate fi implementat cel mai eficient folosind tehnologii semantice. Obținerea unor rezultate optime de implementare necesită ca modelul să fie dezvoltat de un arhitect de date profesionist.
O parte importantă a proiectului de implementare este implementarea conectorilor (interfețe software) pentru toate aplicațiile implicate în schimbul de date. Specialiștii noștri au experiență în dezvoltarea și conectarea conectorilor pentru o gamă largă de software pe diverse platforme.
Realizam proiecte de integrare impreuna cu parteneri bazate pe solutii IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse, precum si bus-ul Business Semantics.
Adesea, un proiect de implementare a unei magistrale de integrare este realizat ca parte a reinginerării generale a arhitecturii informaționale a unei întreprinderi.
2005
Autobuz de servicii corporative - o abordare „buget” pentru rezolvarea problemelor de integrare
Preparat: pe baza de materiale din situri străine
Traducere: Intersoft Lab
Continuând să prezentăm cititorului diverse abordări ale integrării, am decis să ne concentrăm pe o tehnologie relativ nouă și foarte atractivă - Enterprise Service Bus (ESB).
Ce este o magistrală de servicii pentru întreprindere și cum are legătură cu integrarea aplicațiilor pentru întreprinderi (EAI) discutate în numerele anterioare ale revistei DWH, OLAP și XML Experts Club? Conform tradiției consacrate, vom acorda mai întâi cuvântul experților în acest domeniu.
Analiștii Gartner definesc ESB ca un nou tip de middleware care combină funcționalitatea altor tipuri de middleware 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 (Descriere universală, descoperire și integrare). Multe autobuze de servicii de întreprindere acceptă și alte stiluri de comunicare, inclusiv livrare garantată și publicare și abonare. Serviciile furnizate de aceste autobuze oferă „valoare adăugată” pe care middleware-ul de mesagerie ușor nu o oferă - validare a mesajelor, transformare, rutare bazată pe conținut, securitate, descoperire de servicii pentru arhitectura orientată spre servicii, echilibrare a încărcăturii și înregistrare. Unele servicii sunt încorporate în baza magistralei, altele sunt executate în module plug-in. În plus, autobuzele acceptă XML și alte formate de mesaje.
Ce este atât de atractiv la autobuzul de servicii corporative? În primul rând, relativ ieftinitatea sa. Produsele ESB sunt de obicei poziționate ca fiind soluții accesibile sau, după cum se spune, „buget”.
Într-adevăr, astăzi există o cerere din ce în ce mai mare pentru tehnologii de integrare. În timp ce implementările EAI erau legate de obiective strategice și, prin urmare, au avut roade pe termen lung, provocările cu care se confruntă companiile acum sunt tactice și necesită abordări noi. „Modern Business Realities” a atras atenția asupra domeniilor în care furnizorii EAI au fost în mod tradițional slabi – transformare, procesare software centrată pe dezvoltator (cum ar fi Java) și integrare cu tehnologii externe. Toate aceste „terenuri fertile pregătite” pentru apariția unei noi categorii de produse - ESB.
Vorbind despre meritele bus-ului de servicii enterprise, merită citate cuvintele vicepreședintelui și membru al departamentului de cercetare al Gartner Roy Schulte: „Middleware-ul convențional nu mai poate suporta aplicații noi care folosesc servicii orientate (Service Oriented Architecture, abbr. . SOA) și arhitectură bazată pe evenimente (EDA), servicii web și management al proceselor de afaceri. Acesta este motivul principal pentru care arhitecții și managerii de sisteme informatice trebuie să-și consolideze corporația infrastructuri informaţionale folosind ESB."
Un analist principal Gartner evidențiază grupurile de furnizori ESB. El include produsele ESB în primul grup, care sunt poziționate ca soluții de integrare „buget” care sunt potrivite în mod optim pentru suportul aplicațiilor compozite și SOA. Al doilea grup este reprezentat de produsele destinate pieței de servicii Web, iar în cele din urmă sunt ultimele software, oferind suport EDA. Roya Schulte estimează că piața ESB se va înăspri în următorii ani, determinată de cererea în creștere pentru servicii web și soluții multi-protocoale și bazate pe evenimente.
Este interesant că într-o serie de companii ESB este tratat nu ca o categorie de produse, ci ca o arhitectură. De exemplu, la IBM, autobuzul de serviciu al întreprinderii este considerat un „model arhitectural”.
Astfel, se poate afirma că încă nu există o definiție clară a ceea ce este ESB. De fapt, discuția se învârte în jurul a două întrebări:
- Este ESB o arhitectură (și una care nici măcar nu trebuie să fie standardizată), o „abordare unidirecțională” sau un produs independent.
În ciuda faptului că pentru un număr de furnizori care nu au în prezent soluții gata făcute Deși este benefic să vorbim despre Enterprise Service Bus ca o arhitectură, peisajul actual este astfel încât consumatorii au nevoie de funcționalitatea ESB în ofertele lor de produse. Prin urmare, ar trebui să ne așteptăm să vedem o creștere a numărului de furnizori care oferă capabilități ESB în următorii doi ani.
- Care este locul și viitorul produselor ESB, și anume, este Enterprise Service Bus un sistem mai avansat de așteptare a mesajelor, care oferă transformare XML simplă, precum și rutare și mesagerie, sau utilizarea adaptoarelor de aplicații, automatizarea și modelarea proceselor de afaceri vor permite ESB pentru a înlocui cu succes EAI.
Pe acest moment Nu există răspunsuri definitive la întrebările de mai sus.
Cu toate acestea, merită subliniat faptul că, deși există o lipsă de claritate în ceea ce privește Enterprise Service Bus, este clar că datorită faptului că ESB se bazează pe standarde deschise, poate reduce semnificativ costurile de achiziție și implementare.
Rețineți că cuvântul „serviciu” din termenul „autobuz de servicii corporative” este central. Astfel, analiștii Forrester Research văd ESB ca „un strat de middleware care poate fi folosit pentru a accesa un set de servicii de afaceri de bază (reutilizabile). SOA permite ca o mare parte a funcționalității să fie expusă ca „serviciu” pe o magistrală de servicii de întreprindere care transmite, transformă și validează datele de intrare și de ieșire către format XML, primite de la aceste servicii.
ESB și XML
Ar fi nedrept dacă nu am sublinia rolul special al XML - XML stă baza integrării. Dacă acceptăm faptul că XML este mai mult un „alfabet” decât o limbă, devine clar că, pentru a implementa integral integrarea, este necesar să „conducem” procesele de afaceri, să gestionăm Transformarea XMLși validați și redirecționați mesajele XML în întreaga organizație. Toate aceste funcționalități formează baza Enterprise Service Bus.
XML poate oferi o reprezentare cuprinzătoare a unui set de date. Popularitatea acestui limbaj poate fi explicată prin flexibilitatea și extensibilitatea sa ridicată. Într-adevăr, sintaxa XML vă permite să modernizați și să dezvoltați scheme XML specializate pentru a gestiona diferite date.
În același timp, creșterea rapidă a volumului de date care trebuie transferate creează dificultăți serioase pentru funcționarea corporativă. structura informatiei. Astfel, primele proiecte de integrare care au folosit capabilitățile XML au fost dovada „vie” a promisiunii acestui limbaj, dar acum există anumite probleme cu creșterea numărului, dimensiunii și complexității documentelor XML. Principalele motive pentru dificultățile existente (lipsa de scalabilitate) sunt enumerate mai jos:
- Analizați întregul document: de obicei, trebuie să analizați documente întregi, chiar dacă trebuie să extrageți doar o parte a acestuia pentru rutare și filtrare. Dacă documentele devin mari, timpul de așteptare crește.
- Rescanați. Documentele sunt adesea re-analizate - în fiecare etapă a procesului de afaceri, cu alte cuvinte, aceleași documente pot fi scanate de mai multe ori. Deoarece această practică este extrem de consumatoare de resurse, degradează performanța și debitul.
- Design cu un singur fir. În acest caz, următorul pas de procesare nu poate fi început până la finalizarea celui curent; ca urmare, timpul de așteptare crește deoarece întregul proces depinde de pasul cel mai lent.
Pentru a rezolva problema scalabilității insuficiente, se recomandă utilizarea unei arhitecturi de procesare care acceptă următoarele caracteristici:
- Streaming de documente - asigură că documentele XML sunt procesate pe măsură ce sosește fiecare element, de exemplu. este asigurat timp de așteptare redus. Această abordare permite ca mesajele mari să fie procesate la fel de productiv ca și cele mici.
- Procesare selectivă, care realizează câștiguri de performanță foarte semnificative prin procesarea doar a porțiunilor relevante, mai degrabă decât a întregului document XML.
- Procesare cu mai multe fire, în care procesorul gestionează alinierea pașilor secvențiali de-a lungul unui canal, execuția paralelă a pașilor individuali și echilibrarea încărcării pașilor identici atunci când procesează mai multe fragmente XML.
- Singura scanare în care, în loc de mai multe lecturi repetate ale structurii aceluiași document de la bun început, toate fragmentele necesare sunt extrase într-un singur transfer.
Funcțiile de mai sus pot fi implementate folosind Enterprise Service Bus - fără nicio codificare sau configurație specială.
Care este diferența dintre un bus enterprise service bus (ESB) și brokeri de mesaje (de exemplu RabbitMQ)?
Ca urmare, problema performanței nesatisfăcătoare poate fi rezolvată.
Concluzie
Judecând după publicațiile din publicațiile străine pe internet și evaluările analiștilor de la companii de cercetare de top, autobuzul de servicii corporative nu mai este doar tehnologie nouă cu mare potential. De fapt, Gartner prezice că până în 2005, majoritatea companiilor mari vor folosi ESB-uri. IDC consideră că autobuzul de servicii corporative ar trebui să „revoluționeze” tehnologia de informațieși să permită procesarea flexibilă și scalabilă a datelor distribuite.
Într-adevăr, suportul pentru standarde deschise (și în special XML) permite un cost ieftin, dar solutie eficientași garantează o rentabilitate rapidă a investiției, adică un ROI ridicat. După cum remarcă Steve Craggs, vicepreședinte al Consorțiului pentru Integrare, „ESB este baza integrării, oferind un mediu flexibil și personalizabil care permite ca proiectele de integrare să fie implementate cu succes, cu succes și sistematic.”
Și totuși, încă rămâne incertitudinea cu privire la ambiguitatea termenului „autobuz de serviciu corporativ”. Astăzi, ESB se referă la orice tehnologie necesară pentru implementarea SOA. Tocmai acesta este punctul de vedere deținut de ZapThink, companie specializată în dezvoltarea și aplicarea arhitecturii orientate spre servicii. În acest sens, analiștii ZapThink avertizează că dacă în 2005 nu se elaborează o definiție reală și concretă a autobuzului de serviciu al întreprinderii, termenul ESB „va dispărea pentru totdeauna din lexiconul SOA”. Cât despre SOA în sine, acesta va fi discutat în articolul următor.
Publicaţii
- Beth Gold-Bernstein, Este un ESB critic pentru viitorul tău?
- Nigel Thomas și Warren Buckley, „Ascensiunea ESB”.
- Materiale publicate pe site-ul Consorțiului de Integrare.
Ce sunt ESB și SOA¶
O descriere excelentă a gândirii sistemului de sisteme
Nick Coghlan, Dezvoltator Core Python
Disponibil și în Catala, Deutsch, Engleză, Franceză, italiano, Olanda, portugheză, Türkçeși 中文 .
Acronimul ESB și SOA asociat pot fi o sursă de confuzie. ESB înseamnă Enterprise Service Bus. SOA - Arhitectură Orientată pe Servicii.
Aceste nume nu spun prea multe, așa că mai jos sunt informații mai complete într-un limbaj simplu, fără un limbaj corporativ inutil.
Tot adevărul¶
Să ne imaginăm ce se întâmplă când vă conectați la aplicația front-end a băncii dvs.:
- Numele tău este afișat
- Este afișat soldul contului dvs
- Afișează cardurile dvs. de credit și de debit
- Este posibil să existe o listă a fondurilor dvs. mutuale
- De asemenea, primești o listă de împrumuturi prestabilite care te-ar putea interesa
Cu un grad mare de probabilitate putem spune că toate aceste informații îi aparțin sisteme diferiteși aplicații, fiecare dintre care furnizează date printr-un fel de interfață (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV sau orice alta):
- de la CRM care rulează sub control Linuxși Oracle
- dintr-un sistem COBOL care rulează pe un mainframe z/OS
- ei spun că aceste informații provin de la un sistem mainframe, dar acești băieți sunt prea strânși pentru a spune altceva decât că preferă CSV față de orice altceva
- dintr-un amestec de PHP și Ruby care rulează pe Windows
- de la PostgreSQL, Python și Java care rulează pe Linux și Solaris
Întrebarea este cum puteți obține o aplicație frontend pentru a vorbi cu sistemele 1-5? Ei bine, în nici un caz.
Aceasta este o bază fundamentală pentru a ne asigura că astfel de medii se pot scala dincolo de mai multe sisteme. Nu îi forțați să comunice direct unul cu celălalt.
În diagrama de mai jos, fiecare apel către un serviciu furnizat de un alt sistem este reprezentat de o linie de grosimi și stil diferite:
Observați că nici măcar nu am afișat niciun proces de nivel înalt (App1 apelează App2 și fie App3, fie App5, în funcție de faptul dacă răspunsul anterior de la App6 a avut succes, astfel încât App4 să poată prelua ulterior datele care au fost generate de App2, dar numai dacă App1 nu interzice acest lucru etc.).
De asemenea, rețineți că nu vorbim despre servere - fiecare dintre sisteme poate rula pe 10 servere fizice, deci cel puțin 60 de componente fizice vor schimba informații între ele.
Cu toate acestea, unele probleme devin evidente.
Cum se separă interfețele? Cum să planificați descărcarea? Cum coordonați actualizările sau timpul de nefuncționare planificat atunci când fiecare aplicație este gestionată de diferite echipe de dezvoltatori, vânzători sau departamente și jumătate din dezvoltatorii inițiali au părăsit deja compania?
Dacă crezi că poți gestiona 6 aplicații, ce zici de 30?
Te descurci cu 400? Și din 2000? Fiecare aplicație poate fi propriul ecosistem unic, necesitând zeci de servere sau alte dispozitive pentru a rula, deci sunt 20.000 de piese mobile răspândite pe continente, cu tot felul de granițe tehnice și culturale. Și toate aceste părți în mod constant și non-stop doresc să schimbe mesaje tot timpul, fără niciun timp de nefuncționare, deloc. (Vă vom scuti de diagramă.)
Există un nume grozav pentru această situație: haos.
Cum poți îmbunătăți situația?¶
Primul pas este să recunoști că situația este scăpată de sub control. Acest lucru vă permite să căutați o soluție fără a vă simți prea mult vinovat. Bine, s-a întâmplat, nu ai știut să faci mai bine, dar există șansa ca toate acestea să poată fi remediate.
Acest lucru poate aduce cu sine schimbări organizaționale în abordarea IT, dar un alt pas este să ne amintim că sistemele și aplicațiile sunt concepute pentru mai mult decât doar partajarea datelor. Sunt create pentru a susține procesele de afaceri, indiferent de afacerea în sine, fie că este vorba de servicii bancare, înregistrare audio, dispozitive radar, orice.
După ce aveți aceste două puncte clar definite, puteți începe să proiectați sau să vă reproiectați sistemele în jurul serviciilor.
Un serviciu este ceva interesant, reutilizabil și atomic care este expus de către un sistem altor aplicații care doresc să-l folosească, dar serviciul nu este niciodată expus direct într-un mod unu-la-unu. Aceasta este cea mai scurtă și mai semnificativă descriere posibilă.
Dacă o anumită funcționalitate a sistemului îndeplinește aceste trei cerințe:
- eu interesant (interesant)
- R utilizabil (reutilizabil)
- A tomic (atomic)
atunci există șanse mari ca sistemul să poată și să fie expus altor sisteme ca serviciu, dar niciodată conectat direct.
Să discutăm despre abordarea IRA cu câteva exemple.
| Variabil | Note |
|---|---|
| Mediu inconjurator | Sistem CRM al companiei electrice |
| Funcționalitate | Returnarea unei liste de clienți care au fost activi pe portalul de autoservire în T3 2012 |
| Asta e interesant? | Da, destul de interesant. Acesta poate fi folosit pentru a genera tot felul de rapoarte și statistici utile. |
| Este posibil | Nu, nu atât. În ciuda faptului că acest lucru vă permite să creați |
| multe ori | constructe de nivel înalt, cum ar fi statisticile pentru întregul an, |
| utilizare? | Este clar că nu vom avea nevoie de asta în 2018. |
| Este atomic? | Probabil da. Dacă servicii similare există deja pentru alte trimestre, atunci va fi posibil să vizionați întregul an. |
| Cum pot transforma asta într-un IRA? |
|
| Variabil | Note |
|---|---|
| Mediu inconjurator | site de comert electronic |
| Funcționalitate | Returnați fiecare informație care a fost colectată vreodată pentru utilizatorul specificat |
| Asta e interesant? | În general, da. Dacă aveți acces la întreg, puteți alege oricând ceea ce aveți nevoie. |
| Este posibil | Destul de ciudat, nu chiar. Vor fi doar câteva |
| multe ori | aplicații, dacă există, care vor fi de interes |
| utilizare? | folosește absolut orice informație. |
| Este atomic? | Cu siguranta nu. Acest monstru al funcționalității este sortit să fie compus logic din zeci de părți mai mici. |
| Cum pot transforma asta într-un IRA? |
|
| Variabil | Note |
|---|---|
| Mediu inconjurator | Orice sistem CRM de oriunde |
| Funcționalitate | Actualizarea coloanei CUST_AR_ZN din tabelul C_NAZ_AJ după ce cineva a creat un cont |
| Asta e interesant? | Absolut deloc interesant. Aceasta este o funcție internă a sistemului CRM. Nimeni în mintea sa nu ar dori să se ocupe de o funcționalitate atât de scăzută. |
| Este posibil | Da, probabil. Cont poate fi creat prin |
| multe ori | mai multe canale, așa că pare ceva de mai multe ori |
| utilizare? | folosit. |
| Este atomic? | Se pare că da. Aceasta este o actualizare simplă pentru o coloană dintr-un tabel. |
| Cum se face din | |
| acest IRA? | Nici măcar nu încercați să faceți un serviciu din asta. Nu este interesant. Nimeni nu vrea să se gândească la anumite coloane și tabele dintr-un singur sistem. Aceasta este o parte complexă a unui sistem CRM și, deși este reutilizabilă și atomică, nu merită să creați un serviciu din. Este responsabilitatea ta și a CRM să te gândești la asta, nu-i obliga și pe alții să o suporte |
| Variabil | Note |
|---|---|
| Mediu inconjurator | Operator mobil |
| Funcționalitate | Încărcarea unui card preplătit în facturare |
| Asta e interesant? | Extrem. Toată lumea vrea să-l folosească, prin mesaje text, IVR, IM, portaluri, carduri cadou etc. |
| Este posibil | Da. Poate participa la multe niveluri înalte |
| multe ori | proceselor. |
| utilizare? | |
| Este atomic? | Da, din punct de vedere al aplicației de apelare, cardul poate fi reîncărcat sau nu. Faptul că facturarea implementează acest lucru printr-o serie de pași nu este important. Din punct de vedere al afacerii, acesta este atomic este un serviciu indivizibil oferit prin facturare. |
| Cum se face din | Este deja un IRA. |
| acest IRA? |
Dacă ați făcut vreo programare în ultimii 50 de ani, va fi evident pentru dvs. că furnizarea unui serviciu este similară cu furnizarea unui API într-o bucată de cod la alta. Singura diferență este că nu aveți de-a face cu submodule ale unui sistem, lucrați la nivelul întregului mediu al sistemelor individuale.
Disponibilitatea serviciilor în ESB și SOA¶
Acum că știți că sistemele nu comunică direct și înțelegeți ce este un serviciu, puteți începe să utilizați eficient ESB.
Acum este sarcina ESB să furnizeze și să invoce servicii de sisteme integrate. Astfel, în majoritatea cazurilor, între fiecare sistem și ESB trebuie definită o singură metodă de acces, o interfață.
Deci, dacă, ca în diagrama de mai sus, aveți 8 sisteme - atunci aveți 16 interfețe (una în fiecare direcție) pentru creare, întreținere, management și provizion.
Fără ESB, ați avea 56 de interfețe de creat și administrat (presupunând că fiecare sistem vorbește cu fiecare).
Fără 40 de interfețe suplimentare înseamnă mai puțin timp pierdut și mai mulți bani economisiți. Acesta este unul dintre motivele pentru care zilele de vineri vor fi mai puțin stresante.
Numai acest fapt ar trebui să vă încurajeze să luați în considerare implementarea unui ESB.
Dacă unul dintre sisteme este rescris, transferat altui proprietar, împărțit între departamente sau vânzători, atunci va fi sarcina băieților ESB să facă modificările corespunzătoare. Niciunul dintre celelalte sisteme nu va observa acest lucru, deoarece interfața lor cu ESB va fi neatinsă.
Odată ce începeți să respirați serviciile IRA în mod regulat, puteți începe să vă gândiți la serviciile compuse.
Vă amintiți serviciul „dați-mi-orice-poți-despre-acest-client” prezentat mai sus?
Nu a fost o idee bună să creați unul, dar veți întâlni uneori aplicații client care au nevoie să agregă informații. Băieții ESB vor fi responsabili pentru acest lucru, a căror sarcină va fi să selecteze cele mai bune servicii atomice pentru a construi un serviciu compozit pentru acest anumit sistem client care necesită acest set special de date compozite.
În timp, întreaga organizație va începe să înțeleagă că nu mai este vorba despre tabele, fișiere, pachete, funcții, rutine sau înregistrări ale bazei de date. Acum vorbim despre o arhitectură centrată pe servicii interesante, reutilizabile și atomice furnizate de aplicațiile ESB.
Oamenii nu vor mai crede că aplicațiile și sistemele își trimit mesaje unul altuia. Ei vor vedea ESB ca o poartă universală către servicii interesante pe care sistemele lor le pot folosi. Și nici măcar nu vor verifica cine oferă ce, sistemele lor se vor ocupa doar de ESB.
Va fi nevoie de timp, răbdare și efort coordonat, dar este complet realizabil.
Dar atenție...¶
Cel mai Cel mai bun mod distrugeți întregul concept de SOA - implementați un ESB și așteptați-vă ca problemele să se rezolve de la sine. Deși o idee grozavă, simpla implementare a unui ESB nu va fi suficientă, din păcate.
În cel mai bun caz, încercarea de a ascunde ceva sub covor, ca în diagrama de mai jos, nu va duce la nimic:
Oamenii tăi IT vor ura sistemul și, deși managerii vor tolera inițial ESB ca o nouă soluție, mai târziu va deveni un râs. „Ce, acesta este noul glonț de argint? Hahaha.”
Astfel de consecințe sunt inevitabile dacă ESB nu face parte dintr-un plan de dezvoltare mai amplu.
Deci, se dovedește că ESB este doar pentru bănci și altele asemenea?¶
Deloc. Acest buna decizieîn orice situație care necesită munca coordonată a mai multor surse de date și mai multe metode de acces pentru a obține un rezultat interesant.
De exemplu, sarcina de a colecta cele mai recente citiri de la un senzor de temperatură și de a le publica pe mai multe canale, cum ar fi alerte prin e-mail și aplicații pentru iPhone, este potrivită pentru o platformă de integrare.
Verificarea și monitorizarea periodică a funcționării tuturor instanțelor unei aplicații critice și, dacă nu toate funcționează, rularea unui script configurat și trimiterea unui mesaj text către administratori este, de asemenea, grozavă.
Orice lucru care necesită integrare într-un mediu clar și bine definit este probabil potrivit pentru un serviciu ESB. Dar, ca întotdeauna, a decide dacă ceva este cu adevărat potrivit pentru integrare vine cu experiență.
autobuz de serviciu pentru întreprinderi
Desigur, echipa Zato poate ajuta.
Dar am auzit că SOA este XML, SOAP și servicii web¶
Da, asta ar vrea unii să crezi.
Dacă persoanele sau vânzătorii cu care ați lucrat au trimis un fișier CSV codificat BASE64 într-un mesaj SOAP protejat SAML2, atunci este de înțeles de unde ați avut această impresie.
Serviciile XML, SOAP și web au propriile lor cazuri de utilizare, dar, ca orice, pot fi utilizate incorect.
SOA este despre o arhitectură clară și gestionabilă. Faptul că un serviciu poate folosi sau nu SOAP este practic irelevant. SOA ca abordare arhitecturală va fi în continuare valabilă chiar dacă nu este folosit nici un serviciu SOAP.
Dacă un arhitect proiectează o clădire frumoasă, nu poate influența prea mult culoarea interiorului.
Deci nu, SOA nu este XML, SOAP și servicii web. Ele pot fi folosite, dar sunt doar o parte, nu baza.
Puteți trimite colegii pierduți la acest articol, astfel încât să-și dea seama ce este SOA.
Mai mult mai multe¶
Acest capitol acoperă doar elementele de bază, dar ar trebui să ofere totuși o înțelegere clară a cum ar trebui să arate un ESB și SOA și ce este necesar pentru a obține succesul.
Alte subiecte care nu sunt acoperite aici includ (dar nu se limitează la):
- Cum să obțineți asistență de management pentru introducerea unui ESB
- Cum să aduni arhitecți SOA și echipe de analiză
- Reprezentarea modelului de date canonice (CDM) în organizație
- Indicatori cheie de performanță (KPI) - Acum că aveți o metodă comună și unificată pentru furnizarea de servicii între sisteme, ar trebui să începeți să observați și să analizați ceea ce vi se livrează de fapt
- Managementul proceselor de afaceri (BPM) - cum și când să alegeți o platformă BPM pentru managementul serviciilor (răspunsul nu este prea curând, mai întâi aflați cum să construiți servicii plăcute și utile)
- Ce să faci cu sistemele fără API? De exemplu, dacă ESB are acces direct la bazele de date (răspunsul este că variază, nu există nicio regulă de aur)
Deci, ce este Zato?¶
Zato - ESB și server de aplicații scris cu folosind Pythonși poate fi folosit pentru a construi sisteme intermediare și backend. Este un software open source cu suport comercial și comunitar. Și Python este un limbaj de programare cunoscut pentru simplitatea și eficiența sa.
Utilizarea Python și Zato vă permite să vă creșteți productivitatea și să pierdeți mai puțin timp.
Zato a fost scris pragmați pentru pragmați. Acesta nu este un alt sistem construit în grabă de către furnizor în urma hype-ului ESB/SOA.
De fapt, Zato a fost construit pe baza experienței practice de „combatere a incendiilor” provocate de astfel de sisteme. De fapt, autorii lui Zato au petrecut atât de mult timp luptând cu astfel de medii încât au devenit practic impermeabili la orice incendiu.
Aceasta este forja de la care Zato a venit pe lume și ca atare poate oferi performanțe și ușurință în utilizare negăsită în alte soluții similare.
Ne vedem înăuntru Aici!
(Enterprise Service Bus) este conceput pentru a construi un peisaj de informații distribuite al unei întreprinderi. Produsul software asigură interacțiunea tuturor aplicațiilor integrate într-un singur centru, combinând sursele de informații existente și oferind schimb centralizat de date între diferite sisteme de informații.
Enterprise Data Service Bus DATAREON ESB este un mijloc eficient de asigurare a stabilității și completității schimb de informatii, creșterea performanței generale a sistemului informațional și reducerea costurilor cu forța de muncă pentru administrarea acestuia.
Autobuz de serviciu pentru întreprinderi
Software DATAREON ESB inclusă oficial în registru unic Programe rusești pentru calculatoare electronice și baze de date, care pot fi achiziționate de instituțiile de stat și municipale (https://reestr.minsvyaz.ru/).
Pentru integrarea a 2-3 sisteme informatice în companiile mici, DATAREON oferă un produs software creat pe baza DATAREON ESB - DATAREON MQ.
Funcționalitatea DATAREON ESB
Sarcini rezolvate folosind magistrala de servicii de date corporative
- Transfer de dateîntre diferite sisteme informatice (cu rutare sau punct la punct)
- Formarea unui singur spațiu informațional în medii eterogene
- Construirea unui sistem distribuit pe baza unui model de evenimentîn următoarele opțiuni:
- construirea de aplicații cu procese de afaceri end-to-end bazate pe un model de evenimente;
- crearea unui sistem cu sincronizarea aplicațiilor de afaceri în diverse sisteme informaționale
- Chitanță arhitectură de control scalabilă nivel întreprindere/exploatație
- Implementare sisteme de schimb de date la nivel de transport și la nivel de logica de afaceri
- Delegarea sarcinii de construire a fluxurilor de informații departamente analitice
- Reducerea complexității generale a designului de integrareși reducerea cerințelor pentru lățime de bandă canale
- Stabilitate generală crescută strat de transport transmiterea datelor
- Costuri reduse de tranzacție la schimbul de date între diferite departamente
- Costuri globale reduse pentru întreţinerea şi susţinerea sistemului informaţional.
Beneficiile DATAREON ESB Enterprise Data Service Bus
- Integrare rapidă
- Fiabilitate ridicată
- Capacitatea de a reutiliza resurse
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
- Crearea unui model de date de referință care să se potrivească tuturor sistemelor nu este ușoară.
- 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.
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. Pe fiecare server fizic Există 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.