UNIVERSITETI I MITROVICËS “ISA BOLETINI”

FAKULTETI I INXHINIERISË MEKANIKE DHE

KOMPJUTERIKE DEPARTAMENTI: INFORMATIKË

INXHINIERIKE

PUNIM DIPLOME

Mentori: Kandidati:

MSc. Besmir Sejdiu, PhD Cand. Mentor Shyti

Mitrovicë, Shtator, 2020

1

UNIVERSITETI I MITROVICËS “ISA BOLETINI”

FAKULTETI I INXHINIERISË MEKANIKE DHE

KOMPJUTERIKE DEPARTAMENTI: INFORMATIKË

INXHINIERIKE

PUNIM DIPLOME

Ueb shërbimet RESTful API dhe mikroshërbimet

Mentori: Kandidati:

MSc. Besmir Sejdiu, PhD Cand. Mentor Shyti

Mitrovicë, Shtator, 2020

2

1. Përmbajtja

2. Hyrja dhe motivimi ............................................................................................................................. 3

3. Interneti, protokollet dhe komunikimi nëpërmjet ueb-it ................................................................ 4

4. Ueb shërbimet RESTful .................................................................................................................... 11

5. Mikroshërbimet ............................................................................................................................... 21

6. Teknologjitë dhe arkitektura e përdorur për zhvillimin e aplikacionit ......................................... 27

7. Zhvillimi i një aplikacioni që përdorë ueb ..................................................................................... 36

8. Testimi i aplikacionit ........................................................................................................................ 45

9. Përfundimi ....................................................................................................................................... 47

10. Literatura ....................................................................................................................................... 48

11. Lista e figurave .............................................................................................................................. 49

10. Lista e tabelave .............................................................................................................................. 49

3

2. Hyrja dhe motivimi

Në këtë punim diplome do të trajtohet tema që ka të bëjë me komunikimin në internet

ndërmjet sistemeve të ndryshme si dhe programimin me anë të mikroshërbimeve

(microservices).

Për rritjen e vrullshme të përdorimit të internetit tanimë nuk kemi asnjë dyshim, gjë kjo që

na shtyn që të përdorim teknologji të reja që mund ta përballojnë intensitetin e shfrytëzuesve

të resurseve tona në internet si dhe ta rrisim shpejtësinë për t’iu qasur atyre.

Në të kaluarën ka qenë synim se si të jemi prezent në internet, por me rritjen e shfrytëzimit

të internetit janë rritur edhe nevojat për përdorimin e këtyre teknikave të reja që ua

mundësojnë zhvilluesve sikur administratorëve ndërhyrjet më të shpejta dhe pa ndalim të

funksionimit të resurseve të tyre në internet.

Shumëllojshmëria e pajisjeve teknologjike që kanë qasje në internet, gjithashtu i ka shtyrë

inxhinierët të mendojnë për sisteme unitare që programet në këto pajisje të ndryshme të kenë

një pikë referuese për qasje në resurse të njëjta, për këtë arsye kemi vendosur që në këtë temë

ta shtjellojmë komunikimin në mes sistemeve në internet e në veçanti për teknologjinë

REpresentational State Transfer (REST).

Gjithashtu në këtë temë do të flasim edhe për mikroshërbimet, për përdorimin e tyre, për

përparësitë dhe ngecjet që kanë aplikacionet që përdorin mikroshërbimet si dhe do të shohim

në praktikë se si funksionojnë në aplikacionin që e kemi zhvilluar.

4

3. Interneti, protokollet dhe komunikimi nëpërmjet ueb-it

Interneti është gjithnjë e më shumë një pjesë e rëndësishme e njerëzve në mbarë botën.

Në këtë kapitull që është si hyrje për shtjellimin e kapitujve të tjerë do t’i shpjegojmë

konceptet bazike lidhur me internetin.

Çka është interneti?

Interneti është një rrjet global i miliarda kompjuterëve dhe pajisjeve të tjera elektronike.

Me internet është e mundur që të keni qasje thuajse në çdo informacion, të komunikoni me

të tjerët që ndodhen në largësi si dhe të bëni shumë gjëra të tjera.

Ju mund t’i bëni të gjitha këto thjesht duke e kyçur një kompjuter në internet apo siç njihet

ndryshe të hyni në linjë (going online). Pra kur dikush thotë që është online është thjesht një

mënyrë tjetër për të thënë se është i kyçur në internet.

Çka është Uebi (Web)?

World Wide Web apo vetëm web, si quhet shkurt zakonisht, është një koleksion i

uebsajteve(websites) që mund t’iu qasesh përmes internetit. Uebsajti është i përbërë nga

teksti relevant, imazhet dhe resurset e tjera. Uebsajti mund t’i ngjajë formateve të ndryshme

të medieve, p.sh.: artikullit të gazetës a ndonjë programi televiziv ose mund të jetë interaktiv

në mënyrë që është unike për kompjuterët.

Një uebsajt mund të dedikohet për qëllime të ndryshme, si: platformë lajmesh, për reklamim,

librari online, forum për publikimin e fotografive ose diçka tjetër.

Përderisa ju jeni të kyçur në internet ju mund t’iu qaseni dhe t’i shikoni uebsajtet duke e

përdorur një aplikacion të quajtur web browser. Sa për sqarim, web browser-i nuk është

interneti por vetëm përdoret si vegël për t’iu qasur uebsajteve në internet.

5

Si funksionon interneti?

Adresat e internetit

Për shkak se interneti është rrjet global i kompjuterëve, secili kompjuter që është i kyçur në

të duhet të ketë një adresë unike. Adresat e internetit janë të formës nnn.nnn.nnn.nnn, ku

nnn duhet të jetë një numër 0 – 255. Kjo adresë është e njohur si IP adresë. (IP do të thotë

Internet Protocol – Protokoll Interneti)

Figura 1 ilustron dy kompjuterë të lidhur në internet, njëri me IP adresë 1.2.3.4 dhe tjetri me

IP adresë 5.6.7.8. Interneti është paraqitur si objekt abstrakt në mes tyre.

Figura 1. Komunikimi i dy kompjuterëve përmes internetit

Nëse kyçemi në internet përmes një ISP (Internet Service Provider) zakonisht na caktohet një

IP adresë e përkohshme deri sa të mbarojë sesioni. Nëse ne lidhemi në internet nga një rrjet

lokal (LAN – Local Area Network) kompjuteri ynë mund të ketë një IP adresë permanente

ose mund të marrë një të përkohshme nga DHCP1 (Dynamic Host Configuration Protocol)

server. Në secilin rast, kompjuteri ynë do të ketë një IP adresë unike [4].

Protokollet dhe paketat

Pasi kompjuteri ynë tashmë është i lidhur në internet dhe ka një IP adresë unike, të supozojmë

se duam që nga kompjuteri ynë, me IP adresë 1.2.3.4, t’i dërgojmë një mesazh, me tekst

“Tung”, kompjuterit me IP adresë 5.6.7.8. Është e qartë se mesazhi duhet të transmetohet

nëpërmjet telave nga të cilët kompjuteri ynë është i lidhur në internet. P.sh. nëse ne jemi të

lidhur në internet përmes LAN atëherë mesazhi duhet të transmetohet përmes kabllos

koaksiale. Kështu, mesazhi duhet të përkthehet nga teksti alfabetik në sinjale elektronike, të

1 Është një protokoll i menaxhimit të rrjetit i përdorur në rrjetet e Protokollit të Internetit

6

transmetohet përmes internetit dhe të arrijë në kompjuterin tjetër duke u përkthyer prapë në

mesazh me tekst alfabetik. Si arrihet kjo? Kjo arrihet përmes përdorimit të një steku të

protokollit. Çdo kompjuteri i nevojitet një stek i tillë që të komunikojë me internet dhe

zakonisht sistemet operative janë të ndërtuara me një stek të tillë (si p.sh.: Windows, Unix

etj.). Steku i protokollit që përdoret në internet quhet protokolli TCP/IP, për shkak të dy

protokolleve kryesore të komunikimit që përdoren.

TCP/IP protokoll steku duket kështu:

Shtresat e protokollit Komenti

Shtresa e protokolleve të aplikacionit

(Application Protocols Layer)

Protokollet specifike të aplikacioneve si p.sh.: www, e-

mail, ftp etj.

Shtresa e protokollit të kontrollit të

transmisionit (TCP Layer)

TCP i drejton paketat te një aplikacion specifik i

kompjuterit duke përdorur një numër porti (port

number)

Shtresa e protokollit të internetit

(Internet Protocol Layer)

IP drejton paketat te një kompjuter specifik duke

përdorur një IP adresë.

Shtresa e Harduerit

(Hardware Layer)

Konverton paketat që janë në të dhëna binare në sinjale

të rrjetit dhe anasjelltas.

Tabela 1. Shtresat e protokollit

Nëse e ndjekim udhën që mesazhi “Tung” bën nga kompjuteri me IP adresë 1.2.3.4 në

kompjuterin me IP adresë 5.6.7.8, atëherë ndodh diçka e tillë si në vijim:

Figura 2. Komunikimi përmes internetit sipas shtresave të protokolleve

7

1. Mesazhi do të fillojë në majë të stekut të protokollit në kompjuterin me IP adresë

1.2.3.4 dhe do të shkojë poshtë siç tregon në figurën 2.

2. Nëse mesazhi që dërgohet është i gjatë, ai mund të ndahet në pjesë të vogla nëpër

shtresat që kalon. Kjo për shkak se të dhënat që kalojnë nëpër rrjetin e internetit,

menaxhohen të dhëna në pjesë të vogla. Në internet, këto të dhëna në pjesë të vogla

njiheni si paketa (packets).

3. Paketat do të kalojnë nga shtresa e aplikacionit në shtresën TCP. Secilës paketë do t’i

caktohet një numër porti. Portet do t’i shpjegojmë më vonë. Shumë programe në

kompjuterin që pret mesazhin mund të përdorin stekun TCP, prandaj na nevojitet që

të caktojmë numrin e portit për të ditur se në cilin port është duke pritur përgjigje

aplikacioni specifik.

4. Pas shtresës TPC, paketat kalojnë në shtresën IP. Këtu është momenti kur secila

paketë e merr adresën e destinimit, në këtë rast 5.6.7.8.

5. Tani që paketat e mesazhit tonë kanë një numër porti dhe një IP adresë, janë gati për

t’u dërguar përmes internetit. Shtresa e harduerit kujdeset që t’i kthejë paketat tona

që përmbajnë tekst alfabetik në sinjale elektronike dhe t’i transmetojë përmes rrjetit

LAN.

6. Në anën tjetër ISP-ja jonë ka lidhje direkte në internet. Ruteri (router) i ISP-ve

ekzaminon adresën e destinacionit në secilën paketë dhe determinon ku ta dërgojë

atë. Zakonisht, ndalesa e radhës e paketës është një ruter tjetër.

7. Përfundimisht paketat arrijnë te kompjuteri me IP adresë 5.6.7.8. Këtu paketat fillojnë

nga fundi i stekut TCP/IP të kompjuterit marrës dhe vazhdojnë lart.

8. Përderisa paketat vazhdojnë rrugën lart përmes stekut, të gjitha të dhënat e rrugëtimit

që janë shtuar nga kompjuteri dërgues (si p.sh.: IP adresa dhe numri i portit) hiqen

nga paketat.

9. Kur të dhënat mbërrijnë në maje të stekut, paketat janë konvertuar në formën

origjinale dhe shfaqet mesazhi, në rastin tonë “Tung” [4].

Protokollet e Aplikacionit: HTTP dhe WWW (World Wide Web)

Hyper Text Transport Protocol (HTTP) është një protokoll i bazuar në kërkesë (request)

dhe përgjigje (response) që ndodh ndërmjet klientit dhe serverit (client - server). Një

8

HTTP klient (p.sh. një ueb shfletues siç është Mozilla) kryen një HTTP kërkesë te një

HTTP server (p.sh. Apache server), i cili kthen një HTTP përgjigje. Protokolli HTTP

përbëhet nga kreu (header) dhe nga të dhënat (data). Header-i i protokollit HTTP është i

bazuar në tekst, ku header-at janë të shkruar në rreshta me tekst.

HTTP/1.1 lejon që komunikimi ndërmjet klientit dhe serverit të jetë i pashkëputur

(pipelined), ku shumë kërkesa mund të dërgohen (shpesh edhe në të njëjtën paketë), pa

pritur që serveri të kthejë përgjigje. Kufizimi i vetëm është se serveri duhet t’i kthejë

përgjigjet (responses) në të njëjtin rend siç janë pranuar. Kjo mundëson në një efikasitet

më të madh, veçanërisht në rivalidim. Gjithashtu, një variant tjetër është në dispozicion

e që është emëruar si HTTPS. Ky zakonisht përdoret kur privatësia e të dhënave është e

domosdoshme, p.sh. kur kemi të bëjmë me pagesa online. Në fakt protokolli HTTPS është

i përbërë nga dy protokolle që funksionojnë në krye të njëri-tjetrit.

Protokolli i parë është një protokoll sigurie siç janë SSL, TLS ose PCT. Protokolli i dytë

që funksionon përmbi protokollit të sigurisë, është HTTP. URL-të që fillojnë me https://

në të vërtetë janë vetëm një notim i shkurtër për përdoruesit e fundit. Shfletuesi (Web

browser) e lexon skemën URI (https://), e inicion protokollin e sigurisë te server dhe

pastaj kur protokolli i sigurisë është konsoliduar lëshon një kërkesë (HTTP request) të

specifikuar në URI [4].

Më shumë për Hyper Text Transfer Protocol (HTTP)

HTTP është një protokoll i cili mundëson përmbajtje, siç janë dokumentet në HTML.

Është baza e çdo këmbimi të të dhënave në Web dhe në protokollet klient-server, që do

të thotë se kërkesat janë të iniciuara nga marrësi, zakonisht Web browser. Një dokument

i plotë është i ndërtuar nga nëndokumente të paraqitura si p.sh.: tekst, përshkrim,

fotografi, video, skripta dhe të tjera (figura 3).

9

Figura 3. Ilustrimi si funksionon një uebsajt në internet

Klientët dhe serverët komunikojnë duke shkëmbyer mesazhe. Mesazhet dërgohen nga

klienti, zakonisht një Web browser, që quhen kërkesa (requests) ndërsa mesazhet që

dërgohen nga server si një përgjigje quhen përgjigje (responses) [5].

I dizajnuar në vitet e hershme të të ‘90-ve, HTTP është një protokoll i zgjeruar i cili evulon

gjatë gjithë kohës. Është një protokoll që shtrihet në shtresën e application layer, që dërguar

përmes TCP ose përmes një TLS të enkriptuar në një lidhje TCP ose përmes çfarëdo transport

protokolli të besueshëm, mundet teorikisht të shfrytëzohet. Në sajë të zgjerimit

(përmirësimit), HTTP

nuk shfrytëzohet vetëm për të shfaqur hypertext dokumente, por edhe për të shfaqur fotografi

dhe video ose edhe për të postuar përmbajtje në server [5].

Komponentët e sistemeve të bazuara në HTTP

HTTP është një klient-server protokoll: kërkesat (requests) janë të dërguar nga një entitet,

user-agent (ose një proxy në emër të tij). Shumicën e kohës user-agent është një ueb shfletues,

por mund të jetë edhe tjetër gjë.

Çdo kërkesë (request) që është dërguar në server, do të trajtohet nga server dhe do ta përcjellë

një përgjigje (ang. response). Në mes të kërkesës dhe përgjigjes, mund të ketë një numër të

entiteteve, që së bashku janë të dizajnuara si proxy e që performojnë operacione të ndryshme

dhe sillen si gateways ose caches (figura 4).

10

Figura 4. Rrjedhshmëria kërkesë - klient

Në realitet, janë disa kompjuterë në mes të një shfletuesi dhe serverit që i trajtojnë kërkesat;

ata janë për shembull ruterët (routers), modemët ose edhe të tjerë. Duke iu falënderuar

dizajnimit të mirë të Web-it, këto janë të fshehura në shtresat më të ulta (network and

transport layers). HTTP është në krye të application layer. Edhe pse janë të rëndësishme për

të diagnostikuar problemet e rrjetit, shtresat më të ulëta janë kryesisht të parëndësishme për

përshkrimin e HTTP [5].

HTTP is stateless, but not sessionless

HTTP nuk ka gjendje (stateless): nuk ka asnjë lidhje në mes dy kërkesave që janë kryer me

sukses në të njëjtin koneksion. Kjo menjëherë sjell probleme për përdoruesit që tentojnë të

ndërveprojnë me disa faqe njëkohësisht, për shembull, duke e shfrytëzuar shportën e blerjes

në një faqe ecommerce. Por derisa bërthama e HTTP-së është e paqëndrueshme (stateless),

HTTP cookies lejon që të përdoren sesione të qëndrueshme (stateful). Duke përdorur header

mund të zgjerohen, HTTP Cookies janë shtuar në procesin e punës, duke lejuar sesionin në

çdo HTTP request të ndajë kontekst të njëjtë ose gjendje të njëjtë [5].

11

4. Ueb shërbimet RESTful

Çka është RESTful?

REST qëndron për Representational State Transfer dhe është një stil arkitektural që mundëson

komunikimin mes dy sistemeve. Termi REST është shpikur nga Roy T. Fielding në temën

për doktoraturën (PhD.) e tij.

Koncepti REST është i definuar nga disa rregulla, kufizime ose principe. Sistemi, aplikacioni,

shërbimi ose çfarëdo qoftë i cili i plotëson këto REST principe quhet RESTful.

Ueb shërbimet që i përcjellin principet RESTful quhen shërbime RESTful. URI2 shfrytëzohet

për t’iu qasur shërbimeve RESTful për t’i marrë resurset.

Në fjalorin RESTful, resurset nuk janë gjë tjetër përpos të dhëna dhe funksione. Kështu që

përfundimisht ne do t’i thërrasim ueb shërbimet përmes URI për t’iu qasur funksioneve dhe

në këtë mënyrë për t’i marrë të dhënat [6].

Pse RESTful?

Para se të flasim më në detaje për Restful shërbimet, së pari do të theksojmë arsyet kryesore

që e kanë bërë këtë stil arkitektural të popullarizuar:

1. Gjuhë dhe mjedise heterogjene – Kjo është njëra nga arsyet fundamentale të cilën po

ashtu e kanë edhe SOAP3 shërbimet.

• Kjo mundëson që ueb aplikacionet që janë të ndërtuara në gjuhë programuese

të ndryshme të komunikojnë ndërmjet vete.

• Me ndihmën e Restful shërbimeve, këto ueb aplikacione mund të qëndrojnë

në mjedise të ndryshme, disa nga to mund të qëndrojnë në Windows, e disa

tjera në Linux

2 Një Identifikues i Burimeve Uniforme (URI) është një varg karakteresh që identifikojnë qartë një burim të veçantë 3 Simple Object Access Protocol – është protokoll për shkëmbimin e informacionit mes sistemeve të ndryshme

12

Në fund, pavarësisht se në çfarë mjedisi është, rezultati përfundimtar duhet të jetë i njëjtë në

mënyrë që sistemet të komunikojnë me njëra-tjetrën. Restful ueb shërbimet e ofrojnë këtë

fleksibilitet për aplikacionet e ndërtuara në gjuhë programuese dhe platforma të ndryshme që

të komunikojnë ndërmjet vete.

Tani nëse aplikacioni ynë punon me sajte siç janë Facebook, Twitter etj. ne duhet të dimë me

çfarë gjuhe janë programuar këto sajte si dhe në çfarë platforme janë ndëtruar.

Bazuar në këtë që thamë, ne do të duhej të shkruanim kod për të gjitha këto ueb shërbime, e

që do të ishte një mankth. Por, Facebook, Twitter, Google etj. i shfaqin funksionalitetet e tyre

në formë të Restful ueb shërbimeve. Kjo na lejon që këto shërbime t’i thërrasim përmes REST

[7].

2. Shumëllojshmëria e pajisjeve – Ditët e sotme, çdo gjë duhet të punojë në pajisjet

mobile, pavarësisht a janë telefona mobilë, pajisje portabël, apo edhe sisteme të

veturave.

3. Dhe se fundimi rasti i Cloud4 – Çdo gjë është duke lëvizur drejt Cloud. Aplikacionet

ngadalë po lëvizin drejt sitemeve të bazuara në Cloud siç janë Azure ose Amazon.

Azure dhe Amazon sigurojnë shumë API5 të bazuar në akitekturën Restful. Prandaj,

aplikacionet tani duhet të zhvillohen në atë mënyrë që të jenë të përshtatshme për

sistemet Cloud. Kështu, pasi të gjitha sistemet e bazuara në arkitekturën Cloud

punojnë me principet REST, ka më shumë kuptim që ueb shërbimet të zhvillhen në

arkitektura të bazuara në REST për t’i shfrytëzuar sa më mirë shërbimet e bazuara në

Cloud.

4 Cloud computing është disponueshmëria sipas kërkesës e burimeve të sistemit kompjuterik 5 Application Programming Interface – është një ndërfaqe që definon ndërveprimin në mes sistemeve softuerike

13

Elementet kryesore të RESTful

Ueb shërbimet me të vërtetë kanë bërë një rrugë të gjatë prej se kanë filluar të përdoren. Në

2002, ueb konsorciumi pati lansuar definicionin e ueb shërbimeve WSDL6 dhe SOAP. Kjo

definoi standardin se si duhej të implementoheshin ueb shërbimet.

Në 2004, ueb konsorciumi gjithashtu lansoi definicionin për standarde shtesë të quajtura

RESTful. Gjatë këtyre viteve, ky standard u bë mjaft i popullarizuar dhe ka filluar të përdoret

nga shumë uebsajte të njohura në të gjithë botën duke përfshirë edhe Facebook dhe Twitter.

REST është një mënyrë e të qasurit të resurseve që janë në një mjedis specifik. Për shembull,

ne mund të kemi një server që përmban dokumente të rëndësishme, fotografi ose video. Të

gjitha këto janë shembuj të resurseve. Nëse një klienti, le të themi një ueb shfletuesi i nevojitet

ndonjëra nga këto resurse, ai duhet të dërgojë një kërkesë në server për t’iu qasur këtyre

resurseve. REST definon mënyrën se si këto resurse mund të qasen [7].

Elementet kryesore të implementimit të Restful janë si në vijim:

1. Resurset – Elementi i parë kryesor janë vet resurset. Le të supozojmë se një ueb

aplikacion në server ka të ruajtura të dhënat e disa punëtorëve. Le të supozojmë se

URL i ueb aplikacionit është http://empmen.test. Tani në mënyrë që t’iu qasemi të

dhënave të një punëtori në resurse përmes REST, mund të lëshohet komanda

http://empmen.test/employee/1 - Kjo komandë i tregon ueb serverit që të na sjellë të

dhënat e punëtorit numri i të cilit është 1.

2. Request verbs - Kjo e përshkruan se çfarë duam të bëjmë me resurset. Shfletuesi

lëshon një komandë GET (merr) për ta udhëzuar ueb shërbimin se ai dëshiron të marrë

të dhëna. Gjithsesi, ka edhe Request verbs të tjera si p.sh.: POST, PUT and DELETE.

Kështu që në rastin e shembullit http://empmen.test/employee/1, ueb shfletuesi është

dukë lëshuar një GET Verb sepse dëshiron t’i marrë detajet e punëtorit.

6 Web Service Description Language - është një format XML për përshkrimin e shërbimeve të pikave të fundme

http://empmen.test/http://empmen.test/employee/1http://empmen.test/employee/1

14

3. Request Headers (koka e kërkesës) – Këto janë instruksione shtesë që dërgohen në

kërkesë (request). Këto mund të definojnë llojin e përgjigjes (response) së kërkuar

ose detajet e autorizimit (authorization).

4. Request Body (trupi i kërkesës) – të dhënat që dërgohen me kërkesën. Të dhënat

zakonisht dërgohen në kërkesë kur një kërkesë POST bëhet në një REST ueb shërbim.

Në një POST kërkesë, klienti i tregon ueb shërbimit se ai dëshiron të shtojë një resurs

në server. Prandaj, request body (tupi i kërkesës) duhet të përmbajë të dhënat e

nevojshme që resursi të shtohet në server.

5. Response Body (trupi i përgjigjes) – Kjo është pjesa kryesore e përgjigjes (response).

Kështu, nëse jemi duke e ndjekur shembullin e mëparshëm, nëse bëjmë kërkesë në

ueb shërbim përmes http://empmen.test/employee/1, serveri mund të rikthejë një

JSON dokument me të dhënat e punëtorit në trupin e kërkesës (Request Body).

6. Request status codes (status kodet e përgjigjes) – Këto kode janë kode gjenerale të

cilat kthehen me përgjigjen (response) nga ueb shërbimi. Një shembull është kodi 200

që kthehet kur nuk ka ndodhur asnjë gabim kur kthehet përgjigja te klienti [7].

Metodat Restful

Diagrami i mëposhtëm (figura 5) tregon gati të gjitha metodat (POST, GET, PUT dhe

DELETE) dhe nga një shembull se për çka përdoren.

Figura 5. Diagrami i metodave HTTP

http://empmen.test/employee/1

15

Le të supozojmë se ne kemi një RESTful ueb shërbim dhe ai është i definuar në lokacionin:

http://empmen.test/employee. Kur një klient bën një kërkesë në këtë ueb shërbim, ajo mund

të jetë njëra nga secilat metoda të HTTP (GET, POST, DELETE ose PUT). Më poshtë

tregohet se çfarë ndodh nëse njëra nga metodat dërgohet nga klienti.

1. POST – Kjo metodë përdoret për të krijuar një punëtor duke shfrytëzuar ueb

shërbimet Restful

2. GET – Kjo metodë përdoret për të marrë listën e të gjithë punëtorëve duke shfytëzuar

ueb shërbimet Restful

3. PUT – Kjo metodë përdoret për të azhurnuar të gjithë punëtorët duke shfytëzuar ueb

shërbimet Restful

4. DELETE – Kjo metodë përdoret për fshirjen e të gjithë punëtorëve duke shfytëzuar

ueb shërbimet Restful

Le të shohim perspektivën për vetëm një të dhënë. Le të themi se është një punëtor me numër

1.

Veprimet në vazhdim do të kenë këtë kuptim:

1. POST – Kjo metodë nuk do të aplikohet për shak se ne jemi duke shfaqur të dhënat e

punëtorit me numër 1, kjo do të thotë që ky punëtor tashmë ekziston në sistem.

2. GET – Kjo metodë përdoret për të marrë detajet e punëtorit me numër 1 duke

shfytëzuar ueb shërbimet Restful

3. PUT – Kjo metodë përdoret për të azhurnuar të dhënat e punëtorit me numër 1 duke

shfytëzuar ueb shërbimet Restful

4. DELETE – Kjo metodë përdoret për fshirjen e të dhënave të punëtorit me numër 1

[7].

http://empmen.test/employee

16

Arkitektura Restful

Figura 6. Diagrami i arkitekturës RESTful

Një aplikacion ose arkitekturë konsiderohet si RESTful ose stili REST nëse ka karakteristikat

në vijim:

1. Gjendja (state) dhe funksionaliteti janë të ndara në resurse të shpërndara – Kjo do të

thotë se çdo resurs duhet të jetë i qasshëm përmes HTTP komandave si GET, POST,

PUT ose DELETE. Nëse për shembull dikush dëshiron të marrë një dokument nga

serveri, ai duhet të ketë mundësi që përmes kërkesës GET ta marrë dokumentin. Nëse

dëshiron që ta vendosë një dokument në server atëherë duhet që të jetë në gjendje që

përmes komandave POST ose PUT ta bëjë këtë. Dhe së fundmi, nëse dëshiron ta

fshijë dokumentin nga serveri atëherë këtë e bën përmes kërkesës DELETE.

2. Arkitekruara është klient/server, pa gjendje (stateless), e shtresuar dhe përkrah

cache7-in

7 Është një komponentë harduer ose softuer që ruan të dhënat në mënyrë që kërkesat e ardhshme për ato të dhëna të mund të shërbehen më shpejt

17

• Klient-server është arkitektura tipike ku server mund të jetë një ueb server ku

aplikacioni qëndron (hosting) dhe klienti mund të jetë thjesht një ueb

shfletues.

• Pa gjendje (stateless) do të thotë se gjendja e aplikacionit nuk mirëmbahet

nga REST. Për shembull, nëse ne e fshijmë një resurs përmes komandës

DELETE, ne nuk mund të presim që ai resurs të na vijë në kërkesën e radhës.

Në mënyrë që të jemi të sigurt se resursi është fshirë, ne duhet ta dërgojmë një kërkesë

GET. Kërkesa GET dërgohet për t’i marrë të gjitha resurset në server, ku më pas ne

jemi në gjendje të shohim nëse resursi është fshirë me të vërtetë [7].

RESTful principet dhe kufizimet

Arkitektura REST është e bazuar në disa karakteristika të cilat do të shtjellohen më poshtë.

Çdo ueb shërbim REST duhet të jetë në përputhje me karakteristikat e mëposhtme në mënyrë

që të quhet RESTful. Këto karakteristika janë të njohura edhe si princpe të dizajnit (design

principles) që duhet të ndiqen kur punojmë me servise të bazuara në RESTful [7].

1. RESTful klient-server

Kjo është kërkesa fundamentale për arkitekturat e bazuara në REST. Kjo do të thotë që serveri

do të ketë një ueb shërbim REST që do ta përmbushë funksionalitetin e kërkuar nga klienti.

Klienti dërgon një kërkesë në ueb shërbim që ndodhet në server. Serveri pastaj ose do ta

refuzojë ose do të bindet duke i sjellë klientit një përgjigje adekuate.

2. Stateless

Koncepti i stateless (pa gjendje) ka të bëjë me atë se është në dorën e klientit të sigurohet që

i gjithë informacioni i kërkuar të dërgohet në server. Serveri nuk duhet të mirëmbajë çfarëdo

informate ndërmjet kërkesave të klientit. Është thjesht një sekuencë e pavarur pyetje –

përgjigje. Klienti bën një pyetje, serveri përgjigjet në mënyrë të duhur. Klienti do të bëjë një

pytje tjetër. Serveri nuk do të mbajë në mend skenarin e pyetje-përgjigjes së mëparshme dhe

do të përgjigjet në pytjen e re në mënyrë të pavarur.

18

3. Cache

Koncepti i Cache-it është që të na ndihmojë në problemet e stateless që i shpjeguam më lart.

Pasi çdo server klient kërkesë është e pavarur në natyrë, nganjëherë klienti mund ta pyesë

serverin për kërkesë të njëjtë, edhe pse e kishte kërkuar edhe më herët të njëjtën. Kjo kërkesë

do të shkojë në server dhe serveri do të japë një përgjigje. Kjo e rritë trafikun në rrjet. Cache

është një koncept i implementuar në anën e klientit për të ruajtur kërkesa që tashmë janë

dërguar në server. Kështu që nëse bëhet kërkesa e njëjtë nga klienti, në vend se të shkojë në

server, ajo do të shkojë në cache dhe do të marrë informacionin e kërkuar. Kjo kursen sasinë

e trafikut në rrjet nga klienti në server.

4. Sistem i shtresuar

Koncepti i sistemit të shtresuar është se çdo shtresë e re, siç janë shtresat e mesme

(middleware8), mund të shtohet në mes të kërkesës së klientit dhe serverit ku është vendosur

REST ueb shërbimi (Shtresa middleware është ajo shtresë ku krijohet e gjithë biznes logjika.

Ky mund të jetë një shërbim shtesë me të cilin klienti mund të komunikojë para se kërkesa

të shkojë në ueb shërbim.). Por shtimi i kësaj shtrese duhet të jetë transparent në mënyrë që

të mos e pengojë komunikimin në mes klientit dhe serverit.

5. Interface/ Kontrata uniforme

Kjo është teknika themelore se si një ueb shërbim RESTful duhet të punojë. RESTful në

parim punon në shtresën e uebit HTTP dhe përdorë komandat e mëposhtme që të ketë qasje

në resurset e serverit.

• POST – Për të krijuar një resurs të ri në server

• GET – Për të marrë një resurs nga serveri

• PUT – Për t’i ndryshuar gjendjen ose për ta azhurnuar një resurs

• DELETE – Për ta larguar ose fshirë një resurs nga serveri [7]

8 Është softuer kompjuterik që ofron shërbime për aplikacione softuerësh përtej atyre që janë në dispozicion nga sistemi operativ

19

SOAP vs REST. Dallimet?

SOAP (Simple Object Access Protocol) është një standard i bazuar në ueb shërbime me qasje

në protokoll, që është në përdorim për një kohë të gjatë. Zhvilluar fillimisht nga Microsoft,

SOAP nuk është aq i thjeshtë siç na sugjeron akronimi.

Një përmbledhje e shpejtë e SOAP

SOAP mbështetet ekskluzivisht në XML9 për të ofruar shërbime të mesazheve. Microsoft

fillimisht zhvilloi SOAP për t’i zëvendësuar teknologjitë e vjetra që nuk punonin mirë në

internet si p.sh.: Distributed Component Object Model (DCOM) dhe Common Object

Request Broker Architecture (CORBA).

Këto janë funksionet kryesore të SOAP:

• SOAP është një protokoll komunikimi i dizajnuar të komunikojë përmes internetit.

• SOAP mund ta zgjerojë HTTP-në për mesazhe në XML format.

• SOAP siguron transportin e të dhënave për ueb shërbimet.

• SOAP mund të shkëmbejë dokumente të plota ose të thërrasë një procedurë të largët

(remote procedure)

• SOAP mund të përdoret për transmetimin e një mesazhi.

• SOAP është platformë që është e pavarur nga gjuhët programuese.

• SOAP është në format XML që definon se çfarë informacioni dërgohet dhe si.

• SOAP u mundëson aplikacioneve të klientit që lirisht të lidhen me shërbime në

distancë dhe të shfrytëzojnë metodat e këtyre shërbimeve.

REST apo SOAP

Nëse veç planifikoni të krijoni shërbimin tuaj të internetit, vendimi se cili protokoll duhet të

përdoret është krejtësisht në duart tuaja. Janë jashtëzakonisht pak ueb shërbime në internet,

siç është Amazon, që i mbështesin të dyja protokollet. Vendimi juaj shpesh përqendrohet më

9 Qëndron për eXtensible Markup Language. XML është dizajunar për të ruajtur dhe transportuar të dhënat

20

shumë në atë se cili ueb shërbim i plotëson më së miri nevojat tuaja, sesa cilin protokoll ta

përdorni.

Përparësitë e SOAP

SOAP ofron këto përparësi kur krahasohet me REST:

• Gjuha, platforma dhe transporti i pavarur (REST kërkon të përdoret HTTP)

• Punon mirë në mjediset e shpërndara të ndërmarrjeve (REST përdor komunikimin

pikë në pikë (point-to-point))

• I standardizuar

• Siguron një shtrirje të konsiderueshme pre-build në formën e standardeve WS10

• Menaxhim të integruar të gabimeve

• I automatizuar kur përdoret në disa gjuhë

Përparësitë e REST

REST është më i lehtë për t’u përdorur dhe më fleksibil. Ka këto përparësi nga SOAP:

• Nuk kërkon asnjë mjet të shtrenjtë të ndërveprojë me ueb shërbimet

• Më i lehtë për t’u mësuar

• Efikas (SOAP përdorë XML për të gjitha mesazhet, Rest mund të përdorë formate të

tjera më të vogla për mesazhe)

• Shpejtësi (nuk kërkohet ndonjë përpunim i gjerë (extensive))

• Më i afërt me ueb teknologjitë tjera sa i përket filozofisë së dizajnit [8].

10 Qëndron për Web Services (ueb shërbime)

21

5. Mikroshërbimet

Arkitektura e mikroshërbimeve (microservices) është njëra nga arkitekturat softuerike më të

diskutuara, dhe e ka ndryshuar përgjithmonë mënyrën sesi zhvillohen aplikacionet e

ndërmarrjeve të mëdha. Në vend të qasjes monolitike (monolithic) të ngadalshme dhe

komplekse, zhvilluesit dhe kompanitë kudo janë kthyer në arkitekturën e mikroshërbimeve

për të thjeshtësuar dhe shkallëzuar strukturat e tyre. Në fakt, edhe kompanitë si Amazon,

Netflix, Spotify dhe Uber e kanë bërë këtë tranzicion [9].

Në vazhdim do të flasim rreth:

• Çka është arkitektura microservices?

• Dobitë dhe të metat

• Microservices dhe Docker

• Steket e teknologjisë dhe modelet arkitekturore (Technology stacks and architecture

patterns)

Çka është arkitektura mikroshërbimeve?

Nuk ka ndonjë term të përgjithshëm për mikroshërbime. Definicioni më i thjeshtë për

mikroshërbimet, të quajtura ndryshe edhe si arkitektura microservice, është një stil

arkitekturor që strukturon një aplikacion duke shfrytëzuar shërbime që janë të lidhura në

afërsi. Këto koleksione apo module mund të zhvillohen, të vendosen online dhe të

mirëmbahen në mënyrë të pavarur.

Ato veprojnë me një shpejtësi shumë më të shpejtë dhe janë më të besueshme sesa

aplikacionet monolitike tradicionale dhe të komplikuara. Duke përdorur arkitekturat e

mikroshërbimeve, një organizatë e çfarëdo madhësie mund të evoluojë steket teknologjike

për t’i përshtatur me aftësitë e tyre.

Ka shumë dobi të dukshme kur përdorim mikroshërbimet, të cilat do t’i diskutojmë më vonë,

por janë ende disa polemika mbi atë se a duhet kompanitë të kalojnë nga sistemet monolitike

në ato të mikroshërbimeve apo jo. Le të ekzaminojmë dallimet në mes tyre që ta kemi më të

qartë çështjen [9].

22

Monolitik kundrejt mikroshërbimeve (Monolithic vs. Microservices)

Arkitektura monolitike është mënyra tradicionale për zhvillimin dhe vendosjen online të

aplikacioneve. Kjo strukturë është e bazuar rreth konceptit të një njësie të pandashme duke

përfshirë pjesën e serverit, pjesën e klientit dhe bazën e të dhënave. Të gjitha aspektet janë

unifikuar dhe menaxhuar si një njësi e vetme. Kjo do të thotë se për çfarëdo azhurnimi të

kodit i gjithë sistemi do të ndryshojë. Aplikacionet monolitike mund të bëhen shpejt

komplekse, kështu që i gjithë procesi i zhvillimit zakonisht zgjatë më shumë.

Arkitekturë e mikroshërbimeve, në anën tjetër, e zbërthen atë në njësi të pavarura që

funksionojnë si shërbime të ndara. Kjo do të thotë se secili shërbim e ka logjikën dhe kodin

(codebase) e vet. Këto shërbime të ndara komunikojnë ndërmjet vete përmes API-ve

(Application Programming Interfaces).

Pra, cilën arkitekturë duhet ta përdorim? Le ta zbërthejmë këtë.

Kur duhet ta zgjedhim arkitekturën monolitike?

• Nëse ne jemi një kompani me një ekip të vogël. Në këtë mënyrë ne nuk do të

merremi me implementimin (deploying) kompleks të një arkitekture microservice.

• Nëse duam një lansim (launch) të shpejtë. Arkitektura monolitike kërkon më pak

kohë për lansim. Ky sistem do të kërkojë më shumë kohë më vonë kur ne duam ta

azhurnojmë sistemin, mirëpo lansimi fillestar është më i shpejtë.

Kur duhet ta zgjedhim arkitekturën e mikroshërbimeve?

• Nëse duam të implementojmë një aplikacion më të shkallëzuar (scalable).

Shkallëzimi (sacling) i një arkitekture me mikroshërbime është shumë më i lehtë.

Veçoritë dhe modulet e reja mund të shtohen me shumë shpejtësi dhe lehtësi.

• Nëse kompania jonë është e madhe ose planifikon të rritet. Përdorimi i

microservices është i përshtatshëm për kompanitë që planifikojnë të rriten, për arsye

se microservices arkitektura është më shumë e shkallëzuar (scalable) dhe më e lehtë

të përshtatet me kalimin e kohës. [9]

23

Dobitë dhe të metat e mikroshërbimeve (microservices)

Ka një numër të madh të arsyeve pse një arkitekturë microservices është zgjedhje më e mirë

gjatë zhvillimit të projekteve. Le t’i diskutojmë dobitë më të dukshme të kësaj arkitekture

dhe pastaj do t’i shfaqim disa nga të metat. [9]

Dobitë

Përmirësimi i shkallëzueshmërisë (Scalability) dhe i produktivitetit

Ekipet e mëdha zakonisht punojnë së bashku në projekte të mëdha dhe komplekse. Me

microservices, projektet mund të ndahen në njësi më të vogla dhe të pavarura. Kjo do të thotë

se ekpiet mund të veprojnë në mënyrë të pavarur varësisht nga logjika e domenit, kjo do të

minimizojë koordinimin dhe tendosjen. Në sajë të kësaj, ekipet janë përgjegjëse dhe mund të

vendosin se cilat teknologji t’i përdorin varësisht nga nevoja për çdo microservice.

Për shembull, struktura e brendshme e secilës njësi ose konteiner (container) nuk ka rëndësi

për aq kohë sa ndërfaqja (interface) funksionon në mënyrë korrekte. Prandaj, çdo gjuhë

programuese mund të përdoret për të ndërtuar një microservice, kështu që ekipi përgjegjës

mund ta zgjedhë gjuhën më të përshtatshme për anëtarët e tij.

Integrohet mirë me sistemet e vjetra

Sistemet monolitike janë të vështira për t’u mirëmbajtur. Shumë sisteme të vjetra janë dobët

të strukturuara, dobët të testuara, ose varen nga tekonologji të vjetruara. Fatmirësisht,

microservices mund të punojnë me sistemet e vjetra për ta përmirësuar kodin dhe t’i

zëvendësojnë pjesët e vjetra. Integrimi është i lehtë dhe mund të zgjidhë shumë probleme që

i bën sistemet monolitike diçka që i përket të kaluarës.

Zhvillimi i qëndrueshëm

Arkitekturat microservice krijojnë sisteme që mbesin të mirëmbajtshme për kohë të gjatë

derisa disa pjesë mund të zëvendësohen. Kjo do të thotë se microservices mund të shkrihen

lehtë pa e komprementuar sistemin në përgjithësi. Përderisa vartësitë (dependencies) janë

menaxhuar në mënyrë të përshtatshme, ndryshimet mund të bëhen lehtë për t’i optimizuar

nevojat e ekipit dhe performancën.

24

Cross-functionality11

Microservices janë më të mira për ekipe të shpërndara. Nëse ne kemi një ekip që është rreth

e rreth botës dhe i ndarë në divizione, microservices përfitojnë lirinë dhe fleksibilitetin për të

punuar të pavarura. Vendimet teknike mund të merren shpejt që të integrohen me shërbime

të tjera me shpejtësi. Cross-functionality kurrë nuk ka qenë më i lehtë. [9]

Të metat

Procesi i zhvillimit kërkon më shumë punë

Operacioni për ta bërë një sistem microservices do më shumë përpjekje, pasi janë më shumë

njësi që duhet të vendosen në server dhe gjithashtu të monitorohen. Ndryshimet në interface-

a duhet të implementohen kështu që vendosja në server e shërbimeve individuale në mënyrë

të pavarur të jetë ende e mundur.

Testimi duhet të jetë i pavarur

Përderisa të gjitha microservices duhet të testohen bashkërisht, një microservice mund ta

bllokojë fazën e testimit dhe ta ndalojë vendosjen e microservice-ve të tjera në server. Ka

shumë interface për t’u testuar dhe testimi duhet të bëhet në mënyrë të pavarur për të dy pjesët

e interface.

Vështirësitë në ndryshimin e shumë microservices

Ndryshimet që ndikojnë shumë microservices mund të jenë më të vështira për t’u

implementuar. Në microservice sistemin, ndryshimet kërkojnë disa koordinime për

vendosjen e tyre në server [9].

Microservices dhe Docker

Docker dhe mikroshërbimet (microservices) janë sinonime të afërta. Mikroshërbimet duhet

të jenë të sojit që të mund të vendosen në server ndaras si njësi të pavarura me shkallëzim

(scalable). Por, çka nëse ne krijojmë shumë mikroshërbime për një aplikacion të vetëm?

Docker është një zgjidhje e lehtë e problemit për t’i vendosur mikroshërbimet në server. Një

11 Duke përfshirë njerëz ose departamente që bëjnë lloje të ndryshme të punës për të njëjtën kompani

25

mikroshërbim mund të paketohet në një Docker image dhe të izolohet si një Docker

konteiner. Në këtë mënyrë ne mund të ndërtojmë një aplikacion i cili është i pavarur nga

mjedisi i serverit. [9]

Në vend se të ketë një makinë të tërë virtuale në pronësi, Docker konteinerët e ndajnë

bërthamën (kernel) e sistemit operativ në serverin e Docker-it. Proceset nga konteinerët

shfaqen në tabelën e proceseve të sistemit operativ në të cilën Docker konteinerët janë duke

funksionuar.

Për të përdorur Docker-in me microservices, ne duhet të krijojmë Docker images përmes

fajllave të quajtur Dockerfile. Dockerfile-at janë të lehtë për tu shkruar, kështu që përdorimi

i softuerit mund të jetë i lehtë. Të shohim një shembull të Dockerfile për microservices në

Java.

Figura 7. Shembull të Dockerfile për microservices në Java

Një sistem mikroshërbimi tipik përmban shumë Docker konteinera. Koordinimi i një sistemi

të konteinerëve të shumëfishtë Docker kërkon konfigurime për rrjetin virtual. Konteinerët

duhet të jenë në gjendje të gjejnë njëri-tjetrin për të komunikuar. Docker Compose mjedisi

mund të komunikojë me një server tjetër përmes një vegze (link), duke ofruar një sistem

service discovery [9].

Mikroshërbimet asinkrone

Mikroshërbimet sinkrone i bëjnë një kërkesë microservice-ve të tjera ndërsa përpunojnë

kërkesa dhe presin rezultate. Protokollet e komunikimit asinkron dërgojnë mesazhe, ndaj të

cilëve reagojnë marrësit, por nuk ka përgjigje të drejtpërdrejtë. Një mikroshërbim mund të

përkufizohet si asinkron nëse nuk bën kërkesa për mikroshërbime të tjera gjatë përpunimit,

ose bën kërkesa, por nuk pret për rezultate.

26

Mikroshërbimet asinkrone ofrojnë disa avantazhe të dukshme për mikroshërbimet sinkrone

dhe zgjidhin shumë prej sfidave të sistemeve të shpërndara. Logjika e kërkuar për të trajtuar

kërkesat e mikroshërbimeve nuk varet nga rezultatet, duke i bërë kështu shumë më të

pavarura.

Në mënyrë të ngjashme, nëse një partner komunikimi do të dështonte, ai nuk do të rrëzonte

të gjithë sistemin, duke ofruar rezistencë të përgjithshme për sistemin tuaj. Për më tepër,

përpunimi dhe shpërndarja janë pothuajse gjithmonë të garantuara.

Disa shembuj të zakonshëm të teknologjive për microservice-t asinkrone janë Kafka (një

MOM që përdoret zakonisht për mesazhe), formatin e të dhënave REST dhe Atom (për

infrastrukturë shtesë) [9].

Platformat e mikroshërbimeve (microservices)

Platformat e mikroshërbimeve, të tilla si PaaS dhe Docker scheduler, mbështesin

funksionimin dhe komunikimin e microservices tuaja. Këto teknologji mundësojnë

komunikimin midis mikroshërbimeve për vendosjen, analizën e log-ut dhe monitorimin.

Për shembull, këto platforma mbështesin HTTP dhe REST me balancimin e ngarkesës dhe

zbulimin e shërbimit. Mbështetje e kufizuar e operacioneve është e nevojshme për zbatimin

e mikroshërbimeve, në mënyrë që ato të vendosen shpejt dhe të mbështesin mikroshërbime

të shumta.

Platformat e mikroshërbimeve përfaqësojnë një thjeshtëzim dhe zgjidhje të çështjeve të

zakonshme. Disa platforma të njohura janë Kubernetes dhe Docker, të cilat janë shumë të

rëndësishme për operacionet e microservices. PaaS dhe Cloud Foundry janë gjithashtu të

dobishme, por ato nuk janë aq të njohura.

Është e rëndësishme të theksohet se migracioni në këto platforma kërkon një ndryshim në

funksionimin dhe instalimin e aplikacioneve, i cili mund të bëjë në përdorimin e një platforme

mikroshërbimi një hap të madh dhe në kohë. Kjo është pengesa kryesore e platformave të

mikroshërbimeve [9].

27

6. Teknologjitë dhe arkitektura e përdorur për zhvillimin e

aplikacionit

Siç e kemi cekur edhe në hyrje, për këtë punim diplome ne do të zhvillojmë edhe një

aplikacion i cili vë në funksion modalitetet që i kemi shpjeguar në këtë punim.

Në fillim do të flasim për teknologjitë e përdorura dhe arysen pse i kemi përdorur këto

teknologji e më pas do të lëshohemi në arkitekturën e përdorur për ta ndërtuar këtë aplikacion.

Teknologjitë

Gjuha programuese bazë në të cilën është zhvilluar është PHP (Hypertext Preprocessor).

Çka është PHP dhe për çfarë shërben?

PHP është shkurtesë për Personal Home Page. E krijuar në vitin 1994 nga Rasmus Lerdorf,

me qëllim të përcjelljes së vizitave në Web faqen që e përmbante rezymenë e tij. Kuptimi që

i jepet sot është PHP: Hypertext Preprocessor.

Është gjuhë programuese, e dedikuar në veçanti për zhvillimin e Web aplikacioneve. Duke

qenë gjuhë për përpilimin e skriptave që ekzekutohen në server, programet e shkruara në PHP

nuk kompajlohen, por interpretohen gjatë ekzekutimit. Efekti kryesor negativ i kësaj qasjeje

është se aplikacionet, gjegjësisht skriptat, ekzekutohen më ngadalë se ato të kompajluara, siç

janë aplikacionet e shkruara në gjuhët programuese C apo C++. Në këtë aspekt, PHP është i

krahasueshëm me JavaScript, me një dallim thelbësor se JavaScript ekzekutohet brenda

shfletuesit, ndërsa PHP ekzekutohet ekskluzivisht në server.

Meqenëse shfletuesit i njohin vetëm kodet e përpiluara në HTML, CSS dhe JavaScript, edhe

rezultati që gjenerohet nga një PHP skriptë duhet të jetë në njërën nga gjuhët e përmendura.

Kodi i PHP mund të futet brenda kodit HTML, ku është në gjendje t’i shtojë faqes ekzistuese

kodin HTML të gjeneruar në mënyrë programore.

Pra, përdorimi i PHP është shumë specifik: gjenerimi i HTML kodit që insertohet në një

HTML faqe ekzistuese. Me PHP nuk mund të shkruhen aplikacione të pavarura që rezultojnë

në një .exe aplikacion.

28

Kodi në PHP ekzekutohet në server, jo te klienti (shfletuesi). Për dallim nga JavaScript,

ekzekutimi i kodit në PHP nuk varet nga modeli apo versioni i shfletuesit të caktuar.

Skripta ruhet në server dhe shfletuesit i dërgohet vetëm rezultati i ekzekutimit të kodit, në

formë të dokumentit të formatuar në HTML/CSS.

Për këtë shkak, skripta në PHP nuk mund të shihet në shfletues me "View Source", gjë që

është avantazh në aspektin e mbrojtjes së pronës intelektuale, por edhe në aspektin e sigurisë

së aplikacionit.

Sipas Bacon J. (2007), PHP ofron një gjuhë programuese solide dhe mirë të definuar që

përfshin përkrahjen për programim të orientuar në objekte (object-orientated programming -

OOP), strukturat logjike, manipulimet me fajlla, aritmetikë, e shumëçka tjetër.

Gjuha PHP është e ngjashme semantikisht me atë të gjuhëve skriptuese kombinuar me

lehtësitë që ofron gjuha C.

Pasi ne për zhvillimin e aplikacionit kemi përdorur Lumen framework, së pari do të flasim

për termin framework në përgjithësi pastaj edhe për Lumen framework në veçanti [10].

Çka është framework-u?

Në përgjithësi, një framework është një strukturë e vërtetë ose konceptuale, e synuar të

shërbejë si mbështetje ose udhëzues për ndërtimin e diçkaje që e zgjeron strukturën në diçka

të dobishme.

Në sistemet kompjuterike, një framework është shpesh një strukturë shtresore që tregon se

çfarë lloj programesh mund ose duhet të ndërtohen dhe si ato do të ndërlidheshin. Disa

framework-a të sistemit kompjuterik gjithashtu përfshijnë programet aktuale, specifikojnë

ndërfaqet (interfaces) e programimit ose ofrojnë mjete programimi për përdorimin e

framework-ave. Një framework mund të jetë për një seri funksionesh brenda një sistemi dhe

mënyrën sesi ato ndërlidhen; shtresat e një sistemi operativ; shtresat e një nënsistemi

aplikimi; sesi komunikimi duhet të standardizohet në njëfarë niveli të një rrjeti; dhe kështu

me radhë. Një framework është përgjithësisht më gjithëpërfshirës sesa një protokoll dhe më

normativ sesa një strukturë [11].

29

Lumen framework

Lumen është një projekt i ri nga krijuesi i Laravel12, Taylor Otwell. Është një mikro-

framework, që do të thotë është më i vogël, më i shpejtë, version më i pakët se versioni i plotë

i ueb framework. PHP ka edhe dy mikro-framework tjerë të njohur, Slim dhe Silex.

Lumen ka të njëjtin themel si Laravel, dhe shumë prej të njëjtëve komponentë. Por Lumen

është i ndërtuar për mikroshërbime, jo aq shumë për aplikacione që “shihen” nga përdoruesit

(megjithëse mund të përdoret për çdo gjë.)

Për çka përdoret?

Lumen është për projekte dhe komponentë që mund të përfitojnë nga komoditeti dhe fuqia e

Laravel, por mund të përballojë të sakrifikojë disa konfigurime dhe fleksibilitete në këmbim

të shpejtësisë.

Lumen është në shënjestër të mikroshërbimeve - komponentëve të vegjël, të shoqëruar

lirshëm që zakonisht mbështesin dhe përmirësojnë një projekt thelbësor (core).

Mikroshërbimet janë komponentë të veçantë me kontekste të kufizuara (d.m.th. ato kanë

ndërfaqe (interfaces) të përcaktuara mirë mes njëra-tjetrës), kështu që në një arkitekturë me

mikroshërbime mund të keni disa aplikacione të vogla Lumen që mbështesin një tjetër

aplikacion, ndoshta të mundësuar nga Laravel.

PHP Mikro-Framework vs. Full-Stack Framework

Framework-at full-stack ndihmojnë programuesit me të gjithë raftet e zhvillimit nga

ndërfaqja me përdoruesin në bazën e të dhënave. Çdo gjë jashtë një framework-u të plotë,

është teknikisht një "framework jo i plotë". Për atë grup, nëse framework-at dhe libraritë janë

më të vogla se "5k", ose 5,000 rreshta kod, ajo njihet si një mikro-framework.

Mikro-framework-at lënë shumë nga komponentët e një konfigurimi të plotë (full-stack

setup), duke përfshirë:

12 Laravel është një kornizë aplikacioni (framework) në internet me sintaksë ekspresive, elegante. Zhvilluar në PHP

30

• Mekanizmin për shabllonet ueb (Web template engine)

• Validimin për futjen e të dhënave (Input Validation)

• Abstraksionin e bazës së të dhënave (Database abstraction)

• Rolet, llogaritë, dhe verifikimin (authentication)

Arkitektura

Figura 8. Diagrami i funksionimit te arkitekturës së mikroshërbimeve në ueb aplikacion

Siç e kemi cekur edhe në kapitujt e mëhershëm, programin të cilin e kemi ndërtuar ka të

mbërthyer arkitekturën me mikroshërbime (microservices). Këtu shpjegimin do ta nisim duke

filluar nga pjesët më të mëdha të programit e duke e “copëtuar” në pjesë më të vogla për ta

pasur një pasqyrë më të qartë.

Ashtu siç është paraqituar edhe në figurën 8, pjesa me të cilën ka kontakt klienti është e

quajtuar API Gateway e cila është si një portë që merr kërkesat nga klienti dhe i futë në

funksion shërbimet (services) specifike që menaxhojnë kërkesën e caktuar.

API Gateway merr kërkesën në formë të kërkesës HTTP ku edhe e bën filtrimin e asaj kërkese

dhe përmes middleware kryen edhe verifikimin (authentification) dhe pastaj bën kërkesë në

servise përkatëse. Këto kërkesa nuk janë gjë tjetër veçse thirrje në API. Zakonisht këto thirrje

janë brenda një sistemi dhe sigurohen me një kod ose token për të cilin ka dijeni API

Gateway. Kur servisi kthen përgjigjen, API Gateway e filtron atë përgjigje dhe ia kthen

31

klientit i cili ka bërë kërkesë. API Gateway e luan rolin e një shërbimi (service) por që është

ndërmjetsues mes klientit dhe shërbimeve në sistem.

Në vazhdim do të flasim për arkitekturën apo më mirë të themi për strukturën që kemi zbatuar

nëpër shërbime.

Kemi përdorur framework-un Lumen, ai punon në bazë të dizajnit MVC (Model-View-

Controller), por pasi Lumen nuk është framework i plotë e zakonisht përdoret për API, ai nuk

e ka pjesën e pamjes (View).

PHP MVC Framework me shtresa të srtukturuara (Slim PHP MVC Frameworks with

a Layered Structure)

Një PHP MVC aplikacion “i trashë” ka varësi gjithandej, bllokimi dhe prirja ndaj gabimeve,

përderisa një strukturë me shtresa përdorë injeksionin e vartësisë (dependency injection) për

t’i mbajtur gjërat të pastra dhe të qarta.

Janë pesë shtresa kryesore që do t'i mbulojmë:

• Shtresa e kontrollerit

• Shtresa e servisit

• DTOs, një nëngrup i shtresës së servisit

• View decorators, edhe ky një nëngrup i shtresës së servisit

• Shtresa e repository-t

Figura 9. Arkitektura e pa strukturuar kundrejt arkitekturës së strukturuar

32

Për të implementuar një strukturë me shtresa (layered structure), neve na nevojitet një

konteiner për injeksionin e vartësisë (dependency injection container), një objekt që di si t’i

inicializojë dhe t’i konfigurojë objektet. Ne nuk duhet të krijojmë ndonjë klasë shtesë sepse

framework-u e bën të gjithë magjinë. Konsideroni shembullin e mëposhtëm:

33

Në shembullin më lart, UserService është injektuar në SiteController, UserRepository në

UserService dhe modelet User dhe Logs janë injektuar në klasën UserRepository [12].

Shtresa e kontrollerit (The Controller Layer)

Puna kryesore e kontrollerit është që ta pranojë kërkesën dhe ta paraqesë rezultatin. Një

kontroller nuk duhet të përmbajë ndonjë biznes logjikë (business logic) të aplikacionit;

përndryshe, është shumë e vështirë të ripërdorim kodin ose ta ndryshojmë mënyrën sesi

komunikon aplikacioni.

Le të shqyrtojmë një shembull të kontrollerit të mbingarkuar:

34

Pse ky shembull është i keq? Ja disa arsye:

• Përmban shumë biznes logjikë

• Punon direkt me rekorde aktive (Active Record), kështu që nëse ne ndryshojmë diçka

në databazë, për shembull nëse i ndërrojmë emrin fushës last_login, ne duhet ta

ndryshojmë atë në çdo kontroller.

• Ka njohuri për lidhjet në bazën e të dhënave, pra nëse ndryshojmë diçka në databazë

ne duhet ta ndryshojmë atë çdokund.

• Nuk është kodi i ripërdorshëm, kjo çon në ripërsëritjen e kodit.

Kontrolleri duhet të jetë i thatë. Gjithçka çfarë duhet të bëjë është të marrë kërkesën dhe të

kthejë rezultatin. Ja një shembull i tillë:

Por ku shkojnë të gjitha gjërat e tjera? Kjo i përket shtresës së servisit [12].

Shtresa e servisit (The Service Layer)

Shtresa e servisit është shtresa e biznes logjikës. Këtu, dhe vetëm këtu, duhet të gjendet

informacioni rreth rrjedhjes së biznes proceseve dhe interaksioni me modele. Kjo është një

shtresë abstrakte dhe do të jetë e ndryshme për aplikacione të ndryshme, por principi gjeneral

është pavarësia nga të dhënat që i ruajmë.

Kjo është faza me potencialin më të madh për të ndodhur probleme. Zakonisht një AR model

kthehet në kontroller, dhe si rezultat, kontrolleri duhet të punojë me këto modele dhe duhet

të jetë i vetëdijshëm për atributet dhe vartësitë e tyre. Kjo i bën gjërat të çrregullta, nëse ne

duam ta ndryshojmë një lidhje ose atribut të modelit ne duhet ta ndryshojmë atë në çdo vend.

Për të mos pasur punë direkt me modele që punojnë me entitet të databazës këtu na hyjnë në

punë DTO-t (Data Transfer Object) [12].

35

DTO (Data Transfer Object)

Një DTO është një objekt që përdoret për t’i mbërthyer të dhënat, dhe i dërgon ato nga një

nënsistem i një aplikacioni në një tjetër.

DTO-t zakonisht përdoren më së shumti në shtresën e servisit, në një aplikacion me N shtresa,

për të transferuar të dhënat nga kjo shtresë në shtresën e pamjes (UI Layer). Dobia kryesore

këtu është reduktimi i sasisë së të dhënave që duhet të transmetohen në linja në një sistem të

shpërndarë. Këto gjithashtu krijojnë modele të mrekullueshme në një patern MVC.

Dekoratorët e pamjes (View Decorators)

Pasi aplikacioni që e kemi bërë ne nuk ka komponentën e pamjes sepse është vetëm një API,

Dekoratorët e pamjes nuk na nevojiten në këtë aplikacion mirëpo do ta shpjegojmë

funksionin e tyre shumë shkurt.

Për të mos pasur nevojë që brenda pamjes (view) të përdorim logjikë, këtë e bëjmë përmes

dekoratorëve të pamjes (view decorators) [12].

Shtresa e Repository-t (Repository Layer)

Shtresa e repository-t punon me zbatimin konkret të ruajtjes së të dhënave. Më së miri është

ta injektojmë repository-n përmes një ndërfaqeje për fleksibilitet dhe për zëvendësim të lehtë.

Nëse ndryshojmë ruajtjen e të dhënave tona, duhet të krijojmë një repository të ri që zbaton

ndërfaqen (interface) tonë të repository-ve, por të paktën nuk duhet t’i ndryshojmë shtresat e

tjera.

Repository e kryen rolin e një query objekti. Merr të dhëna nga baza e të dhënave dhe drejton

punën e disa modeleve të Active Record. Modelet Active Record, në këtë kontekst, luajnë

rolin e njësive të vetme të modelit të të dhënave - çdo objekti në sistemin për të cilin

kujdesemi ta modelojmë dhe t’i ruajmë informacionin. Ndërsa çdo entitet përmban

informacion, ai nuk e di se si shfaqet (nëse është krijuar ose marrë nga baza e të dhënave),

ose si të ruajë dhe të ndryshojë gjendjen e tij. Përgjegjësi kryesore e repository-t është të

shtojë dhe/ose të ndryshojë një entitet; kjo siguron ndarje më të mirë të problemeve duke e

mbajtur menaxhimin e entiteteve në repository dhe duke i bërë entitetet më të thjeshta. [12]

36

7. Zhvillimi i një aplikacioni që përdor ueb shërbime

Në kapitullin e mëparshëm folëm rreth teknologjive dhe arkitekturës që i kemi përdorur në

zhvillimin e aplikacionit. Kurse në këtë kapitull do të flasim sesi i kemi implementuar ato

teknologji dhe arkitektura në aplikacion.

Shpjegimin e zhvillimit të aplikacionit do ta bëjmë në mënyrë që në fillim do t’i shpjegojmë

funksionet e përbashkëta që i kanë të gjitha shërbimet e më pas do të ndalemi në veçoritë e

secilit shërbim. Por në fillim le të flasim për strukturën gjenerale të aplikacionit.

Aplikacionin të cilin e kemi zhvilluar kemi vendosur ta quajmë Todomen. Ky aplikacion

është në formën e ueb shërbimeve dhe përdor principet e teknologjisë REST prandaj edhe

quhet aplikacion RESTful. Qëllimi i aplikacionit është caktimi i detyrave (tasks) për

përdoruesit. Aplikacioni ka një API Gateway që menaxhon me kërkesat që vijnë nga kilenti

si dhe ka 4 shërbime të ndryshme që kryejnë punë të ndryshme në mënyrë të pavarur.

Për arsye se punimi jonë ka të bëjë më shumë me ueb shërbime më shumë do të flasim përmes

kodit, po për ta ilustruar më mirë qëllimin e aplikacionit nëse ne do t’i bënim edhe pjesën për

pamje atëherë ai do të dukej diçka si në figurën 10.

Figura 10. Ilustrim i pamjes (frontend) së aplikacionit

Për shërbime (services) do të flasim pak më vonë por tani do vazhdojmë pak me strukturën

dhe krijimin e aplikacionit në Lumen API.

37

Që të mundemi ta instalojmë Lumen duhet t’i përmbushim këto kërkesa:

• PHP >= 7.2

• OpenSSL PHP Extension

• PDO PHP Extension

• Mbstring PHP Extension

Që ta shkarkojmë Lumen, na duhet të instalojmë Composer që lehtësisht e gjejmë me një

kërkim në Google. Pastaj në Command Prompt shënojmë:

Pastaj për të krijuar një aplikacion në Lumen japim komandën:

Në rastin tonë e kemi shënuar todomen se kështu është emri i aplikacionit tonë, por mund të

jetë çfarëdo emri tjetër.

Pasi të hapim instalimin e krijuar në Lumen në ndonjë editor ose IDE do të kemi këtë

strukturë (figura 11):

Figura 11. Struktura e përgjithshme e aplikacionit

Fokusi ynë kryesor do të jetë te dosja (folder) app, ku është pjesa kryesore e framework-ut.

Aty do të krijojmë edhe dosje të tjera që do të na ndihmojnë në shtresëzimin e aplikacionit.

38

Gjithashtu interes do të kemi edhe te dosja database në të cilën ka një nëndsoje me emrin

migrations, ku ruhen migracionet që në vete përmbajnë krijimin e tabelave në databazë ose

manipulimin me to. Pjesa ku ne i caktojmë se çfarë URL do të kenë endpoints-at tonë është

te dosja routes në skedarin (file) web.php. Në figurën 12 tregohet se si duket web.php:

Figura 12. Rutat (routes) në web.php

Kjo është struktura përfundimtare e aplikacionit tonë:

Figura 13. Shërbimet e aplikacionit

Në të gjitha shërbimet (services) ne kemi vendosur një middleware të quajtur

AuthenticateAccessMiddleware.php i cili e bllokon qasjen nga jashtë të këtyre shërbimeve

pa e poseduar një kod të fshehur në header të kërkesës (request), d.m.th APIGateway është

në dijeni për këtë dhe posedon këtë kod (shifër) dhe mund t’u qaset shërbimeve pa problem.

public function handle($request, Closure $next)

{

$validSecrets = explode(',', env('ACCEPTED_SECRETS'));

if(in_array($request->header('Authorization'), $validSecrets) )

{ return $next($request);} abort(Response::HTTP_UNAUTHORIZED);

}

39

Shërbimet (services)

• WorkspaceAPI

Ky servis shërben për krijimin e hapësirave punuese (workspaces) ku është edhe pikënisja

e këtij aplikacioni. Shfrytëzuesit kanë të drejtë të krijojnë një apo disa hapësira punuese

dhe t’i emërtojnë sipas dëshirës. Gjithashtu shfrytëzuesi mund të ftojë shfrytëzues të tjerë

t’i bashkëngjiten hapësirës punuese të tij, ta bëjë dikë administrues ose edhe ta fshijë fare.

Në vijim do t’i shpjegojmë hapat të cilët i kemi ndjekur për t’i bërë operacionet CRUD

(Create Read Update Delete) për hapsirën punuese (workspace).

Në fillim kemi krijuar tabelën për workspace përmes komandave me php artisan.

Nga komanda:

Do të gjenerohet skedari (file) që përmban kodin në vazhdim pasi i kemi shtuar edhe

fushat të cilat na janë nevojitur për të krijuar tabelën workspaces:

class CreateWorkspacesTable extends Migration

{

public function up()

{

Schema::create('workspaces', function (Blueprint $table) {

$table->bigIncrements('id');

$table->string('name');

$table->boolean('is_active');

$table->timestamp('expire_date')->nullable();

$table->bigInteger('created_by_id')->unsigned();

$table->timestamps();

});

}

public function down()

{ Schema::dropIfExists('workspaces');

}}

40

Në këtë klasë kemi dy funksione up() dhe down(), funksioni up thirret kur migracioni

(migration) ekzekutohet ndërsa funksioni down thirret kur tërhiqet (rollback) migracioni.

Komanda në vazhdim e ekzekuton funksionin up të klasës më lartë duke krijuar tabelën

në bazën e të dhënave.

Më pas krijojmë modelin AR për tabelën workspaces ku pastaj përmes ORM* mund të

manipulojmë me të dhënat në tabelë. Modeli i tillë duket si kodi në vazhdim:

class Workspace extends Model

{

protected $table = 'todomen_workspace_db.workspaces';

protected $fillable = ['name', 'is_active', 'expire_date', 'created_by_id'];

}

Pasi të kemi krijuar modelin Workspace mund të manipulojmë me të dhëna në shtresën

të cilën e kemi quajtur Respository ose më saktë klasën WorkspaceRespository.php. Për

ta përdorur modelin e krijuar në e inicializojmë atë përmes injeksionit të varësisë

(dependency injection), që mund ta shohim në konstruktorin (cunstructor) e klasës në

vijim:

class WorkspaceRepository

{

protected $workspace;

public function __construct(Workspace $workspace)

{

$this->workspace = $workspace;

}

public function addWorkspace($workspace){

return $this->workspace->create($workspace);

}

public function getWorkspaceById(int $id){

return $this->workspace->findOrFail($id);

}

41

public function getWorkspaces(){

return $this->workspace->orderBy('id', 'DESC')->get();

}

}

Siç edhe e kemi shpjeguar në kapitullin paraprak, te arkitektura funksionet e Repository-

t i shfrytëzon shtresa e servisit që në rastin tonë është WorkspaceService.php:

class WorkspaceService

{

use ApiResponser;

protected $workspaceRepository;

public function __construct(WorkspaceRepository $workspaceRepository)

{

$this->workspaceRepository = $workspaceRepository;

}

public function saveWorkspace($requestWorkspace, $userId)

{

$workspace = [

'name' => $requestWorkspace['name'], 'is_active' => true,

'created_by_id' => $userId];

$ws = $this->workspaceRepository->addWorkspace($workspace);

$wsUserAdmin = ['workspace_id' => $ws['id'], 'user_id' => $userId,

'is_active' => true, 'create_by_id' => $userId];

$this->saveWorkspaceUser($wsUserAdmin);

$this->saveWorkspaceAdmin($wsUserAdmin);

return $this->successResponse($ws, Response::HTTP_CREATED);

}

public function getWorkspace(int $id)

{

return $this->successResponse($this->workspaceRepository-

>getWorkspaceById($id));

}}

Sipas arkitekturës së cekur këto funksione të serviseve i thërrasim në kontroller dhe pastaj

kthejmë përgjigje në formë të Restful response. Kodi i kontrollerit

WorkspaceController.php është si vijon:

42

class WorkspaceController extends Controller

{

use ApiResponser;

protected $workspaceService;

protected $request;

public function __construct(WorkspaceService $workspaceService, Request

$request)

{

$this->workspaceService = $workspaceService;

$this->request = $request;

}

public function index(){

return $this->workspaceService->getUserWorkspaces($this->request-

>header('Authorization-Key'));

}

public function store(Request $request)

{

$rules = ['name' => 'required|max:254', 'expire_date' => 'date_format:Y-

m-d H:i:s'];

$this->validate($request, $rules);

return $this->workspaceService->saveWorkspace($request, $this->request-

>header('Authorization-Key'));

}

public function show($workspace)

{

return $this->workspaceService->getWorkspace($workspace);

}

}

Këto përgjigje pastaj i pranon APIGateway.

Për shkak të ngjashmërive në strukturë mes shërbimeve, vetëm këtë shërbim e kemi

shpjeguar me anë të kodit, ndërsa të tjerëve do t’ua tregojmë vetëm funksionin.

• BoardAPI

Është tjetër shërbim që shërben për krijimin e tabelave në çdo hapësirë punuese.

43

Sa herë që krijohet një hapësirë punuese (workspace) tri tabela (boards) do të krijohen

në mënyrë automatike, të cilat janë To do, Doing, Done. Shfrytëzuesi mund të krijojë

tabela (boards) të tjera sipas dëshirës apo edhe t’i fshijë ato.

• ListAPI

Ky shërbim është si ndërmjetës mes shërbimit BoardAPI dhe TaskAPI. Këtu mbahet

lista e detyrave (tasks) të cilat ndodhen në një tabelë (board).

• TaskAPI

Te ky shërbim jepen detaje për detyrën (task) që i caktohet shfrytëzuesit. Detyra ka

titullin, përshkrimin që mund të jetë tekst ose figurë ose dyjat bashkë, po ashtu ka

edhe komentet. Detyra (task) mund t’i caktohet një apo më shumë shfrytëzuesve si

dhe mund të ketë kohë të caktuar të përfundimit.

Në fund APIGateway ka servise që i thërrasin shërbimet e cekura më lart. Për ta thirrur

shërbimin WorkspaceAPI e përdorim servisin WorkspaceService.php

class WorkspaceService

{

use ConsumeExternalService;

public $baseUri; public $secret; public $userId;

public function __construct()

{

$this->baseUri = config('services.workspaces.base_uri');

$this->secret = config('services.workspaces.secret');

}

public function obtainWorkspaces() { return $this->performRequest('GET',

'/workspaces'); }

public function createWorkspace($data)

{

return $this->performRequest('POST', '/workspaces', $data);

}

public function obtainWorkspace($id)

{

return $this->performRequest('GET', "/workspaces/{$id}");

}

}

44

Përmes këtyre funksioneve bëhet konsumimi i shërbimeve që i kemi në aplikacion e më pas

këto funksione thirren në kontroller të APIGateway ku edhe jepet përgjigja përfundimtare.

WorkspaceController.php është si në vazhdim:

class WorkspaceController extends Controller

{

use ApiResponser;

protected $workspaceService;

public function __construct(WorkspaceService $workspaceService, Request

$request)

{

$this->workspaceService = $workspaceService;

$this->workspaceService->userId = $request->user()->id;

}

public function index()

{

return $this->successResponse($this->workspaceService-

>obtainWorkspaces());

}

public function store(Request $request)

{

return $this->successResponse($this->workspaceService-

>createWorkspace($request->all()));

}

public function show($workspace)

{return $this->successResponse($this->workspaceService-

>obtainWorkspace($workspace));

}}

Shumica e resurseve në APIGateway nuk mund të qasen pa pasur një verifikim

(authentification). Këtë problem e kemi zgjidhur përmes integrimit të Laravel Passport në

projektin tonë. Instalimi i Laravel Passport bëhet përmes Composer me komandën:

45

8. Testimi i aplikacionit

Testi i njësisë (Unit test) na ndihmon të përcaktojmë se çfarë supozojmë të bëjmë para se të

fillojmë ta bëjmë atë. Lumen ka të konfiguruar mjedisin e testimit për ne. Skeda (file) e

konfigurimit është phpunit.xml e vendosur brenda direktoriumit të projektit. I gjithë testi ynë

do të jetë brenda direktoriumit të testeve.

Për arsye të testimit kemi krijuar një skedar (file) të ri prove (test) brenda këtij direktoriumi.

Skedarin e kemi emëruar WorkspaceTest.php. Dosja jonë e provës do ta trashëgojë klasën

TestCase. Me këtë klasë tani kemi qasje në të gjitha metodat që mund t’i përdorim për të

testuar pikat tona përfundimtare (endpoints).

Testimi do të përfshijë këto pika të fundme (endpoints):

• /workspaces [GET] — i merr të gjitha hapësirat punuese (workspaces).

• /workspaces/id [GET] — e merr vetëm një hapësirë punuese.

• /workspaces [POST] — shton një hapësirë punuese të re.

• /workspaces/id [PUT] — ndryshon një hapësirë punuese.

• /workspaces/id [DELETE] — fshin një hapësirë punuese.

Ky është skedari (file) ynë:

class WorkspaceTest extends TestCase

{

public function testShouldReturnAllWorkspaces()

{

$this->get("workspaces", []); $this->seeStatusCode(200);

$this->seeJsonStructure(['data' => ['*' => ['id', 'name', 'is_active',

'expire_date', 'created_by_id', 'created_at', 'created_at']]]);

}

public function testShouldReturnWorkspace()

{

$this->get("workspaces/2", []); $this->seeStatusCode(200);

$this->seeJsonStructure(['data' => ['id', 'name', 'is_active',

'expire_date', 'created_by_id', 'created_at', 'created_at']]);

46

}

public function testShouldCreateWorkspace()

{

$parameters = ['name' => 'TEST name'];

$this->post("workspaces", $parameters, []);

$this->seeStatusCode(201);

$this->seeJsonStructure(['data' => ['id', 'name', 'is_active',

'created_by_id', 'created_at', 'created_at']]);

}

public function testShouldUpdateWorkspace(){

$parameters = ['name' => 'TEST edited name', 'is_active' => true];

$this->put("workspaces/6", $parameters, []);

$this->seeStatusCode(200);

}

public function testShouldDeleteWorkspace(){

$this->delete("workspaces/15", [], []); $this->seeStatusCode(204);

}

}

Pasi kemi përfunduar klasën WorkspaceTest atëherë ne mund t’i ekzekutojmë provat (tests)

tona. Ekzekutimin e bëjmë përmes terminalit duke përdorur komandat specifike.

Nëse duam ta testojmë një metodë specifike, testSholudRetrunAllWorkspaces në rastin tonë,

ose nëse duam t’i testojmë të gjitha metodat e klasës atë e bëjmë përmes komandës:

Pas ekzekutimit të komandës së fundit në terminal do të na shfaqet mesazhi se testimet janë

kryer me sukses:

47

9. Përfundimi

Mikroshërbimet janë më të përshtatshmet për aplikacione më të mëdha. Aplikacionet më të

vogla zakonisht janë më mirë me një bazë kodi monolit (monolith).

Ndonëse është më e lehtë për të zhvilluar dhe për të mirëmbajtur mikroshërbime të pavarura,

menaxhimi i rrjetit kërkon përpjekje shtesë.

Ne kemi folur në detaje për të dy stilet e arkitekturës monolitike dhe atë të mikroshërbimeve.

Ne diskutuam gjithashtu problemet e ndryshme kyçe të aplikacioneve monolitike dhe sesi

paraqiten mikroshërbimet për t'i zgjidhur ato në botën e re të zhvillimeve të aplikacioneve.

Me pak fjalë, zgjidhni arkitekturën e mikroshërbimeve për benefitet e mëposhtme:

• Zhvilloni dhe vendosni në mënyrë të pavarur shërbime

• Shpejtësia dhe gatishmëria

• Cilësia më e mirë e kodit

• Kodi i krijuar / organizuar rreth funksionalitetit të biznesit

• Rritja e produktivitetit

• Shkallëshmëria (scale) më e lartë

• Liria (në një farë mënyre) për të zgjedhur teknologjinë / gjuhën e zbatimit

Edhe me të gjitha përfitimet e ofruara nga arkitektura e mikroshërbimeve, ajo nuk është një

plumb argjendi. Ka ndërlikimet e veta. Mendoni për raste të shumta të qindra shërbimeve në

një projekt të madh. Si do t’i monitoroni këto? Në rast të ndonjë dështimi të shërbimit, si do

të gjurmohet dhe korrigjohet një gabim?

Prandaj edhe në aplikacione të vogla dhe leht të mirëmbajtura aplikimi i arkitekturës së

mikroshërbimeve do të na sjellte kosto shtesë. Ndërsa për aplikacione të mëdha ky stil i

arkitekturës sjell përfitime mjaft të mëdha.

48

10. Literatura

[1] Sam Newman, “Building Microservices: Designing Fine-Grained Systems”, O’Reilly

Media, Inc., ISBN: 978-1491950357, 2015.

[2] Sam Newman, “Monolith to Microservices”, O’Reilly Media, Inc., ISBN: 978-

1492047841, 2019.

[3] Samisa Abeysinghe, “RESTful PHP Web Services”, Packt Publishing, 2008.

[4] https://web.stanford.edu/class/msande91si/www-

spr04/readings/week1/InternetWhitepaper.htm, qasur më 15/06/2020.

[5] https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview, qasur më 18/06/2020.

[6] https://phppot.com/php/php-restful-web-service/, qasur më 19/06/2020.

[7] https://www.guru99.com/restful-web-services.html, qasur më 19/06/2020.

[8] https://smartbear.com/blog/test-and-monitor/soap-vs-rest-whats-the-difference/, qasur

më 25/06/2020.

[9] https://www.educative.io/blog/microservices-architecture-tutorial-all-you-need-to-get-

started, qasur më 28/06/2020.

[10] Tahir Hoxha, “PHP dhe MySQL për fillester”, 2015.

[11] https://whatis.techtarget.com/definition/framework, qasur më 02/07/2020.

[12] https://www.toptal.com/php/maintain-slim-php-mvc-frameworks-with-a-layered-

structure, qasur më 03/06/2020.

[13] https://lumen.laravel.com/docs/7.x, qasur më 03/06/2020.

[14] https://medium.com/@OlabodeAbesin/microservice-architecture-the-complete-guide-

357bf7131cf1, qasur më 05/06/2020.

https://web.stanford.edu/class/msande91si/www-spr04/readings/week1/InternetWhitepaper.htmhttps://web.stanford.edu/class/msande91si/www-spr04/readings/week1/InternetWhitepaper.htmhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Overviewhttps://phppot.com/php/php-restful-web-service/https://www.guru99.com/restful-web-services.htmlhttps://smartbear.com/blog/test-and-monitor/soap-vs-rest-whats-the-difference/https://www.educative.io/blog/microservices-architecture-tutorial-all-you-need-to-get-startedhttps://www.educative.io/blog/microservices-architecture-tutorial-all-you-need-to-get-startedhttps://whatis.techtarget.com/definition/frameworkhttps://www.toptal.com/php/maintain-slim-php-mvc-frameworks-with-a-layered-structurehttps://www.toptal.com/php/maintain-slim-php-mvc-frameworks-with-a-layered-structurehttps://lumen.laravel.com/docs/7.xhttps://medium.com/@OlabodeAbesin/microservice-architecture-the-complete-guide-357bf7131cf1https://medium.com/@OlabodeAbesin/microservice-architecture-the-complete-guide-357bf7131cf1

49

11. Lista e figurave

Figura 1. Komunikimi i dy kompjuterëve përmes internetit .............................................................. 5

Figura 2. Komunikimi përmes internetit sipas shtresave të protokolleve ........................................... 6

Figura 3. Ilustrimi si funksionon një uebsajt në internet ..................................................................... 8

Figura 4. Rrjedhshmëria kërkesë - klient ............................................................................................ 9

Figura 5. Diagrami i metodave HTTP ............................................................................................... 16

Figura 6. Diagrami i arkitekturës RESTful ........................................................................................ 17

Figura 7. Shembull të Dockerfile për microservices në Java ............................................................ 25

Figura 8. Diagrami i funksionimit te arkitekturës së mikroshërbimeve në ueb aplikacion ............... 30

Figura 9. Arkitektura e pa strukturuar kundrejt arkitekturës së strukturuar ...................................... 31

Figura 10. Ilustrim i pamjes (frontend) së aplikacionit ..................................................................... 36

Figura 11. Struktura e përgjithshme e aplikacionit ........................................................................... 37

Figura 12. Rutat (routes) në web.php ................................................................................................ 38

Figura 13. Shërbimet e aplikacionit .................................................................................................. 38

12. Lista e tabelave

Tabela 1: Shtresat e protokollit .......................................................................................................... .6

file:///C:/Users/Dardan/Desktop/Dardan%20Baliu%20-%20Tema%20e%20diplomes.docx%23_Toc511676572file:///C:/Users/Dardan/Desktop/Dardan%20Baliu%20-%20Tema%20e%20diplomes.docx%23_Toc511676572file:///C:/Users/Dardan/Desktop/Dardan%20Baliu%20-%20Tema%20e%20diplomes.docx%23_Toc511676574file:///C:/Users/Dardan/Desktop/Dardan%20Baliu%20-%20Tema%20e%20diplomes.docx%23_Toc511676574