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