În acest articol, subiectul propus se referă la câteva noțiuni despre integrarea aplicațiilor din mediul Enterprise. Valorificând experiența deținută în domeniul integrării aplicațiilor, vom explica ce este și cum arată o arhitectură enterprise, cum este o arhitectură de integrare, când și de ce a apărut acest concept, care sunt beneficiile pe care le aduce și ce posibilități avem pentru implementarea unei soluții de integrare.
Mulți dintre noi asociem noțiunea de Enterprise cu o companie de dimensiuni mari sau foarte mari, cu procese lente sau ineficiente. Dar, dacă ne vom uita la modul în care este definită această noțiune în literatura de specialitate, vom observa că diferă puțin față de percepția noastră.
În termeni generali, enterprise este definit drept orice efort uman de a întreprinde ceva. În consecință, o întreprindere sau o afacere poate fi văzută ca un grup de persoane care lucrează împreună pentru a atinge scop bine definit și care își desfășoară activitatea având ca suport o anumită platformă.
Un standard în domeniul arhitecturilor Enterprise, dezvoltat de The Open GROUP, definește termenul enterprise ca fiind orice organizație sau grup de organizații care au un scop comun.
Spre exemplu, enterprise poate fi:
O corporație sau o divizie a unei corporații;
Un lanț de organizații distribuite pe mai multe regiuni geografice având același proprietar;
Parteneriate sau asocieri de afaceri organizate sub forma unui consorțiu;
Prin urmare, orice organizație, indiferent de mărimea ei, de modul de organizare, de scopul ei, are o arhitectură enterprise.
Având în vedere modul în care este definit conceptul de enterprise, putem afirma că orice organizație este formată din mai multe componente care sunt structurate și aranjate astfel încât să permită, în primul rând, existența companiei și, totodată, să faciliteze îndeplinirea strategiilor și obiectivelor sale.
Existența unei arhitecturi de acest gen, face posibilă optimizarea proceselor de orice natură, manuale sau automate și integrarea acestora într-un mediu care poate răspunde mult mai ușor schimbărilor și oferă suport în dezvoltarea companiei. În plus, facilitează procesul de transformare a afacerii păstrând un echilibru între dezvoltare, inovare și eficiență operațională.
Arhitecturile enterprise, ca natură, tind să conțină numeroase sisteme și aplicații software, care furnizează diferite funcționalități pe care compania se bazează pentru a-și desfășura activitatea zilnică.
La începutul anilor '90, un număr mare de companii au adoptat ideea de produs software împachetat. Adică, un produs care să rezolve una sau mai multe dintre nevoile de business identificate la acel moment. Un exemplu popular este soluția de tipul ERP system, un modul software care promitea a fi un punct unic de intermediere între toate aplicațiile care gestionau resursele companiei.
Deoarece această abordare nu a funcționat conform așteptărilor, companiile au început să adauge soluții complementare pentru a putea gestiona și celelalte zone interes ale companiei. În figura de mai jos, putem identifica diferitele module care pot exista în infrastructura software a unei companii.
În desfășurarea activităților specifice de business, companiile sunt nevoite să evolueze pentru a putea rămâne competitive prin adaptarea continuă la cerințele și nevoile pieței. În centrul acestui proces aflat într-o continuă schimbare se află atât infrastructura software cât și cea hardware a companiilor.
Odată cu creșterea afacerii, a numărului de componente software și a cantității de informații procesate, a trebuit ca la nivelul companiilor să se găsească soluții pentru a face față provocărilor ridicate de optimizarea unei astfel de infrastructuri de aplicații.
Azi, utilizarea cât mai eficientă a informației și capabilitatea de transformare digitală sunt factori cheie pentru succesul afacerii. Nevoia tot mai mare de avea acces cât mai rapid și cât mai eficient la informații a împins companiile să găsească metode de a conecta diferitele lor sisteme informaționale.
De obicei, infrastructura de aplicații dintr-o companie poate fi foarte complexă, compusă dintr-o multitudine de aplicații diferite și având la bază diferite tehnologii și arhitecturi.
Inițial, pentru a facilita interconectarea acestora, s-a aplicat modelul de integrare point-to-point.
Modelul Point-to-point (P2P) presupune implementarea unui conector între fiecare pereche de aplicații sau sisteme care trebuie să comunice. Acest conector va gestiona toate transformările de date, integrarea și alte servicii de mesagerie necesare pentru integrarea celor două componente.
Într-o infrastructură cu puține componente, acest model funcționează suficient de bine oferind o soluție de integrare facilă și nu prea complexă, astfel încât, modificările aduse unui sistem să fie ușor și rapid implementate.
Totuși, pe măsură ce vom adăuga noi componente în această infrastructură, va crește și numărul conexiunilor point-to-point necesare pentru a obține o integrare completă. Prin urmare, costul întreținerii unei astfel de soluții va crește exponențial.
După cum putem observa în imaginea de mai sus, numărul de conectori necesari pentru a integra un număr de opt sisteme depășește valoarea de trei zeci.
Ținând cont și de faptul că fiecare conector va trebui dezvoltat și gestionat separat, aplicarea acestui model de integrare în arhitecturile complexe devine extrem de dificilă ajungând să fie imposibil de gestionat.
Termenul Enterprise Application Integration a fost menționat pentru prima dată în anul 1996, într-o publicație Gartner Group din SUA, unde au fost analizate abordările întâlnite la un anumit număr de companii mari în încercarea de a explica apariția unor serii de probleme în integrare.
EAI poate fi definit ca fiind procesul prin care datele existente într-o aplicație software sunt puse împreună cu datele provenite dintr-o altă aplicație sau sistem.
De cele mai multe ori, termenul EAI este asociat cu tehnologiile middleware având ca rol primordial interconectarea aplicațiilor existente în arhitectura enterprise prin simplificarea și automatizarea proceselor de business.
Ca alternativă la modelul de integrare P2P, unde posibilitatea de a eșua în procesul de conectare a unei infrastructuri complexe crește pe măsura creșterii numărului sistemelor ce trebuie integrate, soluțiile EAI au la bază conceptul de middleware folosit în centralizarea și standardizarea metodelor de integrare aplicabile întregii infrastructuri enterprise.
Sistemele EAI înglobează adaptoare de conexiune pentru transformarea de protocol, procese de transformare a informației pentru conversia datelor din formatul sistemului sursă într-un format care să poată fi înțeles de sistemul destinație, servicii de orchestrare și rutare, cât și alte componente adiacente.
Modelul propus de EAI slăbește conexiunile strâns cuplate din modelul punct-la-punct. O aplicație poate să trimită un mesaj fără a avea nevoie să cunoască locația consumatorului, care sunt informațiile de care acesta are nevoie, sau utilitatea mesajului transmis. Toate aceste informații putând fi gestionate de implementarea EAI.
În concluzie, acest tip arhitectural este mult mai flexibil, componentele putând fi eliminate sau adăugate în funcție de nevoie, oferind în același timp un mediu de dezvoltare simplificat, unde un serviciu poate fi refolosit de mai multe aplicații.
Există două mari topologii de implementare a arhitecturii EAI , fiecare cu avantajele și dezavantajele ei.
Prima implementarea EAI de pe piață a încorporat toate funcționalitățile necesare integrării într-o componentă centrală numită broker.
Această componentă centrală, cunoscută și sub numele de Hub va folosi niște adaptoare Spokes pentru a conecta și transforma datele într-un format pe care să o înțeleagă.
Printre atribuțiile componentei hub regăsim transformarea/translatarea mesajului de intrare într-un format cunoscut de sistemul destinație și rutarea acestuia către consumatorul final.
Printre avantajele oferite de acest model găsim:
Ca orice implementare EAI, permite cuplajul slab (loose coupling) între aplicații;
Aplicațiile pot comunica asincron, transmițând un mesaj și apoi reluându-și activitatea.
Dintre dezavantaje, putem identifica:
Single point of failure, având o singură componentă centrală;
În caz de supraîncărcare a hubului central, va afecta performanța totală a sistemului;
Conform statisticilor în domeniu, acest model arhitectural a fost implementat cu succes de câteva companii, dar majoritatea proiectelor de integrare bazate pe arhitectura Hub-and-spoke a eșuat.
În urma încercărilor de a depăși problemele cauzate de folosirea modelului hub and spoke , a apărut un nou mod de implementare EAI, numit the bus. În timp ce folosește tot o componentă centrală pentru distribuirea mesajelor, acesta reușește să împartă celelalte sarcini de integrare altor componente distribuite în rețea.
Pe măsura evoluției acestui nou model arhitectural, au fost adăugate noi componente care oferă funcționalități precum: securitatea, mecanisme de înregistrare și tratare a excepțiilor, urmărire a mesajelor, etc.
Într-un final, a rezultat o arhitectură care permite dezvoltarea de soluții de integrare ușoare, fiabile și personalizate, cu un grad mare de abstractizare față de nivelul de aplicație, care urmează un model consistent și care pot fi implementate și configurate cu un efort minim, independent de aplicațiile sau sistemele pe care le conectează. Acest model arhitectural este cunoscut drept Enterprise Service Bus.
Modelul de integrare ESB are la bază arhitectura SOA oferind un mediu format din servicii distribuite care comunică între ele în rețea.
În domeniul EAI există o serie de producători de soluții ESB, iar în ciuda diferențelor dintre acestea cele mai multe oferă următoarele funcționalități de bază:
Location transparency - gestionarea într-o asemenea manieră a destinatarilor mesajelor astfel încât un consumator să nu fie nevoit să cunoască detalii despre un producător anume pentru a putea primi mesaje de la acesta.
Transformare - abilitatea de a converti mesajele într-un format care poate fi înțeles și utilizat de către destinatar;
Conversia de protocol - capacitatea de a accepta mesaje transmise prin diferite protocoale cunoscute;
Rutare - funcționalitate prin care, având la bază niște reguli predefinite, mesajele sunt transmise doar către anumiți consumatori;
Îmbogățire a mesajului - proprietatea de a putea adăuga informații extra la un mesaj existent;
Monitorizare / Administrare - o soluție ESB trebuie să poată oferi atât metode de monitorizare a performanței sistemului, cât și de administrare a resurselor și componentelor de infrastructură;
Securitate - manipularea datelor în interiorul ESB și conectarea sistemelor sau aplicațiilor la soluția de integrare, trebuie să fie făcute într-o manieră securizată.
Având în vedere capabilitățile oferite de o astfel de soluție, putem identifica următoarele avantaje:
Lightweight - fiind o arhitectură bazată pe servicii interconectate, este ușor de adaptat la nevoile specifice fiecărei arhitecturi enterprise indiferent de complexitatea acesteia.
Extensibilă - facilitează adăugarea de sisteme sau aplicații noi la infrastructura deja existentă.
Scalabilă și distribuită - având funcționalitățile împărțite pe diferite componente și servicii, acestea pot fi cu ușurință distribuite în rețea și scalate în funcție de nevoile sistemului.
Având la dispoziție detaliile prezentate mai sus, avem un punct de plecare pentru alegerea soluției de integrare potrivită nevoilor din arhitectura pe care vrem să o abordăm.
Pentru mai multe detalii despre zona de enterprise integration, ne găsiți și la:
https://www.meetup.com/Business-Integration-Community-Cluj-Napoca/
de Ovidiu Mățan
de Ovidiu Mățan
