Schimb de date cu magistrala de serviciu între diferite sisteme. Mi-a placut mesajul. Oferte pe piata

), fost nume - Axelot Datareon ESB, este conceput pentru a construi un peisaj de informații distribuite al unei întreprinderi. Produs software asigură interacțiunea tuturor aplicațiilor integrate într-un singur centru, combinând sursele existente de informații și oferind schimb centralizat de date între diferite sisteme informatice.

Autobuzul de servicii de date corporative Datareon ESB este un mijloc de asigurare a stabilității și completității schimbului de informații, creșterea performanței generale a sistemului informațional și reducerea costurilor cu forța de muncă pentru administrarea acestuia.

Produsul software Datareon ESB este inclus oficial în registrul unificat al programelor rusești pentru calculatoare electronice și baze de date, care pot fi achiziționate de instituțiile de stat și municipale.

Funcționalitate

• Acceptă diverse standarde și scenarii de integrare
• Gestionați-vă central peisajul de integrare cu ecosistemul Eclipse
• Transformarea datelor (algoritmi de transformare a datelor în mai multe etape cu controlul diferitelor condiții)
• Transferați date de orice dimensiune (scalare verticală și orizontală)
• Integrare ușoară cu produsele de pe platforma 1C:Enterprise 8
• Asigurarea transferului securizat de date
• Diagnosticare și monitorizare a stării întregii rețele de transmisie a datelor

Probleme de rezolvat

• Transfer de date între diferite sisteme de informații (cu rutare sau punct la punct)
• Formarea unui singur spațiu informaționalîn medii eterogene
• Construirea unui sistem distribuit pe baza modelului de evenimente în următoarele opțiuni:
  • construirea de aplicații cu procese de afaceri end-to-end bazate pe un model de eveniment;
  • crearea unui sistem cu sincronizarea aplicațiilor de afaceri în diverse sisteme informaționale
• Obținerea unei arhitecturi scalabile de management la nivel de întreprindere/holding
• Implementarea unui sistem de schimb de date la nivel de transport și la nivel de logica de afaceri
• Delegarea sarcinii de construire a fluxurilor de informații către departamentele analitice
• Reducerea complexității generale a circuitului de integrare și reducerea cerințelor pentru lățime de bandă canale
• Stabilitate generală crescută strat de transport transmiterea datelor
• Reducerea costurilor de tranzacție la schimbul de date între diferite departamente

2017

Axelot Datareon ESB 2.1.0.0

Soluția AXELOT Datareon ESB este inclusă în lista de competențe Gold Application Development - un fapt care confirmă calitate superioară produsul și compatibilitatea acestuia cu produsele Microsoft.

AXELOT Datareon ESB oferă o serie de beneficii cheie pentru companii:

• Posibilitate de integrare;
• Fiabilitatea și reutilizarea resurselor;
• Obținerea unei arhitecturi scalabile de management la nivel de întreprindere/holding;
• Delegarea sarcinii de construire a fluxurilor de informații către departamentele analitice;
• Reducerea complexității generale a schemei de integrare și reducerea cerințelor pentru debitul canalului;
• Creșterea stabilității generale a stratului de transfer de date de transport;
• Reducerea costurilor de tranzacție la schimbul de date între diferite departamente;
• Reducerea costurilor totale de întreținere și întreținere a sistemului informațional.

Principalele caracteristici ale sistemului:

• Un număr mare de conectori la diverse sisteme: 1C:Enterprise 8, servicii SOAP, servicii REST, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter și altele;
• Mecanism de plugin pentru auto-dezvoltarea conectorilor;
• Suport pentru diverse limbaje și tehnologii de programare la dezvoltarea scenariilor de interacțiune: 1C:Enterprise 8, JavaScript, T-SQL;
• Configurarea scenariilor de transformare a datelor în mai multe etape folosind mecanisme de mapare vizuală și transformări XSLT personalizate;
• Lucrați cu diferite formate de date (XML, JSON, XLS, DBF, CSV, Base64 și altele);
• Statica si rutare dinamică pachete informative;
• Viteză mare de interacțiune și toleranță la erori: cerințe reduse pentru lățimea de bandă a rețelei, echilibrarea sarcinii, izolarea domeniilor de informații, capacitatea de a monitoriza starea nodurilor de integrare;
• Suport pentru modelul de eveniment, apeluri sincrone și asincrone, livrare garantată;
• Schimbarea scenariilor de integrare a sistemelor abonaților (mecanisme de încărcare/descărcare, transformare și rutare) într-un mod „fierbinte” fără a fi nevoie să le oprească (inclusiv configurații pe platforma 1C:Enterprise 8);
• Diagnosticare și monitorizare a tuturor proceselor de integrare, capacitatea de a depana și urmări pachetele de informații.

O atenție deosebită este acordată integrării aplicațiilor pe platforma 1C:Enterprise 8. Livrarea include un subsistem special care poate fi încorporat în orice configurație standard pe platforma 1C:Enterprise 8 și oferă toate mecanismele necesare pentru configurarea și administrarea rapidă și convenabilă a integrării. Interacțiunea „AXELOT: ESB Autobuz de serviciu date" cu configurarea pe platforma 1C:Enterprise 8 se realizează folosind serviciile SOAP și REST.

Componentele serverului „AXELOT: ESB Service Data Bus” sunt dezvoltate în C++. Administrarea și configurarea „AXELOT: ESB Service Data Bus” se realizează în mediul de dezvoltare Eclipse și poate fi realizată împreună cu dezvoltarea sistemelor pe platforma 1C:Enterprise 8 în 1C:Enterprise Development Tools. „AXELOT: ESB Service Data Bus” este multiplatformă și acceptă sisteme de operare MS Windows și Linux.

AXELOT Datareon ESB este o dezvoltare complet rusească și este în curs de a fi inclusă în registrul unificat al programelor rusești pentru calculatoare electronice și baze de date, care pot fi achiziționate de instituțiile de stat și municipale pentru a rezolva anumite probleme.

Autobuz de date de integrare este destinat construirii de aplicații compozite care utilizează diverse standarde și tehnologii de interacțiune construite după diferite principii. O atenție deosebită este acordată integrării aplicațiilor pe platforma 1C:Enterprise.

Acceptă diverse standarde și scenarii de integrare folosind magistrala de date de integrare

Destul de des atunci când construiești aplicații compozite trebuie să faci față unei situații în care diverse tipuri aplicațiile sunt concepute pentru diverse standarde și scheme de integrare. De asemenea, nu este neobișnuit să se schimbe mecanismele de integrare aplicatii existente imposibil sau consumator de timp din mai multe motive: lipsa unui dezvoltator, lipsa cod sursă etc. Autobuzul de integrare vă permite să combinați astfel de aplicații într-un singur întreg, ascunderea diferențelor de integrare la nivelul mecanismelor și setărilor conectorilor tipici, care conduce interacțiunea aplicațiilor la o singură schemă de integrare controlată.

În DATAREON ESB există următoarele tipuri de conectori:

• Conector de servicii SOAP, inclusiv servicii web 1C:Enterprise 8
• Conector pentru servicii REST, inclusiv servicii web „1C:Enterprise 8”
• Conector MS SQL
• IBM DB2 Connector
• Conector Oracle
• Conector PostgreSQL
• Conector SharePoint
• Conector OData 1C
• conector TCP
• Conector Siemens Team Center
• conector SAP și altele.

Toți conectorii au capacitatea de a configura parametric conexiunea la sistemul sursă și de a interacționa cu acesta.

Lista de conectori disponibili este în continuă extindere o listă completă ar trebui verificată cu DATAREON.

DATAREON ESB conține un mecanism care vă permite să dezvoltați în mod independent diverși conectori în limbaje de platformă Java sau .Net. În acest fel, orice scenariu personalizat pentru conectarea la sistemele sursă poate fi implementat.

La Moscova, din 1958, a existat strada a 3-a Stroiteley, dar în 1963 a fost redenumită - acum este strada Maria Ulyanova, iar clădirea 25 de pe această stradă este o clădire Hrușciov cu cinci etaje. În Leningrad (Sankt Petersburg), Strada a 3-a a Constructorilor nu a existat niciodată...

Vorbesc din nou despre integrarea aplicațiilor. Citește-o astăzi standard intern flux de documente interdepartamentale GOST R 53898-2010 Și standardul pare să fie „corect” scris în XML și sunt tot felul de câmpuri utile pe 53 de pagini și toate detaliile. Îmi amintesc că la sfârșitul secolului trecut, am pledat cu tărie pentru apariția standardelor pentru mesajele electronice pe paginile revistei Computer în articolul The Internet Factor in the Development of Client-Bank Systems La sfârșitul secolului trecut, totul părea mai optimist decât la începutul acesteia. Dot-com-urile nu se prăbușiseră încă, cerul era mai înalt, iarba era mai verde, site-urile de socializare erau credibile și Fielding nu și-a susținut încă disertația intitulată Representational State Transfer. Ce s-a întâmplat în puțin peste zece ani și de ce ideea de a standardiza formatul document electronic nu ma mai deranjeaza? Nimic important, doar paradigma de integrare a aplicațiilor s-a schimbat.

Cum era înainte? O bancă a trimis la alta mesaj de e-mail(Îmi pare rău, lucram la Inkombank atunci, așa că voi vorbi despre bănci). A doua bancă a primit mesajul și i-a trimis o chitanță. Toate acestea au fost criptate de zece ori, certificate semnătură digitală, chitanța includea funcția hash a mesajului original... numere de intrare și de ieșire, marcaje temporale (tot criptografice, de altfel) etc. etc. Cea mai discutată întrebare a acelor ani a fost dacă este necesar să se genereze o chitanță pentru chitanță și ce să facă atunci când chitanța nu a fost livrată. În general, este înfricoșător să ne amintim la ce nivel de complexitate este procesul de sincronizare a stărilor multiple imagini virtuale un singur document real. A fost mai ușor cu hârtie. Cel puțin până la inventarea copiatorului.

Să revenim la vremurile moderne. Dacă existau cozi de mesaje pentru a livra mesaje în siguranță și fiabil, atunci a apărut magistrala de serviciu pentru a elimina schimbul de mesaje. Și nu-mi spune că tocmai acest autobuz este cel care schimbă mesaje. Știu asta, o facem singuri, dar nu este foarte corect. Ideea originală a autobuzului de serviciu, mai ales Întreprindere Service Bus (ESB) nu este despre transmiterea de mesaje, ci despre asigurarea faptului că orice aplicație nu trebuie să-și facă griji cu privire la crearea propriei instanțe locale a unui obiect. Scopul serviciului este de a putea obține întotdeauna un astfel de obiect. Dacă aveți nevoie de un document, introduceți adresa URL și utilizați metoda HTTP GET pentru a primi și a citi documentul. Dacă doriți să schimbați un document, ați schimbat documentul folosind aceeași adresă URL utilizând metoda HTTP PUT. POST a fost adăugat, DELETE a fost eliminat, ce poate fi mai simplu? Dați documentului dvs. o adresă URL. Utilizați un protocol în stil WebDAV pentru a prelua un document, a lucra la el și a-l readuce la locul său într-o stare nouă, aceeași definită ca o copie master, de exemplu. la aceeași adresă URL de la care ați luat-o

Altfel, este o apocalipsă. Încasările și notificările privind schimbările de stare nu sunt atât de rele. Necesitatea de a interpreta câmpurile documentului în același mod și pentru aceasta de a sincroniza cărțile de referință este o problemă. A treia stradă a constructorilor din Moscova și a treia stradă a constructorilor din Sankt Petersburg, așa cum se știe din filmul principal de Anul Nou, sunt departe de același lucru. Poate singura carte de referință care este interpretată în mod egal în diferite departamente este calendarul gregorian. Și apoi, nu sunt complet sigur. Sau un alt exemplu - numele meu de pe pașaportul internațional nu se potrivește cu numele meu de pe viza britanică lipită în același pașaport internațional. Pe pașaport scrie MAXIM, iar pe viză scrie MAKSIM. Din această cauză, mi-e teamă să trec granița :) Să adăugăm la aceasta diferența de seturi de stări ale documentelor în diferite sisteme, diferite grafice de tranziție, documente compuse care includ un set de alte documente, plicuri electronice etc. Primim o problemă de o complexitate combinatorie incredibilă. Ce se întâmplă dacă documentul nu ajunge la un departament, ci la mai multe deodată? Într-una se va împlini, în alta va fi respinsă, în a treia se va pierde. Prin urmare, oamenii de proces vor adăuga foarte curând un traseu la acest document, exprimat laconic în notație BPMN pe o duzină de pagini. Excepții, retururi, anulări, rezultate incorecte ale verificării semnăturii digitale, chitanțe nelivrate, chei expirate... Matricea se odihnește (dar programatorii continuă să lucreze)

Integrarea aplicațiilor este o problemă cu care se confruntă mai devreme sau mai târziu departamentul IT al oricărei organizații care are mai multe dintre aceste aplicații. Iată o listă departe de a fi completă de sarcini care se încadrează în conceptul de „integrare”:

• necesitatea de a menține directoare generale (de exemplu, directoare ale clienților sau angajaților);
• lansarea de activități într-un sistem informațional atunci când evenimentele au loc în altul;
• proces de afaceri (o secvență organizată de acțiuni efectuate atât de oameni, cât și de sistemele informaționale) care apar în mai multe aplicații;
• interacțiunea informațională cu partenerii de afaceri (de exemplu, cererea automată de prețuri pentru componente de la furnizor);
• unificarea schimburilor de informații și a proceselor de afaceri în ramurile companiei.

Dacă acest tip de acțiune are loc rar într-o întreprindere (de exemplu, o dată pe zi), atunci aceste acțiuni pot fi organizate într-un mod improvizat - de exemplu, prin încărcarea manuală a datelor dintr-o aplicație în format Excelși încărcarea acestora într-o altă aplicație sau chiar folosirea datelor de intrare duplicate în două sisteme simultan. Cu toate acestea, dacă nevoia de interacțiune a informațiilor între aplicații apare de multe ori pe zi, atunci se pune problema utilizării ineficiente a resurselor umane și, în consecință, este nevoie de automatizarea acestei proceduri.

Integrare punct la punct

Sarcina integrării punct la punct este relativ simplă. Este necesar să înțelegem modul în care fiecare dintre cele două sisteme care interacționează este pregătit să transmită și să primească date, să creeze soluții tehnice adecvate pentru a accesa aceste interfețe și, de asemenea, să implementeze un mecanism de conversie a datelor din formatul de sistem sursă în formatul de sistem de destinație. În cel mai bun caz, sistemele informaționale oferă o integrare specială pentru interfata software(API), iar în cel mai rău caz, citirea și scrierea informațiilor trebuie făcută direct în baza de date a aplicației. Ca rezultat, apare o soluție de integrare locală - un modul software separat, de design propriu, cu toate cerințele ulterioare pentru întreținerea și menținerea relevanței sale.

Integrare punct la punct

Aceasta nu este o problemă mare atâta timp cât există puține integrări punct la punct - una sau două. Cu toate acestea, practica arată că numărul de integrări punct la punct tinde să crească, iar calitatea managementului acestor integrări, dimpotrivă, scade rapid. Există multe motive pentru aceasta: numărul de module de integrare este în creștere, dezvoltatorii care au realizat unul sau altul modul părăsesc organizația, formatele de date din sistemele integrate se schimbă etc. Trist rezultat al dezvoltării evolutive a integrărilor punct la punct este cea mai complexă „carne tocată” a interacțiunilor de integrare între aplicațiile întreprinderii, atitudinea față de care dintre angajații departamentului IT poate fi exprimată cel mai ușor în câteva cuvinte: „Atâta timp cât funcționează, e mai bine să nu-l atingi.” Cu toate acestea, această situație nu se potrivește nici departamentului IT în sine, nici clienților de afaceri.

Umplutura de integrare

Autobuz cu un singur serviciu

După ce a supraviețuit mai multor generații de abordări diferite ale integrării aplicațiilor, industria globală software-ul a ajuns la conceptul de o singură magistrală de servicii pentru întreprindere (Enterprise Service Bus, ESB). Din punct de vedere arhitectural, un ESB este o soluție software care asigură că toate aplicațiile integrate interacționează printr-un singur punct, uniform, oferind dezvoltatorilor și administratorilor un mijloc unificat și centralizat de dezvoltare, testare și monitorizare a progresului tuturor scenariilor de integrare.

Principalele componente care alcătuiesc un autobuz de serviciu modern sunt:

• un broker de mesaje este o coloană vertebrală de înaltă performanță pentru schimbul de mesaje într-un format unificat între aplicații în timp real;
• adaptoare - adaptoarele tehnologice și adaptoarele la sistemele de afaceri asigură interacțiunea cu aplicațiile într-un format acceptabil pentru aceștia, prezentând informațiile din aceste mesaje într-un format unificat perceput de broker - cu cât o anumită platformă de integrare oferă mai multe adaptoare diferite, cu atât sunt mai mari șansele că nu va fi necesar să-l implementeze în organizația dumneavoastră munca suplimentara pentru a crea adaptoare specifice sistemelor dumneavoastră;
• mediu pentru dezvoltarea scenariilor de integrare - cu cât dezvoltarea scenariilor de integrare este mai simplă și mai rapidă, cu atât mai puține investiții în această dezvoltare și, prin urmare, cu atât rentabilitatea investiției este mai rapidă. Autobuzul modern de integrare oferă dezvoltatorului instrumente vizuale pentru construirea scenariilor de integrare, care în cele mai multe cazuri fac posibil să se facă fără codificare de nivel scăzut;
• Instrumente SOA - aderarea la principiile arhitecturii orientate pe servicii este un standard necondiționat pentru toate soluțiile de integrare de tip „single service bus” (după cum reiese din numele său). Sistemele de informații sunt considerate aici ca furnizori și consumatori de servicii în care sunt plasate toate serviciile publicate în autobuz registru unificat cu capacitatea de a reutiliza și de a gestiona politicile asociate cu serviciile;
• diverse instrumente de control și management (audituri, logare, monitorizare centralizată, monitorizare a respectării acordurilor de nivel de servicii etc.).

Avantajele utilizării unui singur autobuz de serviciu includ:

• scalare - capacitatea de a construi soluții de orice dimensiune și sarcină;
• flexibilitate - capacitatea de a implementa și schimba scenarii de integrare fără implicarea semnificativă a dezvoltatorilor;
• securitate - instrumentele de autentificare și autorizare încorporate asigură controlul accesului la servicii la nivelul magistralei propriu-zise, ​​scutind dezvoltatorii scenariilor de integrare de sarcina implementării acestor mecanisme;
• utilizarea standardelor deschise - reduce implicarea specialiștilor scumpi în tehnologiile proprietare;
• centralizarea instrumentelor de control și administrare - vă permite să evitați „încețoșarea” punctului de responsabilitate pentru scenariile de integrare, asigurarea monitorizării operaționale și avertizare timpurie în cazul defecțiunilor.

încă unul cerință importantă Funcționalitatea mediului ESB include abilitatea de a implementa integrarea cu organizații externe - parteneri de afaceri, furnizori, clienți corporativi, sucursale la distanță. Caracteristicile unei astfel de integrări sunt calitatea imprevizibilă a canalelor, lipsa garanțiilor de livrare a informațiilor și slaba pregătire pentru integrare ca atare - de regulă, organizația parteneră oferă o gamă foarte limitată de formate de schimb de date. În acest caz, magistrala de integrare trebuie să conțină un instrument pentru construirea interacțiunii B2B, permițând schimbul de informații conform standardelor deschise, inclusiv industriei, să asigure livrarea garantată, să aibă mijloacele de a configura schimbul de informații în contextul unui anumit partener de afaceri și, desigur, să lucreze în deplină conformitate cu principiile platformei de integrare în sine, izolând dezvoltatorul de scenarii de integrare din detaliile tehnice ale interacțiunii cu partenerul .

Enterprise Service Bus

Managementul proceselor de afaceri

O proporție semnificativă a scenariilor de integrare implică faptul că schimbul de informații implică nu numai aplicații care acționează ca surse sau receptori de informații, ci și oameni - angajați ai organizației care îndeplinesc diverse sarcini sau iau decizii. În acest caz, putem vorbi despre trecerea dincolo de integrarea „pură” și apariția unei noi entități în centrul atenției noastre - procesele de afaceri, iar în cerințele pentru platforma de integrare - nouă funcționalitate pentru managementul proceselor de afaceri (Business Process Management). , BPM). Dacă există cerințe BPM, platforma de integrare trebuie să ofere dezvoltatorului:

• mijloace design vizual procesele de afaceri - este optim ca aceste instrumente să poată fi folosite de oameni care sunt departe de IT, de exemplu, analiști de afaceri sau metodologi. În plus, capacitatea de a transfera modele de procese de afaceri de la instrumente specializate de modelare în mediul de dezvoltare este extrem de utilă. Același instrument ar trebui să permită proiectarea formularelor de sarcini pentru participanții la proces, protejând dezvoltatorii cât mai mult posibil de programare;
• mediu de execuție a procesului de afaceri - un motor special care asigură procesarea regulilor de afaceri, transferul sarcinilor între utilizatori și sistemele informaționale în conformitate cu modelele dezvoltate de procese de afaceri, precum și procesarea situațiilor excepționale (de exemplu, executantul depășește timpul alocat pentru finalizare). o sarcină);
• portalul participanților la procesele de afaceri - un portal specializat care permite utilizatorilor să lanseze procese, să participe la acestea și să monitorizeze progresul rularea proceselorși efectuează acțiuni administrative în conformitate cu drepturile stabilite acestora;
• instrumente de monitorizare și control. Capacitatea de a analiza rapid și retrospectiv fluxul proceselor de afaceri este o parte importantă a oricărei platforme BPM.

Pe în acest moment mulți furnizori de software tind să combine mediul BPM și magistrala de integrareîntr-o singură platformă middleware, eliminând separarea strictă care a existat de câțiva ani între sistemele BPM și instrumentele de integrare a aplicațiilor. Această abordare este foarte progresivă. Unii furnizori merg chiar mai departe și adaugă instrumente profesionale de modelare a proceselor de afaceri pe platformă. Software AG este un pionier în acest sens, oferind o soluție care combină renumitul instrument de modelare ARIS Platform și mediul de integrare webMethods/BPM.

Utilizarea cuprinzătoare a platformei de integrare

Oferte pe piata

În prezent, există trei grupuri de oferte de software pentru construirea ESB-urilor. Aceste grupuri variază atât în ​​ceea ce privește prețul, cât și funcționalitatea oferită.

Primul grup este reprezentat de propunerile companiilor ale căror produse sunt lideri în cercetarea agențiilor analitice în toate categoriile indicate în articol (ESB, SOA Governance, BPM, B2B). Acest grup include:

• IBM cu linia sa de produse WebSphere;
• Software AG cu platforma de integrare webMethods;
• Oracle cu o serie întreagă de propuneri;
• Tibco cu linie Business Integration.

În principiu, cei cărora nu le plac compromisurile pot alege oricare dintre acești producători - toate companiile listate oferă linii de produse cu drepturi depline (totuși, în cazul Oracle, nu este întotdeauna clar despre ce produs vorbim, deoarece după achiziționând un număr de companii, Oracle oferă imediat mai multe produse, nu întotdeauna suficient de integrate între ele). Tibco se deosebește puțin, deoarece dimensiunea acestei companii este mult mai mică decât dimensiunea celorlalți membri ai acestor patru, ceea ce poate ridica unele îndoieli cu privire la stabilitatea acesteia. Software AG nu este încă un producător foarte cunoscut pe piața rusă, dar platforma webMethods, care este astăzi oferta cheie a acestei companii, are un potențial mare. IBM și produsele sale sunt deja cunoscute și utilizate de multe întreprinderi, dar unele dintre ele au plângeri cu privire la costul implementării și întreținerii sistemului.

Al doilea grup de propuneri sunt companii care se concentrează în principal pe funcționalitatea ESB „pură” și au obținut succes aici. Acest grup include: Sun (Glassfish), Progress (Sonic) și Fujitsu.

Ofertele acestor companii sunt bune dacă nu intenționați să extindeți domeniul de aplicare al platformei dvs. către BPM și/sau B2B. În caz contrar, riscați să rămâneți cu funcționalități insuficient dezvoltate și să vă creșteți semnificativ costurile pentru îmbunătățirea acesteia pentru a vă satisface nevoile.

Al treilea grup este cel mai numeros și include toate propunerile neincluse în cele două grupuri anterioare. Listarea tuturor propunerilor pe tema ESB în acest articol este inutilă, puteți obține o astfel de listă în orice motor de căutare. Dacă bugetul tău pentru integrare este limitat și ești înclinat să experimentezi, s-ar putea să-ți încerci norocul cu oricare dintre ele. Cu toate acestea, riscurile legate atât de funcționalitatea insuficient dezvoltată, cât și posibile probleme cu fiabilitate, suport tehnicși perspectivele de dezvoltare a produsului, presupuneți.

Concluzie

În concluzie, aș dori să ofer cititorilor câteva sfaturi simple la alegerea magistralei de integrare:

• Gândiți-vă la construirea unei soluții de integrare fără a aștepta ca problemele de interoperabilitate ale aplicațiilor să vă împingă la perete. Cu cât molozul este mai mare, cu atât este mai dificil să le curățați;
• Alege-ți platforma cu grijă. Căutați un furnizor care să vă mulțumească din toate punctele de vedere, deoarece acum există multe dintre care să alegeți. Ar trebui să fiți interesat atât de parametrii tehnologici ai platformei, cât și de aspectele metodologice ale implementării;
• gandeste-te la viitor. Cerințele funcționale pe care le realizați acum se pot schimba semnificativ într-un an, iar dacă platforma nu le satisface, atunci va trebui să vă „mutați” la alta. Și o mișcare, după cum știți, este egală cu două incendii.

Blogul companiei PNN,

Dezvoltare site

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 mesagerie centralizată și unificată orientată pe evenimente între diverse sisteme de informații bazate pe principiile arhitecturii orientate către 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 capacității 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 confortul utilizării „locuințelor unice” pentru servicii:

Comanda
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 dimensiune 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 a mediului în care lucrează, 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 serviciu care este disponibil pentru alte componente. În cadrul unui singur 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 utilizare 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 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 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 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 seta 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: