REPUBLIKA E SHQIPRIS UNIVERSITETI I TIRANS

FAKULTETI I SHKENCAVE T NATYRS DEPARTAMENTI I INFORMATIKS

JULIAN FEJZAJ

ARKITEKTURAT E BAZAVE T DHNAVE T ORIENTUARA NGA SHRBIMET

TEZ DOKTORATURE

UDHHEQS SHKENCOR: PROF.ASOC. ENDRI XHINA

TIRAN, 2014

UNIVERSITETI I TIRANS FAKULTETI I SHKENCAVE T NATYRS

DEPARTAMENTI I INFORMATIKS

DISERTACION

i paraqitur nga:

MSc. Julian Fejzaj

udhhequr nga

Prof. Asoc. Endri Xhina

Pr marrjen e grads shkencore

DOKTOR

Specialiteti: Informatik

Tema:

Arkitekturat e Bazave t Dhnave t Orientuara nga Shrbimet

Mbrohet m dt. ./...../201.. para juris:

1. ................ Kryetar

2. .... Antar (Oponent)

3. .... Antar (Oponent)

4. Antar

5. Antar

III

Kapitulli 1 - Prezantim me Arkitekturn e Orientuar drejt Shrbimeve (SOA) .... 1

1.1 Arkitektura e Orientuar drejt Shrbimeve (SOA) .......................................... 1

1.1.1 Prbrja, Ndrtimi, Infrastruktura ............................................................... 1

1.1.2 Zhvillimi i SOA ........................................................................................... 2

1.1.3 Karakteristikat kryesore t SOA. ................................................................ 3

1.2 Komponentet arkitekturore t SOA .................................................................. 6

1.3 Avantazhet, Sfidat. ........................................................................................... 7

1.3.1 Avantazhet e SOA. .................................................................................... 7

1.3.2 Sfidat e SOA. ............................................................................................ 7

Kapitulli 2 . Integrimi i Aplikimeve ......................................................................... 8

2.1 far sht Integrimi i Aplikimeve? .................................................................. 8

2.2 Nevoja dhe krkesa e tregut pr Integrimin e Aplikimeve ................................ 9

2.3 Mnyrat e Integrimit t Aplikimeve ................................................................. 10

2.3.1. Platform Integration .............................................................................. 11

2.3.3 Data Integration .................................................................................... 11

2.3.4 Component Integration ......................................................................... 12

2.3.2 Application Integration ........................................................................... 12

Kapitulli 3 Arkitektura e Integrimit t Aplikimeve ............................................... 16

3.1 Arkitektura Point-to-Point ..................................................................... 16

3.2 Arkitektura Middleware ......................................................................... 17

3.3 Stilet e integrimit ......................................................................................... 18

3.4.1 File Transfer ..................................................................................... 19

3.4.2 Shared Database .............................................................................. 19

3.4.3 Remote Procedure Call .................................................................... 20

3.4.4 Messaging ........................................................................................ 21

3.4.5 Web Services ................................................................................... 21

Kapitulli 4 Ndikimi i rrjetit n Bazat e t Dhnave t Shprndara ................... 23

4.1 Rndsia e rolit t rrjetave n arkitekturn SOA ....................................... 23

4.2 Bazat e t dhnave t shprndara ............................................................ 24

4.2.1 Bazat e t dhnave Homogjene dhe Heterogjene ................................... 24

4.3 Vonesat n rrjet ......................................................................................... 25

4.3.1 Vlersimi i Algoritmit t Rrugzimit ..................................................... 26

Kapitulli 5 SOA, Virtualizimi dhe Cloud ........................................................... 27

5.1 Virtualizimi ..................................................................................................... 27

5.1.1 Virtualizimi i shrbimeve .......................................................................... 28

5.1.2 Historiku e virtualizimit t shrbimeve ...................................................... 28

IV

5.2 Cloud computing ............................................................................................ 30

5.2.1 Arkitektura Cloud Computing ................................................................... 30

5.2.1 SOA dhe Cloud Computing ..................................................................... 33

5.2.2 Lidhja midis SOA dhe Cloud Computing .................................................. 34

5.3 Cloud Computing dhe Virtualizimi .................................................................. 35

5.4 Teknika e Migrimit Live .................................................................................. 35

5.4.1 Migrimi live Hyper-V ................................................................................ 36

5.4.1 Optimizimi i Migrimi live ........................................................................... 36

Kapitulli 6-Arkitekturat e Bazave t Dhnave t Orientuara nga Shrbimet (SODA) ................................................................................................................... 39

6.1 Prezantim me Arkitekturn SODA ............................................................ 39

6.1.1 Prdorimi i SODA .................................................................................... 41

6.1.2 T dhnat n SODA ................................................................................ 43

6.2 Mjete t Ms SQL Server pr implementimin e koncepteve SODA .................. 46

6.2.1 Suporti i XML ........................................................................................... 47

6.2.2 Native Web Services ............................................................................... 47

6.2.3 Gjuha CLR dhe integrimi me SQL Server ................................................ 50

6.2.4 Database Change Notifications njoftimet e ndryshimeve n bazn e t dhnave ........................................................................................................... 52

Kapitulli 7 Arkitektura e Shrbimeve t Mesazheve dhe Radhve .................. 54

7.1 Shrbimet Broker t Mesazheve t bazuara n radh n SQL Server ...... 54

7.2 Arkitektura Service Broker ......................................................................... 55

7.3 Ndrtimi i aplikacioneve i bazuar n radhn e mesazheve duke prdorur shrbimet Broker n Sql Server. .......................................................................... 60

Kapitulli 8 Shkmbimi i t dhnave n mnyr standarte ................................ 76

8.1 Modeli Relacional dhe XML ........................................................................... 76

8.1.1 Roli i XML ............................................................................................... 76

8.1.2 XML dhe t Dhnat Relacionale .............................................................. 76

8.1.3 XML n Sql Server .................................................................................. 79

8.2 Kalimi nga te Dhnat Tabelare n XML.......................................................... 81

8.3 Kalimi nga XML n te Dhnat Tabelare .......................................................... 84

Kapitulli 9SOA dhe bazat e t dhnave me kapacitet t lart (Big Data) ......... 86

9.1 Bazat e t dhnave me kapacitet t lart ....................................................... 86

9.2 Problematikat n Bazat e t dhnave me kapacitet t Lart (VLDB) .............. 87

9.2.1 Koncepti i Particionimit ............................................................................ 87

9.2.2 Prfitimi n Performanc me an t Particionimit .................................... 89

V

9.2.3 Shrbimet Data Mining n t dhnat me kapacitet t lart ....................... 91

9.2.4 SOA dhe t dhnat me kapacitet t lart ................................................. 92

9.3 Arkitektura T dhnat me kapacitet t lart-si-shrbime .............................. 93

Konkluzione ........................................................................................................... 95

Referencat ............................................................................................................. 97

Lista e Figurave Figur 1. Karakteristikat e SOA-s .................................................................................. 1 Figur 2. Komunikimi ndrmjet dy shrbimeve Web ................................................... 2 Figur 3. Pavarsia e nj shrbimi ................................................................................ 3 Figur 4. Trasmetimi i mesazheve dhe proesimi i tyre ............................................... 4 Figur 5. Arkitektura Enterprise Service bus ................................................................ 6 Figur 6. Komponentet e arkitekturs s orientuar nga shrbimet ............................... 6 Figur 7. Integrimi i Aplikimeve .................................................................................. 8 Figur 8. Mnyrat e Integrimit .................................................................................... 11 Figur 9. Shembull i Platform Integration ............................................................... 11 Figur 10. Data Integration ndrmjet platformave t ndryshme .............................. 12 Figur 11. Shembull i integrimit Komponent .......................................................... 12 Figur 12. Shembull i Application Integration ......................................................... 13 Figur 13. Komunikimi point-to-point ndrmjet aplikimeve ................................... 17 Figur 14. Aplikimet t lidhura nprmjet nj integration hub ................................ 17 Figur 15. Skema File Transfer ................................................................................ 19 Figur 16. Skema Shared Database .......................................................................... 20 Figur 17. Skema Remote Procedure Invocation ..................................................... 21 Figur 18. Skema Message Bus ............................................................................... 21 Figur 19. Koncepti i Web Service .......................................................................... 22 Figur 20. Sistemet e bazave t dhnave t shprndara .............................................. 24 Figur 21. Diagrami logjik pr makina virtuale t bazuara n hypervisor ................. 27 Figur 22. Virtualizimi i shrbimeve .......................................................................... 30 Figur 23. Arkitektura Cloud Computing ................................................................... 31 Figur 24. Koncepte t implementimit pr Cloud Computing dhe SOA .................... 33 Figur 25. Migrimi Live i makinave Virtuale ............................................................. 36 Figur 26. Paraqitja skematike per nj datacenter ...................................................... 37 Figur 27. Aplikacioni i bazuar n shrbimet SOA .................................................... 40 Figur 28. T dhnat brenda dhe jasht shrbimeve ................................................... 44 Figur 29. Shrbimet dhe mesazhet t lidhura bashk ................................................ 45 Figur 30. Mesazhe t shumfishta t ngjashme ........................................................ 46 Figur 31. Shrbimet kundrejt komponenteve ............................................................ 46 Figur 32. Integrimi i SQL Server 2005 me driver-in http.sys ................................... 48 Figur 33. Nyjet http n SQL Server 2008 ................................................................. 49

VI

Figur 34. Konvertimi nga CLR i CIL n kod native ................................................. 50 Figur 35. Arkitektura SQLCLR ................................................................................ 51 Figur 36. Topologjia dhe rrjedha DCN ..................................................................... 52 Figur 37. Nj dialog i shrbimeve broker ................................................................ 56 Figur 38. Grupet e Komunikimit ............................................................................... 56 Figur 39. Renditja e Mesazheve n SB ..................................................................... 57 Figur 40. Proesi i besueshem i mesazheve n SB ................................................... 57 Figur 41. Objektet e shrbimit SB ............................................................................. 58 Figur 42. Struktura e shrbimit Broker dhe sinjali i dialogut ................................... 59 Figur 43. Objektet SB t krijuara n SQL Server 2008 ............................................ 62 Figur 44. Outputi i radhs Destinacion ..................................................................... 64 Figur 45. Disa prej aplikacioneve kryesore ne nje sistem bankar ............................. 65 Figur 46. Sistemi audit i qendrzuar ......................................................................... 67 Figur 47. Konfigurimi i aplikacionit sipas mesazheve dhe radhve ......................... 72 Figur 48. Tabela audit pas aktiviteteve t ndryshme ................................................ 73 Figur 49. Krahasimi i performancs kur ka aktivitet paralel n t gjitha aplikacionet ...................................................................................................................................... 75 Figur 50. Integrimi i XMl n SQL Server ................................................................. 78 Figur 51. Starndartet SQL/XML dhe XQuery .......................................................... 79 Figur 52. Nj DataSet n XML ................................................................................. 79 Figur 53. OPEN XML ............................................................................................... 84 Figur 54. Proedura SP XML Prepare Dokument .................................................... 85 Figur 55. Faktort q ndikojn n bazat e t dhnave me kapacitet t lart ............. 87 Figur 56. Particionimi i tabels Shitje per do muaj te vitit .................................... 89 Figur 57. Prfitimi n Performanc duke particionuar t dhnat .............................. 90 Figur 58. SOA dhe t dhnat me kapacitet t lart ................................................... 94

Lista e Tabelave Tabel 1. Aplikacioni i Integruar n Makinn Virtuale ............................................... 38 Tabel 2. Krahasimi i kohs Live Migration pr Hipervizor t ndryshm ............... 38 Tabel 3. Koht e mbushjes s logut kur ka aktivitet n nj aplikacion ...................... 73 Tabel 4. Krahasimi i performancs duke prdorur shrbimet n brendsi t databazs ...................................................................................................................................... 74 Tabel 5. Koht kur ka aktivitet paralel n t gjitha aplikacionet ............................... 74 Tabel 6. Diferenca midis modeleve t dhnave Relacionale dhe t dhnave XML .. 77 Tabel 7. Krahasime midis bazave t dhnave me kapacitet t lart ........................... 86 Tabel 8. Koha mesatare e egzekutimit te krkeses pr 'do particion ........................ 90

VII

Hyrje Arkitekturat dominuese t aplikacioneve klient/server dhe shum shtresore t dekadave t fundit kan ngritur nj numr t madh problemesh t cilat lidhen me prshkallzimin dhe disponueshmrie e sistemeve IT. T tjera probleme u shfaqn gjat fazs pr t inkorporuar sistemet e vjetra n ato t reja. Gjithashtu nj problem i madh lidhej me faktin e ruajtjes s t dhnave n databaza shum t mdha, t qendrzuara ku t gjitha komponentet klient kishin akses direkt me databazn, kjo pr faktin q pr sisteme t tilla informacioni, rritej vshtirsia e disponueshmris s tyre. Gjithashtu nj ndr faktort kryesore i cili cnohej n kto baza t dhnash ishte performanca e tyre apo e aplikacioneve q ndrvepronin me to, degradimi i t cilave lidhej direkt me rritjen e numrit t krkesave nga aplikacionet apo rritja e t dhnave. Pas dekadash shperndarjeje t nj numri shum t madh sistemesh t ndrtuara n platforma dhe teknologji te ndryshme, bota ishte plot me sisteme q e kryenin punn e tyre n mnyr perfekte por q nuk kishin asnj shteg t qart pr t ndrvepruar me aplikacione t tjera n nj mjedis gjithmon e m tepr t orientuar dhe t shprndar n infrastrukurn e rrjetit. Arkitektura e orientuar nga shrbimet (SOA) sht nj model arkitekturor q udhheq t gjith aspektet e krijimit dhe prdorimit t proeseve t biznesit t paketuara si shrbime. Kjo arkitektur prcakton dhe siguron q infrastruktura IT t lejoj aplikime t ndryshme t shkmbjen t dhna dhe t marrin pjes n proeset e biznesit pavarsisht nga sistemet e shfrytezimit apo gjuht e programimit t ktyre aplikimeve. SOA prfaqson nj model n t cilin funksionaliteti dekompozohet n njsi t vogla t veanta (shrbime), t cilt mund t shprndahen n rrjet dhe mund t kombinohen s bashku si dhe t riprdoren pr t krijuar aplikime biznes. Kto shrbime komunikojn me njri-tjetrin duke kaluar t dhnat nga nj shrbim tek tjetri, ose duke koordinuar nj aktivitet ndrmjet nj ose m shum shrbimesh. Arkitekturat e bazave t dhnave t orientuara nga shrbimet (SODA) lidhet pikritsh me implementimin e SOA n arkitekturn e bazave t dhnave ku secili komponent i saj n trajtn e shrbimit sht i pavarur.Kjo mundson q sistemet e mdha t dekads aktuale t shprndara si Cloud,Big Data t cilat prdorin parimin e ndarjes n komponente shrbimesh m t vogla t jen m rezistente ndaj dshtimit dhe t ofrojn nj performanc shum t lart komunikimi. Shkmbimi i t dhnave ndrmjet aplikacioneve t ndryshme t cilt nuk jan t hapur(kompatibl) me njri-tjetrin dhe q prdorin baza t dhnash t ndara kategorizohet si nj operacion i komplikuar dhe me kosto pr biznesin. N kt punim do t trajtohet mnyrat e ndryshme q egzitojn pr integruar aplikimet e veanta n organizata mbi sistemet e bazave t dhnave, n nj bashksi aplikimesh bashkpunuese n mnyr q zhvillimi i tyre t bhet sa m fleksibl. Do t trajtohet roli databazave si nj nga faktort kryesor q luan rol n kt integrim, ku do t prqendrohem n studimin e bazave e t dhnave t shprndara

VIII

(distributed) dhe problematikat q shfaqen gjat komunikimit. Nj nga avantazhet m t mdha q ofron ky model shprndarjeje sht q pavarsisht se t dhnat jan te shprndara fizikisht, n nivelin llogjik t dhnat mund t aksesohen nga kudo. Qllimi kryesor i punimit sht q n nj mjedis t shprndar bazash t dhnash t krijohet nj shtres ndrmjetse e cila do t komunikoj me t gjith databazat e shprndara n rrjet duke ruajtur integritetin dhe performancn, pavarsisht nga specifikat apo numri i aplikacioneve heterogjene q ndodhen n kt mjedis t shprndar. Bashksia ktyre t dhnave mund te jet e shprndar fizikisht n vendndodhje t ndryshme t shprndara ne rrjeta lokale, intranet-te apo me an t internetit, midis t cilave shrbimet e bazave t dhnave komunikojn me njra-tjetrn. Aksesimi i t dhnave lidhet direkt me komunikimin n rrjet,ku nj nga pjest e punimit do t jet pikrisht studimi i performancs q ka rrjeti n ket ambjent t shprndar dhe si mund t optimizohet prdorshmria e rrjetit duke przgjedh protokollet e rrugzimit t cilat ndikojn n eleminimin e bllokimeve (starvation) n rrjet. Gjithashtu do t vlersohet performanca q mund t arrihet ne rastet e prdorimit t protokollit IPv6 e duke prdorur teknikn Flow Label. Shtresa ndrmjetse (middleware) do t krijohet sipas arkitekturs s mesazheve dhe radhve (Message Queuing) t cilat prdorin parimin asinkron dhe do t mundsoj q krkesat pr ndryshime n bazat e t dhnave t shprndara relacionale apo aplikacioneve heterogjene, t implementohen direkt n nivel databaze duke ruajtur pavaresin nga njra-tjetra. Q kjo shtres ndrmjetese t komunikoj me bazat e t dhnave t ndryshme dhe t shprndara, do ti ruaj t dhnat n standartin e njohur XML, i cili sht i njohur dhe i integruar n shumicn e sistemeve t menaxhimit t databazave, t cilat suportojn ruajtjen e t dhnave n format XML dhe gjenerimin e XML duke u nisur nga t dhna relacionale.Kalimi nga formati XML n t dhna relacionale dhe anasjelltas do t jet pjes e punimit. Teknikisht n kt punim do t prdoret ambjenti i sistemit t menaxhimit t bazave t dhnave Sql Server i cili suporton n brendsi arkitekturn e mesazheve dhe radhve me an t shrbimeve Broker t integruara n brendsi t tij. Si rast studimi do t merret: krijimi i nj sistemi auditi i qendrzuar n nj bank, i cili do t ruaj gjith ndryshimet q ndodhin nga aplikacionet kryesore t prdorura n bank q ndodhen n servera t ndryshm n rrjet duke mos ndryshuar kodin n aplikacionet heterogjene t prdorura, por duke e mundsuar kt npermjet shrbimeve t mesazheve dhe radhve broker direkt n baz t dhnash. Krkesat e drguara nga bazat e t dhnave jan asinkrone, gj kjo e cila do optimizoj ndjeshm kohn e prgjigjes t do aplikacioni q sht pjes e rastit t studimit.

Disa nga problematikat e trajtuara q do t trajtohen lidhur me kt rast studimi jan:

IX

Rritja e log-ut audit n bazn e t dhnave qndrore n mnyr t pakontrolluar.

Kur trendi i t dhnave n databaz rritet me kapacitete t larta, sht vn re nj degradim i performancs. Si zgjidhje pr kt problem jam prqendruar n teknikn e arshivimit, dhe particionimit, duke prfituar n : mbajtjen nn kontroll t dhnave dhe duke prfituar n performanc.

Qndrueshmria ndaj dmtimit pr bazn e t dhnave.

N sistemin e t dhnave t studimit i cili bashkvepron me databazat e tjera n rrjet, t dhnat ruhen n makina virtuale n server. Nj ndr krkesat e domosdoshme sht qndrueshmria ndaj dmtimit pr bazn e t dhnave. Meqnse t dhnat jan me kapacitete t larta dhe ndryshimet pr kt rast jan t shpeshta, kam studiuar teknikn e Migrimit Live, e cila sht drgimi i shrbimeve dhe t dhnave nga nj makin fizike n nj tjetr n koh reale pr t mundsuar qndrueshmrin ndaj dmtimit. Faktor kryesor sht performanca, dhe pr kt arsye n kt rast jam prqndruar n vazhdim n optimizimin e tekniks s Migrimit Live.

Ky sistem i qendrzuar dhe i madh do t shrbej si burimi kryesor i teknikave data Mining q mundsohen n Sql Server me Analysis Services, t cilat n vazhdimsi do t prdoren pr t krijuar modele t gatshme dhe parashikuese pr auditort e ndryshm. Punimi sht i ndar n nnt kapituj. N kapitullin e par trajtohet modeli i arkitekturs s orientuar nga shrbimet, prbrja infrastruktura, teknologjit dhe zhvillimi i saj. N kt kapitull do t trajtohen komponentet e Cloud Computing, i cili mund t konsiderohet si nj aplikacion i bazuar ne infrastrukturn SOA.

N kapitullin e dyt punimi fokusohet n integrimin e aplikimeve q shpesh i referohemi dhe EAI (Enterprise Application Integration). Do t jepet nje paraqitje e krkesave t tregut pr integrimin dhe do t trajtohen llojet e ndryshme te integrimit ne nivel platfome, t dhnash, komponente dhe aplikacioni. N kapitullin e tret trajtohen arkitekturat e integrimit t aplikimeve. Nj mnyr shum e rndsishme pr t br integrimin e aplikimeve t shkallzueshm sht duke rritur numrin e hapave automatik dhe duke reduktuar numrin e hapave manual.Do t shpjegohen lidhjet midis aplikimeve dhe shtresat e ndrmjetme q shrbejn per integrimin. N kapitullin e katrt diskutohet rndsia dhe roli q ka infrastruktura, protokollet dhe komponentet e rrjetit mbi aplikacionet t cilat lidhen me baza t dhnash te shprndara arkitekturn e orientuar ndaj shrbimeve.Do t krahasohen protokolle t cilat vlersojn gjendjen e rrjetit dhe t burimeve dhe duke u nisur nga kombinimi i elementeve te ndryshm, optimizojn rrugt dhe vonesat.

X

N kapitullin e pest trajtohet virtualizimi,virtualizimi i shrbimeve dhe lidhjet qe egzistojne midisa Virtualizimit, SOA dhe Cloud Computing. Do te trajtohet rndsia e tekniks s Migrimit live cila lidhet me lvizjen e t dhnave n makinat virtuale dhe performancn. N kapitullin e gjasht do t studiohen bazat e t dhnave pr mnyrn e integrimit te koncepteve SOA ne brendsi te databazes dhe mjetet qe e mundesojn kt, koncept i njohur ndryshe si Arkitekturat e Bazave t Dhnave t Orientuara nga Shrbimet (Soda).

N kapitullin e shtat do t ndrtohet nj aplikacion middleware sipas arkitekturs s shrbimeve q drgon t dhna n formn e mesazheve dhe radhve q prdorin parimin asinkron. Kjo do t bhet e mundur n sistemin e menaxhimit te bazave t dhnave Sql Server me an t shrbimeve Broker t integruara n brendsi t Sql Server.

N kapitullin e tet do t trajtohet standarti XML n bazat e t dhnave, i cili sht i njohur dhe i integruar n shumicn e sistemeve t menaxhimit t databazave, t cilat suportojn ruajtjen e t dhnave n format XML dhe gjenerimin e XML duke u nisur nga t dhna relacionale.Kalimi nga formati XML n t dhna relacionale dhe anasjelltas do t jet pjes e ktij kapitulli. N kapitullin e nnt do te trajtohen shtjet q lidhen me bazat e t dhnave me kapacitet t lart, performancn dhe krahasime t ndryshme, Sistemi e t dhnave t shprndara,teknikat data mining dhe lidhja e arkitekturs s orientuar drejt shrbimeve me keto sisteme t ruajtjes s informacionit. Punimi do t mbyllet me konkluzionet

1

Kapitulli 1 - Prezantim me Arkitekturn e Orientuar drejt Shrbimeve (SOA)

1.1 Arkitektura e Orientuar drejt Shrbimeve (SOA)

Arkitektura Service Oriented (SOA) sht nj stil arkitekturor q udhheq t gjith aspektet e krijimit dhe prdorimit t proeseve t biznesit t paketuara si shrbime. Gjithashtu SOA prcakton dhe siguron q infrastruktura IT t lejoj aplikime t ndryshme t shkmbjen t dhna dhe t marrin pjes n proeset e biznesit pavarsisht nga sistemet operative ose gjuht e programimit t ktyre aplikimeve.[1]SOA prfaqson nj model n t cilin funksionaliteti dekompozohet n njsi t vogla t veanta (shrbime), t cilt mund t shprndahen n rrjet dhe mund t kombinohen s bashku si dhe t riprdoren pr t krijuar aplikime biznes. Kto shrbime komunikojn me njri-tjetrin duke kaluar t dhnat nga nj shrbim tek tjetri, ose duke koordinuar nj aktivitet ndrmjet nj ose m shum shrbimesh. Figura e mposhtme prshkruan disa nga karakteristikat e arkitekturs SOA.

Figur 1. Karakteristikat e SOA-s

1.1.1 Prbrja, Ndrtimi, Infrastruktura Duhet q aftsit e software-ve t shprndahen dhe t prdoren. Sigurisht q kto shrbime mund t implementohen si nj bashksi sistemesh. Kt mundsi e jep arkitektura SOA, e cila na jep mundsin e shprndarjes, manaxhimit dhe prdorimit t ktyre burimeve. Me zhvillimin e teknologjis gjithka ka evoluar duke kaluar nga modulet tek objektet, tek komponentet dhe tani tek shrbimet.

2

SOA n mnyrn m t mir lejon prhapjen e nj gjenerate t re t aplikacioneve dinamike. Kto aplikacione dinamike jan ato q ju duhen sot bizneseve pr t automatizuar veprimet manuale, me qllim orkestrimin e proeseve t biznesit. Orientimi drejt shrbimeve jep mundsin e integrimit t burimeve t ndryshme n sisteme t ndryshme. N qoftse do t shtrojm pyetjen se far sht SOA, si prgjigje vijn dy prkufizime t ndryshme, ndoshta edhe konfliktuale. Disa prkufizime e sjellin SOA si nj infrastrukture IT pr t rritur efiensn e biznesit, kurse disa t tjera e prkufizojn ate si nj mnyr pr t rritur efiensn e IT.

1.1.2 Zhvillimi i SOA 1Shrbimet jan nj zhvillim i teknologjis s viteve 80 dhe 90. Ato, n vitet 80 njiheshin si objektet e orientuara nga modelet, m pas si komponente, dhe tani njihen si shrbime t orientuara nga modelet. Shrbimet e orientuara i trashgojn t gjith karakteristikat e dy modeleve paraardhse (si vet prshkrimi, enkapsulimi, natyra dinamike), por ajo q sht m e rndsishme sht zhvillimi q erdhi m pas - si transmetimi i mesazheve ndrmjet shrbimeve. Skema e mposhtme e ilustron m s miri nj shembull tipik komunikimi ndrmjet dy web serviseve.

Figur 2. Komunikimi ndrmjet dy shrbimeve Web

Pjesa kryesore tek shrbimet sht pa diskutim vet shrbimi. Shrbimi n vetvete sht nj program, i cili mund t instalohet n dy pjest q do t komunikojn. Gjithashtu shrbimi mund t prkufizohet edhe si nj proes specifik i nj sistemi operimi si Unix ose Windows. elsi n kto shrbime mbetet arkitektura me prdorimin e nj bashksie kompjuterash t shprndar. Prdorimi i ksaj arkitekture na lejon publikimin e shrbimeve, q jan burimet, dhe jo adresimin tek implementimi i tyre. Me an t SOA, funksionalitetet e aplikacioneve ekspozohen nprmjet nj koleksioni shrbimesh. Kto shrbime jan t pavarura dhe prfshijn llogjikn e biznesit dhe t dhnat. Kjo mnyr bn q ndryshimet q ndodhin tek ofruesi i shrbimit t mos ndikojn tek konsumatori i shrbimit. Duke mbajtur nj ndrfaqe konsistente konsumatori i shrbimit mund t zgjedh nj instanc alternative t t njjtit shrbim pa modifikuar krkesat e aplikacionit. Ofruesi i shrbimit dhe konsumatori nuk jan t detyruar t prdorin t njjtn teknologji. Avantazhi i ksaj mnyre sht se bn t mundur q programe t shkruara n gjuh t ndryshme, n 1 http://msdn.microsoft.com/en-us/library/bb833022.aspx

3

platforma t ndryshme, t komunikojn me njra-tjetrn duke prdorur nj mnyr standarte. Anatomia e nj Web Service Shrbimet e paraqitura si n figurn 3, prdoren gjersisht pr t ekspozuar investimet n IT. Shrbimet vet mund t kompozohen n proese biznesi, pr t qen t prdorshme m pas nga prdoruesit, sistemet apo edhe nga shrbimet e tjera.

Figur 3. Pavarsia e nj shrbimi

N kt model, kryesore sht ndarja e ndrfaqes nga implementimi. Konsumatori i shrbimit duhet dhe ka nevoj t kuptoj vetm ndrfaqen. Implementimi ndodh gjat kohs pa e shqetsuar klientin. Shum prfitime q i adresohen sot SOA, vijn nga ky abstragim. Kjo do t thot q e njjta ndrfaqe mund t aksesohet nga shum klient njkohsisht. Ofruesit e shrbimeve deklarojn nj kontrat pr t paraqitur ndrfaqen publike q ata ofrojn. T gjitha lidhjet me ofruesin e shrbimit ndodhin nprmjet ndrfaqes. Kjo ndrfaqe prmban proese publike si edhe t dhna. Proeset publike prbjn pikn hyrse n shrbim, kurse t dhnat prezantojn mesazhin q do ti drgohet shrbimit. N qoftse do t prdorim nj dokument WSDL pr t paraqitur nj kontrat t thjesht, ather mesazhi prezanton t dhnat. Ndrkoh q pjesa m e vshtir e gjith ksaj sht ekspozimi i ndrfaqes publike dhe mirmbajtja e saj.

1.1.3 Karakteristikat kryesore t SOA. Tre konceptet kyesore t SOA jan: Ekspozimi: fokusohet tek sesi shrbimet do t ekspozohen, n mnyr q t jen t prdorshme nga klientt. Kompozimi: fokusohet n kombinimin e shrbimeve n aplikacione, apo proese biznesi.

4

Konsumi: fokusohet n mnyrn se si kto shrbime t kompozuara do t prdoren nga klientt, prdoruesit fundor. N shumicn e rasteve SOA mund t implementohet duke prdorur disa standarte, ku m t prdorurat jan HTTP, WSDL (Web Services Definition Language), SOAP (Simple Object Access Protocol) dhe XML (eXtensible Markup Language). Kto standarte punojn s bashku pr t transmetuar mesazhet nga nj shrbim tek nj tjetr. N qoftse n drgojm nj letr, ather n duhet ta dim adresn se ku do ta drgojm at. N rastin e SOA ky informacion vjen nga WSDL e cila liston mundsit e trasnmetimit si (HTTP, FTP, SMTP) si edhe gjuhn standarte t komunikimit q sht XML. N t njjtn mnyr zarfi SOAP mban informacion rreth adresave ku do t drgohen mesazhet dhe se kush e ka autorizimin ti hap ato. N zarfin SOAP nuk prcaktohet se kush do ta marr zarfin por emri i makins remote q do ta proesoj informacionin q ndodhet brenda tij. Me kt informacion ne mund t krjojm nj mesazh t bazuar n standartin XML, ta fusim brenda nj zarfi dhe ta nisim nprmjet protokollit HTTP. Marrsi i mesazhit lexon zarfin dhe prcakton makinn remote, adresn e sakt. Mesazhi m pas kalon n kt makin remote pr proesim t mtejshm. Ajo q n shohim n kt proes sht kalimi i mesazhit n shum hapa q nga prgatitja deri tek mbrritja n destinacion. Kjo prbn edhe nj nga sfidat e mdha t SOA, trasmetimin e mesazheve dhe proesimin e tyre.

Figur 4. Trasmetimi i mesazheve dhe proesimi i tyre

1. Shrbimi sht nj koncept shum i rndsishm. Web shrbimet jan

teknologjit q realizojn shrbimet, nprmjet t cilave ato mund t publikohen, zbulohen, dhe prdoren.

2. SOA n vetvete nuk sht vetm nj arkitektur shrbimesh, pasi ajo prfshin politikat, kontratat si edhe ndrfaqet nprmjet t cilave kontrollohet konsumi i shrbimeve.

5

SOA: shte nj arkitektur e bazuar n nj bashksi kompjuterash t shprndar (loosely-coupled architecture) e dizenjuar pr t ndihmuar bizneset t arrijn objektivat e tyre. SOA: Konsiderohet si nj bashksi komponentesh t cilt mund t shprndahen, dhe ndrfaqet e tyre prshkruese mund t publikohen dhe t zbulohen. Pr SOA ekzistojn tre tipe arkitekturash:

1. Arkitektura e aplikimit: Kjo sht ndrfaqja q u ofrohet bizneseve, t cilt konsumojn shrbime nga nj ose m shum ofrues shrbimesh duke i integruar ato n proeset e biznesit.

2. Arkitektura e shrbimit: Kjo shrben si nj ur ndrmjet implementimit dhe

konsumit t aplikacioneve, duke krijuar n kt mnyr nj pamje llogjike me nj bashksi shrbimesh t aksesueshme.

3. Komponentet e arkitekturs: Kjo prshkruan nj mjedis t mundshm q

mbshtet implementimin e aplikacioneve, objektet e biznesit dhe implementimin e tyre.

Kto arkitektura mund t studiohen nga kndvshtrimi i konsumuesit si edhe i ofruesit t shrbimit. elsi i ktyre arkitekturave sht se konsumuesi i shrbimit nuk interesohet pr detajet e imlementimit t shrbimit. Konsumatori fokusohet tek arkitektura e aplikimit, prdorimi i shrbimit, por jo tek komponentet e arkitekturs dhe implementimi i databazs. Ndrkoh q ofruesi i shrbimit fokusohet tek komponentet e arkitekturs, arkitektura e shrbimit, por jo n arkitekturn e aplikimit. Por, si konsumatori i shrbimit ashtu edhe ofruesi kan nevoj t din gjith informacionin rreth aplikacioneve. N thelb t ksaj arkitekture qndron manaxhimi i shrbimeve dhe shprndarja e tyre sipas nj rradh. Pasi sht shrbimi, ai q lidh konsumuesin me ofruesin. Q konsumuesi t dij se pr far shrbimi ai ka nevoj, cilat jan ato shrbime q jan t lira pr tu aksesuar, apo se kush jan ato shrbime q operojn s bashku, u zhvillua koncepti i Business Service Bus (BSB). BSB sht nj pamje llogjike q prezanton t gjitha shrbimet q jan t prdorshme pr nj domain t caktuar.

2 Pr t integruar sistemet IT egzistuese me ato t reja, nj arkitektur e orientuar drejt shrbimeve i duhet nj infrasktruktur e cila mund lidh me njri-tjetrin do burim IT, pavarsisht teknologjis apo ku sht i zhvilluar.Nj infrastruktur e till sht dhe Enterprise Service Bus (ESB) e paraqitur si n figurn 5.

2 http://www.centeractive.com/content/enterprise-service-bus

6

Figur 5. Arkitektura Enterprise Service bus

1.2 Komponentet arkitekturore t SOA Komponentet baz t nj arkitekture t orientuar nga shrbimet jan:

1. Ofruesi i shrbimeve (Sevice providers): Nj ofrues shrbimesh sht nj komponente ose nj bashksi komponentesh q ekzekuton funksionet e biznesit, gjithashtu pranon inpute dhe outpute.

2. Konsumuesi i shrbimeve (Service consumer): Nj konsumues shrbimesh sht nj bashksi komponentesh t interesuar t prdorin shrbimet q mundsohen prej ofruesve t shrbimeve.

3. Depozituesi i shrbimeve (Service repository): Nj depozitues prmban prshkrimet e nevojshme pr t gjitha shrbimet q ofrohen nga shrbyesit e ndryshm. Ofruesit e shrbimeve i depozitojn shrbimet q ata ofrojn n kto komponente dhe konsumuesit e tyre mund t aksesojn ato kur ata kan nevoj. Kto komponente baz jan paraqitur n figurn 6.

Figur 6. Komponentet e arkitekturs s orientuar nga shrbimet

7

1.3 Avantazhet, Sfidat.

1.3.1 Avantazhet e SOA. Avantazhet e SOA shihen n dy kndvshtrime: n IT dhe n biznes.

1. Duke e par nga pozicioni i IT, ajo lehtson manaxhimin e burimeve t shumta t shprndara prmes shum platformave, t cilat krkojn m pak investime n hardware dhe jan m t besueshme e m pak t kushtueshme. Kurse, duke e par SOA nga pikpamja e biznesit, ajo lejon zhvillimin e nj gjenerate t re aplikacionesh dinamike q jan zgjidhja e shum problemeve t biznesit.

2. SOA krijon lidhje t forta midis klientve dhe ofruesve t shrbimeve. Duke i br aplikacionet dinamike dhe shrbimet e bizneseve t prdorshme pr prdoruesit e jashtm dhe ofruesit, ajo arrin jo vetm nj bashkpunim m t mir, por rrit n kt mnyr edhe knaqsin e bashkveprimit.

3. SOA duke ndihmuar n rritjen e nivelit t informimit pr aplikacionet, dhe

rritjen e aksesueshmris s shrbimeve t biznesit arrin n kt mnyr q t dyja palt ti kuptojn m mir krkesat q kan ndaj njri-tjetrit.

Burimet IT, t shprndara dhe komplekse prbjn thelbin e bizneseve. Por, kto burime vite m par nuk prfaqsonin at q priste biznesi prej tyre. Zgjidhja e ktij problemi nuk sht zvendsimi i aplikacioneve apo sistemeve, por prdorimi i shrbimeve t SOA si ur pr t plotsuar nevojat e biznesit. Orientimi drejt shrbimeve e arrin kt qllim, duke i br sistemet m t afrta ndaj krkesave t biznesit. Ndjekja e ksaj linje bn q investimet n IT t prshtaten me strategjit e biznesit.

1.3.2 Sfidat e SOA. Cilat jan sfidat q i paraqiten SOA-s. [42]Gjithmon zhvillimet kan edhe mangsit e tyre. Edhe tek SOA t gjitha kto zhvillime shoqrohen nga ana tjetr edhe me disa mangsi. Nj prej tyre sht edhe siguria e cila sht shum e rndsishme n fushn e teknologjis, mungesa e s cils sjell vjedhjen e t dhnave sensitive.Prandaj sht i nevojshm validimi t dhnave dhe rritja e masave t siguris. Marrja e masave t nevojshme ndalon sulmet e shumta dhe rrit performancn duke reduktuar duplikimin e kodit. Rritja eksponenciale e numrit t lidhjeve shkakton uljen e shpjetsis s komunikimit. Menaxhimi i numrit t madh t lidhjeve do t reduktoj numrin e serverave, uljen e kostos, reduktimin e kompleksitetit dhe rritjen e performancs. Prdorimi i memorjes kashe dhe hostimi i shrbimeve t prbashkta sht nj mundsi q duhet aplikuar. Rritja e madhsis s mesazheve SOAP. Kjo krkon m shum bandwith dhe shum burime pr tu konsumuar. Zgjerueshmria (scalability), standarti XML q prdoret pr t transmetuar mesazhet krkon nj infrastruktur m t prshkallzueshme. Por nga ana tjetr kjo sfid sjell edhe rritjen e performancs.

8

Kapitulli 2 . Integrimi i Aplikimeve Ky kapitull do t trajtoj n mnyr t detajuar integrimin e aplikimeve, ku struktura e organizimit paraqitet n figurn e mposhtme.

Platform

Data Component

Application Manual

Automatik Automatik

Point-to-Point Middleware

Service Oriented File Transfer

Shared Database Remote Procedure Call

Messaging Web Services

Figur 7. Integrimi i Aplikimeve

2.1 far sht Integrimi i Aplikimeve? Integrimi i aplikimeve q shpesh i referohemi dhe EAI (Enterprise Application Integration) sht nj term kompjuterik biznesi pr planet, metodat dhe mjetet q synojn modernizimin, konsolidimin dhe koordinimin e aplikimeve kompjuterike n nj korporat.[2] Zakonisht, nj korporat ka aplikime dhe baza t dhnash ekzistuese t trashguara dhe synon t vazhdoj ti prdor kto sisteme ndrkoh q shton apo migron n teknologji t reja.[3]

INTEGRIMI i APLIKIMEVE

far sht integrimi i aplikimeve?

Krkesa e tregut pr integrimin e aplikimeve

Llojet e integrimit t aplikimeve

Prqasjet e integrimit t aplikimeve

Arkitekturat e integrimit

Stilet e integrimit t aplikimeve

Protokollet e transportit

9

Integrimi i aplikimeve sht ndarja dhe prdorimi i prbashkt, n mnyr t sigurt dhe t orkestruar, i t dhnave dhe proeseve ndrmjet aplikimeve t ndryshme t nj kompanie.[4]

2.2 Nevoja dhe krkesa e tregut pr Integrimin e Aplikimeve Me kalimin e viteve, mjediset IT jan br gjithnj e m shum komplekse dhe heterogjene pr shkak t nevojave t ndryshme t klientit dhe risive t menjhershme n industrin e IT.[5] Mjediset moderne siprmarrse prbhen nga nj numr i madh aplikimesh, q jan zhvilluar ndr vite, sa her q ka pasur dhe jan idenifikuar krkesa t reja nga klienti/biznesi. Pr rrjedhoj, kto aplikime n m t shumtn e rasteve, jan t periudhave t ndryshme, jan shkruar nga persona t ndryshm duke prdorur gjuh dhe teknologji t ndryshme, qndrojn n platforma hardware t ndryshme, prdorin sisteme operative t ndryshme, si dhe ofrojn funksionalitete t ndryshme. Pr kompanin, kto kushte mund t cojn n aktivitete t teprta, kosto m t larta si dhe n prgjigje jo efiente ndaj klientit. Ashtu sic punonjsit duhet t punojn s bashku pr t realizuar qllimet e biznesit, edhe aplikimet kan nevoj t bjn t njjtn gj.[6] N munges t integrimit t aplikacioneve, kompanit nuk do t jen n gjendje t sistemojne (leverage) informacionin prezent n depot (repositories) n zgjerim t vazhdueshm t ndrmarrjes dhe mund t rrezikojn t marrin vendime jo korrekte pr shkak t informacionit kontradiktor (inconsistent). Nj ndrmarrje (enterprise) funksionon n mnyrn m t mir kur sistemon informacionin q sht prezent n depo t ndryshme n ndrmarrje.[7] Mqs shumica e aplikacioneve prezent n ndrmarrje nuk jan t hapur (open) ose kompatibl me njri-tjetrin, ather krkohet prpjekje shtes pr t integruar aplikacionet e ndryshme brenda ndrmarrjes. Disa nga aplikimet e trashguara jan kritike pr realizimin e funksioneve t biznesit dhe pr rrjedhoj nuk mund t zvndsohen. Nj pjes e ktyre aplikimeve kan nevoj t integrohen me sisteme t tjera. T tjer mund t ken nevoj t migrohen n nj arkitektur t re ose t ri implementohen duke prdorur teknologji t tjera. Sfida q shum kompani tashm po ndeshin sht se si t sigurojn nj metod nprmjet s cils kto aplikime t mund t punojn s bashku pr t adresuar krkesat e biznesit q vazhdimisht evoluojn.[8] Integrimi i sistemeve kompjuterike me njri tjetrin erdhi si prgjigje ndaj nevojs pr t lidhur s bashku shum sisteme t veanta kompjuterike. Sistemet e integruara supozohet t bashkpunojn dhe t sigurojn funksionalitete t unifikuara. Pr m tepr, pritet q nj sistem i ri i integruar t operoj mbi t dhnat e siguruara nga t gjith sistemet kompjuterike pjesmarrse. Ka shum faktor q e bjn integrimin t vshtir dhe sfidues. Sistemet, q supozohet se duhet t integrohen, mund t operojn n organizata t ndryshme, mund t jen zhvilluar duke prdorur teknologji t ndryshme, mund t jen sisteme t trashguara pa mirmbajts etj.

10

Nevoja pr t integruar sistemet mund t lind nga shum arsye, psh, bashkimi i dy kompanive, bashkimi i shum degve t nj kompanie, nevoja pr t pasur nj sistem prgjegjs pr koordinimin e t tjerve. Nj arsye tjetr mund t jet reduktimi i kostos. Nj sistem i unifikuar, nga kndvshtrimi i biznesit, sht m efektiv dhe m i lir t mirmbahet se sa dy sisteme q punojn n mnyr t pavarur. Rezultate t pritshme nga integrimi jan si m posht:[9] - Reduktohet kosto - Rritet efikasiteti - Prmirsohen proeset e bisnesit (business processes) - Unifikohet rrjedha e informacionit (flow of information) - Arsye t tjera q e bjn proesin e integrimit akoma m t vshtir jan: - Sistemet q duhet t integrohen, mund t jen t shprndar gjeografikisht n

makina t vendosura n vendndodhje t largta. - Sistemet mund t jen shkruar n gjuh t ndryshme programuese - Sistemet mund t mos ken dokumentacion e nevojshm teknik - Sistemet mund t ekzekutohen n mjedise t ndryshme (sisteme operative,

konfigurimet hardware etj) - Sistemet mund t menaxhohen nga njsi t ndryshme organizative ose edhe

kompani t ndryshme - Kompanit, q sigurojn proprietary software, nuk jan t gatshm t marrin

pjes n proesin e integrimit, sepse nuk duan t zbulojn implementimin e brendshm t produkteve t tyre.

- Punonjsit mund t mos jen t gatshm tu prshtaten ndryshimeve si rrjedhoj e proesit t integrimit.

Realizimi n mnyr efiente i integrimit t aplikimeve i siguron do kompanie prfitimet e mposhtme: 1. Aplikimet funksionojn n mnyr m efiente dhe me kosto m t ult. 2. Lejon modifikimin e proeseve t biznesit sipas krkesave t kompanis 3. Siguron m shum kanale shprndarjeje pr kompanin 4. Lejon t shtohen hapa automatik n proese biznesi q m par krkonin

ndrhyrje manuale.

2.3 Mnyrat e Integrimit t Aplikimeve Ekzistojn sisteme t ndryshme pr t ndar/shkallzuar zgjidhjet e integrimit n nivele t ndryshme. Nj metod sht t ndahen teknikat e integrimit n: integrim i brendshm dhe integrim i jashtm. Nj kategorizim m i detajuar fokusohet n fleksibilitetin dhe shkallzueshmrin e zgjidhjeve t integrimit. N figurn 8 m posht, jan paraqitur katr mnyrat e integrimit Integrimi Platform, Data, Component dhe Application[10].

11

Figur 8. Mnyrat e Integrimit

N vijim do t paraqitet nj prshkrimi i shkurtr i katr llojeve t integrimit si m sipr.

2.3.1. Platform Integration

Integrimi Platform siguron lidhjet dhe ndrfaqet e shrbimeve ndrmjet sistemeve me hardware, sisteme operative dhe aplikime t ndryshme. Zgjidhjet jan individuale dhe lidhja bhet nprmjet Borkers ose RPC (Remote Procedure Calls) etj.[11] Duke qen se secila zgjidhje integrimi sht individuale, ngarkesa (workload) sht po aq e lart sa integrimi fillestar kur sisteme t reja duhet t shtohen n arkitekturn aktuale. Figura e mposhtme tregon nj shembull t arkitekturs s integrimit t tipit platform ndrmjet dy platformave t ndryshme.

Figur 9. Shembull i Platform Integration

2.3.3 Data Integration

12

Zgjidhjet Data Integration ofrojn mjete pr t ekstraktuar, transformuar dhe zhvendosur t dhna.[12] Prfshin integrimin platform dhe krkon informacion mbi skemat e databaza-ve. Nj shembull i zakonshm i data integration sht kur t dhnat nga nj databaz shtohen n nj databaz tjetr nprmjet SQL. N shum raste, t dhnat mund t integrohen ndrmjet dy platformave dhe sistemeve database t ndryshme, gj q do t krkoj prdorimin e API dhe database connectivity drivers pr t aksesuar secilin nga database servers n mnyr q t ngarkohen t dhnat n nj tjetr. Kjo tregohet n figurn si m posht:

Figur 10. Data Integration ndrmjet platformave t ndryshme

2.3.4 Component Integration

Zhvillimi i nj data integration mund t konsiderohet si component integration. Tipare t shumta rrjeti i shtohen produktit si psh: load balance, fault protection, session management dhe security. Baza e nj zgjidhje component integration sht nj server q ofron t gjith karakteristikat e msiprme. Figura e mposhtme prfaqson nj shembull t component integration.

Figur 11. Shembull i integrimit Komponent

2.3.2 Application Integration

13

Zgjidhjet application integration ofrojn nj framework pr krijimin dhe ndryshimin e zgjidhjes s integrimit si psh shtimi i aplikimeve t reja shpejt dhe me lehtsi. Framework-u konsiston n pre-built adapters pr sistemet m t zakonshme t cilat zvoglojn kohn pr shtimin e aplikimeve t reja.[13] Madje disa lidhin secilin aplikim me nj form t unifikuar. Ky trajtim ofron nj avantazh t madh kur aplikimet ndryshojn duke qen se vetm lidhja (mapping) me formn e unifikuar duhet t ndryshohet, t gjith aplikimet e tjera jan t paprekur. Nj zgjidhje application integration prfshin t gjith shrbimet e prshkruara n seksionet pasuese t ketij kapitulli. Figura e mposhtme tregon si mund t integrohen aplikime t ndryshme s bashku dhe fleksibilitetin e ndryshimeve n topologjin e integrimit.

Figur 12. Shembull i Application Integration

Framework i para-zhvilluar e bn t leht shtimin e aplikimeve t reja, duke prdorur lloje t ndryshme prshtatsish

Qllimi i integrimit t aplikimit sht t krijohet nj framework pr t integruar sisteme jo kompatibl dhe t shprndar, duke e br m t shpejt dhe m t leht zgjerimin e proeseve t biznesit prgjat organizats. Sot, shum kompani kryesore prpiqen dhe tentojn t zhvillojn frameworks, mjete integrimi dhe infrastrukture service-oriented n mnyr q t realizojn kt detyr. Mund t konstatohet se prpjekjet e pasukseshme kundrejt interoperabilitetit t aplikimeve brenda organizats kan sjell keqinterpretim t konceptit t integrimit t aplikimeve nga shum organizata. Nj nga pyetjet q shtrohet si rrjedhoj sht: fare sht enterprise application integration? far impakti ka kjo teknologji

mbi ndrveprimin e aplikimeve dhe si mund t prfshihet n nj organizat?

14

Prpara se sa ti prgjigjemi ktyre pyetjeve, n duhet t japim nj prcaktim pr termin enterprise integration detyra q bn aplikime t ndryshme t punojn s bashku pr t prodhuar nj trsi funksionalitetesh t unifikuara.[12] Kjo detyr sht m shum se vetm thjesht integrimi i aplikimeve por duhet t marr n konsiderate kriteret, opsionet e integrimit, stilet, politikat dhe gjithashtu prcaktimi i prqasjes m t mir pr integrimin e aplikimeve.

Integrim i aplikimeve sht nj pjes shum e rndsishme e strategjis IT t do biznesi. Bizneset po mendojn se si t kombinojn aplikimet e tyre t veanta n nj bashksi aplikimesh bashkpunuese n mnyr q biznesi i tyre t bhet m fleksibl. Nj biznes fleksibl krkon detyrimisht IT fleksibl.

Integrimi manual i aplikimeve

Integrimi manual i aplikimeve sht proesi kur personeli (psh. punonjesit ose klientet) duhet t vproj si ndrfaqe ndrmjet aplikimeve dhe t lehtsoj integrimin mes tyre.[4] Kjo mund t jet n formn e mbledhjes s informacionit dhe regjistrimit t informacionit n disa sisteme dhe rrjedhimisht duke lexuar informacion nga kto sisteme n mnyr q ti prgjigjemi krkesave t klientit. N raste t tjera, nj person mund t nevojitet t lexoj informacionin mbi klientin nga nj databaz, dhe m pas ta ri-regjistroj at n nj databaz tjetr q prdoret pr qllime t tjera. Kjo form integrimi krkon shum pak investim n teknologji por m shum prpjekje nga prdoruesi dhe zhvilluesit. Disavantazhet e identifikuara me teknikn manuale jan:

N m t shumtn e rasteve ka nj probabilitet t lart t pasaktsive n t dhna pr shkak t inkonsistencs dhe mungess s shkallzueshmris.

Integrimi manual bhet m kompleks kur ka m shum sisteme q varen nga t dhnat dhe gjithashtu kur organizata bhet m komplekse.

Me rritjen e sasis dhe kompleksitetit t t dhnave ose me rritjen e numrit t aplikimeve, organizata do t krkoj m shum njerz pr t mirmbajtur nj mjedis t till manual integrimi.

Nj mjedis q mbshtetet shum n integrimin manual sht zakonisht shum jo efient, dhe nuk zgjerohet aq lehtsisht si mjediset q prdorin teknika m t automatizuara.

Integrimi automatik i aplikimeve

Nga ana tjetr, integrimi automatik kombinon hapat njerzore me pak automatizim. Njeriu nuk mund t prfshihet n nj fush ku zgjidhja automatike korresponduese sht shum e vshtir ose e shtrenjt pr tu implementuar ose

15

kur biznesi krkon q nj person t marr vendimet. Kjo teknik krkon m shum investim n teknologji, por pasi investimi bhet, numri i njerzve t prfshir n integrimin e aplikimeve mund t reduktohet zakonisht.[4] Reduktimi i prfshirjes humane zakonisht redukton kostot dhe rrit besueshmrin (reliability). Ky lloj integrimi nuk konsiderohet si mjaftueshm efient, duke qen se akoma krkon ndrhyrjen e disa personave n mes t proesit, psh. nevoja e ndrhyrjes humane pr t transformuar t dhnat q krkohen nga nj sistem tjetr, dhe gjithashtu t sigurohemi q t dhnat po prdoren nga aplikimi tjetr prpara se sa t hidhen.

Integrimi automatik i aplikimeve

Integrimi automatik sht nj teknik q redukton varsin humane n proesin e integrimit dhe lejon aplikimet t ndrveprojn pa ndrhyrje. Ky lloj integrimi konsiston n aplikime q komunikojn nprmjet nj trsie ndrfaqesh (interfaces) dhe prshtatsish (adapters). Psh. dy databaza mund t ndajn s bashku (share) t dhna, q transformohen dhe kalohen nga databaz i par n database-in e dyt pa ndrveprim human. Megjithse integrimi plotsisht automatik i aplikimeve largon varsin nga njeriu, sisteme t tilla mund t jen m t shtrenjt pr tu implementur dhe mund t mos jen praktike pr shum probleme biznesi. N shum raste, nj organizat akoma do t krkoj njerz pr t marr vendime biznesi dhe shum shpesh gjithashtu sht m efiente t ket nj person q kontrollon nj proes teknik. Teknika plotsisht automatike pr integrimin e aplikimeve sht br teknika m e besueshme (reliable) pr shkak t faktit q shkallzueshmria, efiensa dhe konsistenca derivohen n proesin e ndarjes s t dhnave (data sharing), komunikimin dhe shkmbimin e mesazheve. Teknikat e msiprme prbjn prqasjet baz pr integrimin e aplikimeve. Secila teknik ka avanatzhet dhe disavantazhet e saj, bazuar n mjedisin, natyrn e aplikimeve q kan nevoj t integrohen dhe gjithashtu siguria dhe politikat e tjera t biznesit. n do t vlersojm kriteret dhe krkesat pr seciln teknik dhe do t bjm krahasimin e tyre bazuar n kriteret dhe krkesat n kapitullin pasues. Le t vshtrojm n vijim arkitekturn e integrimit q t shikojm se si mund t adoptohet n teknikat e msiprme.

16

Kapitulli 3 Arkitektura e Integrimit t Aplikimeve

Integrimi i aplikimeve mund t mbshtetet nga arkitektura t ndryshme. Nj nga arkitekturat sht zgjidhja point-to-point ku secili aplikim lidhet direkt me do aplikim tjetr. Kjo zgjidhje mund t funksionoj pr nj numr t vogl aplikimesh, por kur shtrihen shum aplikime, numri i lidhjeve rritet shum shpejt. Pr m tepr, kur nj aplikim i ri prezantohet, duhet t lidhet me do njrin prej aplikimeve t tjera. Arkitektura tjetr sht mbi konceptin e modelit t integrimit bazuar n middleware. Ideja kryesore sht t reduktohet numri i ndrfaqeve duke vendosur nj message bus n qendr dhe nv kt mnyr e bn m t leht suportin ndaj ndrfaqeve. Nse nj nga aplikimet ndryshon formatin, vetm nj lidhje duhet t ndryshohet: lidhja me message bus. N t njjtn mnyr, nse shtohet nj aplikim, vetm nj lidhje e re krkohet. [14]Nj mnyr shum e rndsishme pr t br integrimin e aplikimeve t shkallzueshm sht duke rritur numrin e hapave automatik dhe duke reduktuar numrin e hapave njerzor (manual). Nj gj e till e ka br integrimin automatik t aplikimeve m t sukseshm, t shkallzueshm dhe efient sesa integrimet manual dhe automatik. Kjo implikon krijimin e ndrfaqeve ndrmjet aplikimeve pr t zvndsuar punn njerzore. Rritja e nivelit t automatizimit zakonisht rrit sasin e informacionit q shkmbehet ndrmjet aplikimeve pa qn nevoja t rritet numri i punonjsve pr t realizuar qllimet e biznesit. shtjet e shkallzimit, gjithsesi nuk mund t zgjidhen thjesht nprmjet automatizimit. Duhet t konsiderojm dhe numrin e aplikimeve dhe se si ndodh integrimi ndrmjet tyre. N kt punim do t trajtohen alternativat e mposhtme pr integrimin automatik: 1. Arkitektura Point-to-Point 2. Arkitektura Middleware 3. Arkitektura Service Oriented

3.1 Arkitektura Point-to-Point

Modeli point-to-point prshkruan nj struktur t decentralizuar n t ciln do aplikim komunikon drejtprdrejt me secilin prej aplikimeve t tjera. Me rritjen e numrit t aplikimeve dhe shrbimeve, rritet edhe numri i ndrfaqeve dhe lidhjeve q duhet t mirmbahen n nj mjedis point-to-point. Numri maksimal i lidhjeve q nevojiten prcaktohet si vijon: x (x=1 to n-1) Ku n sht numri i aplikimeve q duhet t integrohen. Numri i ndrfaqeve q krkohen mund t arrij deri n 2-fishin e numrit t lidhjeve. Problemi n kt metod sht mungesa e konsistencs. Sa m shum q zhvillohen ose prditsohen aplikimet, aq m shum ndrfaqe shtes duhet t krijohen. do ndryshim e bn mjedisin m t vshtir pr tu kuptuar, deri sa, arrin nj pik q struktura bhet aq komplekse sa sht e pamundur t menaxhohet efektivisht. Nj

17

struktur kaq komplekse mund t pengoj kompanin q t ndryshoj (zhvendos) qllimet e saj t biznesit, pr shkak t kostove t larta t ndryshimeve IT. Ky lloj integrimi sht i prshtatshm pr kompani q duan t integrojn pak aplikime me nj numr t vogl shrbimesh. Figura 13 tregon numrin e lidhjeve t nevojshme t krijohen n nj mjedis point-to-point me 3 dhe 10 aplikime, n rastin kur duhet t sigurojm q t gjith aplikimet mund t komunikojn me njri-tjetrin.

Figur 13. Komunikimi point-to-point ndrmjet aplikimeve

N skenarin A t figurs 3, pr 3 aplikime nevojiten 3 lidhje dhe 6 ndrfaqe, ndrsa pr shembullin n skenarin B (10 aplikime) krkohen 45 dhe dhe 90 ndrfaqe[4] .

3.2 Arkitektura Middleware Modeli middleware ose integration hub na siguron nj struktur m t centralizuar, n t ciln nj integration hub vendoset ndrmjet aplikimeve, dhe secili aplikim komunikon me hub dhe jo drejtprdrejt me aplikimet e tjera. do aplikim ka nevoj vetm pr nj ndrfaqe dhe nj lidhje me integration hub. Avantazhi kryesor i nj mjedisi integration hub sht shkallzueshmria. Figura e mposhtme tregon prdorimin e nj integration hub srisht n mjedise me 3 dhe 10 aplikime.

Figur 14. Aplikimet t lidhura nprmjet nj integration hub

18

N figurn e msiprme, krkohet vetm nj lidhje me integration hub, me ndrfaqe t nevojshme tek aplikimi dhe tek integration hub. Megjithat, shum mjedise krkojn vetm nj ndrfaqe (ose asnj nse aplikimi prdor standartin e suportuar nga hub). Ky konfigurim na on n nj maksimum prej 3 lidhjesh dhe 6 ndrfaqesh pr shembullin me 3 aplikime ose 10 lidhje dhe 20 nderfaqe n rastin e shembullit me 10 aplikime. N m t shumtn e rasteve, numri i ndrfaqeve sht ndjeshm m i vogl. Modeli integration hub sht ndjeshm m i shkallzueshm pr mjedise integruese me shum aplikime. Zakonisht kompanit e mdha kan nj numr shum t madh aplikimesh. sht e pamundur t krijojm ndrfaqe individuale pr do pik ndrveprimi. Zgjidhja sht t krijojm nj mjedis integrues q lejon t gjith aplikimet t komunikojn n mnyr logjike t paracaktuar. Nj infrastruktur e till hub na lejon t modifikojm ose prditsojm elementt shum m leht, dhe t bjm nj veprim t till ather kur biznesi e krkon dhe jo kur teknologjia paraprirse t na e mundsoj. Gjithashtu e lejon kompanin t ndryshoj m lehtsisht drejtimin e saj dhe t prdor produktet dhe shrbimet e saj pr t prmbushur krkesat vazhdimisht n rritje. Mqs ndrfaqet ndodhen n integration hub (dhe zakonisht jan standard-based), nuk sht e nevojshme ti rishkruajm ato sa her q prezantohen aplikime t reja. Megjithat, implementimi i nj hub mund t jet teknikisht nj sfid dhe madje shum i kushtueshm pr mjedise m t thjeshta integruese. Akoma m tej, mund t duhet t sakrifikojm kompleksitetin e disa t dhnave pr t siguruar q do aplikim sht konform standarteve t integration hub.[4]

3.3 Stilet e integrimit

Ka shum stile q sugjerohen dhe aplikohen pr integrimin e aplikimeve dhe q variojn nga ato n nivel t ult deri tek nocioni i mesazheve asinkrone dhe orientimi drejt shrbimeve (web services). Kto trajtime mundsojn integrimin duke ndar (share) t dhnat ose logjikn e biznesit. Katr zgjidhje n nivel t ult (low level), t cilat mund t duken t vjetra dhe t thjeshta kur krahasohen me teknologjit e reja, jan identifikuar n kt punim. Megjithse t vjetra dhe t thjeshta, kto katr zgjidhje sic dhe do diskutohen n kt seksion, jan akoma t zbatueshme dhe t dobishme. Ata gjithashtu prbjn bazn pr skemat e tjera m t prpunuara/zhvilluara t arkitekturave integruese. Trajtimet q do diskutohen jan:

1. File Transfers 2. Shared Databases 3. Remote Procedure Invocations 4. Messaging

5.Web Services

19

3.4.1 File Transfer

Synimi i ksaj arkitekture teknike t thjesht sht t shkmbehet informacion ndrmjet aplikimeve ose platformave t shumta nprmjet transferimit t skedarve (files) n batch mode. Nj aplikim e bn nj gj t till duke eksportuar informacionin e nevojshm n nj format standart. Pavarsisht nga mnyra, rezultati sht nj skedar me gjith informacionin e nevojshm, q m pas mund t transmetohet tek aplikime t tjera, t cilt m pas duhet t importojn dhe filtrojn informacionin nga skedari prpara se sa ta proesojn at. Figura e mposhtme prshkruan skemn file transfer (export-import) ku aplikimi A shkmben t dhna me aplikimin B. T dhnat transferohen ndrmjet sistemeve n mnyr asinkrone duke prdorur batch file transfers dhe rrjedha e t dhnave sht njdrejtimshe. Ndryshimet n njrin sistem shum rrall prekin sistemet e tjera, prve se kur struktura, formati dhe semantika e t dhnave q po transferohen ndryshon. File transfer sht nj zgjidhje me kosto efektive pr transferimin e batch files ndrmjet paltformave me variacion t gjer.[4]

Figur 15. Skema File Transfer

N kt arkitektur tipike, integruesit marrin prgjegjsin e transformimit t skedarve n formate t ndryshme, dhe garantojn q skedart gjenerohen n intevale t rregullta n prputhje me natyrn e biznesit. Nj vendim i rndsishm me skedart sht far formati t prdoret.[12] Shum rrall do t ndodh q outputi i njrit aplikim t jet ekzaktsisht far nevojitet pr aplikimin tjetr, pr rrjedhoj kjo krkon t bhet pak proesim i skedarve gjat rrugs. Jo t gjith aplikimet q prdorin nj skedar duhet ta lexojn at, nj prej tyre mund t duhet t prdor mjete proesimi mbi t. Si rezultat, formatet standart t skedarve po prdoren gjithnj e m shum me kalimin e kohs.

3.4.2 Shared Database

Skema file transfer e diskutuar m lart ka tendencn t prezantoj nj form ngadalsie (latency) q sht shpesh e pa pranueshme. Ndonjher, aplikimet duhet t punojn mbi t njjtin dataset gjat kohs s tyre t operimit. Shared Database ofron zgjidhjen. Arkitektura Shared Database mundson integrimin e aplikimeve t ndryshme duke br q aplikimet ti ruajn t dhnat e tyre n nj databaz t vetm shared. Nse nj trsi aplikimesh t integruara mbshteten n

20

t njjtn databaz, ather jemi mjaftueshm t sigurt q kto aplikime jan konsistente gjat gjith kohs. Nse merren update-e t njkohshme tek nj pjes e vetme t dhnash nga burime t ndryshme, ather duhet t kemi sisteme pr menaxhimin e transaksioneve q duhet t merret me kt problem. Duke qen se koha ndrmjet update-ve sht shum e vogl, gabimet mund t gjenden leht dhe t rregullohen. Database i prbashkt nuk duhet detyrimisht t jet nj databaz fizik; mund t jet dhe nj shared database virtual, n sensin q nj mekanizm komunikimi garanton q t gjith instancat e ndryshme fizike t databazs mbahen t sinkronizuara. Menaxhimi i transaksioneve luan nj rol t madh n kt rast, por transaksionet jan mjaft t zakonshme pr do DBMS. Skema ilustrohet si m posht:

Figur 16. Skema Shared Database

3.4.3 Remote Procedure Call

Skema Remote Procedure Invocation (RPI) e paraqitur n figurn 16, n ndryshim nga dy skemat e diskutuara m par, q ndajn vetm informacionin, ndahet dhe n funksionalitete n m t shumtn e rasteve. C/C++ RPC dhe Java RMI jan q t dyja shembuj t Remote Procedure Invocation.[12] Remote Procedure Invocation aplikon parimin e enkapsulimit pr t integruar aplikime t ndryshme. Nse nj aplikim ka nevoj pr informacion q zotrohet nga nj aplikim tjetr, ather e pyet drejtprdrejt at aplikim. Nse nj aplikim ka nevoj t modifikoj t dhnat e nj tjetri, ather e bn nj gj t till duke kryer nj thirrje (call) tek aplikimi tjetr. Secili aplikim mund t mirmbaj integritetin e t dhnave q zotron. Gjithashtu, secili aplikim mund t ndryshoj t dhnat e tij t brendshme pa prekur aplikimet e tjera. Parimi baz i ksaj skeme sht t zhvillohet secili aplikim si nj objekt ose komponent large-scale me t dhna t enkapsuluara dhe rrjedhimisht t ofrohet nj ndrfaqe pr t lejuar aplikimet e tjera t ndrveprojn me aplikimin n ekzekutim.

21

Figur 17. Skema Remote Procedure Invocation

3.4.4 Messaging

Messaging pretendon t jet trajtimi teknik m fleksibl i integrimit krahasuar me skemat e mparshme t transportit t diskutuara m lart. Kjo skem akomodon ndarjen e informacionit si dhe ndarjen e funksioneve dhe shrbimeve. Gregor Hohpe dhe Bobby Woolf e prcaktuan kt skem si nj prqasje (approach) teknik e prdodur pr t transferuar paketat e t dhnave n mnyr frekuente, me shpejtsi, me besueshmri dhe n mnyr asinkrone, duke prdorur formate t customizuar.[12] Asynchronous messaging sht krejtsisht nj reagim pragmatik ndaj problemeve t sistemeve t shprndara. T drgosh nj mesazh nuk krkon q t dy sistemet t jen gati dhe n gjendje pun n t njjtn koh. Ideja baz e messaging ilustrohet n figurn 17.

Figur 18. Skema Message Bus

Ndarja e informacionit sht fare e thjesht me nj skem t mesazheve t vendosur ku ndryshimet transmetohen live tek aplikimi tjetr. N kt rast, ngjarja si sht modeluar n figurn m lart do t jet njoftimi i update.

3.4.5 Web Services

Nj prcaktim pr Web service nga W3C sht si vijon: Nj web service sht nj sistem software i projektuar pr t mbshtetur ndrveprimin makin-makin n rrjet. Ka nj ndrfaqe q prshkruhet me an t nj formati t proesueshm nga makina (specifikisht WSDL). Sistemet e tjera ndrveprojn me web service n nj mnyr t parashkruar n prshkrimin e tij duke prdorur mesazhe SOAP, q zakonisht transportohen duke prdorur HTTP me nj serializim XML. do

22

funksionalitet ose shrbim mund t ekspozohet si nj web service. Pr do shrbim q do t ekspozohet si web service: Funksionaliteti duhet t prshkruhet n gjuhn WSDL (Web Services Description Language) Konsumuesit e shrbimit ndrveprojn me web service duke prdorur mesazhe SOAP. N mnyr opsionale, lista e web service mund t ruhet n UDDI registries. Ofruesi i shrbimit duhet t regjistrohet n UDDI registry. Nj web service zakonisht identifikohet nga nj URI (Unified Resource Identifier). Nj web service ka prcaktimet WSDL. Pr t komunikuar me web service duhet t prdorim mesazhet SOAP, q jan mesazhe XML-based q transportohen nprmjet protokolleve t internetit si HTTP, SMTP dhe FTP. Shrbimet web mund t prshkruhen m mir me diagramn e mposhtme:

Figur 19. Koncepti i Web Service

N kt rast, krkuesi i shrbimit sht klienti i web service, dhe ofruesi i shrbimit sht hostuesi i web service. Nj krkues bn krkesa SOAP tek ofruesi dhe ky i fundit prgjigjet. Nj service registry mund t mendohet si nj databaz web service-sh. Ka prcaktimet dhe URI-t pr web service-t. Zhvilluesit e web service-ve mund ti publikojn shrbimet e tyre n nj service registry nse duan. Pas ksaj dikush mund t bj krkim (query) dhe t zgjedh shrbimin nga registry. Duke qen se nj registry ka t gjith informacionin q nevojitet pr t zhvilluar nj web client, zhvilluesit mund t krkojn dhe t gjejn informacionin q ju nevojitet nga nj service registry duke prdorur UDDI (Universal Description, Discovery and Integration) Mnyra m e prhapur dhe q prdoret m s shumti pr t realizuar nj SOA sht duke prdorur web service. Ndrkoh q SOA na ofron parimet, shrbimet web na ofrojn strategjin pr t realizuar nj SOA. Web Service zhvillohen duke prdorur nj set standartesh XML si WSDL (Web Service Definition Language), SOAP (Simple Object Access Protocol) dhe UDDI (Universal Description Discovery and Integration).Web Services krijohen duke prdorur mjedise zhvillimi dhe shprndahen n Application Server.

23

Kapitulli 4 Ndikimi i rrjetit n Bazat e t Dhnave t Shprndara

4.1 Rndsia e rolit t rrjetave n arkitekturn SOA

Grupet q merren me manaxhimin e infrastrukturs se IT, po vazhdojn t mbajn krkesat e trashgimis dhe aplikacioneve t reja n nj qendr t dhnash. [16] Organizimi i IT (ITO) i shrben biznesit n mnyr t till q n momente presioni t shprndaje me shum duke prdorur t njejtat burime apo dhe me pak rregullat e reja mbi sigurine po krkohen n qeverisjen e korporatave dhe mbrojtjen e informacionit, dhe problemet me perputhshmerine, reduktimi i kostos, manaxhimi i performancs se biznesit, dhe proesi i funksionimit t nder-bizneseve jan n qendr t vemendjes se drejtuesve. Gjithnj e me teper, biznesi po drejtohet drejt IT pr t permirsuar efiensn e tij. Brenda mureve t ITO, ritmi i aplikacioneve t reja sht duke u prshpejttuar. Duke u nisur nga krkesat gjithnj n rritje, zhvilluesit jan duke prshtatur metodologji t reja. Zhvillimi si psh RAD (rapid application development) ose teknika ekstreme programimi, dhe grupet e programimit po lshojne nj lum programesh t reja dhe shrbime q ekzekutohen n rrjetin e korporats dhe po aq mir perhapen edhe drejt klienteve dhe partnereve t biznesit. N mbshtetje t ktyre aplikacioneve - edhe far sht trashguar dhe t rejat - pyetja sht e njjt si do t mundet Organizata e IT, t arrij objektivat e fleksibilitetit, sigurimin e aksesit n kto aplikacione duke siguruar disponueshmeri t vazhdueshme, prshkallzim dhe performanc, sht ose penges n kosto apo n shum raste e pamundur pr t dizenjuar kto funksione brenda vete aplikacioneve.Si rrjedhim, nj rol thelbesor luan rrjeti n njesimin e aplikacionit dhe n varsin ndaj infrastrukturs. Kjo sht nj kthes shum e mir nga e kaluara, ku rrjetit i jepej vazhdimisht nj konsiderate dytsore dhe shihej thjesht si lidhs. Pa rrjetin e tij, biznesi nuk ka aplikacione, dhe pa aplikacionet e tij, biznesi nuk mund t funksionoje. Pr shum persona, humbja e rrjetit on direkt n humbje t ardhurash. Gjithsesi tradicionalisht, rrjeti ka qene jofleksibel dhe i pamundur pr tju prgjigjur sfidave t aplikacioneve t kohs, ose me hapesira sigurie, mungese prshkallzimi, problemeve n performanc prgjat WAN, apo dhe mos -funksionim. Kjo ndodh pasi rrjeti ka mungese inteligjence pr tu prshtatur dhe pr t siguruar shrbime efektive n kosto t cilat mund t prdoren pr llogari t aplikacionit. Pr networker-at pr t shprndare aplikacionet n mnyr t suksesshme, nuk sht thjeshte shtje shtimi t kapacitetit apo lidhjes. Qasje t reja n shprndarjen e aplikacioneve si psh arkitekturat e orientuara drejt shrbimeve, peer-to-peer, dhe grid computing ndryshojn n mnyr radikale rrjedhn e trafikut ndrmjet pikave n rrjet. Qasja reaguese tipike pr t adresuar sfidat e aplikacioneve n network sht aplikimi i point solutions, si psh ekuilibruesit e ngarkeses s serverave, paisjet e

24

prshpejttimit, paisjet ndrhyrese, paisjet detektuese/parandaluese, ose zgjidhjet e transformimit t permbajtjes. Kjo rezulton n kosto shum t larta t supportit t infrastrukturs, ku problemi domain (applikacioni) sht transferuar n rrjet n formen e shum paisjeve t vecanta t cilat performojne n mnyr nj funksionale nga shites t ndryshem q sht pikerisht lloji i gabimit dizenjues arkitekturor q shmangin kompanite me t sprovuara n treg. Krkohet nj nivel shum i lart i automizimit, integrimit dhe dizenjimit arkitekturor, me mbshtetje inteligjence bazuar n rrjet.

4.2 Bazat e t dhnave t shprndara

Pavarsisht llojit t aplikacionit apo shrbimeve t ndryshme, sht shum e rndsishme q informacioni t cilin ato prdorin t ket nj qendrueshmeri t lart, t jete i ruajtur, i sigurt, si edhe t ket mundsin e zgjerimit sipas krkesave dhe rritjes s prdoruesve. Tendenca pr adresimin e ktyre krkesave sht e prirur drejt bazave t t dhnave t shprndara.[17] Ndryshe nga sistemet paralele, n t cilat, proesoret jan shum t lidhur dhe i referohen vetm nj sistemi baze t dhnash, nj sistem i shprndare bazash t dhnash, konsiston n site t lidhur dobt t cilt nuk ndajne me njri-tjetrin komponente fizike. Pr me teper, sistemet e bazave t te dhnave q ekzekutohen n do site mund t ken nj shkalle t konsiderueshme pavarsie t ndersjellte. Secili site mund t marre pjes n ekzekutimin e transaksioneve q aksesojne t dhna nga nj apo disa faqe. Dallimi me i madh ndrmjet sistemeve t qendrzuara dhe t shprndara t bazs s t dhnave sht se, n t parn t dhnat vendosen n nj vend t vetm, ndersa n t dyten, t dhnat pozicionohen n vende t ndryshme. Kjo shprndarje e t dhnave sht shkaku i shum vshtirsive n proesimin e transaksioneve dhe proesimin e krkesave

Figur 20. Sistemet e bazave t dhnave t shprndara

4.2.1 Bazat e t dhnave Homogjene dhe Heterogjene

Ne sistemet e bazave t dhnave t shprndara Homogjene, t gjitha sitet kan t njejtin sistem software t manaxhimit t bazs s t dhnave, jan t vetedijshme

25

pr njra-tjetrn, dhe bien dakord t bashkepunojne n proesimin e krkesave t prdoruesve. Ne nj sistem t tille, sitet lokale dorzojn nj pjes t autonomis s tyre n kuptimin e t drejtave t tyre pr t ndryshuar skemat apo manaxhimin e bazs s t dhnave. Ne t kundrt, n bazat e t dhnave t shprndara Heterogjene, site t ndryshem mund t prdorin skema t ndryshme, dhe sisteme t ndryshme software pr manaxhimin e t dhnave. Sitet mund t mos ken informacion pr njri-tjetrin, dhe mund t sigurojn vetm bashkpunim t kufizuar n proesimin e transaksioneve. Diferencat n skema jan shpesh here nj problem shum i madh pr proesimin e krkesave (queries), ndrkoh q divergjenca n software bhet penges pr proesimin e transaksioneve q aksesojne shum site n t njjtn kohe.

4.3 Vonesat n rrjet do kompjuter mund t ekzekutoj nj numr arbitrar shrbimesh, dhe do shrbim sht ndrtuar n nj mnyr t till q siguron se ai mund t shkmbej informacion me do shrbim tjeter n rrjet pa ndrhyrjen e njeriut dhe pa patur nevojn e kryerjes s ndryshimeve n vet programin kryesor. Arkitektura SOA ndan funksionet n komponente t mirpercaktuara, t cilat zhvilluesit i bjn t aksesueshme si shrbime n rrjet. Kjo bn t mundur t ekzekutohet SOA n nj shumllojshmeri platformash t shprndara, t cilat mund t aksesohen nprmjet rrjeteve t shumllojsheme. Ndarja e t dhnave ndrmjet aplikacioneve t ndryshme sht thelbi i aplikacioneve te biznesit. shte e natyrshme q impakti i infrastrukturs s rrjetit egziston n lidhje me komunikimin e shrbimeve t ndryshme n baza t dhnash t shprndara. Duke u nisur nga rekomandimet dhe proedurat e vazhdueshmerise s biznesit, rekomandimet pr aplikacione kritike jan pr t vendosur bazat e t dhnave larg njra tjetrs, ku n disa raste mund t jen edhe n kontinente t ndryshme. N kto raste problemet t cilat lidhen me vonesat n rrjet jan t pranishme Ne mund t masim vonesat e nj lidhjeje rrjeti duke prdorur paisje network-u, por vetm kjo nuk na jep t dhna reale rreth efektit q shkakton kjo vonse tek prdoruesi. Vonesat n rrjet dhe performanca n rrjet ndrmjet shtress s aplikacionit dhe shtress s bazs s t dhnave, mund t jen faktore sinjifikante n kohn e prgjigjes. Ka nj efekt i cili mund t matet dhe kto matje mund t prdoren pr t ushqyer me informacion pr prmirsim n infrastrukture n mnyr q t reduktohen vonesat.

26

4.3.1 Vlersimi i Algoritmit t Rrugzimit

Vrtet shtimi i lidhjeve ose rritja e kanalit t komunikimit midis burimit dhe destinacionit redukton vonesat, por kjo shoqrohet me nj kosto t lart. Egzistojne metoda alternative t cilat vlersojn dhe krahasojne algoritmat t cilat prdoren nga protokollet e rrugzimit.Algoritmi i rrugzimit sht elementi kryesor i cilin ndikon n perzgjedhjen e rruges midis dy nyjeve q komunikojne.Rruget jo t zgjedhur mir mund t ndikojne n prdorimin jo efient t kanalit t komunikimit dhe kjo ndikon n vonesat totale[15] . Pas nj krahasimi t br midis dy algoritmave t ndryshme rrugzimi t prdorura n nj rrjet LAN nisur nga transferimi i bazs s t dhnave n SQL Server 2008 me kapacitet 15 GB, rezulton se rrugzimi QoS(rrugzimi i cilesise s shrbimit) kundrejt algoritmit SPF(rruga me e shkurter e para) n total ka rezultate me t mira pr eleminimin e bllokimeve (starvation), t cilat jan t lidhura drejperdrejt me performancn totale t rrjetit.Algoritmi QoS n kete rast ndihmon balancuesin e puneve n rrjet dhe optimizon prdorshmerine e rrjetit. N nj mjedis t shprndar bazash t dhnash do t krijohet nj shtres ndrmjetse si n paragrafin 7.3, e cila do t komunikoj me t gjith databazat e shprndara n rrjet duke ruajtur integritetin dhe performancn, pavarsisht nga specifikat apo numri i aplikacioneve heterogjene q ndodhen n kt mjedis t shprndar. Bashksia ktyre t dhnave mund te jet e shprndar fizikisht n vendndodhje t ndryshme t shprndara ne rrjeta lokale, intranet-te apo me an t internetit, midis t cilave shrbimet e bazave t dhnave komunikojn me njra-tjetrn.

Aksesimi i t dhnave lidhet direkt me komunikimin n rrjet, referuar transferimit te mesazheve me an t shrbimeve broker mbi databazn SQL Server 2008, n nj rrjet jo LAN,t implementar n sistemin MPLS mbi teknikn IPV6 duke prdorur teknikn me Flow Label, e cila ndryshe nga router-at normale prdor router-at MPLS dhe shfaq nj performanc me t mir n sasine e throughput-it se n ate me routera IP [22]

27

Kapitulli 5 SOA, Virtualizimi dhe Cloud

5.1 Virtualizimi

Virtualizimi sht nj ndarje logjike e krkess pr shrbime nga burimet fizike q i sigurojn ko shrbime. Virtualizimi siguron aftsin pr t ekzekutuar aplikacione, sisteme shfrytzimi, ose sisteme shrbimesh n nj mjedis t veant logjik t pavarur nga mjedisi fizik i kompjuterit.Virtualizimi siguron nj nivel logjik abstraksioni q lehtson aplikacionet, sistemet e shrbimeve, madje dhe sistemin operativ nga t qent t lidhura n nj pjes specifike t hardware-it. Fokusimi i virtualizimit n mjediset operative logjike n vend t atyre fizike i bn aplikacionet, shrbimet dhe instancat e nj sistemi operativ t transferueshm npr sisteme fizike t ndryshme kompjuterash. Ka shum tipa t ndryshm t virtualizimit, t gjith rrotullohen rreth ides baz t sigurimit t aksesit logjik n burimet fizike. Sot, virtualizimi sht zakonisht i hasur n rrjete, sistemet e bazave t dhnave, dhe proeset e serverave, n nivel t sistemit operativ dhe at t makins. Virtualizimi mund t shihet si nj pjes e prirjes s prgjithshme t iniciativs IT q prfshin automatic computing, nj skenar n t cilin mjedisi IT do t jet i aft t menaxhoj veten duke u bazuar n aktivitetin e perceptuar, dhe dobin e kompjuterizimit, ku fuqia kompjuterike shihet si nj dobi pr t ciln klientt paguajn pr aq sa ju nevojitet. Qllimi m i zakonshm i virtualizimit sht t qendrzoj detyrat administrative duke prmirsuar shkallzueshmrin dhe ngarkesn e puns. Virtualizimi hardware i kompjuterit sht virtualizimi i kompjuterit ose i sistemit operativ, i cili fsheh karakteristikat fizike t nj platforme kompjuterike nga prdoruesi dhe n vend t ksaj tregon nj platform kompjuterike abstrakte. N fillimet e tij software-i q kontrollonte virtualizimin u quajt program kontrolli, por n ditt e sotme ka marr emrin hypervisor ose monitor i makins virtuale. Hypervisor-i sht administrator dhe menaxher i burimeve t prdorura nga makinat virtuale. Hypervisor-i si n figurn 21 vendoset n pjesn e siprme t hardware dhe kjo quhet virtualizimi i plot, ose mund t vendoset n pjesn e siprme t sistemit operativ dhe kjo quhet virtualizimi OS.

Figur 21. Diagrami logjik pr makina virtuale t bazuara n hypervisor

28

N varsi t tipit t hypervisor- it t prdorur dhe n prqasjen specifike t virtualizimit q ndiqet, kodi i burimit t sistemit operativ q vepron n nj makin virtuale mund te kt nevoj pr tu modifikuar pr t komunikuar me hypervisor.

5.1.1 Virtualizimi i shrbimeve

[18] Virtualizimi i shrbimeve sht nj nga idet m t fundit i cili mund t siguroj nj koh m t shpejt t tregut pr software, me cilsi m t lart dhe risk m t vogl. Virtualizimi i shrbimeve simulon sjelljen e komponentve software, pr t hequr kufizimet e varsis n ekipet e zhvillimit dhe testimit, kshtu q ata mund t ofrojn software m t shpejt, me risk dhe kosto m t ult. Kufizimet e varsis s sistemit mund t limitojn seriozisht prpjekjet e zhvillimit dhe t testimit, veanrisht n mjediset e ndrvarura kompleks. Komponentt downstream mund t jen t padisponueshm, me nj performanc t dobt, ose t paprdorshm. Prve ksaj, koha dhe kostot pr t ngritur skenart pr t dhnat test dhe laboratort e testit fizik s bashku me grindjet e shpeshta pr burimet shared, mund t limitojn n mnyr t konsiderueshme qllimin e testimit dhe kompromentoj cilsin e aplikacionit. Virtualizimi i shrbimeve automatikisht kap dhe krijon modelet virtuale reale t sistemeve t pavarura, kshtu q sistemet e vrtet nuk nevojiten m pr zhvillim dhe testim. Termi Virtualizim sht gjithashtu gjersisht i prdorur n kontekste t tjera, si jan virtualizimi i ruajtjes dhe virtualizimi i memories.

5.1.2 Historiku e virtualizimit t shrbimeve

Ekspozimi m i hershm n virtualizim pr shumicn e praktikuesve IT sht puna me sistemet e virtualizimit t hardware si jan Citrix ose VMware. Premisa e virtualizimit t hardware sht e thjesht: hardware pak i prdorur sht i zakonshm pr infrastrukturn IT pr shumicn e organizatave. Duke bashkuar s bashku burimet hardware dhe kapacitetet e paprdorura, dhe duke alokuar kt infrastruktur t bashkuar pr zhvilluesit e aplikacionit dhe testuesit, ndrmarrjet mund t eleminojn kostot nga infrastuktura IT. Kjo sht nj ide e madhe e cila ka deprtuar gjersisht n t gjith ndrmarrjet n mbar botn. Por a kap ajo t gjitha vlerat q priten pr ndrtimin e teknikave t aplikacionit modem, si jan SOA, BPM dhe mjediset e bazuara n Cloud(Cloud-based)?

N ndmarrjet e sotme t mdha, vet SOA nuk sht m nj dukuri e veant, n fakt, orientimi i shrbimit sht baza pr t pasur nj proes IT agile. Pyetja nuk sht me t vrtet se kush e bn SOA, por kush ofron shrbime cilsore m shpejt dhe m lir: ose, implementimi i modemit m t besueshm, me kohn m t shpejt n treg.

Zhvillimi i orientimit t shrbimit dhe testimi kan evoluar shum, tani kemi metodologji zhvillimi t reja dhe t sofistikuara, metodologji testimi dhe mjete q adresojn nevojat e ktyre aplikacioneve t shprndara, heterogjene, multi-tier. Ndrsa SOA flet pr sisteme autonome q jan integruar dhe ka ende t lir pr tu

29

zhvilluar n mnyr t pavarur, ajo nuk arrin afatet kohore t zhvillimit t ekipeve q duhet t ndajn aksesin n sistemet shared. Projektet e mdha t implementimit dhe integrimit jan t mbushur me sekuenca t detyrave q pfshijn shum kufizime t sistemit shared q jan rezistente ndaj virtualizimit t hardware.

[23]Teknikat e zhvillimit service-based ofrojn nj riprdorim m t madh t komponentve t software pr t prmbushur nevojat e biznesit. Sidoqoft, kur prdoret vetm, SOA nuk arrin t adresoj shtjen e kostove mjedisore t shpenzuara n testimin e ktyre sistemeve t integruara, pr shkak t faktorve si jan koha e shpenzuar pr shkak t setup-it kompleks t t dhnave, koha e humbur pr shkak t varsis s padisponueshme, dhe kosto m t larta. Virtualizimi i shrbimeve sht aftsia pr t imituar sjelljen dinamike dhe karakteristikat e performancs s nj shrbimi n nj mjedis virtual. Virtualizimi i shrbimeve mundson replikimin e sjelljes pr nj aset IT i cili sht shum i vlefshm kur sistemi target ka kufizuar vlefshmrin apo koston e lart t prdorimit. Pr ekipet e testimit, zhvillimit dhe performancs, Shrbimi Virtual prgjigjet n sistemin n prov ashtu si komponentt live.

Virtualizimi i shrbimeve ka evoluar sot pr t prfshir jo vetm shrbimet por gjithashtu sistemet e bazs s t dhnave, mainframe-t, dhe nj gam t gjer t aseteve t tjera IT.

Virtualizimi i shrbimeve ka prparuar n nj pik ku ajo mund t prmirsoj n mnyr t konsiderueshme parashikueshmrin dhe shpejtsin e nj zinxhiri kritik n t dyja, testim dhe zhvillim.

Duke thyer kufizimet rreth sistemeve t mbi shfrytzuar, virtualizimi i shrbimeve mund ti mundsoj organizats t marr nj shtres t shrbimit q sht me kosto m efektive, m fleksibl, dhe n gjendje pr t ofruar aplikacionet m shpejt n treg se konkurrenca. [19] Virtualizimi i shrbimeve sht koncepti q i lejon shrbimet fizike t ekspozohen prmes nj aplikacioni ndrmjets(ose broker) n mnyr t ngjashme me mnyrn se si reverse proxy klasik i prcjellin mesazhet t aplikacionet prapa tyre. Ndryshimi ndrmjet reverse proxy primitiv dhe ndrmjetsve t virtualizimit t shrbimeve sht se kto t fundit jan t ngarkuar me inteligjenc dhe njohuri t asaj q shrbimet dhe API-t n t vrtet jan duke ekspozuar. Kjo inteligjenc sht ajo q i bn ndrmjetsit e virtualizimit nj instrument t fuqishm software dhe jo ndrhyrs n skenart brokerage t shrbimit t jets reale. Konsideroni diagramn e mposhtme ku nj ndrmjets shrbimi ekspozon potencialisht qindra shrbime biznesi sikur ata jan shrbime t vrteta, por me vler t shtuar t monitorimit jo ndrhyrs n koh reale, autentifikimit t menaxhuar dhe kontrollit t aksesit, siguris dhe tejkalimin e protokolleve t komunikimit, menaxhimit Service Level Agreements dhe shum t tjer n t njjtn koh.

30

Figur 22. Virtualizimi i shrbimeve

5.2 Cloud computing Cloud computing sht nj model q lejon prshtatjen e krkesave t networkut pr t aksesuar nj bashksi burimesh t konfigurueshme si (interneti, serverat, hapesirat, aplikacionet dhe shrbimet) t cilat mund t realizohen me nj shpejtsi t madhe si edhe me nj krkes minimale suporti. Nj sistem cloud computing ka nj mnyr pun t thjesht. Kompjuterat lokal nuk kan nevoj t bjn punn e rnd t ekzekutimit t aplikimeve. Sistemi i kompjuterave n cloud merret me kt gj. E vetmja gj q i nevojitet kompjuterit t prdoruesit sht nj ndrfaqe software e sistemit cloud computing, q mund t jet nj Web browser i thjesht. Pjesa tjetr mbetet n dor t rrjetit cloud. E mira e cloud computing sht se mund t fillosh t punosh me at platform n do moment. dokush me nj lidhje interneti dhe me nj kart krediti mund t prdor t njjtat burime pr t hostuar dhe pr t ndrtuar apilakacionet web. Ne n rolin si prdorues t internetit kemi prdorur disa forma t cloud computing. Nse kemi nj e-mail account si psh Hotmali, Yahoo! Mail ose Gmail, athere n kemi disa eksperienca me cloud computing. N vend q t ekzekutojme nj program e-mail n kompjuterin ton, n logohemi remote n nj Web mail account. Software-i dhe kujtesa fizike e account-it ton nuk ndodhen n kompjuterin ton personal, por n kompjuterin n cloud.

5.2.1 Arkitektura Cloud Computing

Kur flasim pr nj sistem cloud computing, sht mir ta ndajm at n dy seksione: front end-i dhe back end-i. Kto seksione lidhen me njri-tjetrin me an t nj rrjeti, zakonisht Interneti. Front end-i sht ana e kompjuterit t prdoruesit, ose ndryshe nga klienti. Back end-i sht pjesa cloud e sistemit.

Front end-i perfshin nj kompjuter klient dhe nj aplikim t nevojshm pr t aksesuar sistemin cloud computing. Jo t gjith sistemet cloud computing kan t njjtn

31

ndrfaqe. Shrbime si aplikime e-mail prdorin Web browsers, ndrsa sistemet e tjera kan aplikacione t tyre pr t siguruar lidhjen e klientve n rrjet.

N back end-in e sistemit ka kompjutera t ndryshm, servera dhe sisteme t ruajtjes s t dhnave, t cilt sbashku krijojn cloud-in. N teori nj sistem cloud computing mund t prfshij praktikisht do program kompjuteri q mund t imagjinojm, q nga programe pr proesimin e t dhnave deri tek lojrat. Zakonisht do aplikacion ka serverin e tij t dedikuar. Nj server qndror administron sistemim, monitoron trafikun dhe krkesat e klientve, duke u siguruar q do gj t ekzekutohet normalisht. Kjo ndjek nj bashksi rregullash q quhen protokolle dhe prdor nj lloj t veant software t quajtur middleware. Middleware bn t mundur q kompjuterat n rrjet t komunikojn me njri-tjetrin.

Figur 23. Arkitektura Cloud Computing

Cloud computing nuk sht vendi n t cilin aplikimi i akseson burimet n mnyr t drejtprdrejt, por ai i akseson ato me dika t ngjashme me nj shrbim (service). Pra, aplikimi n vend q t komunikoj me nj hard drive pr t dhnat dhe me nj CPU pr kalkulime, ai komunikon me disa shrbime (services) q ia sigurojn kto burime. Shrbimi (service) bn lidhjen e do krkese pr burime, me burimet fizike, n mnyr q tja ofroj aplikimit. Shrbimi (the service) akseson nj sasi t madhe burimesh fizike dhe mund ti ndaj ato n mnyr dinamike sipas nevojave. Sipas ksaj mnyre, nse nj aplikimi i nevojitet nj numr i vogl burimesh, psh pr kalkulime, ather shrbimi (service) do ti caktoj nj sasi t vogl, psh nj CPU. Nse aplikimi krkon nj sasi t madhe burimesh, ather shrbimi do ti caktoj nj sasi t madhe CPU, psh nj grid me CPU. i gjith ky proes trajtohet nga shrbimi dhe jo nga aplikimi.

Arkitektura e cloud computing Service Oriented Architecture Arkitektura cloud computing Middleware Architecture Enterprise IT Architecture

32

Software Architecture Arkitektura e cloud computing sht nj struktur e nj sistemi e cila bashkon burimet e cloud, shrbimet middleware, komponentet softwerike, geo-location duke u bazuar n vetite e tyre dhe n lidhjet q ekzistojn midis ktyre komponentve. Nj pjes e rndsishme e arkitekturs sht dhe dokumentimi i stemit t cloud. Dokumentimi lehtson komunikimin midis palve t interesuara pr t komunikuar, apo edhe midis dokumentve ku prshkruhen vendimet e hershme, t cilat mund t riprdoren n nj koh t dyt. Cloud computing sht duke krijuar nj epok t re pr IT duke ofruar nj bashksi shrbimesh, q duhet t ken nj kapacitet infinit. Ky sht edhe si rezultat e evolimit t kompjuterit dhe tekonologjis s komunikimit. N kt evolucion, fokusi zhvendoset nga koncepti i kompjuterit si dika fizike n nj data center si nj bashksi shrbimesh. Shum organizata sot jan duke punuar me cloud n mnyr q t ulin ngarkesn e t dhnave dhe zvoglimin e