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

4.4. Arhitecturi utilizate în integrarea aplicaţiilor

4.4.1. Arhitectura orientată pe servicii

Arhitectura orientată pe servicii (Service-Oriented Arhitecture - SOA) exprimă un concept de arhitectură software ce presupune folosirea serviciilor Web disponibile în scopul satisfacerii cerinţelor utilizatorilor de software. Un sistem SOA poate fi implementat în multe moduri, folosind o varietate de instrumente şi tehnologii. Tehnologia serviciilor Web, care constituie baza SOA, a fost adoptată de marea majoritate a jucătorilor din industria de software: IBM, Microsoft, Sun Microsystems, SAP, Oracle şamd.

O platforma completă de tip SOA permite integrarea aplicaţiilor de întreprindere, realizându-se astfel implementarea simplă a proceselor de afaceri în cadrul companiilor. Într-un mediu SOA, nodurile dintr-o reţea asigură disponibilitatea resurselor ca servicii independente, pe care utilizatorii le accesează într-un mod standardizat.

SOA implică mai mult decât conexiunile dintre serviciile Web sau setul de componente de afaceri ce ar urma să fie livrat şi care ar putea funcţiona împreună. SOA determină, de fapt, obţinerea de beneficii gestionând proceselor de afaceri cu ajutorul aplicaţiilor existente. SOA reprezintă viitorul serviciilor IT, o arhitectură orientată pe servicii permiţând integrarea tuturor resurselor IT, inclusiv a aplicaţiilor create prin tehnologii .NET sau Java.

Orientarea pe servicii reprezintă o nouă metodă pentru proiectarea sistemelor distribuite. Conceptele principale folosite în cadrul acestei abordări sunt:

• 
  serviciu: unitate independentă a unei aplicaţii care expune funcţionalitatea către clienţii din reţea prin intermediul unei interfeţe bazate pe mesaje;
  
• 
  client: un modul al unei aplicaţii care facilitează accesul utilizatorilor la funcţionalitatea oferită de servicii;
  
• 
  sistem distribuit: un sistem interconectat de servicii şi clienţi.
  

Sistemele orientate pe servicii sunt sisteme slab cuplate, proiectate pentru a permite schimbarea pentru adaptarea la noi cerinţe sau metode de implementare. Prin utilizarea modelului orientat pe servicii este posibilă obţinerea unei interoperabilităţi între aplicaţii, indiferent de platformele şi limbajele de programare utilizate în dezvoltarea acesteia. Dezvoltatorii de aplicaţii nu au nevoie să cunoască tipul de sistem, modelul de obiecte sau protocoalele folosite de către sistemele care trebuie integrate. Expunerea funcţionalităţii folosind protocoale standardizate şi interfeţe care pot fi obţinute dinamic conduce la o cuplare slabă între subsisteme, permiţând astfel o conectare simplă şi asigurând o flexibilitate sporită aplicaţiei.

Implementarea SOA necesită o serie de componente, precizate detaliat în [NET09]. Pe scurt, aceste componente sunt:

• 
  serviciile de afaceri (Business Services): în mod normal, primul pas spre SOA este adoptarea serviciilor web. Acest lucru presupune expunerea aplicaţiilor şi a sistemelor deja existente prin intermediul interfeţelor bazate pe standarde;
  
• 
  resgistrul (Registry): sistemul de înregistrări al unei SOA ce furnizează o modalitate de administrare a serviciilor de afaceri. Un registru reţine descrierea detaliată a unui serviciu SOA şi utilizează informaţia respectivă într-un serviciu de afacere de tip Registry;
  
• 
  managerul de politici (Policy Manager): produs bazat pe standarde ce simplifică procesul de creare, administrare şi standardizare a politicilor necesare oricărei afaceri;
  
• 
  consola de adminostrare (Management Console): soluţie de management ce permite utilizatorilor să monitorizeze, să administreze şi să securizeze serviciile Web sau procesele SOA în totalitate, dar şi să asigure managementul eficient al sistemelor “fragile” din punct de vedere tehnologic;
  
• 
  translatoare de mesaje: module software aşezate înaintea oricărui serviciu astfel încât serviciile interne să poată fi accesate în limbajul nativ al sistemului în cauză şi în acelaşi timp în acelaşi limbaj pe ansamblu, de obicei XML, ca orice alt serviciu din reţea.
  

La început, această tehnologie nu era dominată, în aparenţă, de o tendinţă anume. Instrumentele de integrare nu erau diferenţiate: exista unul singur pentru toate conexiunile. Pe măsură ce conceptul SOA a evoluat, arhitectura s-a divizat în categorii cu însuşiri diferite. La cel mai înalt nivel acestea sunt:

• 
  aplicaţii fizice: programele care duc la bun sfârşit sarcinile;
  
• 
  servicii directoare: separă procesele de afaceri;
  
• 
  sincronizarea datelor: componentă folosită la construirea şi întreţinerea conexiunilor de date;
  
• 
  nivelul de procese de afaceri, care utilizează serviciile pentru a acoperi procesele specifice afacerii.
  

Aceste componente au funcţii şi structuri diferite, de aceea se recomandă folosirea de tehnologii separate.

Un principiu fundamental al SOA se referă la faptul că serviciul furnizat prin intermediul unei interfeţe trebuie să rămână acelaşi, până la identitate, independent de implementare. Un serviciu de “detalii client”, de exemplu, trebuie să furnizeze aceeaşi funcţie economică independent de faptul că implementarea obiectului economic este realizată într-o singură componentă partajată, peste mai multe platforme şi sisteme anterior în funcţie, sau furnizată de la un partener comercial prin Internet.

Tehnologiile de livrare a aplicaţiilor întrebuinţate ulterior fac ca această transparenţă să devină o problemă dificilă. Serviciile de apelare care sunt implementate în diferite tehnologii nu sunt directe, iar cuplarea strânsă a interfeţelor are ca semnificaţie afectarea acestora (prin modificare lor) odată ce a apărut o schimbare în implementarea componentei. Schimbarea (modificarea) componentelor are ca efect, de asemenea, schimbări în ceea ce priveşte aplicaţiile de apelare, anulând astfel anumite beneficii aşteptate de la proiectarea bazată pe componente.

Spre deosebire de arhitecturile tradiţionale orientate-obiect (object-oriented), SOA cuprinde servicii cuplate, dar independente, puternic interoperabile. Deoarece aceste servicii operează pe diferite platforme de dezvoltare (Java sau .NET), componentele software devin reutilizabile (de exemplu, un serviciu C# ar putea fi folosit de o aplicaţie Java sau alt limbaj de programare), datorită faptului că interfaţa a fost definită ţinându-se cont de standarde (Web Services Description Language - WSDL) din domeniu, care încapsulează (ascund) implementarea specifică faţă de client/serviciu.

O caracteristică fundamentală a arhitecturii propuse este separarea definirii proceselor de integrarea back-end, separare ce permite analiştilor să se concentreze asupra dezvoltării soluţiilor pentru probleme specifice. Prin această separare, este asigurată o arhitectură de tip “plug-and-play”, un nivel de separare ce sigură schimbarea sistemelor de tip back-end fără schimbarea proceselor [NET18].

Arhitectura orientată pe servicii a fost dezvoltată pentru a soluţiona problemele legate de integrare şi automatizarea proceselor interne şi externe cu alte companii sau parteneri în reţea. Scopul final este de a avea o arhitectură IT care acoperă în mod optimal cerinţele prezente şi viitoare, respectiv integrarea internă EAI şi externă G2B, G2C, G2G, WebServices.

Arhitectura conceptuală îndeplineşte o serie de criterii pentru validarea ulterioară a conceptelor, tehnologiei şi produselor, care asigură:

• 
  integrarea tuturor funcţiilor relevante şi a proceselor;
  
• 
  integrarea sistemelor existente în noua platformă, asigurând protecţia investiţiilor;
  
• 
  minimizarea riscului, reacţie rapidă la schimbarea cerinţelor;
  
• 
  complexitate redusă prin construirea unei interfeţe bazate pe servicii specifice integrate în sistem;
  
• 
  utilizarea standardelor XML, XSL, SOAP, UDDI, WSDL şi HTTP;
  
• 
  flexibilitate;
  
• 
  abilitatea de extindere în conformitate cu necesităţile – scalabilitate;
  
• 
  reducerea costurilor şi creşterea productivităţii prin transferul rapid al aplicaţiilor de pe orice platformă.
  

Prin procese de afaceri construite pe o arhitectură orientată pe servicii, o companie poate exploata aplicaţiile software existente, astfel încât să atingă un grad superior de interoperabilitate nu doar între toate departamentele firmei ci şi cu alte companii. Această abordare valorifică resursele existente pentru a ajuta la îmbunătăţirea productivităţii, permiţând astfel companiei să reacţioneze rapid la schimbările intervenite pe piaţă, fructificând astfel oportunităţile de afaceri.
Beneficiile arhitecturii orientate pe servicii

O arhitectură orientată pe servicii conţine servicii web pe care dezvoltatorii le creează într-un nivel de servicii specific. Serviciile pe care aceştia le dezvoltă dispun de interfeţe publicate, ce se adresează unei anumite zone de afaceri. Organizaţiile care îşi concentrează eforturile pe integrarea de servicii, vor avea parte de numeroase beneficii.

Recuperarea rapidă a investiţiilor. Un nivel de servicii robust are avantajul unei recuperări rapide şi substanţiale a investiţiilor aduse în construirea componentelor software. Serviciile individualizează domeniile distincte ale afacerii. De exemplu, o companie creează un serviciu ce dispune de toate metodele necesare pentru a administra stocurile. Aşezând logica afacerii (datele) într-un nivel separat, acesta poate exista independent de orice alt sistem în care este integrat. Un alt exemplu se poate referi la nevoia unei organizaţii de a crea un serviciu pentru autorizarea cărţilor de credit. Dezvoltatorii vor introduce funcţionalitatea respectivă în aplicaţia care are nevoie de ea sau într-o componentă independentă.

Mobilitatea codului. Deoarece transparenţa locaţiei este o proprietate a arhitecturii orientate spre servicii, mobilitatea codului devine realitate. Conectarea dinamică la un serviciu înseamnă că activitatea utilizatorului nu este influenţată de locaţie (a lui sau a serviciului pe care îl foloseşte). De aceea, o organizaţie are flexibilitatea necesară pentru a muta servicii pe o maşină diferită sau către un furnizor extern.

Funcţionalităţi specializate pentru dezvoltatori. Arhitectura orientată spre servicii va forţa aplicaţia să fie organizată pe mai multe niveluri, fiecare cu un rol specific pentru dezvoltatori. Un dezvoltator de aplicaţii client trebuie să cunoască tehnologii precum SWING, JSP sau .NET. Fiecare nivel necesită un set complex de cunoştinţe. Având aceste delimitări de specializare, dezvoltatorii vor excela în domeniul particular în care activează. Companiile vor avea la rândul lor de câştigat, nefiind nevoite să mai apeleze la specialişti cu o bogată experienţă în dezvoltarea de aplicaţii.

Securitate mărită. Crearea unui nivel de servicii înseamnă de fapt construirea unei interfeţe de reţea adiţională ce poate fi folosită de mai multe aplicaţii. Când sistemele erau construite prin metode monolitice sau client-server, problema securităţii era abordată în front-end. De multe ori companiile nu mai implementau componente de securitate din cauza cheltuielilor de întreţinere. Pe de altă parte, serviciile sunt folosite de multe aplicaţii, aşa că dispun de propriul mecanism de securitate. De aceea fiecare program va avea mai multe niveluri de autentificare pentru aplicaţia client de serviciu.

Teste superioare - mai puţine erori. Dezvoltatorii au la dispoziţie instrumente precum JUnit pentru crearea de teste. Acestea pot fi rulate pentru a valida serviciul, independent de orice aplicaţie care îl foloseşte. O practică foarte bună este aplicarea de teste în timpul unui proces automat. Mai multe teste înseamnă, de obicei, mai puţine erori şi o creştere pe ansamblu a calităţii.

Suport pentru mai multe tipuri de clienţi. Un alt beneficiu al SOA este posibilitatea companiilor de a folosi o varietate de clienţi pentru accesarea unui serviciu. Un PDA ce foloseşte J2ME poate accesa un anumit serviciu prin HTTP, iar un client SWING poate accesa acelaşi serviciu via RMI. Având în vedere faptul ca nivelurile de aplicaţii client sunt separate de servicii, noi tipuri de clienţi pot fi implementaţi cu uşurinţă.

Asamblarea serviciilor. Utilizatorii vor ajunge să înţeleagă serviciile ca pe nişte bunuri refolosibile, ce pot fi combinate într-o multitudine de moduri. Utilitatea va consta în dezvoltarea mai rapidă de noi aplicaţii.

Mentenanţă superioară. Prin orientarea spre servicii, ca locaţie a logisticii, operaţiunile de mentenanţă se îmbunătăţesc deoarece dezvoltatorii pot localiza defectele de cod mai uşor.

Scalabilitate. O cerinţă importantă pentru arhitecturile orientate spre servicii este transparenţa locaţiei. Pentru a obţine aceste lucru, aplicaţiile caută servicii într-un director şi se conectează la ele dinamic. Această situaţie caracterizează scalabilitatea, întrucât cererile de conectare pot fi înaintate fără intervenţia clientului de serviciu.

Fără îndoială instalarea unui nivel de servicii presupune un efort suplimentar la începutul proiectului, dar beneficiile pe termen lung sunt evidente.

4.4.2. Oracle Application Integration Architecture

Oracle Application Integration Architecture (OAIA), arhitectură lansată în aprilie 2007, oferă procese de afaceri care leagă compartimentele operaţionale, crescând eficienţa costurilor şi reducând ciclul de viaţă. Oracle oferă soluţii prefabricate de integrare a proceselor, suport şi optimizări pe parcursul acestor integrări, implementând şi utilizând cele mai bune practici de afaceri pentru conectarea şi optimizarea operaţiilor afacerii.

Avantaje oferite:

• 
  soluţii prefabricate de integrare care reduce costul integrării sistemelor şi minimizează riscurile;
  
• 
  cele mai bune practice de afaceri bine documentate sunt disponibile pentru integrare în aplicaţiile existente;
  
• 
  arhitectură deschisă, bazată pe standarde.
  

OAIA se bazează pe facilităţile oferite de Oracle Fusion Middleware, şi include metodologia şi instrumentele din SOA, împreună cu un depozit de servicii de afaceri (Business Service Repository) care permite dezvoltarea sau extinderea aplicaţiilor.

4.4.3. Enterprise Services Architecture

Enterprise Services Architecture (ESA) este interpretarea pe care SAP a dot-o unei arhitecturi SOA care extinde conceptul de serviciu Web, înlocuindu-l cu conceptul propriu de serviciu al întreprinderii (enterprise service). Din punct de vedere tehnic, serviciile de întreprindere se bazează pe servicii Web, oferind acces la elementele şi funcţiile afacerii în termeni economici. Utilizarea serviciilor de întreprindere în cadrul aplicaţiilor conduce la o creştere a flexibilităţii, deschiderii si vitezei.

Bazate pe standarde deschise, serviciile de întreprindere încapsulează funcţionalităţile întreprinderii şi le expune ca servicii reutilizabile, care pot fi apoi combinate cu alte servicii pentru a răspunde unor cerinţe noi. Serviciile de întreprindere pot fi rapid combinate pentru a compune noi aplicaţii şi a sprijini noi procese de afaceri.

Aceste servicii pot comunica logica de afaceri între aplicaţii care rulează pe platforme disparate. Utilizând aceste servicii, se poate răspunde mai rapid la schimbările care apar în cadrul firmelor, şi se pot reduce costurile prin reutilizarea fucţionalităţilor deja existente.

Organizaţiile pot adopta această arhitectură prin implementarea platformei SAP NetWeaver®. SAP are chiar un program de adoptare SOA, prin care asistă organizaţiile doritoare la elaborarea şi implementarea planului de adoptare SOA. SAP oferă atât soluţiile software orientate pe servicii, cât şi platforma tehnologică SAP Netweaver şi asistenţă altor companii care doresc să îşi dezvolte propriile arhitecturi orientate pe servicii, pentru soluţii SAP şi non-SAP.