curs isi
DESCRIPTION
Curs ISI.pdfTRANSCRIPT
1
Curs „Integrarea Sistemelor Informatice”
An 2, Master BDSA Lect. Univ. Dr. Diaconiţa Vlad
Începutul integrării în domeniul echipamentelor informatice poate fi considerat
momentul apariţiei circuitului integrat în 1959 ([LUBO07]). Acest circuit a reunit alte
descoperiri cum ar fi: tranzistorii, rezistenţele şi condensatorii pe o singură pastilă de siliciu
(silicon chip). Într-o lucrare din anul 1965, Gordon Moore, membru fondator Intel, prezicea
că numărul de tranzistori pe un microcip se va dubla la fiecare 18 luni [MOOR65]. Această
lege şi-a demonstrat valabilitatea în cei 45 de ani care au trecut de la formularea ei. Acesta
poate fi motivul pentru care avem nevoie de integrare: pentru a ne descurca în condiţiile unei
complexităţi crescute. În acest context putem aminti principiile managementului complexităţii
care sunt: descompunerea în părţi mai mici şi mai uşor de manipulat (divide et impera),
construirea unei interfeţe standard pentru ca aceste părţi să comunice, apoi dezvoltarea unei
structuri ierarhice unde informaţia este din ce în ce mai abstractizată odată ce urcăm în
ierarhie.
Un pas important în evoluţia integrării sistemelor informatice este apariţia tehnologiei
middleware. Acesta a apărut spre sfârşitul anilor 80 pentru a descrie un nivel de mediere între
sistemele de operare şi aplicaţiile dintr-o arhitectură distribuită. A început să fie folosit la
scară mai largă o dată cu dezvoltarea bazele de date relaţionale de la mijlocul anilor 90,
realizând o integrare bazată pe mesaje, mijlocind comunicarea între celelalte componente ale
sistemului informatic. Middleware-ul conţine servere web şi de aplicaţii, fiind baza
tehnologiile moderne ca arhitectura pe trei niveluri sau cea orientată pe servicii. Această
tehnologie este
În momentul de faţă complexitatea continuă să crească, atât la nivelul instrumentelor
cât şi la nivelul programelor şi a sistemelor informatice. Tendinţa este de utilizare a
orientării pe servicii în cât mai multe domenii ale informatizării.
Noţiunea de integrare la nivelul întreprinderii, aşa cum este înţeleasă în cadrul modelării
se referă la un set de concepte şi abordări, cum ar fi: definirea arhitecturii globale a
sistemului, consistenţa luării deciziilor la nivel de sistem, noţiunea procesului care modelează
fluxul de activitate peste marginile funcţiilor, alocării dinamice a resurselor cât şi a
consistenţei datelor [VERN02].
Integrarea duce la complexitate, aceasta din urmă determină la rândul ei diversificarea.
Din punctul de vedere al diversităţii, integrarea este efectul evoluţiei ciclice şi progresive a
unei multitudini de tehnologii fiind sprijinită de performanţele şi de expertiza profesioniştilor
din domeniu. Putem considera că integrarea este mai mult decât o simplă interoperabilitate şi
2
implică un nivel de dependenţă funcţională. Dacă sistemele interoperabile pot funcţiona
separat, un sistem integrat este afectat în cazul întreruperii fluxului de servicii.
Utilizarea de standarde eficiente pentru reprezentarea datelor, cunoştinţelor şi serviciilor
este fundamentală pentru realizarea interoperabilităţii între sisteme. În lucrarea [JAGR06] se
propun următoarele standarde pentru realizarea unei integrări performante:
standardul OMG pentru definirea interfeţelor serviciilor pentru un sistem Product
Management System (PDM) într-un mediu distribuit şi orientat pe obiecte;
standardul STEP (ISO 10303) pentru definirea reprezentării datelor;
standardul XML pentru schimbul de date structurate si semi-structurate.
Înainte de a folosi un tip de integrare, trebuie înţelese foarte bine aspectele legate de
oportunităţile oferite de acesta şi de riscurile implicate. Numai atunci, se poate face o evaluare
obiectiva. Posibilitatea de a avea acces direct la serviciile unei aplicaţii şi ca urmare
posibilitatea integrării sporite acestor aplicaţii, reprezintă un beneficiu important. Totuşi, acest
beneficiu este urmat de un risc real mare datorita costurilor de implementare a integrării
bazate pe servicii, deoarece aceste costuri ar putea, în anumite cazuri, sa depăşească valoarea
creata de integrare.
Sintetizând, se poate defini integrarea în domeniul sistemelor informaţionale ca o
activitate ce reuneşte oameni, echipamente, programe şi cunoştinţe.
In literatura de specialitate ([LINT03], [JAGR06]) se pune accent pe patru strategii de
integrare care chiar dacă se regăsesc sub diferite denumiri:
prin portal;
prin procese de afaceri;
orientată pe date;
orientată pe servicii (SOA).
Portalul este privit în primul rând ca soluţie de integrare la nivelul unei instituţii, cu
posibilităţi de extindere a serviciile şi către utilizatorii din afara acesteia. Integrarea orientată
pe portal permite unui utilizator să aibă acces la o multitudine de sisteme, în cadrul sau/şi
în afara întreprinderii sale. Portalul include o tehnologie care externalizează informaţiile din
sistemele integrate folosind o interfaţă unificată bazată pe tehnologia Web [LUVE09_2].
Abordări mai recente în integrarea orientată pe portal, precum cele descrise în [YANG09]
utilizează tehnici de ontologie şi lingvistică pentru dezvoltarea de tehnologii automatizate de
adnotare, care împreună cu metode automate de construire a ontologiile ajută la dezvoltarea
de portaluri semantice.
În lucrarea [ATKA09] se arată cum folosind tehnologiile de web semantic şi RDF
(metodă pentru modelare şi descriere conceptuală a informaţiilor) se pot descrie informaţii de
tip geo-portal utilizând metadate bazate pe ontologii.
3
Soluțiile comerciale (Oracle Portal, spre exemplu) conțin diverse instrumente pentru a
capta si integra date din surse diverse de date cum ar fi bazele de date relaționale, serviciile
web, foi de lucru, XML, site-uri web sau sisteme ERP precum SAP-ul. Se pot folosi si
abordări orientate pe PDK ( Portlet Developer Kit) pentru a croi mai bine soluții de integrare
personalizate
Integrarea prin procese de afaceri se realizează prin coordonarea interacţiunilor între
mai multe sisteme, urmărind starea fiecărui proces de afaceri în cadrul fiecăruia dintre sisteme
şi permiţând raportarea centralizată. Fiecare dintre sistemele de aplicaţii disparate
completează o parte dintr-o funcţie de business şi se doreşte integrarea acestora în aşa fel încât
funcţia de business să poată fi completată în mod automat [LUBO07].
Acest tip de integrare se realizează prin crearea unui nivel de logică a aplicaţiei, care va
conţine procese ce vor fi gestionate unitar şi vor fi definite pe baza setului curent de procese şi
date, existent în aplicaţiile a căror integrare este vizată.
Integrarea prin procese de afaceri reprezintă un mecanism de gestiune a datelor
interschimbate şi de apelare a proceselor într-un mod unitar, astfel încât să se permită
administrarea şi execuţia proceselor comune care există în cadrul aplicaţiilor şi între acestea.
Scopul este de a grupa procese relevante pentru a obţine valoare maximă, susţinând fluxul de
informaţii şi controlul logic între aceste procese. Această abordare completează soluţiile de
integrare a aplicaţiilor (soluţii care includ serverele de aplicaţii, obiecte distribuite şi alte
niveluri middleware) prin oferirea unui mecanism pentru legarea proceselor şi pentru
crearea soluţiilor de tip proces-proces care automatizează o sarcină odată ce aceasta a fost
realizată manual.
Dacă integrarea clasică a aplicaţiilor este o soluţie tactică, motivată de cerinţele a două sau
mai multe sisteme de a comunica, atunci putem considera integrarea proceselor de afaceri ca
fiind una strategică, gestionând regulile de afaceri pentru a determina cum ar trebui să
interacţioneze sistemele astfel încât să susţină valoarea afacerii din fiecare sistem folosind un
model de afaceri abstract. Comparând, dacă integrarea tradiţională a aplicaţiilor se referă la
schimbul de informaţii între două sau mai multe sisteme fără ca procesele interne să fie
vizibile; integrarea proceselor de afaceri duce la un model de proces şi mută informaţia între
aplicaţii conform modelului respectiv.
Integrarea orientată pe procese de afaceri este cel mai bine definită prin construirea unor
reguli, într-o secvenţă logică pentru: a realiza interschimbul de informaţie între sistemele
participante, a vizualiza procesele pe niveluri de aplicaţii şi pentru a crea procese abstracte
comune atât pentru sistemele interne cât şi pentru cele externe. Există trei servicii majore
oferite de către acest tip de integrare: vizualizarea proceselor conţinute de sistemele în cauză,
abstractizarea interfeţei, o măsură în timp real a performanţei proceselor de afaceri. Se
folosește cel mai adesea un Enterprise Service Bus care permite conectivitatea intre aplicații si
servicii si pune la dispoziție tehnologia pentru a automatiza procesele (figura 1).
4
Figură 1 Arhitectura ESB
În abordarea orientată pe date (informaţii), pentru integrarea aplicaţiilor este necesar
ca schimbul de informaţii să apară între sursele de date, iar aplicaţiile suferă modificări
minime.
Problema schimbului de informaţii la nivelul surselor de date (cel mai adesea BD) apare
într-o diversitate de situaţii, atât comerciale (spre exemplu două sau mai multe companii vor
să-şi integreze anumite date) cât şi ştiinţifice (combinarea rezultatelor cercetării provenite din
două dicţionare diferite).
Datele pot fi:
Structurate, stocate în diverse baze de date relaţionale
Nestructurate: documente electronice, dosare de clienţi, poze, filme, date
provenite de la senzori, date stocate în dispozitive medicale etc
Semi-structurate: XML, EDI , SWIFT
Integrarea informaţiei la nivel de întreprindere (Enterprise Information Integration -
EII), este un cadru de lucru (framework) ce are ca scop combinarea de date provenite din
diferite surse eterogene şi eventual distribuite: baze de date, depozite de date, fişiere XML,
fişiere LDAP (protocol pentru interogarea şi modificarea datelor), fişiere ASCII etc pentru ca
utilizatorul sa aibă o viziune unitară a acestor date. Acest concept este diferit de integrarea
clasică orientată pe informaţii care presupune un schimb de date între diferite surse
Folosirea unei platforme de integrare a informaţiei la nivel de informaţii nu necesită
modificări ale aplicaţiilor sursă sau ţintă, eventual anumite optimizări pentru realizarea mai
rapidă a accesului la date. Probleme pot apărea datorită interfeţelor diferite care sunt folosite
pentru a accesa un model al bazei de date diferit (baza de date virtuală). O abordare de tip EII
poate fi folosită şi într-o soluţie în care trebuie să folosim date în timp real, împreună cu date
dintr-un depozit de date, pentru a combina, spre exemplu, date istorice cu date actuale.
5
În cadrul integrării orientate pe informaţii pot include şi tehnica de ETL cu procesele sale
(extrage, transformă şi încarcă) care sunt în general folosite pentru a popula un depozit de
date. Dacă se folosesc date dintr-o singura bază de date, sau din mai multe baze de date
compatibile legate între ele, putem folosi ca soluţie de integrare depozitul virtual, împreună cu
tehnicile de optimizare a regăsirilor, cum ar fi: partiţionare, indexare, utilizarea hint-urilor sau
a funcţiilor analitice aşa cum le-am descris în articolul [LUVE08].
Oracle Database Gateway este un produs care permite conectare la mai multe surse de
date, cum ar fi: DB2, Sybase, Informix, SQL Server, IMS, VSAM, Adabas sau alte surse de
date prin ODBC/JDBC (MySQL, Fox, Access, Excel). Pentru interoperabilitate între sisteme
disparate, translații de limbaj SQL, de date şi de metadate sunt necesare chiar şi atunci când
sistemele non-Oracle sunt bazate pe SQL. Gateway-ul oferă facilitați de a translata dintr-un
dialect de limbaj, cel mai adesea SQL, în altul. Câteva exemple de transformări se regăsesc în
tabelul 1.
Tabel 1 Diferențe de dialect SQL
Oracle Non-Oracle
select upper(prenume) from angajati; select uppercase(prenume) from angajati;
SELECT * FROM sys.dba_objects
WHERE object_type = 'TABLE';
SELECT * FROM catalog_objects
VARCHAR2, NUMBER WHERE object_name LIKE '%EP%'
Oracle Data Integrator (ODI) își are rădăcinile în achiziționarea companiei Sunopsis de
către Oracle în 2006 şi este produsul strategic al companiei în ceea ce priveşte integrarea
orientată pe date. Precum se arată în figura 2 arhitectura lui este bazată pe ELT care
presupune mutarea datelor direct în baza de date destinaţie şi transformarea acestora ulterioară
folosind mecanismele SGBDR-ului respectiv.
Figură 2 ETL vs ELT
6
Big Data este unul din trendurile principale care foloseşte informaţiile pentru
îmbunătăţirea modelelor de afaceri. Este o combinaţie de tehnologii orientate pe
managementul datelor care permit stocarea, gestionarea şi manipularea unor volume vaste de
date la viteza cerută şi la timpul potrivit pentru a obţine avantaje relevante şi reacție promptă.
In general se caută tipare care să sugereze o schimbare majoră, spre exemplu preferinţele
clienţilor se modifică sau sunt elemente în cadrul companiile care trebuie evaluate până nu
este prea târziu.
Pentru implementate este necesară o infrastructură pentru a asigura scalabilitate,
distribuirea sarcinilor şi managementul datelor.
Caracteristici Big Data
Volum mare de date procesat;
Viteza mare de procesare;
Varietatea datelor surselor;
Veridicitate rezultatelor.
Exemple utilizare:
în producţie, companiile pot monitoriza datele venind de la senzori pentru a
determina cum pot face modificări de procese înainte de apariţia unui eveniment
catastrofal;
în vânzări, se poate facilita creşterea vânzărilor de produse similare atunci când
clientul realizează o tranzacţie;
în medicină, pentru a determina cauzele unei boli şi pentru a oferi medicului
asistenţă în opţiunile de tratament;
în cercetare, institutele se lovesc adesea de insuficienta putere de procesare pentru
a rula modele sofisticate sau pentru a procesa imagini, filme sau alte surse de date
ştiinţifice.
Unele date pot fi stocate în diverse baze de date relaţionale iar altele, cum ar fi documente,
dosare de clienţi, poze, filme, date provenite de la senzori, date stocate în dispozitive medicale
sau de alt tip pot fi nestructurate.
Pentru implementate este necesară o infrastructură pentru a asigura scalabilitate,
distribuirea sarcinilor şi managementul datelor.
Chiar dacă este cea mai recentă soluţie de integrare, în fluxul principal de publicaţii se
acordă cea mai mare atenţie integrării orientate pe servicii.
Termenul de orientat pe servicii există de ceva timp şi s-a folosit în diferite contexte şi cu
diferite scopuri reprezentând o modalitate de a separa problemele. Logica necesară rezolvării
unei probleme poate fi mai bine construită şi îndeplinită dacă este împărţită într-o colecţie de
probleme mai mici şi interconectate fiecare adresându-se unei bucăţi specifice din problema
7
principală. Conceptele de bază ale SOA sunt similare cu tehnica din programare divide et
impera. Divide et impera se bazează pe principiul descompunerii problemei în două sau mai
multe sub-probleme, mai uşoare, care se rezolvă, iar soluţia pentru problema iniţială se
obţine combinând soluţiile sub-problemelor. De multe ori, sub-problemele sunt de acelaşi
tip şi pentru fiecare din ele se poate aplica aceeaşi tactică a descompunerii în sub-
probleme, până când, în urma descompunerilor repetate, se ajunge la probleme care admit
rezolvare imediată. Diferenţa principală constă că în cazul orientării pe servicii
descompunerea se face după criterii funcţionale, elementele componente nefiind doar nişte
copii în miniatură a întregului ci unităţi ce au sens, şi pot funcţiona individual.
Conform [JONE05], chiar dacă termenii de serviciu şi orientare pe servicii există de mult
timp, probleme încă rămân în a definii serviciile din punctul de vedere al: securităţii,
integrităţii, a mediului, disponibilităţii.
Conform [ERL07], integrarea orientată pe servicii permite aplicaţiilor să împartă metode
comune, dar care funcţionează ca unităţi distincte, slab cuplate. Acest proces se realizează fie
prin definirea unor metode care pot fi accesate de toate aplicaţiile, şi ca urmare integrate, fie
prin punerea la dispoziţie a unei infrastructuri pentru asemenea metode, de exemplu serviciile
Web. Serviciile web oferă un standard destinat interoperabilităţii dintre aplicaţiile software
eterogene, dezvoltate pe o diversitate de platforme şi medii de lucru [BODI08]. Metodele pot
fi accesate fie prin stocarea acestora pe un server central (obiecte distribuite), fie printr-un
mecanism de servicii Web standard, cum ar fi .NET. Trebuie înţeles faptul că nu orice
aplicaţie care foloseşte servicii web este orientată pe servicii. SOA reprezintă o arhitectura
bazata pe un set propriu de principii. Serviciile web reprezintă doar un instrument performant
pentru implementarea acestei arhitecturi.
Sistemele orientate pe servicii sunt sisteme proiectate pentru a permite schimbarea şi
adaptarea facilă la noi cerinţe sau metode de implementare. Prin utilizarea modelului orientat
pe servicii este posibila obţinerea unei interoperabilităţi între aplicaţii, indiferent de
platformele şi limbajele de programare utilizate în dezvoltarea acesteia. Dezvoltatorii şi
integratorii de aplicaţii nu au nevoie sa cunoască tipul de sistem, modelul de obiecte sau
protocoalele folosite de către sistemele care trebuie integrate [IONI05].
Orientarea pe servicii poate fi folosită şi pentru implementarea de noi practici sau
tehnologii, spre exemplu SDM (Service Delivery Management). Unii furnizori de servicii IT
presupun că este eficient să se dezvolte soluţii performante prin migrarea la un set standard de
instrumente. Acest lucru este adevărat doar dacă furnizorul de servicii are control total asupra
scopului şi a arhitecturii clientului. Conform [KUBI07], în acest aspect, tendinţa este către o
externalizare (outsourcing) selectivă pentru ca un client să aibă control asupra soluţiei
implementate dar să poată şi menţine unele dintre instrumentele deja utilizate. Externalizarea
reprezintă opţiunea strategică, a unei companii, de a-şi transfera anumite procese total sau
parţial către furnizori de servicii specializaţi - BPO (Business Process Outsourcing). De multe
8
ori mediile ţintă sunt eterogene iar posibilitatea de control al furnizorului de servicii este
limitată. Din această cauză, se cere o nouă abordare în automatizarea programării activităţilor
şi o nouă generaţie de soluţii de management al serviciilor furnizate, pentru a putea tine sub
control elementele eterogene şi pentru a promova lucrul în echipă. Se poate implementa o
soluţie SDM, pornind de la principiile orientării pe servicii, definind componente slab cuplate
şi un şablon de realizare a serviciilor pe care soluţia le integrează.
Un alt concept care poate fi utilizat la dezvoltarea SOA este Software-ul ca un Serviciu
(SaaS) ce oferă posibilitatea de a compune servicii folosind internetul, fiind un important
beneficiu pentru SOA. Totuşi, complexitatea şi timpul necesar pentru dezvoltarea şi punerea
la dispoziţie a serviciilor compuse fac această activitatea una predispusă la erori. În lucrarea
[ROLE09] se propune o abordare semi-automată de compunere ca un serviciu (CaaS) cu
elemente de limbaj specific domeniului (DSL), numit Vienna Composition Language (VCL).
Această abordare, care nu necesită compunere la nivel de client, are rolul de a facilita
dezvoltarea rapidă de servicii compozite folosind o ierarhie bazată pe restricţii. Apelarea
serviciile de compunere declanşează procesul iar serviciile nou create sunt imediat activate şi
făcute disponibile.
Conform [CUNN05], serviciile din cadrul SOA interacţionează pe baza unei definiţii
formale (contract, spre ex WSDL) care este independenta de platformă şi limbaj aşa că, spre
exemplu, servicii scrise în C# şi rulând pe platforme .Net şi servicii scrise în Java şi rulând pe
platforme J2EE pot fi folosite de o a treia aplicaţie. De asemenea, aplicaţiile care rulează pe
oricare din aceste platforme pot folosi facilităţi oferite de alte servicii WEB. Expunerea
funcţionalităţii folosind protocoale standardizate şi interfeţe care pot fi obţinute dinamic
conduce la o cuplare slabă între subsisteme, permiţând astfel o conectare simplă şi asigurând o
flexibilitate sporita aplicaţiei. Cuplarea slaba descrie o legătură între doua sisteme care fac
schimb de date. Fiecare parte înaintează cerinţele sale şi face câteva presupuneri despre
cealaltă parte. Sistemele slab cuplate sunt considerate deosebit de folositoare când sistemul
sursa sau destinaţie suferă schimbări dese.
În articolul [JAGR06] este prezentat un prim model, inspirat de primele standarde ale
serviciilor web, care definea SOA ca o arhitectură construită în jurul a trei componente de
bază: consumatorul de servicii, furnizorul de servicii, agentul de servicii.
În cadrul acestui model, furnizorul de servicii (service provider) creează un serviciu web
având posibilitatea publicării interfeţei acestuia, şi poate accesa date de la agentul de servicii.
Standardul folosit pentru descrierea serviciilor este WSDL(Web Services Description
Language).
Agentul de servicii (service broker/registry) gestionează interfaţa web a serviciului şi
accesul la datele disponibile de către un posibil consumator al serviciului. Dacă agentul de tip
public poate fi disponibil în Internet, cel privat este disponibil numai unei categorii restrânse
de consumatori, cum ar fi utilizatorii intranet-ului unei companii. Specificaţia UDDI
9
(Universal Description, Discovery and Integration) poate fi folosită pentru standardizarea
formatului agentului de servicii.
Consumatorul serviciului (service requestor) localizează intrările în agentul de servicii
utilizând diverse operaţii de căutare. SOAP (Simple Object Access Protocol) poate pune la
dispoziţie formatul folosit pentru comunicaţii între furnizorul de servicii şi de consumatorul
de servicii.
Această arhitectură de bază este prezentată în figura 3.
Din figura 3 se observă că la început consumatorul de servicii trebuie să contactează
agentul de servicii, sau direct serviciul web, pentru a obţine informaţii despre interfaţa
acestuia. Pentru aceasta, se foloseşte un Discovery Document care poate fi realizat în mod
static sau dinamic. După ce a fost reperat serviciul web, clientul cere o descriere a acestuia
care trebuie sa cuprindă metodele expuse, parametrii acestor metode, precum şi ce tip au
valorile care se returnează după execuţie. Aceste informaţii sunt încapsulate într-un document
WSDL şi sunt necesare clientului pentru a şti cum să încapsuleze cererile către furnizorul de
servicii web în pachete SOAP şi cum anume să interpreteze pachetele SOAP venite de la
furnizor ca urmare a cererii efectuate de client. Furnizorul de servicii este văzut de către
consumator ca un obiect, metodele unui Web Service devenind metode ale obiectului proxy.
Unele din aceste tehnologii nu se mai folosesc în implementările recente de SOA care
generează o arie mult mai largă de elemente şi metadate. Această arie de elemente include:
scheme XML, descriptori BPEL, transformări XSTL şi multe altele. Aceste elemente trebuie
Furnizorul de
servicii
Consumatorul de
servicii
Agentul de
servicii
Publică
servicii
Caută
servicii
Cerere
informaţii
Furnizare
informaţii
Figură 3 Un prim model SOA, prelucrare după [JAGR06]
10
să fie stocate pentru a fi accesibile şi a beneficia de reutilizare, facilităţi care nu sunt puse la
dispoziţie de specificaţia UDDI.
O platformă completă de tip SOA permite integrarea aplicaţiilor, rafinându-se procesele
de afaceri în cadrul companiilor după standarde dinainte stabilite. Prin procese de afaceri
construite pe o arhitectura orientată pe servicii, o companie poate exploata aplicaţiile software
existente, astfel încât să atingă un grad superior de interoperabilitate nu doar între
departamentele firmei, ci şi cu alte companii. Aceasta abordare valorifica resursele existente
pentru a ajuta la îmbunătăţirea productivităţii, permiţând astfel companiei sa reacţioneze rapid
la schimbările intervenite pe piaţă, fructificând astfel oportunităţile de afaceri
([DIAC09],[ERL05]).
O soluţie de integrare bazată pe SOA diferă de una bazată pe EAI (Enterprise Application
Integration) prin faptul că integrarea nu se mai realizează centralizat, ci este împinsă spre
margini, integrarea fiind lăsată în seama aplicaţiilor propriu zise, magistrala de date (bus)
standardizând mesajele interschimbate. În figura 4 se prezintă un model al arhitecturii
ESB/SOA.
Figură 4 Schemă arhitectură ESB/SOA, prelucrare după [DASC08]
Fiecare aplicaţie are modul ei propriu de a reprezenta şi de a lucra cu informaţiile.
SOA foloseşte un ESB pentru a ruta şi schimba mesaje la un nivel înalt de abstractizare. Se
pot folosi adaptoare la nivelul fiecărei aplicaţii pentru a convertii mesajele din formatul
specific aplicaţiei la un format specific soluţiei de integrare, în acest mod integrarea nu se va
mai realiza în centrul soluţiei ci la margini. Se pot utiliza şi modele ierarhice de magistrale de
11
servicii (service bus) pentru a permite diferitelor departamente sau subsidiare să-şi
construiască propriile lor niveluri de abstractizare între aplicaţii.
Primele ESB erau destul de rudimentare şi aveau în principal rolul de a pune în
legătură serviciile web cu cei care aveau nevoie de ele. Soluţiile ESB moderne încearcă să
facă mai mult mai mult decât atât, au scopul declarat, chiar dacă nu întotdeauna atins, de a ne
permite gestiunea tuturor problemelor IT dintr-o organizaţie.
Cuplarea uşoară este probabil caracteristica cea mai invocată în literatura de
specialitate privind tehnologia serviciilor web şi a orientării pe servicii. Acest lucru este
parţial adevărat, aşa cum se arată, spre exemplu şi în [DASC08]. Serviciile web, prin natura
limbajului WSDL şi a documentelor de tip XSD (XML Schema Definition), pot fi într-un fel
uşor cuplabile prin faptul că formalizează o comunicare între furnizorul şi consumatorul de
resurse fiind o tehnologie neutră de platformă şi cu posibilităţi bune de reutilizare. Totuşi,
dacă privim la o sursă WSDL vom observa că adesea acestea conţin adrese şi porturi:
<service name="PreiaCotatie">
<port binding="s1: PreiaCotatie Binding"
name=SoapPort">
<s2:address location="http://www.host.ro:7001/esb/Preia_Cotatie" />
</port>
</service>
Prin specificarea unei adrese şi a unui port se va lega respectivul serviciu de existenţa sa
fizică pe un anumit calculator. Chiar dacă vom folosi adrese DNS pentru a substitui părţi din
adresă şi a folosi serviciile web pe grupuri de servere, serverele DNS nu pot gestiona stările
serviciilor care rulează pe aceste servere. Pentru a asigura cuplarea uşoară va fi nevoie de un
nivel de mediere capabil de a interconecta diverse tehnologii şi a putea furniza o soluţie
pentru ca un serviciu web să poată fi accesat fie prin http, ftp sau chiar email. O magistrală
modernă de servicii ar trebui să fie bazată pe fişiere de configurare şi nu pe cod-sursă, să fie o
soluţie în care să nu fie necesară compilarea sau desfăşurarea ([DILU09_1], [DILU09_2],
[DASC08]).
Pentru a explica mai bine soluţiile orientate pe servicii, putem face o paralelă cu o
comunitate în care există mai multe societăţi ale căror servicii pot fi folosite de mai mulţi
consumatori. Este de preferat ca lucrurile să se desfăşoare în acest mod decât să existe un
singur furnizor de servicii. Dacă aducem în ecuaţie şi termenul de arhitectură, conceptul de
orientare pe servicii ia o conotaţie tehnică reprezentând un model în care logica de
automatizat este descompusă în unităţi mai mici şi distincte [ERL05]. Colectiv, aceste unităţi
pot forma logica unei aplicaţii iar individual pot fi distribuite în locaţii diferite. Distribuirea
12
logicii în unităţi separate nu este un concept nou, în acest capitol insist asupra aspectelor care
fac orientarea pe servicii un concept special.
Dacă într-o comunitate distribuită impunem anumite dependenţe, putem afecta potenţialul
de dezvoltare. Vrem ca aceste unităţi distincte să interacţioneze pentru a-şi îmbunătăţi una
alteia serviciile dar vrem sa evităm un model în care entităţile formează legături strânse din
care pot rezulta inter-dependenţe restrictive. Chiar dacă ne dorim ca aceste unităţi să fie
interdependente vrem totuşi ca ele să adere la o convenţie comună, spre exemplu: să
folosească aceeaşi monedă, aceeaşi limbă, aceeaşi parametrii de calitate. Aceste standarde
sunt în beneficiul consumatorului dar în acelaşi timp nu reduc abilitatea entităţilor distincte de
a se auto-conduce. Arhitectura orientată pe servicii încurajează unităţile individuale de logică
să existe autonom, dar nu izolate. Unităţile de logică trebuie să se conformeze unui set de
principii care le permite să se dezvolte independent dar trebuie să se supună unor standarde
comune. SOA numeşte aceste unităţi servicii.
Pentru a îşi păstra independenţa, serviciile încapsulează logica într-un context distinct.
Acest context poate fi specific unui proces de afaceri, unei entităţi sau unei alte grupări.
Problema căreia i se adresează un serviciu poate fi de mare sau de mică amploare, deci scopul
şi dimensiunea logicii reprezentate de serviciu poate diferii [ERL07]. Mai mult, logica unui
serviciu poate cuprinde logica altui serviciu. În acest caz, unul sau mai multe servicii compun
un colectiv. Spre exemplu, soluţiile de automatizare a logicii afacerii sunt de obicei
implementări ale proceselor de afaceri. Acest proces este compus din algoritmi care dictează
acţiunile soluţiei. Algoritmul (logica) poate fi descompusă într-un şir de paşi pe care îi
execută într-o ordine dictată de regulile de afacere dar şi de condiţiile de rulare. Când
construim o soluţie de automatizare alcătuită din servicii , fiecare serviciu încapsulează o
sarcină îndeplinită de o anumită secvenţă de paşi. Un serviciu poate încapsula o parte dintr-un
proces dar şi un întreg proces, aşa cum putem vedea în figura 5.
Înţelegerea posibilităţilor de reutilizare a softwareului poate fi dificilă deoarece sistemele
informatice sunt de multe ori distribuite şi interconectările complicate. Tehnologiile nou
apărute pot diminua abilităţilor unei companii pentru reutilizare programelor proprii şi de
aceea se poate apela la o paradigmă, un stil fundamental de dezvoltare bazat pe outsourcing
[BLTA10].
Pentru ca serviciile să folosească logica încapsulată, ele trebuie să participe la efectuarea
diverselor activităţi. Pentru a face acest lucru, trebuie să formeze relaţii distincte cu cei care
vor să o folosească. În cadrul SOA, serviciile pot fi folosite de alte servicii sau de alte
programe. Indiferent de cine sunt folosite, relaţia dintre servicii se bazează pe înţelegerea
faptului că pentru a exista interacţiune, serviciile trebuie să ştie unul de altul. Acest lucru se
poate realiza folosind descrierea serviciilor. O descriere de serviciu, la modul cel mai simplu,
stabileşte numele serviciului, parametrii de intrare cât şi datele returnate. Modalitatea în care
13
serviciile folosesc rezultatele descrierilor într-o relaţie se numeşte cuplare uşoară (loosely
coupled). Serviciul A ştie de existenţa lui B deoarece A deţine descrierea lui B.
Pentru ca serviciile să interacţioneze, trebuie să existe schimb de informaţii. Este deci
necesar existenţa unui cadru (framework) de comunicare pentru a se putea folosi cuplarea
uşoară. După ce un serviciu trimite un mesaj, pierde controlul cu ce se întâmplă cu mesajul
după aceea (figura 6). De aceea trebuie ca mesajele să existe ca unităţi independente de
comunicare, şi ca şi serviciile, să fie autonome şi să îşi poată îndeplini singure rolul din logica
de procesare.
Secventă a
unui proces
subproces
Proces
Serviciu
Serviciu
Serviciu
Figură 5 Logica încapsulată de un serviciu, prelucrare după [ERL05]
14
Serviciile care pun la dispoziţie descriptori şi comunică prin mesaje formează o
arhitectură primitivă care se aseamănă cu arhitecturile distribuite care foloseau mesajele şi
separau interfaţa de logica proceselor. Diferenţele apar din modul în care componentele
principale: serviciile, descriptorii şi mesajele sunt proiectate.
Orientarea pe servicii este o abordare în baza căreia poate fi organizată distribuirea
resurselor IT într-o soluţie integrată care fluidizează concentrările de informaţii şi
maximizează capabilităţile de adaptare ale afacerii. Aceasta modularizează resursele IT,
facilitând conectarea flexibilă a proceselor de business, care la rândul lor, integrează
informaţii provenite de la alte sisteme. Orientarea pe servicii a resurselor IT implică utilizarea
protocoalelor standard şi a interfeţelor convenţionale pentru a facilita accesul la logica de
business şi a informaţiei furnizate de diverse servicii.
Putem descrie SOA astfel: arhitectura orientată pe servicii este un set de componente
care pot fi apelate şi a căror descrieri de interfeţe pot fi publicate pentru a fi descoperite şi
utilizate.
Ca şi orientarea pe obiecte, orientarea pe servicii, introduce un concept distinct pentru
proiectarea componentelor arhitecturii. Când o soluţie este alcătuită din mai multe unităţi de
procesare logică putem spune că avem de a face cu o soluţie orientată pe servicii. Prezint în
continuare principiile orientării pe servicii şi modul cum putem aplica aceste principii în
construirea unui sistem informatic integrat. Sintetizând, principiile orientării pe servicii sunt
următoarele (prelucrare după [ERL05] şi [DASC08]) :
cuplarea uşoară, serviciile menţin o relaţie care le minimizează dependenţa dar
acestea ştiu de existenţa celorlalte servicii;
contractul între servicii, serviciile aderă la o comunicare standard, definită în mod
colectiv de descrierile serviciilor;
autonomia, serviciile au control deplin asupra logicii pe care o încapsulează;
abstractizare, pe lângă ceea ce este descris în contract, serviciile includ logica şi din
lumea exterioară;
Serviciul A
Serviciul B
Descrierea
serviciului B
Mesaj de sine
statator
Figură 6 Mesajul ca unitate de sine stătătoare
15
reutilizare, logica este împărţită în servicii cu principalul scop de a promova
reutilizarea;
agregarea, colecţii de servicii pot fi coordonate şi agregate pentru a forma servicii
agregate;
uşurinţa descoperii, serviciile sunt proiectate pentru a fi descoperite prin mecanisme
specifice.
Având cunoştinţe despre componentele care alcătuiesc arhitectura de baza şi un set de
principii de proiectare, putem modela şi standardiza aceste componente folosind o platforma,
spre exemplu serviciile web. Nu avem neapărat nevoie de serviciile web pentru a
implementa o soluţie SOA, termenul de orientare pe servicii şi modelele abstracte SOA
existau dinainte de apariţia serviciilor web, dar la acest moment sunt soluţia cea mai logica
şi care răspunde cel mai bine la cerinţelor.
Nu trebuie să considerăm SOA doar din punctul de vedere al tehnologiei, ci ca o
arhitectură ce promovează un mediu normalizat orientat pe servicii, numit SOE (service-
oriented environment). Punând accent pe interoperabilitate, SOA combină capacitatea apelării
de funcţii la distanţă cu mecanisme dinamice de regăsire şi execuţie.
Putem compara orientarea pe servicii cu orientarea pe obiecte, insistând pe asemănări dar
şi pe diferenţe. Putem în primul rând să considerăm şi obiectele cât şi serviciile ca fiind unităţi
logice de procesare. Orientarea pe servicii pune accent pe cuplarea uşoară dintre unităţile de
procesare. şi în cazul orientării pe obiecte se pot crea unităţi de program reutilizabile, slab
cuplate, dar în general aceste provin din clase predefinite, rezultând unităţi de procesare nu
aşa de independente. În cazul orientării pe servicii se folosesc descriptorii de mesaje pentru ca
fiecare mesaj să poată conţine cât mai multă informaţie. Programarea orientată pe obiecte
foloseşte interfeţe de programare a interfeţelor (API) pentru ca unităţile de comunicaţii (RPC)
să poată realiza diverse operaţii. Orientarea pe servicii permite unităţilor de logică să difere în
dimensiuni şi în domeniul acoperit. Obiectele în general sunt mai mici şi au un domeniu mai
precis. Orientarea pe servicii presupune crearea de unităţi de procesare inactive care sunt
conduse de unităţi inteligente de comunicaţie (mesajele). Orientarea pe obiecte încurajează
îmbinarea logicii de procesare cu datele rezultând unităţi inteligente: obiectele. În cazul
orientării pe servicii, unităţile de servicii nu păstrează starea, adică un răspuns nu depinde de o
acţiune anterioară a utilizatorului. Obiectele pot păstra starea datorită legăturii dintre date şi
algoritm. Orientarea pe servicii promovează compunerea unităţilor de logică slab cuplate.
Orientarea pe obiecte face posibilă compunerea obiectelor dar în acelaşi timp promovează
moştenirile care duc la dependenţe funcţionale.
Comparaţia între arhitectura client-server, web pe trei niveluri şi cea orientată pe servicii,
e sintetizată în tabelul 2.
16
Tabel 2 Comparaţie între arhitectura client-server, web pe trei niveluri şi SOA
Client-Server Web pe trei
niveluri
SOA
Logica aplicaţiei Accentul se pune pe
client
Se pot folosi
subprograme stocate
pe server
Se regăseşte pe
nivelul serverului
de bază de date şi
pe cel de aplicaţii
Logica este împărţită
după cerinţele
orientării pe servicii
Se pot folosi
subprograme stocate
pe server
Procesarea
informaţiilor
Procesarea împărţită
între client şi server
Consum de resurse
ridicat
Se realizează pe
serverul de
aplicaţii şi pe cel
de bază de date
Procesare distribuită,
consum de resurse mai
scăzut
Tehnologii folosite Limbaje de
programare de nivel
înalt, baze de date
HTTP, HTML, Java,
XML
Limbaje de programare,
baze de date, accentul
pus pe tehnologiile
web, în special pe
serviciile web şi XML
Asigurarea
securităţii
Centralizată, facilă Se realizează de
către serverul de
aplicaţii pe baza
informaţiilor din
baza de date
Mai dificilă, se foloseşte
WS Security
Facilităţi de
administrare
Administrare uşoară
a serverului, dificilă a
clienţilor
Administrarea
serverelor se
realizează prin
intermediul unor
interfeţe dedicate
Se pot folosi agenţi de
servicii privaţi