Studiul tehnologiilor informatice de integrare a aplicaţiilor standarde utilizate la integrarea aplicaţiilor

4.5. Tehnologii informatice de integrare a aplicaţiilor

4.5.1. Tehnologia middleware

Tehnologiile care permit realizarea integrării aplicaţiilor în cadrul unei întreprinderi constituie ceea ce se numeşte în limbajul de specialitate middleware [NET17]. Cea mai bună abordare în încercarea de definire a middleware-ului este pe baza funcţiilor sale. Middleware este un mecanism care permite unei entităţi (bază de date sau aplicaţie) să comunice cu o altă entitate (sau cu mai multe entităţi). Cu alte cuvinte, middleware este un tip de software care facilitează comunicaţia între două sau mai multe sisteme software.

Deşi este un termen utilizat pentru a desemna mai multe subcategorii de tehnologii, în prezent, pentru realizarea unei aplicaţii formate din mai multe componente distribuite se utilizează cu precădere fie tehnologiile orientate-obiect reprezentate în standardele CORBA sau DCOM, fie tehnologia Java şi conceptul de componentă Java Bean. Cu ajutorul acestor tehnologii se realizează cele mai multe servere de aplicaţii din categoria celor ce trebuie să satisfacă cerinţe severe de performanţă şi disponibilitate.

Folosirea tehnologiilor middleware în cadrul integrării aplicaţiilor este posibilă datorită existenţei următoarelor două elemente:

• 
  conceptul de interfaţă care caracterizează fiecare componentă conectată la magistrala middleware şi permite descrierea ansamblului de servicii oferite de către infrastructură; în cadrul EAI, interfeţele sunt construite la nivelul adaptoarelor asociate aplicaţiilor;
  
• 
  metodologia orientată-obiect permite construirea unui model de interfeţe, care să răspundă necesităţilor utilizatorilor şi să contribuie la reducerea nivelului de complexitate necesar creării şi gestionării sistemelor distribuite [SARU00].
  

Tehnologia middleware poate fi utilizată pentru urmărirea şi administrarea ciclurilor de viaţă şi pentru asigurarea politicilor în cadrul mediilor de dezvoltare integrate.

4.5.1.1.Modele middleware

Există două modele de middleware: logic şi fizic. Modelul logic descrie cum are loc transferul de date conceptual, iar modelul fizic descrie metodele precum şi tehnologia folosite pentru transferul de informaţie. Configuraţiile asociate modelului logic sunt:

• 
  unu la unu,
  
• 
  mulţi la mulţi şi
  
• 
  sincron versus asincron.
  

Modelului fizic îi sunt asociate modele bazate pe mesaje.

Middleware unu la unu foloseşte o conexiune software temporară între două programe sau comenzi (pipe) pentru a permite unei aplicaţii să acceseze altă aplicaţie. Considerăm, spre exemplu, două aplicaţii A şi B. Când aplicaţia A încearcă să comunice cu aplicaţia B închide conexiunea folosind o procedură de apel sau un mesaj (figura 4.11).

Aşa cum sugerează numele, middleware-ul mulţi la mulţi, leagă mai multe aplicaţii între ele. Această capacitate îl face cel mai potrivit pentru integrarea aplicaţiilor. În plus, este cel mai puternic middleware logic, deoarece oferă atât flexibilitate cât şi adaptabilitate problemei integrării.

Figura 4.11. Configuraţia unu la unu

Sunt mai multe exemple de middleware mulţi la mulţi: integrare la nivel de servere, middleware tranzacţional (servere aplicaţii şi monitori TP) şi chiar obiecte distribuite. Practic, orice tip de middleware care poate să lucreze cu mai multe de două aplicaţii sursă şi destinaţie în acelaşi timp poate susţine acest model (figura 4.12).

Figura 4.12. Configuraţia mulţi la mulţi

Avantajul modelului unu la unu este simplitatea, modelul mulţi la mulţi având dezavantajul complexităţii. Această problemă este atenuată de noua generaţie de middleware.

Middleware-ul asincron face transferul de informaţie între mai multe aplicaţii în mod asincron, ceea ce presupune că software-ul middleware se poate deconecta de la aplicaţia sursă sau destinaţie. Aplicaţiile nu sunt dependente de alte aplicaţii conectate pentru procesare. Procesul care permite acest lucru are aplicaţiile plasate într-o coadă de aşteptare, fiecare cu un mesaj asociat şi fiecare rulează independent, răspunsul de la celelalte aplicaţii primindu-se mai târziu. Avantajul principal este acela că middleware-ul nu blochează celelalte aplicaţii din procesare. Mai mult decât atât, deoarece middleware-ul se decuplează de la aplicaţie, aceasta poate să continue procesarea, indiferent de stadiul celorlalte aplicaţii.

Pe de altă parte, middleware-ul sincron, este strâns cuplat la aplicaţii. Aplicaţiile sunt dependente de middleware pentru a procesa unul sau mai multe apeluri funcţie pe o aplicaţie la distanţă. Ca rezultat, aplicaţia care apelează trebuie să oprească procesarea pentru a aştepta răspunsul aplicaţiei aflate la distanţă. Acest tip de middleware este referit ca unul care “blochează”. Dezavantajul acestui model este cuplarea aplicaţiilor la middleware şi la aplicaţia la distanţă.

4.5.1.2. Tipuri de middleware

Modelele middleware au avut o evoluţie continuă încă de la apariţie, ceea ce duce la ivirea unor dificultăţi de a le încadra în anumite categorii. Cu toate acestea, se observă existenţa câtorva tipuri de middleware care se pliază foarte bine pe rezolvarea anumitor tipuri de probleme. Următoarele tipuri de middleware vor fi descrise în continuare: RPC, MOM, obiecte distribuite, middleware orientat pe baza de date, middleware tranzacţional (include monitori TP şi servere de aplicaţii) şi servere de integrare.

Remote Procedure Calls (RPC) reprezintă cel mai vechi tip de middleware, uşor de înţeles şi de folosit. Acesta oferă dezvoltatorilor capacitatea de a apela o funcţie dintr-un program şi de a o executa într-un alt program, pe o maşină la distanţă (figura 4.13). Pentru dezvoltator, funcţia se execută local, faptul că aceasta este de fapt executată pe maşina aflată la distanţă fiind ascuns.



Figura 4.13. Funcţionarea RPC

RPC sunt modele sincron de middleware. Pentru ca RPC să fie activat, execuţia programului trebuie oprită. În ciuda simplităţii, majoritatea RPC-urilor nu au o performanţă foarte bună. Cum majoritatea transferurilor de informaţie necesită o reţea, un middleware de tip RPC foloseşte toate resursele reţelei. Un RPC tipic necesită 24 de paşi distincţi pentru a îndeplini cererile. Acest nivel de performanţă limitează beneficiile unui apel RPC într-o reţea înceată, cum este Internetul.

Middleware-ul orientat pe mesaje (MOM) este un software care foloseşte mesaje, unităţi de informaţie (de tip BYTE), care sunt interschimbate de aplicaţii, ca pe un mecanism de a face transfer de informaţie de la un punct la altul. Deoarece MOM foloseşte mesajele pentru a realiza comunicarea între aplicaţii, nu este necesară cuplarea aplicaţiilor la middleware (se bazează pe modelul asincron). Mesajul intră astfel într-o coadă manager (figura 4.14), care hotărăşte când este trimis mesajul la destinaţia finală. Mesajele care se întorc la aplicaţia apelantă vor fi prelucrate când aplicaţia va fi disponibilă. Dezvoltatorii consideră ca utilizarea mesajelor MOM este destul de uşor de urmărit şi organizat.

Mesajele au o structură (schemă) şi un conţinut (date). Se pot asemăna cu o bază de date cu o singură înregistrare care se deplasează între aplicaţii printr-un mecanism de schimb de mesaje. Există două tipuri de modele MOM: unu la unu şi coadă de mesaje (Message Queue - MQ). MQ permite fiecărui program participant să lucreze fără a fi întrerupt de nivelul middleware. Deoarece software-ul MQ (seria MQ de la IBM, MSMQ de la Microsoft) gestionează distribuţia de mesaje de la un program la altul, coada manager poate optimiza performanţa folosind metode de acordare a priorităţii.

Figura 4.14. Middleware orientat pe mesaje

În vederea îndepărtării pericolului ca mesajele să se piardă atunci când are loc o cădere de sistem, majoritatea modelelor MQ permite ca mesajele să fie declarate drept persistente sau stocate pe disc la anumite intervale de timp, oferind astfel un nivel de protecţie.

Obiectele distribuite sunt clasificate ca fiind middleware deoarece facilitează comunicarea între aplicaţii. Obiectele distribuite sunt programe-aplicaţii de mici dimensiuni care folosesc interfeţe şi protocoale standard pentru comunicare. De exemplu, dacă se creează un obiect distribuit CORBA care rulează pe un sever UNIX şi un altul care rulează pe un server NT, folosind un protocol standard de comunicaţie, obiectele pot face interschimb de informaţie şi funcţii (acelaşi standard – CORBA, acelaşi protocol – IIOP (Internet InterORB Protocol)).

Există două tipuri de obiecte distribuite: CORBA şi COM (Component Object Model). CORBA este creat de OMG în 1991 şi este mai mult un standard decât o tehnologie oferind specificaţii pentru crearea unui obiect distribuit. COM este creat de Microsoft şi include interfeţe standard şi protocoale de comunicaţie.

Middleware-ul orientat pe baza de date se referă la orice middleware care facilitează comunicaţia fie cu o bază de date, fie cu o aplicaţie, fie între mai multe baze de date. Dezvoltatorii folosesc acest tip de middleware ca pe un mecanism de extragere a informaţiei dintr-o bază de date locală sau la distanţă. De exemplu, pentru a extrage informaţia dintr-o bază de date Oracle, dezvoltatorul trebuie să apeleze un astfel de middleware astfel încât să poată realiza autentificarea la baza de date, cererea de informaţie şi procesarea informaţiei care a fost extrasă din baza de date (4.15).

Middleware-ul orientat pe baza de date lucrează cu două tipuri de baze de date: CLI (Call Level Interface) şi middleware nativ pe baza de date.

CLI reprezintă API-uri comune, care oferă acces la baze de date folosind o interfaţă bine definită. De obicei, CLI lucrează cu baze de date relaţionale. Acesta este şi cazul Open DataBase Connectivity (ODBC) de la Microsoft. ODBC foloseşte o interfaţă pentru a facilita accesul la o bază de date şi drivere pentru a gestiona diferenţele dintre bazele de date. De asemenea, oferă acces simultan la baze de date multiple, arhitectura ODBC presupunând existenţa unui driver manager care să faciliteze comunicaţia între diferite baze de date.



Figura 4.15. Middleware orientat pe baze de date

Java DataBase Connectivity (JDBC) de la JavaSoft este un alt exemplu de CLI. JDBC este o interfaţă standard care foloseşte un singur set de metode Java pentru a facilita accesul la baze de date multiple. JDBC se aseamănă cu ODBC şi funcţionează de pe orice aplicaţie Java: applet, servlet, Java Server Pages (JSP), Enterprise JavaBean (EJB).

Monitorii TP sunt prima generaţie de servere de aplicaţii, la fel ca şi produsele middleware de tip tranzacţional. Acestea oferă un mecanism pentru a facilita comunicarea între două sau mai multe aplicaţii (figura 4.16), precum şi o locaţie pentru logica aplicaţiei. Exemple de TP includ Tuxedo de la BEA Systems, MTS de la Microsoft, CICS de la IBM.



Figura 4.16. Monitor TP

Monitorii TP se bazează pe tranzacţii, văzute ca unităţi de lucru cu un început şi un final. O tranzacţie are doar două stări: poate sa fie ori finalizată, ori anulată complet. În acest ultim caz, dacă tranzacţia a actualizat resurse aflate la distanţă (baze de date, cozi), aceste actualizări vor fi anulate de asemenea.

TP asigură două servicii importante. Pe de o parte, TP oferă servicii care garantează integritatea tranzacţiilor (serviciul de tranzacţie), iar pe de altă parte, un monitor TP asigură managementul resurselor şi servicii de management pe termen lung (serviciul de aplicaţie). Cele două servicii sunt ortogonale.

De asemenea, monitorii TP oferă conectori la resurse ca baze de date, alte aplicaţii sau cozi. Aceşti conectori necesită o dezvoltare de aplicaţie sofisticată pentru a comunica cu tipurile variate de resurse. Odată conectate, aceste tipuri de resurse sunt integrate în tranzacţii. Ca urmare, aceşti conectori pot fi reconstituiţi dacă apare o cădere de sistem.

Serverele de aplicaţie definesc segmentul pieţei de middleware cu cea mai rapidă evoluţie. Cu toate acestea, tehnologia serverelor de aplicaţii nu este nouă (monitorii TP pot fi consideraţi servere de aplicaţii datorită caracteristicilor comune). Majoritatea serverelor de aplicaţii sunt middleware Web şi procesează tranzacţii aparţinând aplicaţiilor Web. Noutatea acestor servere de aplicaţii este că folosesc limbaje moderne, cum este Java, în locul celor tradiţionale procedurale, cum sunt C sau Cobol (ceea ce se întâmplă la monitorii TP).

Mai simplu, serverele de aplicaţii asigură posibilitatea accesului la alte aplicaţii şi fac posibilă procesarea şi stabilirea resurselor necesare conexiunilor. Aceste resurse includ baze de date, aplicaţii ERP şi chiar aplicaţii tradiţionale de tip mainframe. Serverele de aplicaţii oferă interfeţei utilizator mecanisme de dezvoltare. În plus, în cele mai multe cazuri oferă şi mecanisme de amplasare a aplicaţiilor pe platforma Web (4.17).

Figura 4.17. Arhitectura unui server de aplicaţie tipic

Producătorii de servere de aplicaţii consideră că produsele lor au o tehnologie ce permite rezolvarea problemelor de integrare a aplicaţiilor. Ca urmare, serverele de aplicaţie, ca şi monitorii TP, joacă un rol important în domeniul integrării aplicaţiilor. Mulţi dintre producători încorporează tehnologii de gestiune a mesajelor, transformare şi rutere inteligente, servicii care sunt native serverelor de integrare.

Serverele de integrare reprezintă partea de vârf a tehnologiei middleware pentru integrarea aplicaţiilor sau cel puţin potenţialul acesteia. Serverele de integrare pot facilita schimbul de informaţie între două sau mai multe aplicaţii sursă sau destinaţie şi pot face diferenţa între semanticele aplicaţiei şi platforme. Ca urmare, această tehnologie se potriveşte perfect cu integrarea aplicaţiilor.



Figura 4.18. Servere de integrare

Serverele de integrare pot apărea în multe aplicaţii folosind reguli comune şi motoare de rutere. Ele pot transforma schema şi conţinutul informaţiei pe durata transferului între aplicaţii şi baze de date.

Serverele de integrare sunt servere care gestionează mesaje între două sau mai multe aplicaţii sursă sau destinaţie. În plus, aceste servere transformă schemele de mesaje şi modifică conţinutul mesajelor. Serverele de integrare pot avea într-adevăr funcţii adiţionale, incluzând un motor şi o interfaţă de integrare a proceselor, precum şi un mecanism de management.

Importanţa serverelor de aplicaţii este stabilită în funcţie de poziţia ocupată de acestea în cadrul companiei. În general, după cum este evidenţiat şi în figura 4.18, serverele de integrare nu sunt o tehnologie de dezvoltare a aplicaţiilor ci mai degrabă una care permite comunicarea între mai multe aplicaţii, fără să presupună existenţa unui schimb de informaţii despre natura aplicaţiilor între care se face schimbul de date. Pe scurt, serverele de integrare gestionează informaţia între baze de date şi aplicaţii.