Integrarea Aplicatiilor Informatice Prin Servicii Utilizand Metodologia Soa

LUCRARE DE DISERTAȚIE

Integrarea aplicațiilor informatice prin servicii utilizând metodologia SOA

Cuprins

1. Introducere

1.1 Motivare

1.2 Obiective

1.3 Structura

2. SOA – concepte și principii

2.1 Evoluția sistemelor de calcul

2.2 Dezvoltarea orientată obiect

2.3 Dezvoltarea orientată pe componente

2.4 Sisteme distribuite

2.4.1 Apelul procedurilor la distanță (RPC)

2.4.2 Obiecte distribuite

2.4.3 Middleware orientat pe mesaje (MOM)

2.5 Arhitectura orientată pe servicii (SOA) – Definiție

2.5.1 Entitățile și caracteristicile SOA

2.5.2 Dezvoltarea orientată pe servicii

2.5.3 Stratificarea arhitecturii SOA

2.6 Tehnologii pentru arhitecturii orientate pe servicii

2.6.1 J2EE

2.6.2 COM/DCOM

2.6.3 CORBA

2.6.4 Servicii Web

2.6.5 Compararea tehnologiilor pe baza specificațiilor

3. Implementarea prototipului unei infrastructuri conforme cu metodologia SOA

Concluzii

Bibliografie

Introducere

Încă din perioada de început a dezvoltării unităților de calcul până în timpul prezent cunoscut ca Era Tehnologiei Informației, arhitecturile software au evoluat rapid pentru a permite realizarea de structuri sofisticate de aplicații informatice capabile nu doar să îndeplinească funcțiile de bază așteptate de la fiecare sistem de calcul, ci să influențeze din punct de vedere al eficienței viață oamenilor prin creșterea randamentului activității societăților, transformarea acestora în ecosisteme agile ce se pot adapta rapid într-un mediu dinamic, eficienței operaționale și inovației ce au ca rezultat utilizarea de funcționalități și servicii de aplicații universale, comune. Arhitectura bazată pe servicii (SOA) oferă această viziune pentru a face față complexității tehnice specifice dezvoltării și integrării aplicațiilor pentru întreprinderi precum și alinierea nevoilor de afaceri și furnizarea de funcționalități pentru procesele de afaceri cu un grad crescut de control asupra specificațiilor acestora.

Arhitectura bazată pe servicii (SOA) reprezintă un stil de proiectare arhitecturală și o combinație de metodologii care vizează realizarea interoperabilității aplicațiilor situate la distanță sau locale, omogene sau eterogene prin folosirea de servicii cu logică reutilizabilă. Orientarea pe servicii prezintă variații în adoptarea tehnologiei de punere în aplicare, mai degrabă decât să se concentreze pe tehnologia de implementare propriu-zisă metodologia SOA consideră descrierea domeniului problemei înainte de implementarea concretă pe baza unei platforme specifice.

Deși SOA nu impune în mod direct o anumită tehnologie și a fost aplicată pentru dezvoltarea de software înainte de inventarea serviciilor Web, arhitecturile capabile să îndeplinească viziunea SOA într-un mod mult mai fidel sunt construite cu tehnologii pentru servicii Web. Motivate de aceste tehnologii competente, întreprinderile folosesc standarde deschise pentru comunicarea în rețea, mesaje și descrierea interfețelor serviciilor. Implementarea SOA prin servicii Web reprezintă la acest moment soluția cea mai avantajoasă, deoarece serviciile Web aduc îmbunătățiri fundamentale în dezvoltarea de aplicații bazate pe metodologia SOA.

Este necesar să se urmeze noi abordări și metodologii specifice, atunci când se proiectează structura unei aplicații bazate pe servicii în detrimentul abordărilor tradiționale de dezvoltare de software. SOA are nevoie de strategii de dezvoltare unice, care să înlocuiască abordările convenționale pentru construirea de arhitecturi software, promițând dezvoltarea de structuri de aplicații de tip plug-and-play și module capabile să exprime funcționalități de afaceri clare specifice domeniului problemei date.

SOA oferă o disciplină arhitecturală puternică și o zonă de focalizare centrată pe crearea, modelarea și dezvoltarea serviciilor, definirea informațiilor de proces, stabilirea strategiilor și abordărilor pentru integrarea orientată pe servicii. Serviciile sunt pietrele de temelie ale SOA iar noile aplicații pot fi construite prin consumul acestor servicii și orchestrarea acestora într-un proces de afaceri. Acestea sunt unități reutilizabile ce îndeplinesc funcționalități comune de afaceri și tehnologie.

Pentru a pune în aplicare un SOA de succes în întreprinderi, presupune luarea în considerare a diferitelor concepte și strategii de implementare ce formează caracteristicile esențiale ale întreprinderii orientate pe servicii. O implementare SOA completă reflectă nu numai asupra dezvoltării de servicii, ci și asupra posibilității de a le utiliza pentru a integra diverse elemente de logică a aplicațiilor și construirea de aplicații compozite.

Fig.1.1 Arhitectura orientată pe servicii în cadrul întreprinderii

După implementarea cu succes a SOA, întreprindere beneficiază prin reducerea timpul de dezvoltare, utilizând structuri de aplicații flexibile și adaptabile ce furnizează un grad ridicat de conectivitate dinamică a logicii aplicațiilor între partenerii de afaceri.

Motivare

SOA aduce o abordare evolutivă în dezvoltarea de software, cu toate acestea, se introduc multe concepte distincte și metodologii care trebuie să fie definite și explicate pentru a înțelege beneficiile SOA într-un mod precis cu scopul construirii unei arhitecturi competente ce îndeplinește viziunea SOA. Principala problemă este analiza și evaluarea diferențelor SOA față de stilurile arhitecturale cu o vechime apreciabilă aplicate pe scară largă în dezvoltarea de sisteme software, identificarea îmbunătățirilor pe care SOA le aduce implementării și aplicarea acestor cunoștințe în dezvoltarea de aplicații ce folosesc servicii astfel încât să se obțină o implementare ce corespunde cât mai fidel specificațiilor SOA.

În primul rând, este necesar să se înțeleagă în mod clar ce este SOA și caracteristicile fundamentale ale orientării pe servicii. Din moment ce SOA este un concept independent de orice tehnologie de implementare ce se concentrează pe definirea aspectelor arhitecturale ale aplicațiilor inclusiv modelarea și proiectarea serviciilor și proceselor, se observă diferite variante de implementare SOA în cadrul întreprinderilor. În special, în zilele noastre SOA se aplică prin servicii Web ca metodă derivată din implementările inițiale realizate cu ajutorul tehnologiilor CORBA, COM / DCOM și RMI.

Logica de programare tradițională se concentrează în special pe dezvoltarea interfeței cu utilizatorul, prelucrarea unei baze de date sau executarea unei tranzacții, cu toate acestea, SOA oferă o zonă extinsă de operabilitate incluzând fluxul de proces și de integrare orientată pe servicii care în cele din urmă ajunge la dezvoltarea unei logici singulare, unificate a aplicației, ce poate include diferite servicii și aplicații din cadrul întreprinderii și își propune să rezolve o problemă de afaceri specifică domeniului și să ofere pe scară largă funcționalități concrete unitare.

Este evident că dezvoltarea de aplicații bazate pe servicii este mai dificilă decât dezvoltarea unei aplicații tradiționale având cerințe specifice; pentru a înțelege SOA într-un mod eficient, este necesar a înțelege ce reprezintă acest stil arhitectural, investigarea informațiilor ce trebuie să fie incluse în modelul arhitectural al unei soluții orientate pe servicii și analizarea scenariilor posibile de implementare.

Obiective

În principal, acestă lucrare introduce elementele de bază ale SOA luând în considerare restul aspectelor necesare pentru orientarea pe servicii, inclusiv principiile de arhitectura, design și modelare de servicii și strategiile pentru construirea de aplicații de tip întreprindere prin combinarea serviciilor individuale pentru a forma o infrastructură SOA.

Vom aborda SOA tratând următoarele aspecte:

Aplicațiile orientate pe servicii necesită o abordare diferită a modelului arhitectural. Este necesară descrierea și clarificarea aspectelor precum; ce este SOA, relațiile dintre SOA și alte arhitecturi și abordări de dezvoltare, precum și cerințele SOA cu scopul de a demonstra modul în care arhitectura poate fi aplicată în dezvoltarea de aplicații software.

Este necesară demonstrarea principiilor de bază și a conceptelor dezvoltării de aplicații bazate pe servicii prin conceperea și implementarea unui studiu de caz prototip.

Structura

Capitolul următor reprezintă o introducere a arhitecturii orientate pe servicii(SOA). Diferite modele de dezvoltare software și stiluri arhitecturale vor fi discutate și comparate cu dezvoltarea bazată pe servicii. SOA va fi explicată în detaliu în această parte prin definirea entităților, caracteristicilor și arhitecturii stratificate.

În continuarea acestei lucrări ne vom axa pe tehnologiile de implementare a arhitecturii orientate pe servicii. Fiecare tehnologie va fi descrisă și comparată cu scopul de a identifica avantajele aduse în dezvoltarea și implementarea de aplicații bazate pe servicii.

După care ne vom concentra pe principiile de dezvoltare a aplicațiilor bazate pe servicii prin demonstrarea proiectării și punerii în aplicare a unui studiu de caz prototip.

Încheind cu un rezumat al lucrării ce va prezenta perspective viitoare ale arhitecturii orientate pe servicii.

SOA – concepte și principii

Dezvoltarea de software devine din ce în ce mai provocatoare din punct de vedere al complexității datorită creșterii nevoilor și cerințelor de a dispune de infrastructuri complexe capabile să rezolve probleme din viața reală. În mod similar, îmbunătățirile tehnologice, prin multitudinea de tendințe și alternative încurajează construirea de arhitecturi combinate pentru dezvoltarea de sisteme software.

Arhitectura software descrie infrastructura sistemului software prin descompunerea acestuia în componente și interacțiunile la nivel înalt între fiecare dintre acestea. Componentele sunt module abstracte construit ca o "unitate" pe baza altor componente. Interacțiunile la nivel înalt între componente sunt numite "conectori". Configurația componentelor și conectorilor descrie modul în care un sistem este structurat și se comportă, figura 2.1.

Fig. 2.1 Definiția abstractă a arhitecturii software

Arhitectura software a unui program sau sistem de calcul reprezintă structura sau structurile sistemului ce cuprind componentele software, proprietățile vizibile ale acestor componente, precum și relația dintre ele. Pentru a simplifica complexitatea arhitecturală în mod convențional, sistemul este construit din module ce implică funcții, obiecte, componente și servicii.

Cu toate acestea, din zilele de început ale informaticii până în prezent, în așa zisa era a tehnologiei informației, dezvoltare de software a trecut prin anumite etape ce au extins domeniul implementării de aplicații de la micile departamente la nivelul întreprinderi și în cele din urmă în Internet. Aceste etape au modelat arhitectura sistemelor software având ca rezultat obținerea de software mai puternic, mai capabil și mai eficient ce își propune să răspundă așteptărilor complexe din cadrul sistemelor de calcul.

Arhitectura orientată pe servicii (SOA) reprezintă un tip de arhitectura software cu trăsături și caracteristici distincte. Conceptul SOA a apărut la începutul anilor 1980 și a devenit un stil arhitectural semnificativ mai ales după apariția serviciilor Web. Înainte de a examina arhitectura în detaliu, este important să prezentăm conceptele de dezvoltare de software și tehnologiile aferente existente, pentru a evidenția progresul evolutiv adus de SOA, eliminând în acest fel ideea că arhitectura de tip SOA este una fără fundamente în tehnologiile cu o vechime considerabilă în activitate.

Evoluția sistemelor de calcul

Îmbunătățirile în tehnologiile hardware și în special a invenției rețelelor au încurajat dezvoltatorii de software să obțină mai multe beneficii de la echipamentele hardware și să construiască sisteme software complexe ce au la bază aceste tehnologii.

Rețelele au evoluat de la câteva mașini conectate la resurse de calcul enorme interconectate prin intermediul Internetului. În consecință, complexitatea, dimensiunea și puterea de calcul a sistemelor au dus la transformarea programelor cu structură monolitică la infrastructuri de calcul distribuit. Pe baza acestor tendințe emergente în domeniul tehnologiilor de calcul, dezvoltatorii și arhitecții au trebuit să-și reînnoiască viziunile, să înlocuiască abordările vechi de dezvoltare de aplicații trecând la abordări noi ce permit utilizarea corespunzătoare a noilor tehnologii emergente.

Primele abordări ale sistemelor de calcul au început cu mainframe-uri închise cu structură monolitică. Aplicațiile monolitice au fost consecința evoluției sistemelor cu un singur procesor în care prelucrarea și gestionarea datelor era complet centralizată.

Dezvoltarea procedurală reprezintă metoda inițială de dezvoltare a aplicațiilor și presupune execuția procesului pe o singură mașină și manipularea datelor prin operații de acces direct așa cum se arată în figura 2.2. Această metodă poate duce la apariția dependențelor între algoritmii programului ceea ce face ca modificările ulterioare să nu fie un proces tocmai facil. În cazul în care reprezentarea datelor este modificată, pot apărea efecte substanțiale asupra programului în locuri multiple .

Fig. 2.2 Dezvoltarea de software utilizând metoda procedurală

FORTRAN, COBOL, C, Pascal și BASIC sunt limbaje utilizate pentru dezvoltarea de software pe baza paradigmei procedurale. Pentru a dezvolta o aplicație cu aceste limbaje este necesară cunoașterea detaliată a mediului de stocare al datelor. O altă dificultate este reprezentată de faptul că, deși dezvoltatorii au implementat biblioteci partajate de cod și descompuneau structura aplicației în module, programul încă prezenta multe dependențe în interiorul său iar schimbările erau greu de administrat și izolat.

Dificultățile cu care se confrunta dezvoltarea de software procedural au dat naștere unei noi abordări ce implica descompunere proceselor complexe în subprocese mai mici așa cum este ilustrat în figura de mai jos (Fig. 2.3).

Proiectare și dezvoltare structurată reducea complexitatea programului prin proiectarea de module mici ce pot fi reutilizate în cadrul aplicației. În acest fel, aspectul de date al programului și partea de comportament erau separate în mod semnificativ.

Proiectare structurată a permis elaborarea de structuri de aplicații mai flexibile și mai complexe decât dezvoltare de software prin metoda procedurală, cu toate acestea, dependențele încă prezente între modulele individuale și date sunt mari pentru a permite construirea unui sistem software eficient.

Fig. 2.3 Dezvoltarea de software utilizând metoda structurată

Abordare client-server reprezintă o evoluția a tehnicilor de dezvoltare software, în care accentul este pus pe construirea de sisteme de aplicații individuale. Designul implică separarea clientul și logicii aplicației de purtătorul datelor, serverul, atât logic cât și fizic. Un factor important în dezvoltarea de software de tip client-server îl reprezintă faptul că acestă abordare permite utilizatorului să prelucreze date prin intermediul unei conexiuni de rețea. Tehnologia a dus la evoluția sistemelor de file-sharing, ce încă sunt folosite pentru a accesa sistemele de fișiere globale disponibile prin intermediul unor protocoale specifice cum ar fi HTTP, și a tehnologiilor serverelor de baze de date. Aceste evoluții sunt în strânsă corelație cu progresul tehnologiilor de calcul distribuit.

În această perioadă au fost dezvoltate monitoarele de procesare a tranzacțiilor pentru a oferi consecvență, securitate și integritate datelor din sistemele distribuite. O altă dezvoltare a sfârșitului anilor 1980 și începutul anilor 1990 este reprezentată de tehnologiile groupware ce ofereau serviciul de e-mail și forme superioare de aplicații interactive cum ar fi camerele de chat și video-conferințe.

Pornind de la începutul anilor 1990, necesitatea de a permite separarea clară a datelor și a logicii aplicației de interfața acesteia a provocat înlocuirea tehnologiilor de tip client-server cu soluții N-tier orientate pe componente. Nivelurile suplimentare reduceau cuplajul între module și permiteau mai multor clienți să acceseze și să utilizeze nivelul de logică al sistemului, așa cum se arată în figura 2.4.

Fig. 2.4 Dezvoltarea de software utilizând metoda client-server și N-tier

Prima abordare de dezvoltare de software este specifică în principal furnizorilor privați de soluții software aceștia având control asupra fiecărui pas al dezvoltării produsului. Aceste soluții sunt denumite soluții proprietare iar în cea mai mare parte depind în totalitate de furnizorul lor. Sistemele actuale se bazează pe software proprietar în grade diferite. Capacitățile

și calitatea software-ului proprietar pot fi ridicate datorită îmbunătățirii continue și adăugării de caracteristici în conformitate cu așteptările utilizatorului final de către furnizorul soluției software.

Cealaltă categorie majoră de software comercial este reprezentată de software-ul open source, o abordare pentru dezvoltarea de software în care mai mulți furnizori colaborează pentru a construi specificațiile tehnologie independent de software-ul proprietar. Principalul beneficiu al software-ului open source este reprezentat de terminologia uniformă de descriere a structurii soluției, caracteristică fundamentală pentru construirea unei tehnologii standard adecvate pentru utilizatorii finali. Un beneficiu suplimentar este interoperabilitatea pe care o poate furniza între aplicații software diferite.

Odată cu apariția World Wide Web, o nouă eră a dezvoltării software este în desfășurare. Internetul a început inițial ca o modalitate de a publica lucrări științifice și a evoluat în HTML dinamic (Hypertext Markup Language), și în cele din urmă la XML (Extensible Markup Language), un meta-limbaj și o tehnologie fundamentală, standard, ce permite schimbul de date între diferite platforme.

XML descrie datele într-un mod independent de aplicațiile client, iar serviciile Web utilizează această tehnologie pentru a permite schimbul de date între procese distribuite pe medii de calcul eterogene. Astăzi dezvoltarea de aplicații presupune crearea de servicii independente, accesibile și controlate prin intermediul firewall-ului ce furnizează o funcție discretă. Clienții interacționează cu serviciile, ce sunt asamblate pentru a construi infrastructura aplicațiilor.

Fig. 2.5 Evoluția fizică a sistemelor de calcul

Dezvoltarea orientată obiect

Dezvoltare orientată obiect permite obținerea de software prin încapsulare atât a datelor cât și a comportamentului în tipuri de date abstracte numite clase. Instanțe ale acestor clase se materializează în module mici denumite obiecte, așa cum se arată în figura 2.6. Orice modificare a reprezentării datelor afectează doar obiectele ce încapsulează datele respective. Clasele au o durată de viață nelimitată, însă obiectele au o durată de viață limitată.

Fig. 2.6 Dezvoltarea orientată obiect

Obiectele comunică între ele prin mesaje. Dezvoltarea bazată pe obiecte aduce un plus modelarii software prin ascunderea comportamentului și a datelor prin intermediul obiectelor ca elemente fundamentale de construcție a sistemelor software. Nu există aproape nici o dependență între obiecte, totuși, un număr mare de obiecte interconectate creează dependențe ce pot fi dificil de gestionat.

În dezvoltarea orientată obiect, totul este un obiect. Caracteristicile principale ale paradigmei orientate obiect sunt:

Încapsularea: Un obiect conține atât proprietățile fizice, numite date, cât și funcționalitatea acestor date, descrisă ca un comportament, formând un modul software distinct, denumit pachet.

Ascunderea de informații: Un obiect păstrează ascuns mecanismul intern și nu dezvăluie

informații specifice despre arhitectura sa cu excepția interfețelor.

Asocierile și moștenirea: Clasele și obiectele se pot asocia între ele. Moștenirea este o formă specială de asociere ce descrie o relație de tip este-un între obiecte și clase formând o structură ierarhică ce permite claselor să fie extinse în subclase.

Polimorfismul: dezvoltarea orientată obiect permite implementări diferite ale aceluiași mesaj în două sau mai multe clase separate.

Paradigma orientată obiect reprezintă un set de tehnici utilizate pentru dezvoltarea de sisteme software. Analiza orientată obiect extinde capabilitățile tehnologiei informației pentru modelarea proceselor de afaceri din lumea reală, aceasta reprezintă o evoluție în comparație cu paradigma procedurală, ce necesita modelarea mediilor de afaceri prin termeni de flux de control și de reprezentare a datelor. Analiza orientată obiect oferă un mecanism de modelare a

realității ce ușurează comunicare cu utilizatorul final.

Proiectare orientată obiect este o altă fază majoră a industriei software ce a avut un succes comercial real pe piața software-ului de proces. Proiectare orientată obiect presupune planificarea structurii software, îmbunătățirea calității software-ului prin identificarea deficiențele de structură, și obținerea rapidă de prototipuri a sistemelor software.

Celălalt aspect major al paradigmei obiect se concentrează pe punerea în aplicare a principiilor. Programarea orientată obiect se poate face cu ajutorul unor limbaje ca Smalltalk, C++, Java și C#, toate acestea și nu numai fiind o alegere promițătoare pentru punerea în aplicare a paradigmei pentru dezvoltarea de software orientat pe obiecte. Calitatea majoră a orientării obiect este reprezentată de faptul că implementarea propriu-zisă permite dezvoltarea de aplicații încapsulate în mod corespunzător.

Beneficiul orientării obiect este reprezentat de faptul că structurile software se adaptează mult mai ușor entităților din lumea reală. Astăzi, tehnologia orientată obiect este utilizată pe scară largă devenind paradigma dominantă în dezvoltarea de aplicații software. Această tehnologie, atunci când este combinată cu infrastructuri de componente poate permite interoperabilitatea între aplicații software din medii diferite.

Dezvoltarea orientată pe componente

Componentele sunt module software mai sofisticate decât obiectele și necesită schimbări fundamentale în sistemul de gândire, în procesele software precum și în utilizarea tehnologiei. Dezvoltarea bazată pe componente permite programatorilor să creeze sisteme mai complexe, de înaltă calitate, pentru că oferă mijloace mai bune de gestionare a complexității și dependențelor din cadrul unei aplicație.

O componentă software este definită ca o unitate de compoziție cu interfețe specificate prin contract și dependențe de context explicite. O componentă software-ul poate fi implementată în mod independent și se supune compoziție terților. Acesta reprezintă un grup de obiecte ce au o interfață specifică, ce lucrează împreună pentru a asigura o funcție a aplicației, așa cum se poate fi văzut în figura următoare (Fig. 2.7).

Fig. 2.7 Dezvoltarea orientată pe componente

Componenta se poate referi la mai multe construcții software diferite, de la logica unei singure aplicații la un întreg sistem funcțional. În toate cazurile, o componentă este un pachet software cu una sau mai multe interfețe definite. O componentă este executată de un mediu specializat oferit de un server de aplicații, cum ar fi un container J2EE ce oferă funcțiile necesare, cum ar fi managementul tranzacțiilor și al conexiunilor la bazele de date.

Componentele se suprapun pe proprietățile tehnologiei orientare obiect, precum încapsularea și polimorfismul, exceptând proprietatea de moștenire, în gândirea centrată pe componente moștenirea prezintă forme de dependență fiind nepotrivită pentru cele mai multe forme de împachetare și reutilizare. În schimb, componentele reutilizează funcționalitățile mai degrabă prin invocarea altor obiecte și componente decât prin moștenire de la acestea. În terminologia componentelor, aceste invocări sunt denumite delegări.

Componentele au specificații ce permit descrierea modului de integrarea a acestora, reprezentate de interfețele lor publice, față de alte componente. Reutilizarea specificațiilor componentelor reprezintă o formă de polimorfism. Preferabil, specificațiile componentelor sunt standarde locale sau globale ce sunt larg refolosite în cadrul unui sistem, o întreprindere sau o industrie.

Componentele pot fi integrate pentru a crea o entitate mai mare, ce ar putea fi o nouă componentă, un framework de componente, sau un întreg sistem. Acest lucru poartă numele de compoziție. Componentele combinate dobândesc specificațiile componentelor constitutive. Acest lucru este adesea numit integrare plug-and-play.

Componentele reutilizabile sunt produsul proiectării software eficiente. Arhitectura furnizează contextul de proiectare în care componentele sunt construite și refolosite, celălalt aspect important în ceea ce privește componentele este reprezentat de faptul că dezvoltarea de arhitecturi software bazate pe specificațiile componentelor permit construirea independentă în paralel a părților sistemului. Limite ce definesc o parte individuală a sistemului sunt subsisteme testabile și pot fi împărțite la una sau mai multe echipe de proiect.

Mulți furnizori de platforme au produs deja infrastructuri software ce suportă tehnologii orientate pe componente. Aceste infrastructuri de componente, cum ar fi Microsoft .NET, Enterprise JavaBeans, sunt esențiale pentru dezvoltarea de aplicații enterprise orientate pe componente. Cu suport pentru XML, servicii Web și alte standarde, aceste tehnologii pot inter opera pentru construirea de aplicații software sofisticate.

Sisteme distribuite

Deși SOA, nu are o implicare directă în sistemele de calcul distribuit, trebuie să includă tehnologiile middleware existente și conceptele de calcul distribuit. Un SOA de succes ar trebui să depășească dificultățile cu care se confruntă în materie de tehnologii middleware existente, prin oferirea unei abordări eficace de dezvoltare de aplicații și tehnologiilor viitoare, cu luarea în considerare a acestor aspecte din faza inițială de implementare.

Abordarea inițială în ceea ce privește calcul distribuit este de a stabili o comunicare între două programe distribuite în mod direct prin intermediul protocoalelor de rețea primare. Ca pas evolutiv următor un framework de comunicare middleware va permite accesarea aplicațiilor de la distanță, fără a cunoaște detalii tehnice cum ar fi sistemele de operare, informații de nivel jos al protocolului de rețea, și adresa de rețea fizică.

Pe măsură ce tehnologiile de calcul distribuit evoluează, devine tot mai necesară furnizarea mai multor implementări de rețea pentru a satisface cerințe variate de calitate a serviciilor. Aceste cerințe pot include termene de livrare a mesaj, performanță, transfer, fiabilitate, securitate și alte cerințe non funcționale.

Infrastructurile de calcul distribuite orientate obiect adecvate asigură transparența accesului și oferă dezvoltatorilor libertatea de a folosi protocoalele necesare pentru a satisface cerințele de calitate a serviciilor aplicației. Prin urmare, evoluția tehnicilor pentru distribuția de componente software de întreprindere a dus la promisiunea de aplicații interoperabile universal.

Aplicațiile practic, comunică unele cu altele, în două moduri : sincron și asincron. Cu toate acestea, în realitate, există, de obicei, numeroase variante ale acestor moduri de bază de comunicare.

În mesajele sincrone, schimbul de mesaje necesită angajamentul simultan al ambelor aplicații. Acest lucru este adesea denumit mesaj cerere-răspuns.

Fig. 2.8 Mesaje sincrone cu răspuns

În mesajele asincrone, clientul trimite un mesaj și își continuă activitatea fără a aștepta răspunsul. Bazat pe un acord a priori, cum ar fi un punct final predefinit și convenit, receptorul trimite un răspuns expeditorului.

Fig. 2.9 Mesaj asincron cu răspuns

Apelul procedurilor la distanță (RPC)

Dezvoltarea conceptului de apel al procedurilor la distanță (RPC), a fost inițiată de Sun Microsystems la mijlocul anilor 1980 și este documentat ca protocol de RFC 1050, 1057, și 1831. O infrastructură de comunicare cu aceste caracteristici se consideră ca fiind RPC compatibilă, chiar și în cazul în care punerea în aplicare a acesteia nu se bazează pe RFC-urile corespunzătoare.

RPC implică executarea unei funcții sau a unei procedurii a unei aplicații distribuite ce încapsulează codul necesar și o face reutilizabilă pentru acces de la distanță. Apelul la distanță este direcționat prin intermediul rețelei la o altă aplicație, unde este executat, iar rezultatul este apoi returnat apelantului. Cele mai multe implementări RPC sunt bazate pe un protocol cerere-răspuns sincron, ce presupune blocarea clientului până când serverul răspunde la cerere.

Fig. 2.10 Modelul conceptual al apelului procedurilor la distanță (RPC)

Modelul RPC are mai multe componente. Protocolul de rețea oferă comutare, rutare, secvențierea pachetelor, adresarea, și redirecționarea între circuitele virtuale pentru transmiterea de date de la nod la nod. Bibliotecile RPC sunt specifice unei anumite tehnologii și asigură transferul de date între gazde. De asemenea, sunt responsabile pentru recuperare în cazul erorilor și controlul fluxului punct la punct. Logica specifică clientului și serverului stabilesc, coordonează, și termină conexiunile, schimburile și dialogurile dintre aplicații. În cele din urmă, nivelul aplicație conține aplicația propriu-zisă și procesele utilizatorilor finali, în care funcționalitățile specifice sunt executate.

Scopul principal al dezvoltării protocoalelor de tip RPC este fundamentat de necesitatea de a furniza aplicații independente de platformă. La sfârșitul anilor 1980, DCE (Distributed Computing Environment), a apărut ca o inițiativă de a standardiza diferitele tehnologii concurente de apel al procedurilor la distanță. Cu toate acestea, DCE nu a câștigat un sprijin pe scară largă în cadrul industrie. Alte tehnologii, cum ar fi CORBA, COM / DCOM și Java Remote Method (RMI), sunt utilizate în practica de astăzi și oferă suport RPC robust bazat pe platforme de calcul distribuite.

Obiecte distribuite

Conceptul de obiecte distribuite, a apărut la începutul anilor 1990, și reprezintă evoluție a programării orientate pe obiecte, ce permite apelul la distanță al procedurilor sau funcțiilor ca înlocuitor pentru stilurile tradiționale de programare modulară.

De obicei, obiectele distribuite sunt administrate de un Object Request Broker (ORB), care gestionează comunicarea și schimbul de date cu potențialele obiecte de la distanță. Acesta oferă o platformă de distribuție orientată pe obiect, transparența locației și permite obiectelor să își ascundă detaliile de implementare față de clienți.

Fig. 2.11 Object Request Broker

CORBA este cea mai comună implementare a tehnologiei ORB bazată pe RPC, nu acordă o atenție deosebită datelor sau serviciilor de execuție a aplicațiilor, scopul său principal fiind acela de a oferi o implementare corectă a unui framework de obiecte distribuite.

Middleware orientat pe mesaje (MOM)

Middleware-ul orientat pe mesaje (MOM), este de obicei o componentă software localizată între părțile ce comunică ce oferă un mecanism de conectare între diferite aplicații. Acesta este responsabil pentru manipularea diferitelor dependențe dintre aplicații precum sistemele de operare, hardware-ul, și protocoale de comunicare. Un MOM expune facilitățile sale, folosind un API ce definește modul în care aplicațiile distribuite ar trebui să utilizeze sistemul MOM pentru a comunica unele cu celelalte prin mesaje. Mesajele sunt legate de o anumită funcție ce trebuie executată la primirea mesajului.

Fig. 2.12 Middleware orientat pe mesaje

Soluțiile de mesagerie bazate pe MOM pot fi proiectate în diferite topologii, cum ar fi MOM centralizat, ce este concepută ca o rețea centrală hub-and-spoke unde MOM acționează ca o magistrală de mesaje între componentele aplicației; sau topologie MOM hibridă, ce are un MOM central care acționează ca un router între părțile ce comunică folosind propriile lor MOM-uri locale.

MOM joacă un rol important prin furnizarea unui mediu ce permite transferul de date și comunicarea între două aplicații. Caracteristicile unui middleware de comunicare pot fi descrise după cum urmează:

Nu este nevoie ca expeditorul și receptorul să fie conectați simultan.

Oferă garanții puternice de livrare a cererilor și răspunsurilor între participanți.

Adaugă funcționalitate, în unele cazuri, prin traducerea și formatarea mesajelor pe traseu între participanți.

MOM încurajează cuplajul slab între consumatorii și producătorii de mesaje, și permite construirea de sisteme dinamice, de încredere și de înaltă performanță. Cu toate acestea nu ar trebui să fie subestimată complexitatea ce stă la baza sistemelor ce utilizează MOM-uri făcând dificilă dezvoltare corespunzătoare a sistemului.

Arhitectura orientată pe servicii (SOA) – Definiție

Arhitectura orientată pe servicii (SOA) reprezintă un stil arhitectural ce utilizează metode și tehnologii ce permit întreprinderilor să se conecteze și să comunice dinamic cu aplicațiile software ale diferiților parteneri de afaceri de pe platforme eterogene, oferind servicii generice și fiabile, care pot fi utilizate ca blocuri elementare de construcție a aplicațiilor software. In acest fel este posibilă dezvoltarea de aplicații și sisteme informatice mai bogate și mai avansate.

Deși SOA nu este un concept nou, mai ales după inventarea serviciilor Web, noile evoluții în acest domeniu aduc o nouă metodă în construcția de arhitecturi de aplicații software, o nouă abordare pentru reconstrucția infrastructurii software existente și posibilitatea de a comunica cu alte întreprinderi în baza serviciilor disponibile.

Cu toate acestea, construirea unei implementări SOA este încă o provocare din următoarele motive:

Modul în care SOA abordează resursele software este diferit de arhitecturile tradiționale.

SOA are nevoie de un nivel de reglementare arhitecturală.

Implementarea SOA are nevoie de un mediu ce poate fi accesat de diferite întreprinderi.

Definirea și compoziția serviciilor în unele noi într-un mediu securizat și administrat este un alt aspect ce necesită o abordare specială.

Entitățile și caracteristicile SOA

SOA este un stil arhitectural ce definește un model de interacțiune între trei unități funcționale principale în care consumatorul serviciului interacționează cu furnizorul de servicii pentru a identifica un serviciu care se potrivește cu cerințele sale prin căutarea într-un registru. Un meta-model ce descrie această interacțiune este prezentat în figura următoare (Fig. 2.13).

Fig. 2.13 Modelul conceptual al arhitecturii orientate pe servicii(SOA)

SOA conține 6 entități în modelul său conceptual, descrise după cum urmează:

Consumatorul de servicii: Este entitatea SOA, ce caută un serviciu ce execută o funcție specifică. Consumatorul poate fi o aplicație, un alt serviciu, sau un alt tip de modul software ce are nevoie de serviciul respectiv. Locația serviciului este descoperită fie prin cătare într-un registru, sau în cazul în care acesta este cunoscută consumatorul poate interacționa direct cu furnizorul de servicii.

Furnizorul de servicii: Acesta este entitatea adresabilă de rețea care acceptă și execută cererile consumatorilor. Furnizează descrierea serviciului și implementarea acestuia. Furnizorul de servicii poate fi o componentă, sau alt tip de sistem software ce îndeplinește cerințele consumatorului de servicii.

Registrul de servicii: Este un director care poate fi accesat prin intermediul rețelei și conține descrieri ale serviciilor disponibile. Funcția sa principală este de a stoca și de a publica descrierile serviciilor expuse de furnizori și livrarea acestora către consumatorii de servicii interesați.

Contractul serviciului: Un contract de serviciu reprezintă o descrierea ce clarifică modul de interacțiune între consumator și furnizorul de servicii. Acesta conține informații despre formatul mesajelor de tip cerere-răspuns, condițiile în care ar trebui să fie executat serviciul și aspecte calitative ale serviciului.

Proxy-ul serviciului: Acesta asistă interacțiunea dintre prestatorul de servicii și consumator prin furnizarea unui API scris în limbajul de programare specific consumatorului. Este distribuit de către furnizorul de servicii și este o entitate utilă dar nu necesar obligatorie. De asemenea poate îmbunătății performanța și oferii facilități de cache. Proxy-ul serviciului este o entitate opțională în arhitecturile de tip SOA.

Închirierea serviciului: Specifică cantitatea de timp în care un contract de servicii este valabil. Este gestionat de registru și specifică termenele de execuție bine definite în care legătura cu serviciul poate fi realizată. Utilizarea de servicii închiriate permite cuplajul slab între furnizorul de servicii și consumator și întreținerea informațiilor de stare a serviciilor.

Arhitectura orientată pe servicii reflectă principii și caracteristici specifice ce trebuie aplicate atunci când se construiesc infrastructuri de aplicații orientate pe servicii după cum urmează:

Serviciile sunt vizibile și legate dinamic.

Servicii trebuie să fie vizibile în mod dinamic la run-time. Consumatorul serviciului găsește serviciul dorit prin căutarea în registru și obține toate informațiile necesare pentru utilizarea acestuia. Nu există nici o dependență la momentul compilării aplicației pentru a lega aplicația clientului de serviciul respectiv, în afară de contractul de servicii pe care registrul îl oferă.

Serviciile sunt autonome și modulare.

Un serviciu suportă interfețe unificate, funcționale și agregate pentru a efectua o logică de afaceri specifică și concretă. Aceste interfețe sunt legate unele de altele, în contextul unui modul și conțin informații suficiente pentru a fi funcționale fără nici o dependență de alte module software sau aplicații.

Serviciile sunt interoperabile.

Servicii dețin capacitatea de a comunica unul cu celălalt fără nici o dependență de platformă sau limbaj. Deoarece fiecare modul software ar putea avea structuri proprietare în interiorul său, arhitecturile bazate pe servicii utilizează tehnologii interoperabile ce suportă protocoalele și formatele de date ale consumatorilor prezenți și viitori.

Serviciile sunt slab cuplate.

Cuplajul descrie nivelul de dependență dintre modulele software. Modulele slab cuplate sunt flexibile și au dependențe bine definite, în mod contrar, sistemele software strânse cuplate sunt dificil de configurat, din cauza cerințelor necunoscute ale modulelor din cadrul structurii software. Arhitectura orientată pe servicii încurajează dezvoltarea serviciilor slab cuplate ca unitate de construcție software. Cuplajul slab se realizează prin utilizarea de registre de servicii. Serviciul nu necesită alte informații specifice sistemului pentru a fi executat în mod autonom, cu toate acestea, o legătură strânsă nu poate fi evitată la nivelul definiției de interfață sau la legarea de un protocol specific.

Serviciile au o interfață de rețea adresabilă.

Un serviciu ar trebui să-și publice interfața sa în rețea pentru a se conforma principiilor de proiectare arhitecturală orientată pe servicii, astfel încât consumatorul să fie capabil să invoce serviciul de o manieră distribuită în cadrul rețelei. În acest fel este posibilă utilizarea serviciului în orice moment de consumatori diferiți. Un serviciu poate fi, de asemenea, accesat prin intermediul interfeței locale fără utilizarea rețelei. Cu toate acestea, unul dintre principalele obiective în construirea unei implementări SOA este de a permite consumul de servicii într-un mod independent de locație.

Serviciile au interfețe cu granulație grosieră.

Conceptul de granularitate este legat de modul de implementare a interfețelor în sistemele software. Dacă interfața suportă toate funcțiile necesare pentru ca serviciul să își îndeplinească scopul în cadrul procesului de afaceri, aceasta este o interfață cu granulație grosieră. Dimpotrivă, dacă interfața implementează numai o parte din funcționalități, se consideră a fi o interfață cu granulație fină. Granularitatea poate fi aplicată pentru implementarea întregului serviciu, și/sau la metodele individuale de execuție a interfeței. Un sistem software orientat pe servicii permite proiectarea de interfețe cu granulație grosieră în mod natural și diferite niveluri de granularitate. Obiectele ce compun serviciul pot fi în continuare cu granulație fină, cu toate acestea ele sunt împachetate în interiorul structurii fizice a serviciului.

Fig. 2.14 Granularitate serviciilor

Serviciile sunt transparente din punct de vedere al locației.

SOA promovează transparența amplasării, ceea ce înseamnă pentru consumatorul serviciului că nu cunoaște locația serviciului decât în timpul execuție prin intermediul registrului de servicii. Singura dependență între consumator și furnizor este contractul de serviciu ce își poate schimba locația fără afecta consumatorul.

Serviciile pot fi compuse în noi aplicații.

O altă caracteristică cheie a SOA este reprezentată de posibilitatea construirii de noi aplicații din serviciile existente prin compoziție. Compoziția este o tehnică de design eficientă ce se concentrează în principal pe modularitatea serviciilor și reutilizarea funcționalității acestora fără a cunoaște dinainte ce aplicații le vor utiliza.

SOA dispune de metode de auto recuperare

Auto recuperarea este descrisă ca fiind capacitatea unui sistem de a se recupera în cazul apariției unei erori în timpul execuției sale. Sistemele orientate pe servicii trebuie să acorde o mai mare importanță auto recuperării decât alte stiluri arhitecturale deoarece serviciile sunt combinate pentru a executa o funcția de afaceri la run-time. Consumatorul ar trebui să aibă posibilitate de a găsi diferite servicii în rețea ce oferă aceeași funcționalitate cu scopul de a înlocui serviciile defecte.

Dezvoltarea orientată pe servicii

Serviciile sunt evoluție a componentelor ce însumează interfețele mai multor componente într-o singură interfață pentru a îndeplini o funcție specifică. Un serviciu este o resursă abstractă capabilă să realizeze o sarcină specifică. Servicii dețin potențialul de a reflecta funcții de afaceri, precum și definiții de activități tehnice.

Dezvoltarea bazată pe servici avansează dezvoltarea bazată pe componente într-un mod în care serviciile implică dezvoltarea de componente distribuite ce cooperează și sunt realizate în diferite limbaje de programare, de asemenea, orientare pe servicii adaugă caracteristici cum ar fi independența de platformă, descoperirea dinamică a serviciilor și nivelul îmbunătățit de reutilizare a modulelor aplicațiilor.

Orientarea pe servicii este în plină evoluție în zilele noastre, dezvoltarea de aplicații bazate pe servicii în care serviciile reprezintă elementul natural fiind prezente în rețeaua Internet și în tehnologiile World Wide Web. Aceste tehnologii modifică structura aplicațiilor pentru a permite construcții software open source mult mai dinamice și care să rezolve problemele de interoperabilitate prin aplicarea de standarde ce sunt acceptate la scară largă de organizații și producătorii de software.

Serviciile sunt proiectate și dezvoltate pentru a sprijini următoarele caracteristici:

Fiecare serviciu definește o funcție de afaceri specifică și poate emula o activitate din viața reală.

Un serviciu poate avea diverse proceduri și operațiuni.

Serviciile interacționează cu alte servicii și componente de sistem într-o maniera de cuplaj slab, într-un mediu orientat pe mesaje pentru a realiza obiectivele de afaceri.

Serviciile au interfețe definite în mod clar și pot fi utilizate de multe alte servicii și aplicații.

Servicii nu trebuie să fie într-un mediu distribuit.

Figura de mai jos ilustrează dezvoltarea bazată pe servicii în cadrul componentelor și obiectelor (Fig.2.15).

Fig. 2.15 Dezvoltarea bazată pe servicii

Dezvoltare de software a trecut prin anumite etape și modele arhitecturale, până a permite dezvoltarea de servicii independente de platformă, reutilizabile. Fiecare model arhitectural oferă un mijloc mai bun de a face față dificultăților în dezvoltarea de software decât abordările anterioare cu scopul de a realiza structuri software îmbunătățite care se potrivesc cu cerințe lumii reale.

Arhitectura timpurie a software-ului se baza pe un design structurat, ce avea reguli rigide pentru dezvoltarea de construcții software și suport limitat pentru dezvoltarea de aplicații robuste și sofisticate. Tehnologiile orientate obiect aduc flexibilitate în dezvoltarea de software prin încapsularea logicii de afaceri prin intermediul funcțiilor cu granulație grosieră și a claselor; cu toate acestea, avantajele concrete ale dezvoltării de aplicații robuste sunt dobândite prin evoluția componentelor și serviciilor.

Următorul tabel ilustrează caracteristicile și trăsăturile fiecărui modele arhitectural:

Tabel 2.1 Comparația modelelor arhitecturale de dezvoltare

Stratificarea arhitecturii SOA

Primele sisteme erau structurate pe două niveluri iar clientul avea acces direct la baza de date și API-urile de rețea, fără nici un model logic interpus. Această abordare poate încă fi utilizată în sistemele software în cazul în care dezvoltarea este de dimensiuni mici sau prototip. De asemenea, unele module din cadrul sistemelor avansate pot aplica această abordare pentru a oferi anumite funcționalități. Cu toate acestea, dezvoltarea de aplicații pe două niveluri este limitată la sisteme cu ciclu de viată scurt și nu oferă API-uri flexibile. Acestă abordare nu oferă suficientă izolarea a codului implementării față de client, ceea ce face arhitectura rigidă și nescalabilă pentru mai mulți utilizatori simultani.

În prezent, modelul de dezvoltare a aplicațiilor utilizat cel mai frecvent se bazează pe trei niveluri ale structurii arhitecturale, și anume, presupune un strat suplimentar între client și nivelurile de stocare a datelor. Stratul suplimentar, numit stratul de logica de afaceri, oferă izolare codul de client și permite partajarea logicii aplicației între diferite implementări ale clienților. Este o abordarea competentă pentru dezvoltarea de software pentru gestionarea flexibilă a datelor și a resurselor de sistem.

Fig. 2.16 Modelul arhitectural pe doua niveluri și trei niveluri

SOA se bazează pe dezvoltarea de aplicații N-tier în care serviciile sunt suprapuse pe componente ce sunt responsabile de furnizarea anumitor funcționalități și menținerea cerințelor de calitate a serviciilor așa cum se arată în figura 2.17.

Fig. 2.17 Nivelurile arhitecturii orientate pe servicii

Fiecare nivel în SOA are caracteristici arhitecturale specifice, așa cum este descris mai jos:

Nivelul sistemelor operaționale: Acest nivel conține aplicațiile existente cum ar fi CRM-uri și aplicații de tip ERP, sisteme orientate-obiect, și aplicații de business intelligence. Aceste aplicații oferă fundamentul serviciilor și fiecare dintre ele are propriile sale structuri proprietare, baze de date și alte mecanisme de acces la resursele de sistem.

Nivelul componentelor întreprinderii: Acestea sunt componente specializate ce oferă funcții și îndeplinesc anumite cerințe pentru servicii. Ele sunt activele de afaceri pentru implementările de servicii și alte necesități ale sistemului, cum ar fi managementul, disponibilitatea și echilibrarea încărcării serviciilor.

Nivelul serviciilor: Acest nivel conține serviciile propriu-zise ce pot fi descoperite și invocate de către alte aplicații pentru a oferi o funcție de afaceri specifică întreprinderii. Serviciile realizează și distribuie interfețele componentelor întreprinderii ca descrieri de servicii ce sunt publicate pe rețea.

Nivelul de compoziție a proceselor de afaceri: Serviciile pot fi compuse într-o singură aplicație prin orchestrarea sau coregrafia acestora tratând cazuri și procese de afaceri specifice.

Nivelul prezentare: furnizează interfețele utilizator pentru servicii și aplicații compozite. Deși nivelul prezentare nu este în strictă corelație cu principiile SOA, deoarece utilizarea serviciilor ca interfață cu utilizatorul duce la discuții cu privire la dezvoltarea de standarde cum ar fi Portlet și specificații Web Services for Remote Portlet (WSRP).

Altă preocupare pentru SOA o reprezintă integrarea serviciilor și aplicațiilor compozite în întreprindere prin furnizarea de caracteristici cum ar fi fiabilitatea, rutarea corespunzătoare și coordonarea serviciilor, precum și gestionarea altor detalii tehnice, inclusiv protocolul și integrarea acordului părților. Cerințele QoS (calitatea serviciilor), securitatea, gestionarea și monitorizarea serviciilor sunt de asemenea alte cerințe care trebuie să fie clarificate atunci când se proiectează arhitecturi de aplicații bazate pe servicii.

Tehnologii pentru arhitecturii orientate pe servicii

Tehnologia inițială orientată pe servicii a fost introdusă la sfârșitul anilor 1990 de Sun Microsystems fiind cunoscută sub numele Jini Technology Network. Jini era un mediu dinamic compact ce permitea descoperirea și utilizarea serviciilor de pe o rețea. Scopul său principal era să permită dispozitivelor, cum ar fi imprimantele să se conecteze dinamic la rețea și să își înregistreze servicii lor disponibile.

Prin urmare, interesul de a utiliza serviciile ca o unitate de construcție software a dus la dezvoltarea mai multor seturi de tehnologii pentru punerea în aplicare a arhitecturii orientate se servicii.

Cu toate acestea, provocările construirii unei arhitecturi SOA legate în special de interoperabilitate, complexitatea de integrare și de transport la standardele industriei, influențează abordările curente în dezvoltare de aplicații bazate pe servicii.

J2EE

Java 2 Platform Enterprise Edition (J2EE) este o tehnologie bazată pe containere ce sprijină proiectarea, dezvoltarea și implementarea de aplicații bazate pe componente distribuite. J2EE folosește o arhitectură de aplicații pe mai multe niveluri în care logica este împărțită funcțional în diferite componente și fiecare componentă poate rula pe o mașină diferită.

Componentele J2EE sunt scrise în limbajul Java și asamblate într-o aplicație J2EE. Aplicațiile Java accesează sistemele externe prin intermediul serviciilor de infrastructură oferite de către serverele de aplicații conforme cu tehnologia J2EE. Specificațiile J2EE definesc următoarele componente J2EE:

– Componente client: Aplicații client și applet-uri

– Componente Web: Java Servlets și Java Server Pages

– Componente de afaceri: Enterprise JavaBeans

Specificațiile J2EE propun mai multe servicii și fiecare dintre aceste servicii are diferite funcționalități care pot fi utilizate în dezvoltarea de aplicații orientate pe servicii. Clienții accesează aceste servicii prin intermediul API-urilor furnizate. Unele dintre serviciile de bază sunt definite după cum urmează:

– JavaBeans: JavaBeans sunt clase obișnuite Java care sunt conforme cu standardele și convențiile producătorului.

– Enterprise JavaBeans (EJB): EJB-urile sunt componente distribuite pe parte de server ce depind de o infrastructură pusă la dispoziție de către un server de aplicații. EJB sprijină dezvoltarea logicii de afaceri a aplicațiilor.

– Java Naming and Directory Interface (JNDI): JNDI oferă acces la directorul de servicii. Clienți Java folosesc JNDI ca metodă de accesarea a EJB-urilor, bazelor de date și altor resurse.

– Java Database Connectivity (JDBC): Oferă acces la bazele de date relaționale.

– Java Message Service (JMS): JSM este o arhitectură și un API pentru utilizarea mesajelor claselor Java.

– J2EE Connector Architecture (JCA): JCA este un framework și API ce definește o interfață standard prin care programele Java pot accesa o varietate de sisteme moștenite sau care nu folosesc Java.

– Java Transaction Service (JTS): JTS este o implementare Java a Object Transaction Service (OTS), un standard în industrie pentru tranzacțiile distribuite.

– Java Mail: Oferă un API pentru trimiterea de e-mail-uri din clasele Java.

Java Message Service (JMS)

Sistemele de mesagerie la nivel de întreprindere asigură transportul de informații de încredere între diverse aplicații pe o varietate de rețele și sisteme informatice eterogene. Aceste sisteme au caracteristic faptul că permit programelor ce interacționează să ruleze la momente diferite și ascund complexitatea rețelelor. Java Message Service (JMS) este o interfață de dezvoltare ce suportă interacțiunea între mesaje asincrone standardizate și oferă capacitatea de a simula modul de comunicație sincron tip cerere/răspuns.

Un mesaj este o colecție de date pe care o aplicație încearcă să o trimită alteia, de obicei, pe o altă mașină. Sistemele de mesagerie oferă un mecanism pentru stocarea mesajelor primite într-o coadă de așteptare, pentru a permite receptorului să prelucreze mesajele și să răspundă la un moment de timp ulterior. Complexitatea în acest mecanism este dată de nevoia de a avea un transfer sigur al mesajelor între expeditor și receptor.

JMS are un set rigid de reguli pentru gestionarea comunicațiilor cu scopul realizării transportului mesajelor într-un mod fiabil și stabil cu caracteristici de persistență și confirmare a mesajului și de administrare a performanței consumatorului mesajului, care se poate deconecta și reconecta la furnizorul JMS.

Figura de mai jos ilustrează procesul de comunicare între expeditorul mesajului, furnizorul JMS și destinatarul mesajului.

Fig. 2.18 Modelul conceptual Java Message Service

API-ul JSM acceptă două modele de mesaje:

Punct-la-punct: În acest model, mesajul creat de expeditor este apoi pus într-o coadă de așteptare fiind adresat unui destinatar specific. Destinatarul citește mesajele sosite din coada de procesare.

Fig. 2.19 Mesaje Punct-la-punct

Publicare-abonare: În acest model, expeditorii publică mesaje, care sunt apoi ordonate pe subiecte. Mai mulți destinatari se pot abona la acest subiecte primind o copie a mesajelor în cauză.

Fig. 2.20 Mesaje publicare-abonare

Aceste modele folosesc aceleași concepte fundamentale, ce indică faptul că au în comun un set de interfețe de bază. Fiecare interfață de bază are sub-interfețe separate ce suportă tipuri de modele individuale.

JMS permite de multe ori comunicarea dincolo de granițele firewall. De asemenea, mulți producători extind implementarea furnizorilor pentru a suporta mesaje SOAP prin HTTP. În acest mod, HTTP este folosit ca protocol de transport în API-ul JMS transferând mesaje SOAP ca mesaje text. Acest lucru este adesea numit SOAP prin JMS.

Remote Method Invocation (RMI)

Remote Method Invocation (RMI) reprezintă acțiunea de invocare a unei metode a unei interfețe la distanță pe un obiect la distanță. Cel mai important, o invocare a unei metode pe un obiect la distanță are aceeași sintaxă ca invocarea unei metode pe un obiect local. RMI permite invocarea de metode într-o rețea distribuită de clienți și servere furnizând managementul obiectelor și facilitând distribuția acestora pe oricare dintre mașinile conectate.

RMI este o tehnologie simplă datorită modelului său ușor de utilizat nativ Java. Aceasta permite dezvoltarea de aplicații de dimensiuni mici, distribuite, bazate pe obiecte. Un obiect la distanță are metode ce pot fi invocate de către o altă aplicație situată chiar și pe o altă stație. Interfețele ce descriu metodele obiectului la distanță sunt numite interfețe la distanță.

Aplicațiile ce folosesc obiecte distribuite prin RMI se împart în două categorii:

Server, creează un număr de obiecte la distanță, fac referire la acele obiecte la distanță, pentru a le face accesibile, și așteaptă solicitările clienților prin invocarea metodelor pe aceste obiecte la distanță.

Client, primește o referință la distanță la unul sau mai multe obiecte din server și apoi invocă metodele acestora expuse de interfețele la distanță .

Referințele de obiecte la distanță pot fi solicitate fie prin facilitatea de denumire a RMI-lui cunoscută ca RMI Registry, sau aplicația poate transfera referințe la obiecte la distanță ca parte din funcționarea normală. Framework-ul RMI oferă mecanismul necesar pentru încărcarea obiectelor și transformarea necesară a datelor. Se utilizează servere de Web pentru a încărca clasele respective scrise în limbajul de programare Java, folosind orice protocol URL, cum ar HTTP sau FTP.

Figura de mai jos este diagrama arhitecturală a modelului aplicațiilor RMI:

Fig.2.21 Modelul distribuit RMI

Funcționalitatea RMI se bazează pe apelul procedurilor la distanță (RPC). Un client de tip agent este folosit ca reprezentant local sau proxy pentru un obiectul la distanță. Fiecare obiect la distanță poate avea o structură la nivelul server-ului ce este creată dintr-un obiect de tip interfață comună. Agentul este utilizat pentru conectarea la registrul RMI, în timp ce structura de la nivelul server-ului transmite apelul la distanță al procedurii la implementarea obiectului în cauză.

RMI oferă un mecanism numit Object Activation, prin care managementul implementării obiectelor executate și referințele persistente la aceste obiecte sunt furnizate. Un obiect la distanță ce este instanțiat este numit activ, în timp ce în cazul în care obiectul nu este instanțiat, el este numit obiect pasiv. Transformarea unui obiect pasiv într-un obiect activ reprezintă procesul de activare. RMI folosește activare lentă, ceea ce înseamnă că obiectul este activat doar atunci când client invoca prima metoda a obiectului.

Nucleul API-ului RMI oferă un protocol de rețea implicit numit Java Remote Method (JRMP). RMI-prin-JRMP (RMI/JRMP) este un protocol proprietar, compact ce permite comunicare cu alte obiecte Java RMI. Principalele sale caracteristici sunt ușurința în utilizare și utilizarea de colectoare distribuite de memorie.

Limitările RMI /JRMP pot fi depășite utilizând protocolul de comunicație Internet Inter-ORB (IIOP) . RMI-pe-IIOP (RMI / IIOP) nu necesită cunoașterea unei limbaj separat, deoarece folosește Java ca limbaj nativ pentru a defini interfața serviciilor oferind flexibilitate și performanță îmbunătățită. RMI / IIOP pot interacționa cu aplicații scrise în alte limbaje.

COM/DCOM

Component Object Model (COM) este o tehnologice ce face parte din familia sistemelor de operare Microsoft Windows ce este folosită de către dezvoltatori pentru a crea software reutilizabil, pentru a interconecta componente cu scopul construirii de aplicații, și utilizarea serviciilor Windows în cadrul acestora. COM reprezintă o combinație de alte tehnologii Microsoft precum. COM +, Distributed COM (DCOM) și ActiveX.

COM este o arhitectură software bazată pe componente ce permite combinarea unor componente ce aparțin unor aplicații variate cu scopul construirii de noi aplicații software de nivel superior. COM definește un standard de interoperabilitate între componente. Acesta este independent de limbajul de programare, disponibil pe mai multe platforme și extensibil.

Un obiect COM este definit ca o unitate de cod compilată utilizată pentru furnizarea anumitor servicii. Aceste obiecte sunt diferite față de conceptul de obiect definit în programarea orientată obiect, întru-cât un obiect îndeplinește o cerință complexă în sistem. COM definește aceste obiecte ca obiect componenta sau pur și simplu obiect.

Aplicațiile comunică unele cu celelalte, printr-o colecție de funcții numite interfețe. Interfețele asigură logica aplicației utilizată între componente. Un pointer identifică interfața pe care componenta obiect o implementează în timpul interacțiunii cu diferite componente. Acesta este folosit doar pentru a apela funcția fără a modifica starea sistemului. Interfețele sunt definite în mod static la compilare iar un obiect componentă poate implementa mai multe interfețe.

Figura 2.22 afișează relațiile dintre obiectele componente; interfețe și pointeri în contextul aplicațiilor ce folosesc tehnologia COM:

Fig.2.22 Modelul arhitectural COM

Distributed Component Object Model (DCOM) extinde COM, astfel încât să permită comunicarea între obiecte de pe calculatoare diferite pe o rețea LAN, WAN și Internet. Acestă tehnologie permite componentelor să fie utilizate în medii distribuite prin abstractizarea detaliilor de nivel scăzut al protocoalelor de rețea.

În COM, interacțiunea dintre diferitele componente este asigurată de utilizarea unei tehnici de comunicare inter-proces furnizate de sistemul de operare, deoarece componentele nu pot apela direct componentele țintă, atunci când aceste componente sunt situate pe mașini diferite, DCOM înlocuiește comunicare inter-proces locală cu un protocol de rețea și ascunde detaliile de comunicare de componentele client.

Figura de mai jos reprezintă ilustrarea arhitecturii DCOM. Modelul este constituit din Runtime-ul COM, DCE RPC-ul și furnizorul de securitate, ce oferă împreună fundamentul pentru punerea în aplicare a protocolului DCOM.

Fig.2.23 Modelul arhitectural DCOM

Din punct de vedere arhitectural DCOM permite dezvoltare cross-platform. Permite integrarea farmework-urilor de dezvoltare neutre din punct de vedere al platformei și medii de mașini virtuale pentru a construi o singură aplicație distribuită.

CORBA

Common Object Request Broker Architecture (CORBA) este un sistem obiect ce oferă un cadru în care obiectele pot comunica unul cu altul de o manieră distribuită fără dependențe de platformă sau limbaj de programare. Un sistem obiect reprezintă o colecție de obiecte ce izolează solicitanții de servicii de furnizorii de servicii printr-o interfață încapsulată în mod corespunzător. În special, clienții sunt izolați de implementarea serviciilor prin reprezentări de date și cod executabil.

CORBA este o specificație a Object Management Group. Acesta definește Interface Definition Language (IDL), un API de bază, ce clasifică o infrastructură de comunicații bazată pe Object Request Broker (ORB) pentru aplicații distribuite, și un protocol de comunicații bazat pe TCP / IP numit Internet Inter-ORB Protocol (IIOP).

IDL este un limbaj utilizat în descrierea atributelor și operațiunilor obiectelor distribuite ce combină aplicațiile client cu serverul pentru utilizarea serviciilor specifice CORBA. Conversațiile dintre clienți și server, se bazează pe un contract specificat și atâta timp cât contractul este valabil, implementările aplicațiilor client sunt independente de acest contract.

Componenta principală în arhitectura CORBA este Object Request Broker (ORB), o componentă software ce asigură o comunicare corespunzătoare a obiectelor în medii eterogene. Acesta interconectează toate componentele aplicațiilor, interfețele și serviciile pentru a putea realiza interoperabilitatea și a asigura anumite funcții pentru aplicațiile distribuite.

Figura 2.24 este o ilustrarea a componentelor din structura arhitecturală CORBA.

Fig.2.24 Structura CORBA Object Request Interface

Arhitectura CORBA permite clientului să fie conștient de prezența obiectelor server și să le invoce utilizând metoda invocării dinamice. Clienții pot utiliza, de asemenea, secvențe IDL ce definesc modul în care pot invoca obiectele server. Interfețele ORB sunt API-uri specifice pentru serviciile CORBA. Structurile oferă mediul de implementare al obiectelor. Iar adaptoarele obiect se ocupă de comunicare între un obiect și ORB.

CORBA definește o varietate de servicii concepute pentru realizarea comunicării sofisticate între diferite părți permițând punerea în aplicare a cerințelor de calitate a serviciilor (QoS).

Unele dintre aceste servicii sunt definite după cum urmează:

– Serviciul evenimente: permite alocarea corespunzătoare a evenimentelor la componentele aferente ce subscriu sau nu la anumite mesaje sau evenimente.

– Serviciul ciclului de viață: oferă consistență obiectelor distribuite din cadrul arhitecturii CORBA.

– Serviciul de evidență: permite componentelor distribuite să se descopere reciproc căutându-se după denumire.

– Serviciul de persistență: oferă o interfață utilizată pentru stocarea componentelor pe o varietate de sisteme de management de baze de date.

– Serviciul de securitate: oferă un cadru de securitate pentru obiectele distribuite.

– Serviciul de tranzacții: oferă standarde pentru tranzacții în două faze între componente recuperabile.

Interoperable Object Reference (IOR) este referința adresabilă de rețea dată unui obiect în CORBA. IOR codifică numele de gazdă și portul la care mesajele sunt trimise și oferă un mecanism ce permite identificarea diferitelor obiecte.

Servicii Web

Serviciile Web reprezintă un set de tehnologii bazate pe XML, ce au scopul de a oferi o modalitate standard pentru comunicarea între diferite aplicații și interoperabilitate între medii de calcul eterogene. Servicii Web folosesc tehnologii standard Internet pentru mesaje și schimbul de date, ceea ce le face potrivite pentru dezvoltarea unei aplicații accesibile într-un mediu independent de platforma.

Putem defini serviciile Web după cum urmează:

"Un serviciu Web este un sistem software conceput pentru a permite interacțiuni de tip mașină-la-mașină în cadrul unei rețele. Prezintă o interfață descrisă într-un format procesabil de către mașină (de obicei WSDL). Sistemele interacționează cu serviciul Web într-un mod prevăzut în descrierea sa, folosind mesaje SOAP, de obicei transmise prin HTTP cu serializare XML împreună cu alte standarde Web ".

Implementarea unui serviciu Web poate fi scrisă în orice limbaj și pe orice platformă. Tehnologia serviciilor Web face ca această logică de implementare să fie accesibilă folosind tehnologii standard Web, cum ar fi protocolul HTTP și browser-e Web, ducând la o comunicare mai rapid și mai dinamică între aplicațiile conectate.

Arhitectura serviciilor Web este orientată pe servicii, un consumator căutând un furnizor de servicii pentru a executa anumite funcții. Un registru de servicii conține serviciile publicate și atunci când există o cerere pentru un serviciu, transmite ca răspuns informații ce permit solicitantului să localizeze și să invoce serviciul.

Figura 2.25 ilustrează rolurile existente în cadrul arhitecturii serviciilor Web:

Fig.2.25 Arhitectura Serviciilor Web

Modelul arhitecturii serviciilor Web se bazează pe o familie de tehnologii stratificate. Fiecare strat este interdependent și oferă un nivel de abstractizare și funcționalitate pentru dezvoltarea de aplicații bazate pe servicii Web.

Figura următoare ilustrează unele dintre aceste tehnologii de bază.

Fig.2.26 Stiva de tehnologii ce stă la baza serviciilor Web

XML (Extensible Markup Language) este elementul fundamental al serviciilor Web și un limbaj de bază pentru definirea și prelucrarea datelor. XML suportă crearea și gestionarea de conținut dinamic, permite definirea datelor ca elemente ce se auto-descriu, ce pot avea sub elemente fiind o familie de tehnologii utilizate pentru crearea, definirea, și transformarea documentelor XML.

Unele dintre tehnologiile bazate pe XML includ:

XML schema: un document XML care definește tipurile de date, structura și elemente permise dintr-un document XML asociat.

XML namespaces: asigură denumiri unice calificate pentru elementele documentelor XML.

Extensible Stylesheet Language Transformations (XSLT): utilizat pentru transformarea documentelor XML în alt format de document XML.

Simple Object Access Protocol (SOAP) este un standard pentru descrierea modului de citire și formatare a mesajelor XML între consumatorul de servicii și furnizorul de servicii în arhitectura serviciilor Web. Acesta oferă un framework de comunicații independent de sistemul de operare, limbajul de programare sau platforma de calcul distribuit. Un mesaj SOAP are trei părți:

Pachetul SOAP: acesta este elementul superior al documentului XML și specifică faptul că mesajul este un mesaj SOAP.

Antetul SOAP: conține atribute opționale, informații de context al aplicațiilor și directive folosite în procesarea mesajului. Se specifică poziția mesajului care poate fi un punct intermediar sau un eventual punct final.

Corpul SOAP: conține datele efective ce trebuie să fie trimise între sursă și destinație.

Mesajele SOAP suportă unul dintre cele două tipuri de modele de schimb de mesaje: formatul orientat document și formatul RPC. Schimbul de mesaje orientat document permite consumatorilor și producătorilor de servicii să facă schimb de documente XML ca reprezentare a datelor, în timp ce în cadrul mesajelor stil RPC datele sunt transmise ca argumente și conțin informații suficiente pentru a invoca o metodă și îndeplini o funcție oferită de producător. SOAP impune în mod fundamental un model de comunicare cu sens unic; cu toate acestea, este posibilă implementarea modelului de tip cerere/răspuns.

Web Services Description Language (WSDL) este un limbaj bazat pe XML pentru descrierea interfeței serviciilor Web și specificarea un contract de servicii. Acesta oferă o modalitate standard de a descrie tipurile de date transmise în mesaje, operațiunile ce trebuie să fie efectuate asupra mesajelor și maparea acestor operațiuni la protocolul de transportul.

Documentul WSDL este structurat în secțiuni logice pentru a crea o descriere finală a serviciului Web, care este apoi utilizat de consumatorul serviciului pentru a interacționa cu serviciul. Descrierea cuprinde următoarele elemente principale:

Elementul definitions este elementul rădăcină al documentului XML și declară
domeniul de nume și numele serviciului.

Elementul types conține definiții de tipuri de date utilizate în comunicațiile dintre furnizorul de servicii și consumatori.

Elementul message reprezintă parametrii de intrare și ieșire transferați între solicitantul de servicii și producător, și descrie diferitele mesaje pe care serviciile le schimbă.

Elementul operations reprezintă o anumită interacțiune în conversație.

Elementul portType descrie setul de operații pe care serviciile le permit și oferă informații ca numele operațiilor și parametrii de intrare și de ieșire.

Elementul binding reprezintă o anumită legătură a operațiunilor cu un anumit protocol de implementare, cum ar fi SOAP.

Elementul service reprezintă o colecție de porturi. Un port descrie o locație de rețea în care serviciul poate fi invocat.

Consumatorii de servicii folosesc fișierul WSDL pentru a interacționa cu serviciul folosind următorul scenariu ilustrat în figura de mai jos:

Fig.2.27 Interacțiunea serviciului cu consumatorii

O altă tehnologie importantă a serviciilor Web este reprezentată de Universal Description, Discovery and Integration (UDDI) ce definește un cadru prin care furnizorii de servicii publică, descoperă și construiesc un registru global de serviciile disponibile. Un registru expune serviciile disponibile pentru consumatori și permite producătorilor de servicii să își facă cunoscute serviciile lor către posibilii consumatori.

Există trei tipuri de registre:

Pagini albe: permite consumatorilor să efectueze căutări după adresă, informații de contact, și identificatori cunoscuți.

Pagini aurii: include clasificări de informații bazate pe taxonomii standard.

Pagini verzi: indică serviciile oferite cu referințe la un anumit proces de afaceri.

UDDI include patru părți principale în arhitectura sa și anume; businessEntity, businessService, bindingTemplate, și tModel.

BusinessEntity conține informații descriptive despre o anumită organizație de afaceri și oferă referințe la serviciile oferite de acesta. BusinessService indică serviciul propriu-zis, ce are un identificator unic. Informațiile necesare pentru ca un client să invoce un serviciu sunt furnizate de bindingTemplate. TModel (modelul tehnic) este utilizat în principal pentru a indica specificațiile externe ale serviciului oferit.

Figura de mai jos prezintă scenariul de utilizare a acestor tipuri de structuri de date primare:

Fig. 2.28 Modelul structural informațional al UDDI

Serviciile Web au domenii de utilizare largă, inclusiv accesul la sisteme software back-end, baze de date, integrarea cu diverse aplicații pentru a realiza interacțiuni de tip business-to-business (B2B), integrarea aplicațiilor întreprinderii (EAI), și realizarea de aplicații Internet ce oferă utilizatorilor acces la resursele sistemului informatic al organizației .

Compararea tehnologiilor pe baza specificațiilor

Tehnologiile care au fost introduse în această secțiune pot fi folosite pentru a implementa arhitecturi orientate pe servicii. Cu toate acestea, capacitățile fiecărei tehnologie determină complexitatea pe care își propun să o rezolve atunci când sunt folosite în construirea unui SOA. Deși serviciile Web sunt o abordare nouă și revoluționară în dezvoltarea de software bazat pe servicii, este foarte important să se hotărască asupra unei tehnologii ca remediu universal în abordarea acestei arhitecturii software.

Următoarea parte va stabili caracteristicile importante SOA și analiza aceste tehnologii pentru a defini competențele conform cerințelor SOA.

Modelul de dezvoltare

Deși SOA implică dezvoltarea serviciilor în structura sa, abordările din înainte de serviciile Web precum JMS pentru dezvoltarea de aplicații orientate pe servicii se bazau pe comunicarea între obiecte distribuite ce se concentrau în principal pe mesaje și apeluri RMI. O diferență cheie între CORBA, COM / DCOM și serviciile Web este reprezentată de faptul că acestea oferă o arhitectura bazată pe componente obiect în timp ce serviciile Web oferă structuri de comunicații bazate pe servicii.

Limbajul de definire al interfeței

Fiecare tehnologie a introdus propriul său limbaj de definirea al interfețelor folosit pentru a descrie serviciu în mod public. COM/DCOM utilizează Microsoft Interface Definition; CORBA folosește CORBA Interface Definition Language (IDL), și J2EE folosește limbajul de programare Java. Web Service Definition Language (WSDL) este utilizat în cadrul stivei de tehnologii al serviciilor Web și acceptat ca limbaj universal. Utilizează XML și oferă posibilitatea de legare la mai multe canale de transport.

Cuplajul

O caracteristică importantă a SOA este dată de posibilitate de a dezvolta un model arhitectural slab cuplat în care serviciile sunt combinate și reasamblate cu scopul de a defini structura unei aplicații compuse, noi. O aplicație strâns cuplată are relații predeterminate în cadrul structurii sale fapt ce face ca modificările de structură sa fie dificile.

JMS se bazează pe o structură de mesagerie. Deoarece producătorul și consumatorul mesajului sunt nu dependenți unul de altul, JMS îndeplinește cerințele de cuplaj slab prin acest mijloc. Serviciile Web vizează, de asemenea, dezvoltarea de aplicații slab cuplate; cu toate acestea pot apărea cuplaje strânse la nivelul definiției interfeței și a protocolului folosit. J2EE, COM/DCOM și CORBA necesită dezvoltarea de interfețe rigide nepermițând dezvoltarea de interfețe slab cuplate.

Independența de platformă

Din punct de vedere arhitectural serviciile din diferite aplicații și platforme eterogene pot fi combinate fapt ce implică diverse structuri de componente scrise într-o varietate de limbaje de programare. O tehnologie orientată pe servicii independentă de platformă permite îmbinarea componentelor și infrastructurilor sofisticate de aplicații bazate pe servicii prin asamblarea acestora pentru a dezvolta o arhitectură orientată pe servicii ce îndeplinește criteriile specificate de metodologia SOA.

CORBA promovează dezvoltarea independentă de platformă în care aplicațiile pot fi scrise în orice limbaj, cu toate acestea, este necesar pentru a putea comunica, ca aplicațiile să utilizeze același Object Request Broker, de la același furnizor pentru a permite interoperabilitatea completă. Serviciile Web acceptă independența de platformă prin utilizarea tehnologiilor standard Internet, cum ar fi XML și HTTP. J2EE și COM/DCOM oferă medii de dezvoltare de aplicații specifice unui furnizor, părțile implicate în comunicare trebuind să utilizeze aceleași standarde.

Interoperabilitatea, suport pentru standarde deschise

Tehnologiile existente înainte de introducerea serviciilor Web ofereau propriile lor protocoale bazate pe TCP/IP. Aplicațiile construite cu aceste tehnologii cum ar fi CORBA și DCOM sunt dependente de implementările specifice unui singur furnizor. JMS și RMI presupun utilizarea de medii identice de ambele părți ale comunicării pentru a putea inter opera. Serviciile Web standardizează protocolul de comunicare prin utilizarea de tehnologii larg acceptate, tehnologii Internet deschise, pentru construirea de aplicații interoperabile distribuite. Acest progres permite aplicațiilor să aibă acces și să comunice cu ușurință unele cu altele.

Serviciile Web nu necesită un anumit limbaj de programare, protocol sau sistem de operare între părțile implicate în comunicare, așa că se atinge un nivel ridicat al cerințele de interoperabilitate și oferă o soluție universală, atunci când se construiește o arhitectură orientată pe servicii în termeni de interoperabilitate.

Transparența locației

Transparența locație este una din principalele caracteristici ale SOA. SOA stipulează că un consumator al unui serviciu trebuie sa poată să localizeze în mod dinamic serviciul în cadrul unui registru, fără cunoașterea poziției exacte a serviciului. Prin urmare, în cazul în care este necesară mutarea unui servicii dintr-un loc în altul, consumatorii acestui serviciu nu ar trebui să fie afectați de această schimbare.

CORBA Interoperable Object References (IORs) asigura transparența locației pentru obiecte în mod static. Serviciile Web folosesc URL-uri pentru a indica locația lor acestea având un caracter dinamic.

Modul de comunicare

Tehnologiile distribuite bazate pe obiecte cum ar fi COM/DCOM și CORBA suportă comunicații sincrone stil RPC. JMS suportă în mod specific comunicațiile asincrone, însă totuși este posibilă construirea de aplicații JMS cu comunicare sincronă . Serviciile Web pot fi folosite atât în modul de comunicare sincron cât și cel asincron.

Descoperirea serviciilor și suport registru

Tehnologia utilizată în construirea SOA ar trebui să prevadă un mecanism care să le permită consumatorilor să descopere în mod dinamic serviciile disponibile dintr-un registru și pentru furnizor să fie posibilă publicarea serviciilor sale, care apoi vor fi disponibile publicului.

CORBA oferă funcționalități standard de descoperire de servicii și suport registru, cum ar fi serviciul Naming, ce mapează un nume logic la o referință obiect, și serviciu Trading, care permite găsirea unui serviciu pe baza proprietăților specificate ale serviciului. Serviciile Web folosesc UDDI, un registru cu scop general ce poate fi folosit pentru a interoga serviciile disponibile.

Securitatea

Securitatea este principala preocupare mai ales atunci când se construiesc infrastructuri de aplicații distribuite pe scară largă. Aceasta implică caracteristici cum ar fi autentificarea, autorizarea, criptarea, integritatea datelor și auditul acestora.

JMS oferă standarde de securitate compatibile J2EE în mare parte puse în aplicare de către furnizorul JMS fiind specifice acestuia. CORBA asigură securitate prin serviciul de securitate standard CORBA. Principalul dezavantaj al serviciilor Web este că încă se dezbate adoptarea unui standard general acceptat privind implementarea unui mecanism sofisticat de securitate pentru acestă tehnologie. Serviciile Web pot utiliza HTTPS pentru securitate la nivelul de transport, sau alte tehnologii Internet de securitate, cum ar fi SSL sau semnătura XML. Efortul de standardizare este în principal în jurul standardului WS-Security, ce va permite un model interoperabil de securitate punct-la-punct în viitor.

Suport tranzacțional

Anumite aplicații necesită ca datele să fie persistente și tranzacționale. Serviciile Web în prezent, nu suportă tranzacțiile. WS-Coordination și WS-Transactions sunt modele de standarde în curs de adoptare pentru serviciile Web ce vor face posibile modelele tranzacționale cu compensare slab cuplate. JMS suportă tranzacții doar până la punctul de intrare în coada de mesaje, consumatorul mesajului fiind responsabil pentru suportul tranzacțional după ce mesajul este extras din coada de așteptare. CORBA oferă un modelul tranzacțional satisfăcător numit CORBA Object Transaction Service ce permite atât tranzacții cu viață scurtă pe bazele de date cât și tranzacții de afaceri cu durată extinsă ce pot implica integrarea cu diferite sisteme de afaceri autonome.

Tabelul 2.2 afișează o comparație completă a acestor tehnologii bazată pe caracteristicile și funcțiile discutate:

Tabel 2.2 Compararea caracteristicilor tehnologiilor orientate pe servicii

După cum se poate observa din tabelul de mai sus, serviciile Web oferă o îmbunătățire semnificativă în evoluția mediilor de calcul orientate pe servicii. Serviciile Web oferă independență de platformă, cuplaj slab și comunicații bazate fundamental pe standarde Internet deschis, noua abordare pentru dezvoltarea de aplicații oferă avantajul interacțiunii flexibile între partenerii de afaceri și ușurință în rezolvarea complexității integrării între aplicațiile distribuite.

Cu toate acestea, tehnologiile de servicii Web sunt încă în proces de evoluție și există în continuare eforturi pentru ca serviciile Web să ofere caracteristici și funcționalități suplimentare, cum ar fi securitatea și suportul tranzacțional. În timp ce, J2EE și CORBA sunt medii de calcul robuste și mature ce oferă caracteristici satisfăcătoare, fiabilitate și scalabilitate.

O altă preocupare atunci când se are în vedere construirea unui SOA este că tehnologia ar trebui să permită dezvoltarea de aplicații în mod rapid (RAD), cu asigurarea unui model de programare universal, criteriu pe care serviciile Web îl îndeplinesc. Deși CORBA este o tehnologie utilizată pe scară largă și oferă un mediu de dezvoltare bogat, este nevoie să se învețe un nou model de programare și nu permite dezvoltarea rapidă la costuri reduse de aplicații.

În prezent, serviciile Web câștigă teren ca tehnologie dominantă în detrimentul celorlalte tehnologii. Evoluțiile viitoare ale serviciilor Web vor stabili acceptabilitatea și competența acestei tehnologii, determinându-i poziția între opțiunile disponibile pentru dezvoltarea de arhitecturi orientate pe servicii.

Implementarea prototipului unei infrastructuri conforme cu metodologia SOA

Pe piața de astăzi, este esențial ca aplicațiile dezvoltate să poată comunica între ele utilizând Internetul. Aplicații sunt infinit mai utile atunci când pot accesa servicii Web pentru a prelua și schimba informații.

Aplicațiile de astăzi comunică prin apeluri de procedură la distanță (RPC) între obiecte cum ar fi DCOM și CORBA. Dar RPC prezintă probleme de compatibilitate și de securitate – de exemplu, pentru a accesa un serviciu de la distanță, calculatorul client trebuie să furnizeze programului de pe server un anumit argument. Ce se întâmplă dacă programul ce furnizează serviciul se schimbă? Ce se va întâmpla cu clienții ce solicită serviciul?

O altă problemă apare atunci când firewall-urile și servere-le Proxy blochează acest tip de trafic (lucru pe care îl fac în mod normal). O modalitate universală pentru ca aplicațiile să comunice ar fi prin intermediul protocolului HTTP, deoarece HTTP este suportat de toate serverele și browser-ele Internet – cu toate acestea, HTTP nu a fost proiectat pentru aceste tipuri de servicii, însă, SOAP ne oferă o soluție elegantă pentru acestă problemă.

SOAP este un protocol simplu bazat pe XML ce permite aplicațiilor să schimbe informații prin HTTP. SOAP și serviciile Web oferă un nivel de abstractizare, ca o modalitate de a facilita comunicarea între aplicațiile ce rulează pe sisteme de operare diferite, folosind diferite tehnologii și limbaje de programare, fără ca transmisiile de date sa fie oprite de firewall-uri.

Un mesaj trimis prin SOAP formatat ca un document XML. Acesta este alcătuit din trei părți – un plic, un antet și un corp. Plicul încapsulează antetul și corpul mesajului. Acesta conține informațiile necesare pentru procesarea mesajului, inclusiv o descriere a tipului de date găsite în interiorul plicului. Mai conține de asemenea, informații despre expeditor și destinatarul mesajului. Informațiile din antet pot efectua funcții, cum ar fi autentificarea. Corpul mesajului conține datele propriu-zise. Datele ar putea fi o solicitare de informații – de exemplu, atunci când un solicitant de servicii caută într-un registru de servicii un serviciu Web. Sau ar putea fi răspuns la o cerere de informații, cum ar fi atunci când registrul trimite înapoi un descriptor de serviciu. Pentru exemplificarea acestor aspecte în continuare se consideră un exemplu de implementare a unei infrastructuri ce are la bază serviciile Web.

Acest studiu de caz prezintă implementarea unei infrastructuri ce se bazează pe specificațiile SOA, modelul implementat face referire la un caz ipotetic dar cu caracteristici întâlnite în lumea reală. Arhitectura ilustrează modul de interconectare a trei aplicații uzuale din activitatea unei întreprinderi și anume o aplicație CRM, o aplicație de facturare si o aplicație de gestiune a stocurilor, cele trei aplicații sunt aplicații bazate pe servicii Web, acestea vor folosi serviciile puse la dispoziție de server-ul întreprinderii ce are încapsulate implementările serviciilor și a logicii conforme cu procesele de afaceri. Datele sunt stocate în sistemul de gestiune a bazelor de date, Microsoft SQL Server. Pentru a evidenția independența de platformă a infrastructurii aplicațiile vor fi dezvoltate după următorul scenariu:

Aplicația server va rula sub platforma Microsoft Windows întru-cât în scenariul considerat întreprinderea folosește produse Microsoft pentru infrastructura informatică proprie iar soluția de stocare a datelor este tot un produs Microsoft, Microsoft SQL Server.

Luând în considerare costul achiziției de licențe pentru stațiile de lucru și compatibilitatea platformei cu dispozitivele de identificare a produselor folosite de angajații depozitului firmei întreprinderea în cauză decide dezvoltarea aplicației de stocuri pe platforma Linux.

Aplicația CRM va fi dezvoltată să ruleze pe platforma Microsoft Windows, iar aplicația de facturare va fi dezvoltată pentru platforma Apple Mac OS X.

Figura de mai jos ilustrează în mod conceptual infrastructura tratată.

Fig.3.1 Modelul conceptual al infrastructurii

Sistemul va fi dezvoltat în totalitate în limbajul de programare C++ utilizând tehnologiile Qt și KD SOAP pentru realizarea aplicațiilor, respectiv pentru implementarea funcționalităților specifice arhitecturilor bazate pe servicii Web, de asemenea se va utiliza limbajul T-SQL specific SGBD-ului Microsoft SQL Server pentru realizarea bazelor de date si manipularea datelor stocate în acestea.

Qt este un framework cross-platform pentru dezvoltarea de aplicații și interfețe utilizator ce poate fi folosit cu limbajul de programare C++, acest framework este prezent sub doua tipuri de licențe una open-source (GPL v.3 și LGPL v2.1) și una comercială fiind un produs Digia.

Qt este un mediu de dezvoltare complet cu instrumente concepute pentru a simplifica crearea de aplicații și interfețe utilizator pentru desktop, platforme mobile și echipamente integrate. Suportă platformele desktop Windows, Linux/X11, Mac OS X, Embedded Linux, Android și Windows și platformele mobile Android, iOS, BlackBerry 10, Sailfish OS, Tizen și WinRT.

Pentru a putea implementa funcționalitățile specifice serviciilor Web în completarea framework-ului Qt a fost utilizată tehnologia KD SOAP produsă de KDAB acesta furnizează suportul necesar pentru realizarea implementărilor pe parte de server dar si pe parte de client pentru realizarea unei infrastructuri conforme SOA.

KD SOAP este un instrument pentru crearea de aplicații client pentru serviciile Web și oferă mijloacele de creare de servicii Web fără a fi nevoie de componente suplimentare, cum ar fi un server Web dedicat.

KD SOAP face posibilă interacțiunea cu aplicațiile ce au API-uri ce pot fi exportate ca obiecte SOAP. Serviciul Web oferă apoi o interfață către implementare accesibilă mașinii prin intermediul protocolul HTTP.

Apelurile metodelor la distanță sunt tratate prin standardul SOAP ce descrie apelurile de metode, parametrii și valorile returnate ca documente XML.

KD SOAP este, de asemenea, un instrument pentru crearea de implementări de servere de servicii Web. Acest lucru face posibil exportul de API-uri ale aplicațiilor ca obiecte SOAP. Aplicațiile client le pot accesa apoi prin protocolul HTTP. Modulul server al KD SOAP conține toate funcționalitățile necesare, care să permită implementarea de servicii Web fără a fi nevoie de un server Web extern.

Funcționalități ale KD SOAP

Biblioteca KD SOAP oferă un nivel de abstractizare atât pentru transportul efectiv, precum și pentru construirea de obiecte de date și apeluri de metode. (Acesta din urmă ușurează dezvoltatorii de aplicații de scrierea manuală a codului necesar pentru manipularea XML-urilor, permițându-le să construiască structuri de date complexe arbitrare folosind simple clase C++).

abstractizarea transportului oferă modalitatea de apelare sincronă cât și asincronă prin metoda Qt signal/Slot a metodei la distanță și manipularea răspunsului.

Modulul server suportă atât manipulări single-threaded precum și multi- threaded a cererilor și execuției metodelor.

KD SOAP asistă programatorul cu generatorul de cod kdwsdl2cpp, ce furnizează mijloace suplimentare pentru creșterea productivității acestuia prin generarea de API proxy pe partea de client sau interfețe obiect pe partea de server bazate pe descrierea formală din fișierul WSDL. Folosind clasele generate de această abordare se permite verificare în timpul dezvoltării a tipurilor și oferirea comportamentul de tip "în proces" al obiectelor (de exemplu, folosind tipurile de date C++ ca parametri și valorile returnate ale fiecărei metode a serviciilor Web).

KD SOAP are o licență open-source de tip LGPL și una comercială necesară dacă biblioteca este folosită în scopuri comerciale.

Fig.3.2 Reprezentare abstractă a modului de comunicare între aplicații prin intermediul serviciilor Web.

Pentru proiectarea interfețelor serviciilor s-a utilizat mediul de dezvoltare integrat Eclipse generându-se cu ajutorul acestuia fișierele WSDL necesare pentru crearea implementărilor serviciilor Web și utilizării acestora de către aplicațiile client.

Fig.3.3 Reprezentare grafică a interfeței serviciului utilizat în cadrul aplicației CRM realizată cu ajutorul mediului de dezvoltare integrat Eclipse

Fig.3.4 Secvență din fișierul WSDL al serviciului pentru clienți

În secțiunea următoare sunt prezentare aplicațiile ce constituie infrastructura modelată începând cu aplicația server responsabilă cu managementul și controlul cererilor venite de la aplicațiile client pentru serviciile Web oferite.

Fig.3.5 Aplicația server (platforma Windows) cu toate serviciile active

Fig.3.6 Aplicația server cu doua servicii oprite

Aplicația CRM este responsabilă în cadrul arhitecturii realizate cu managementul relațiilor cu partenerii de afacerii (clienți și furnizori), stocând datele de contact ale acestora ce sunt utilizate în cadrul sistemului de către aplicațiile de facturare respectiv de management al stocului unde sunt folosite datele furnizorilor atunci când sunt introduse NIR-uri și facturi furnizor, documentele emise pentru un partener anume pot fi regăsite și în cadrul aplicației CRM prin intermediul serviciilor puse la dispoziție de server, pe care aplicația CRM le utilizează pentru a extrage informații contextuale ce privesc un anumit partener de afaceri.

Fig.3.7 Cadre din aplicația CRM (platforma Windows)

Aplicația de gestiune a stocurilor folosește serviciile disponibile pentru a aduce modificări stocului curent și nomenclatorului de produse al întreprinderii, acesta folosește și informații despre furnizori acestea fiind administrate de aplicația CRM și sunt puse la dispoziție prin intermediul unui serviciu Web specializat.

Fig.3.8 Aplicația de gestiune a stocurilor (platforma Linux)

Fig.3.9 Adăugarea unui NIR în cadrul aplicației de gestiune a stocurilor

Fig.3.10 Adăugarea de produse în aplicația de gestiune a stocurilor

Fig.3.11 Adăugarea unei facturi furnizor în cadrul aplicației de gestiune a stocurilor, în scopul urmăririi acesteia în cadrul platformei integrate

Aplicația de facturare folosește informații furnizare de serviciile Web precum datele clienților și oferta de produse existentă în acest moment în stocul întreprinderii.

Fig.3.12 Generarea unei facturi ( platforma Apple Mac OS X)

Concluzii

Arhitecturile orientate pe servicii (SOA) oferă o platformă comună și un mediu de execuție pentru aplicațiile eterogene construite cu diverse tehnologii. Orientarea pe servicii sprijină interoperabilitatea dintre aceste aplicații prin ascunderea structuri lor interne în mod reciproc creând un sistem distribuit flexibil și slab cuplat.

Dezvoltare orientată pe servicii reprezintă o evoluția naturală a dezvoltării de software bazat pe componente, serviciile fiind create din componente. Dezvoltarea de servicii este partea centrală a orientării pe servicii ce reprezintă o provocare serioasă deoarece interfața unui serviciu ar trebui să fie suficient de versatilă pentru a sprijini nevoile sistemelor de calcul interne, precum și a altor consumatori necunoscuți din cadrul întreprinderii sau din organizații externe la momentul proiectării acesteia.

SOA permite crearea de servicii cu logică reutilizabilă, flexibile și slab cuplate ceea ce face dezvoltare bazată pe servicii valoroasă pentru multe organizații. Întreprinderile obțin beneficii din implementarea SOA pentru ca serviciile sunt capabile să exprime nu numai proprietățile tehnice ale mediului de calcul ci se pot concentra și asupra reprezentării și rezolvării unor funcționalități de afaceri de specialitate și a unor probleme de domeniu. Serviciile aflate la distanță pot să fi compuse în procese de afaceri, fluxul de proces fiind esențial pentru o organizație ca să-și îndeplinească activitățile sale în mod eficient, într-un sistem informatic.

Implementarea SOA în întreprinderi permite integrare directă a logicii aplicațiilor și construirea de structuri de aplicații sofisticate specifice nevoilor întreprinderii. SOA este cel mai bine realizată în cadrul întreprinderilor prin intermediul tehnologiilor sistemelor de management al proceselor de afaceri deoarece informațiile de proces sunt construite de utilizarea serviciilor individuale iar procesul de afaceri are la baza serviciile. Integrarea aplicațiilor întreprinderilor prin intermediul serviciilor Web este o abordare la fel de bună pentru realizarea SOA deoarece înlocuiește tehnologiile tradiționale middleware și aduce îmbunătățiri în construcția de structuri de aplicații.

Deși SOA este independentă de o tehnologie specifică, ea își amplifică filosofia cu ajutorul tehnologiei serviciilor Web, cu toate acestea, aceste tehnologii sunt încă în dezvoltare și suportul pentru implementarea matură a SOA pe baza serviciilor Web este o țintă viitoare și o zonă de lucru pentru foarte multe organizații și medii de calcul.

În cadrul acestui studiu, o infrastructură prototip bazată pe servicii a fost dezvoltată pentru a ilustra caracteristicile fundamentale ale SOA. La nivelul de bază, studiul de caz demonstrează interoperabilitatea diferitelor platforme, reutilizarea serviciilor slab cuplate, a logicii de afaceri, precum și consumul de servicii din alte module software pentru a forma o interacțiune bazată pe servicii între aplicații.

SOA poate fi pusă în aplicare prin combinarea diferitelor instrumente ce oferă funcționalități specializate pentru construirea mediului de execuție. O abordare destul de nouă este reprezentată de oferirea de framework-uri ce furnizează toate instrumentele și modelele necesare în aceiași infrastructură. În prezent, în industria specifică există oferte diverse, inclusiv platforme integrare, suite de management și monitorizarea SOA, și colecții de instrumente de proiectare, crearea și de modelare de servicii. Din păcate, evoluțiile open source în acest domeniu sunt încă în faza incipientă și de cele mai multe ori implementările actuale nu îndeplinesc în mod complet cerințele cadru ale abordării SOA.

SOA este din ce în ce mai adoptabilă și operabilă pentru că organizațiile continuă să sprijine implementările bazate pe servicii. În viitor, SOA va avea o influență semnificativă asupra dezvoltării de infrastructurii de aplicații enterprise odată cu facilitarea dezvoltării tehnologiilor utilizate.

SOA are o influență extinsă în fiecare etapă de dezvoltare a aplicațiilor, inclusiv analiza și proiectarea serviciilor individuale, implementarea de servicii, crearea de aplicații noi din servicii existente prin compoziție și implementarea de servicii prin intermediul strategiilor și abordărilor orientate pe servicii. SOA obligă și aplică principiile sale și considerentele arhitecturale în aceste etape ale dezvoltării de aplicații. In acest context, este posibil să se elaboreze și să extindă specializarea conceptelor aplicabile și subiectele discutate în cadrul acestei lucrări.

Bibliografie

James McGovern, Sameer Tyagi, Michael E. Stevens, Sunil Mathew Java Web Services Architecture, Morgan Kaufmann Publishers, 2003

L. Bass, P. Clements, R. Kazman Software Architecture in Practice, Addision-Wesley, 1997

Raphael Malveau, Thomas J. Mowbray Software Architecture: Basic Training, Prentice Hall PTR, 16 Aprilie 2004

E. Yourdon, L. Constantine Structured Design, Prentice Hall, 1975

G. Booch Object Oriented Design with Applications, Benjamin-Cummings Publishing, 1990

C. Szyperski Component Software: Beyond Object-Oriented Programming, Addision-Wesley, 1998

Dirk Slama, Karl Banke, Dirk Krafzig Service Oriented Architecture: Inventory of Distributed Computing Concepts, Prentice Hall PTR, 10 Decembrie 2004

Bieber, Carpenter, Stevens Jini Technology Architectural Overview, Sun Microsystems, 2001

World Wide Web Consortium (W3C), Web Services Architecture, 11 Februarie 2004, http://www.w3.org/TR/ws-arch/

Ali Arsanjani How to Identify, Specify and Realize Services for your SOA (Part II and III), IBM, 2005, http://www.ebizq.net/topics/dev_tools/features/5632.html

Sun Microsystems, Java 2 Platform Enterprise Edition Specification, Version 5.0 http://java.sun.com/j2ee/

Jeff A. Estefan, Exploring Open Software Standards for Enterprise e-business Computing, 28 August 2000, IBM International Technical Support Organization.

Sun Microsystems, Java Message Service Specification, Version 1.1 http://java.sun.com/products/jms/docs.html

Sun Microsystems, Remote Method Invocation Architecture and Functional Specification, http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html

Microsoft Corporation, Component Object Model (COM), http://www.microsoft.com/com/default.mspx

Sara Williams, Charlie Kindel The Component Object Model: A Technical Overview, Microsoft Corporation, October 1994.

Microsoft Corporation, DCOM Technical Overview, November 1996

Object Management Group, Common Object Request Broker Architecture: Core Specification, Version 3.0.3, March 2004 http://www.omg.org/technology/documents/corba_spec_catalog.htm

World Wide Web Consortium (W3C), Extensible Markup Language (XML) Specification, Version 1.0, 04 Februarie 2004, http://www.w3.org/TR/REC-xml/

World Wide Web Consortium (W3C), SOAP Specification, Version 1.2, 24 Iunie 2003, http://www.w3.org/TR/soap/

World Wide Web Consortium (W3C), Web Services Description Language Specification, Version 1.1, 15 Martie 2001, http://www.w3.org/TR/wsdl

OASIS UDDI Technical Committee, Universal Description, Discovery and Integration Specification, Version 3.0.2, 2004, http://uddi.org/pubs/uddi_v3.htm

M. Endrei, J. Ang, A. Arsanjani, S. Chua, P. Comte, P. Krogdahl, M. Luo, T. Newling Patterns: Service Oriented Architecture and Web Services, IBM Redbook, Aprilie 2004

M. Fowler UML Distilled: Applying the Standard Object Modeling Language, Addision-Wesley, 1997

B. Meyer Object Oriented Software Construction, Prentice Hall, 1997

Boris Lublinsky SOA Design: Meeting in the Middle, 20August 2004

Greg Lomow, Eric Newcomer Introduction to SOA with Web Services, Addison Wesley, 2005

Lawrence Wilkes, Richard Veryard Service Oriented Architecture: Considerations for Agile Systems, CBDI Forum, Aprilie 2004

Object Management Group, Unified Modeling Language Specifications http://www.uml.org/

Object Management Group, Unified Modeling Language Specification, Version 2.0, 8 Octombrie 2004

Simon Johnston, UML 2.0 Profile for Software Services, IBM, 13 Aprilie 2005

Object Management Group, Model Driven Architecture Specifications, http://www.omg.org/mda/specs.htm

The Middleware Company, SOA Blueprints Specification, Version 0.5, Iunie 2004 http://www.middlewareresearch.com/soa-blueprints/

Kaj van de Loo, Implementing an Enterprise Services Architecture, 27 Iulie 2004

Apache Software Foundation, Beehive Project, Version 1.0 http://incubator.apache.org/beehive/

Sun Microsystems, Java Community Process, JSR 175: A Metadata Facility for the Java Programming Language, 30 Septembrie 2004 http://www.jcp.org/en/jsr/detail?id=175

Apache Software Foundation, the Apache Struts Web Application Framework, http://struts.apache.org/

Sun Microsystems, Java Community Process, JSR 181: Web Services Metadata for the Java Platform, 27 Iunie 2005, http://www.jcp.org/en/jsr/detail?id=181

Apache Software Foundation, Tomcat Project, http://jakarta.apache.org/tomcat/

Amazon Web Services Home Page, www.amazon.com/Webservices

James M. Snell, Resource-Oriented vs. Activity-Oriented Web Services, Oct. 2004

David S. Linthicum Approaching Application Integration, Addision Wesley, 13Feb. 2004

Abraham Kang, Enterprise Application Integration Using J2EE, 9 August 2002

Manoj Seth, Web Services – A Fit for EAI (Part 1 and 2), Octombrie 2002 http://www.developer.com/tech/article.php/10923_1489501_1

Martin Keen, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren, Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM Red Book, Iulie 2004

Naveen Balani, Model and Build ESB SOA Frameworks, 15 Martie 2005

Sun Microsystems, Java Community Process, JSR 168, Portlet Specification, v1.0, Octombrie 2003, http://www.jcp.org/en/jsr/detail?id=168

Bryan Castle, Introduction to Web Services for Remote Portlets, 15 Aprilie 2005

Thomas Schaeck, Web Services for Remote Portlets (WSRP) Whitepaper, 22 Septembrie 2002, IBM Corporation

World Wide Web Consortium (W3C), Web Service Choreography Interface (WSCI) Specification, Version 1.0, 8 August 2002, http://www.w3.org/TR/wsci/

OASIS, Business Process Execution Language for Web Services (BPEL4WS) Specification, Version 1.1, 5 Mai 2003, http://dev2dev.bea.com/Webservices/BPEL4WS.html

A. Mani, A. Nagarajan Understanding Quality of Service for Web Services, Ianuarie 2002, IBM DeveloperWorks

Global Grid Forum (GGF), the Open Grid Services Architecture, Informational Document, version 1.0, 29 Ianuarie 2005, http://www.globus.org/ogsa/