Razvoj in analiza zmogljivosti rešitev na osnovi ogrodja ASP .NET Core

Transkripcija

1 UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Tomi Jerenko RAZVOJ IN ANALIZA ZMOGLJIVOSTI REŠITEV NA OSNOVI OGRODJA ASP.NET CORE Diplomsko delo Maribor, avgust 2017

2 RAZVOJ IN ANALIZA ZMOGLJIVOSTI REŠITEV NA OSNOVI OGRODJA ASP.NET CORE Diplomsko delo Študent: Študijski program: Smer: Mentor: Lektorica: Tomi Jerenko visokošolski študijski program Informatika in tehnologije komuniciranja Razvoj informacijskih sistemov doc. dr. Boštjan Šumak Jasmina Vajda Vrhunec, prof. slov.

3

4 Zahvala Zahvaljujem se mentorju doc. dr. Boštjanu Šumaku za pomoč pri izdelavi diplomskega dela. Zahvaljujem se tudi dr. Alešu Černezlu za vse znanje in nasvete, ki so mi bili v veliko pomoč pri pisanju diplomskega dela. Posebna zahvala velja družini, ki mi je omogočila študij, ter prijateljem in sošolcem, ki so mi bili v oporo.

5 Razvoj in analiza zmogljivosti rešitev na osnovi ogrodja ASP.NET Core Ključne besede:.net, ASP, Core, spletne aplikacije, oblačno računalništvo UDK: (043.2) Povzetek V diplomskem delu smo spoznali principe in dobre prakse oblačnega računalništva ter lastnosti ogrodij za razvoj spletnih aplikacij. Kot glavno temo diplomskega dela smo predstavili kratko zgodovino ogrodja ASP.NET Core, nato pa še principe delovanja funkcionalnosti in primere uporabe. V praktičnem delu diplomskega dela smo prikazali potek namestitve aplikacije, zgrajene z ogrodjem, na strežnike Apache, Nginx in IIS ter za vsakega izvajali obremenitvene teste, katerih rezultate smo na koncu primerjali in poskušali najti najhitrejšega. Prav tako smo primerjali performančnost enake aplikacije, zgrajene na predhodnem ogrodju ASP.NET MVC 5. i

6 Developement and Analysis of Solution Performances Based on ASP.NET Core Framework Key words:.net, ASP, Core, Web Applications, Cloud Computing UDK: (043.2) Abstract In our work, we got to know the principles and good practices of cloud computing, and the properties of frameworks for the development of web applications. As the main theme of this thesis, we presented a short historical overview of the ASP.NET Core framework, and then demonstrated the principles of the functionality and examples of use. In the practical part of the thesis, we demonstrated the process of installing applications which built with the latter framework on Apache, Nginx and IIS web servers. We performed performance tests and compared them trying to find the fastest one. We also compared performance of the same application built using ASP.NET MVC 5 framework. ii

7 KAZALO 1 UVOD RAZVOJ OBLAČNIH REŠITEV Oblačno računalništvo Ogrodja za razvoj spletnih aplikacij ASP.NET CORE Struktura projekta Middleware in upravljanje napak Statične datoteke in ponudniki datotek Usmerjanje Prepisovanje in preusmeritve zahtev URL Spletni vtičniki Globalizacija in lokalizacija Dnevniki Injiciranje odvisnosti Namestitvena okolja Upravljanje stanja aplikacije Strežniki Vzorec MVC v okviru ogrodja ASP.NET Core iii

8 4 ZMOGLJIVOSTI REŠITEV OGRODJA ASP.NET CORE Azure Aplikacija Windows Server 2016 in IIS Ubuntu in Nginx CentOS in Apache Apache JMeter Rezultati testiranja SKLEP LITERATURA PRILOGA iv

9 KAZALO SLIK SLIKA 1: DATOTEČNA STRUKTURA PROJEKTA SLIKA 2: STRUKTURA CEVOVODA S KOMPONENTAMI MIDDLEWARE [15] SLIKA 3: PRIMER POIMENOVANJA DATOTEK.RESX SLIKA 4: PRIMER VSEBINE DATOTEKE.RESX SLIKA 5: POVEZAVA MED NADZORNIKOM, VMESNIKOM IN PODATKI SLIKA 6: DODAJANJE SPREMENLJIVKE OKOLJA V ORODJU VISUAL STUDIO SLIKA 7: DELOVANJE OBRATNEGA POSREDNIŠKEGA STREŽNIKA IN STREŽNIKA KESTREL [38] SLIKA 8: MODUL ASP.NET CORE [39] SLIKA 9: DELOVANJE STREŽNIKA WEBLISTENER [40] SLIKA 10: POVEZAVA MED KOMPONENTAMI MVC [43] SLIKA 11: VELIKOST VIRTUALNIH NAPRAV SLIKA 12: VARNOSTNA PRAVILA VIRTUALNE NAPRAVE SLIKA 13: DODELITEV STATIČNEGA IP-NASLOVA IN IZBIRA DOMENE SLIKA 14: NAMEŠČENI NUGET PAKETKI SLIKA 15: E-R-DIAGRAM PODATKOVNE BAZE SLIKA 16: IZPIS PODATKOV UPORABNIKU SLIKA 17: DODAJANJE SPLETNE STRANI NA IIS SLIKA 18: NASTAVITVE APLIKACIJSKEGA BAZENA "NO MANAGED CODE" SLIKA 19: DODAJANJE DOVOLJENJ MAPI APLIKACIJE SLIKA 20: DODAJANJE APLIKACIJSKEGA BAZENA V PRIJAVO STREŽNIKA SQL SLIKA 21: VSEBINA DATOTEKE "HOSTS" SLIKA 22: NASTAVITVE NITI V ORODJU APACHE JMETER SLIKA 23: NASTAVITVE ZAHTEVKA V APACHE JMETER KAZALO IZVORNE KODE IZVORNA KODA 1: VSEBINA METODE MAIN IZVORNA KODA 2: VSEBINA RAZREDA STARTUP IZVORNA KODA 3: UPORABA RAZŠIRITEV "MAP", "RUN" IN "USE" IZVORNA KODA 4: DODANA KOMPONENTA ZA STATIČNE DATOTEKE IZVORNA KODA 5: PREDLOGA POTI TIPIČNE STRUKTURE APLIKACIJE MVC IZVORNA KODA 6: PRIMER IMPLEMENTACIJE ZA PREUSMERITEV IN PREPIS ZAHTEV URL IZVORNA KODA 7: PRIMER IMPLEMENTACIJE STORITEV LOKALIZACIJE v

10 IZVORNA KODA 8: UPORABA LOKALIZACIJE IZVORNA KODA 9: REGISTRACIJA STORITVE IZVORNA KODA 10: INJICIRANJE ODVISNOSTI S KONSTRUKTORJEM IZVORNA KODA 11: KONSTRUKTOR RAZREDA STARTUP IZVORNA KODA 12: NASTAVITVE GOSTITELJA KAZALO TABEL TABELA 1: REZULTATI MERITEV PRI 100 ZAPISIH TABELA 2: REZULTATI MERITEV PRI 500 ZAPISIH TABELA 3: REZULTATI MERITEV PRI 2500 ZAPISIH TABELA 4: PRIMERJAVA RAZLIK POSREDNIŠKIH STREŽNIKOV NA ENEM JEDRU TABELA 5: PRIMERJAVA RAZLIK POSREDNIŠKIH STREŽNIKOV NA DVEH JEDRIH TABELA 6: PRIMERJAVA RAZLIK STREŽNIKA KESTREL NA ENEM JEDRU TABELA 7: PRIMERJAVA RAZLIK STREŽNIKA KESTREL NA DVEH JEDRIH TABELA 8: PRIMERJAVA RAZLIK APLIKACIJ ASP.NET CORE IN MVC 5 NA ENEM JEDRU TABELA 9: PRIMERJAVA RAZLIK APLIKACIJ ASP.NET CORE IN MVC 5 NA DVEH JEDRIH KAZALO GRAFOV GRAF 1: PRIKAZ MERITEV PRI 100 ZAPISIH GRAF 2: PRIKAZ MERITEV PRI 500 ZAPISIH GRAF 3: PRIKAZ MERITEV PRI 2500 ZAPISIH KAZALO IZPISOV PRIMER IZPISA 1: POTEK PREUSMERITVE ZAHTEVE URL PRIMER IZPISA 2: POTEK PREPISOVANJA ZAHTEVE URL PRIMER IZPISA 3: VSEBINA ROKOVANJA ODJEMALCA PRIMER IZPISA 4: VSEBINA ROKOVANJA STREŽNIKA PRIMER IZPISA 5: IZBRAN JEZIK V GLAVI ZAHTEVKA IN PIŠKOTKU PRIMER IZPISA 6: VSEBINA DNEVNIŠKEGA ZAPISA vi

11 PRIMER IZPISA 7: AKTIVEN STREŽNIK SQL NA OPERACIJSKEM SISTEMU UBUNTU PRIMER IZPISA 8: USPEŠNO POGNANA STORITEV KAZALO NASTAVITVENIH DATOTEK NASTAVITVENA DATOTEKA 1: NASTAVITVE STREŽNIKA NGINX NASTAVITVENA DATOTEKA 2: NASTAVITVE STORITVE ZA STREŽNIK NGINX NASTAVITVENA DATOTEKA 3: NASTAVITVE STREŽNIKA APACHE NASTAVITVENA DATOTEKA 4: NASTAVITVE STORITEV STREŽNIKA APACHE vii

12 SEZNAM UPORABLJENIH KRATIC Angleščina Slovenščina IIS Internet Information Services Internetne informacijske storitve ASP Active Server Pages Aktivne strežniške strani MVC Model, View, Controller Model, pogled, nadzornik HTTP Hypertext Transfer Protocol Protokol za prenos nadbesedila ETL Event Trace Log Zapis sledenja dogodkov GUID Globally unique Identifier Globalno unikaten identifikator ID Identification Identifikacija URI Uniform Resource Identifier Enoten identifikator virov URL Uniform Resource Locator Enoten lokator virov API Application programming interface Vmesnik za namensko programiranje IP Internet Protocol internetni protokol HTTPS Hypertext Transfer Protocol Secure Varen protokol za prenos nadbesedila SSL Secure Sockets Layer Varen vtičniški sloj IT Information Technologies Informacijske tehnologije HTML Hypertext Markup Language Jezik za označevanje nadbesedila OS Operating System Operacijski sistem SSH Secure Shell Varni oklep SQL Structured Query Language Strukturirani povpraševalni jezik SDK Software Developement Kit Komplet za razvoj programske opreme CSS Cascading Style Sheets Prekrivni slogi DNS Domain Name System Sistem domenskih imen viii

13 1 UVOD V današnjem načinu razvoja aplikacij je zelo uveljavljen razvoj spletnih aplikacij. To je posledica vedno večjega števila mobilnih naprav, tablic in osebnih računalnikov, ki imajo različne velikosti zaslonov in različne operacijske sisteme. To predstavlja problem razvijalcem, saj je treba aplikacijo prilagajati za različne velikosti zaslonov in jo za vsak operacijski sistem posebej izdelati. Z razvojem spletnih aplikacij je ta problem delno rešen, saj do vsebine dostopamo s spletnimi brskalniki, na katerih se vsebina praviloma prikazuje enako. Težava, ki se pojavi, je, da imajo mobilne rešitve manjšo zmogljivost kot osebni računalniki, saj imajo omejene vire (slabši procesor, uporabljajo baterijo, imajo manj dinamičnega pomnilnika). Tukaj predstavlja rešitev oblačno računalništvo, ki predstavlja način delovanja računalniških sistemov tako, da imamo manj zmogljive računalniške enote, na katerih delamo, te pa so povezane na zmogljivejšo računalniško enoto, kjer se izvajajo procesi. Na manj zmogljivih napravah samo podajamo neke ukaze, ki se potem izvedejo na centralnem računalniku, ta pa vrne podatke za prikaz naši napravi, ki jih prikaže. To predstavlja manj stroškov za nakup naprav, potrebnih za uporabo določene programske opreme. Razvijalci tako najamejo oblačne storitve, kjer nameščajo, testirajo in uporabljajo spletne aplikacije. Ti oblačni sistemi so zasnovani tako, da dodeljujejo računalniške vire dinamično, ko jih potrebujemo. S tem namenom so se razvila ogrodja za razvoj spletnih aplikacij, ki so "cloudready". Z razvojem tovrstnih aplikacij dosežemo lahko prenosljivost in prilagodljivost oblačnim storitvam. Razvijalci se za uporabo neke tehnologije odločijo na podlagi več dejavnikov. Pri uporabi nove tehnologije je pomembno, da je tehnologija kompatibilna z okolji, aplikacijami, orodji, drugimi tehnologijami itd. Aplikacije je treba načrtovati dolgoročno. To pomeni, da uporabljamo standardizirane mehanizme in preverjene tehnologije. V zakup moramo vzeti, da se trendi nenehno spreminjajo. Trg se nenehno prilagaja razvoju znanosti ali povpraševanju, zato so vedno znova na voljo drugačna orodja, okolja, aplikacije, storitve 1

14 itd. To moramo pri načrtovanju aplikacij upoštevati, saj morajo biti te enostavno prilagodljive tem trendom. Aplikacije "Cloud-ready" so načrtovane z namenom, da so prenosljive in prilagodljive. Dobro načrtovane oblačne aplikacije predstavljajo manj vloženega truda za prilagajanje novim trendom, uporabo novih tehnologij, manj težav pri zamenjavi namestitvenih okolij itd. Enostavna menjava namestitvenih okolij prinaša prednosti tudi pri drugih dejavnikih, na primer kadar se odločamo za nek strežnik ali operacijski sistem na podlagi naših potreb. Če performančnost aplikacije ni tako pomembna, se preprosto odločimo za uporabo manj zmogljivega in cenejšega strežnika oziroma obratno. Kadar imamo aplikacijo nameščeno v oblaku, je ena izmed dobrih lastnosti dinamično dodeljevanje virov. Ko potrebujemo zmogljivejše naprave, se tem na preprost način dodelijo dodatni viri, ki se zaračunajo po porabi. To predstavlja rešitev, kadar so zahteve po storitvi velike samo začasno, nimamo pa denarnih sredstev za nakup dragih strežnikov. Da se pri izbiri operacijskih sistemov in strežnikov ne odločamo na slepo, moramo vedeti, kako se neka storitev ali aplikacija na njih obnese z vidika performančnosti in varnosti. Eno izmed novejših ogrodij za razvoj aplikacij "cloud-ready" je ogrodje ASP.NET Core, ki je osrednja tema tega diplomskega dela. Ogrodje je namenjeno razvoju oblačnih rešitev, spletnih aplikacij in poslovne logike na mobilnih napravah. Da ga lahko podrobneje razumemo, moramo spoznati njegove lastnosti, namen, potek razvoja rešitev in smisel. Če se odločamo za njegovo uporabo, želimo vedeti, kako se obnese v smislu performančnosti in varnosti na različnih operacijskih sistemih v kombinaciji z različnimi spletnimi strežniki. V diplomskem delu bomo temo obravnavali v treh glavnih poglavjih. Najprej bomo v drugem poglavju predstavili razvoj oblačnih rešitev. Razložili bomo, kdaj je aplikacija pripravljena za namestitev v oblak, predstavili, na kaj moramo biti pozorni pri razvoju oblačnih aplikacij skozi primere dobre prakse, in pojasnili, kakšne so lastnosti teh aplikacij. Nato bomo razložili pojem oblačno računalništvo, njegove bistvene karakteristike, modele storitev in modele namestitev. Prav tako bomo pojasnili, kaj so ogrodja za razvoj spletnih 2

15 aplikacij, katera so trenutno aktualna ogrodja, zakaj koristijo ter kakšne so njihove glavne funkcionalnosti in lastnosti. V tretjem poglavju bomo predstavili ogrodje ASP.NET Core 1.1. Najprej bomo proučili samo ogrodje, njegovo zgodovino in povod za njegov nastanek. V nadaljevanju bomo predstavili nekatere glavne funkcionalnosti in način delovanja. Razložili bomo strukturo aplikacije, njene komponente in njeno delovanje. Prav tako bomo predstavili medsebojno povezanost komponent in njihov namen. Spoznali bomo vstopno točko aplikacije in način, kako se jo konfigurira. Predstavili bomo funkcionalnosti, kot so upravljanje napak, pomen in uporaba komponent Middleware, streženje statičnih datotek, delovanje usmerjanja oziroma "Routing", pomen prepisovanja in preusmerjanja zahtev URL, spletni vtičniki, globalizacija in lokalizacija, uporaba ter pomen strežniških dnevnikov, injiciranje odvisnosti, namestitvena okolja, upravljanje stanja aplikacije, strežnik Kestrel, uporaba obratnega posredniškega strežnika in komponenta MVC. Vse te funkcionalnosti bomo predstavili teoretično, njihovo delovanje in način implementacije pa prikazali na kratkih primerih. V četrtem poglavju bomo izdelali preprosto aplikacijo z ogrodjem ASP.NET Core in na njej izvajali obremenitvene teste. Predstavili bomo zbirko oblačnih storitev Azure, saj bomo z njihovo pomočjo ustvarili virtualne naprave, na katere bomo nameščali našo aplikacijo. Aplikacija bo nameščena na operacijske sisteme Windows Server, Ubuntu Server in CentOS. Predstavili bomo celoten postopek namestitve vseh potrebnih komponent za pravilno delovanje aplikacije na teh operacijskih sistemih. Na operacijski sistem Windows Server bomo namestili spletni strežnik IIS, na Ubuntu Server strežnik Nginx, na CentOS pa strežnik Apache. Prav tako bomo predstavili delovanje izdelane aplikacije in pojasnili, kakšne scenarije želimo s to aplikacijo simulirati. Nazadnje bomo predstavili orodje, s katerim bomo izvajali obremenitvene teste, imenovano Apache JMeter. Predstavili bomo nastavitve tega orodja in pojasnili, kako smo ga uporabili. Na aplikaciji bomo izvajali obremenitvene teste, s katerimi bomo poskušali ugotoviti maksimalno prepustnost pri približno 100-odstotni obremenjenosti procesorja. Najprej 3

16 bomo izvedli teste na enojedrnem procesorju, nato pa na dvojedrnem. Količino podatkov iz podatkovne baze, ki jih bo aplikacija procesirala, bomo povečevali za petkratnik prejšnjega števila. Začeli bomo s 100 zapisi, nadaljevali s 500 in zaključili z Opazovali bomo razlike performančnosti aplikacije pri uporabi različnih operacijskih sistemov v kombinaciji z različnimi spletnimi strežniki. Primerjali bomo, ali obstaja razlika performančnosti med uporabo strežnika Kestrel in uporabo obratnega posredniškega strežnika s strežnikom Kestrel na enakem operacijskem sistemu. Ker je ogrodje ASP.NET Core kompletna prenova njegovega predhodnika ASP.NET MVC 5, bomo primerjali tudi razlike performančnosti med njima. Ker ogrodja ASP.NET MVC 5 ni mogoče poganjati na drugih operacijskih sistemih kot Windows, bodo testi in njihova primerjava omejeni na operacijski sistem Windows z uporabo spletnega strežnika IIS. Rezultati meritev bodo zapisani v tabelah, prikazani pa bodo grafično. V zaključku diplomskega dela bodo predstavljene ugotovitve meritev. Celotna koda aplikacije z dodanimi komentarji in strukturo projekta bo priložena v prilogi tega diplomskega dela. 4

17 2 RAZVOJ OBLAČNIH REŠITEV Razvoj aplikacij za oblak postaja dandanes pogosto opravilo. Aplikacija je pripravljena na oblak, kadar jo lahko učinkovito naložimo na zasebni ali javni oblak. Takšne aplikacije morajo biti zasnovane tako, da izkoriščajo prednosti oblačnih infrastruktur, ki so jim na voljo, prav tako pa sama infrastruktura aplikaciji ne sme predstavljati težav pri delovanju. Dobra praksa, ki jo upoštevamo pri razvoju takšnih aplikacij, je [1]: aplikacije ne izdelujemo za specifično topografijo. To pomeni, da mora biti aplikacija skalabilna in dinamična, kar zagotovimo z uporabo generičnih razredov, vmesnikov, funkcij in drugih elementov; datotečni sistem se spreminja. Ker se vozlišča, na katerih je aplikacija nameščena, spreminjajo, je pomembno, da ne shranjujemo podatkov na lokalni sistem samega vozlišča, saj se lahko pri izpadu vozlišča podatki izbrišejo ali pa so začasno nedostopni. Za preprečitev tega se podatki shranjujejo na oddaljeno odlagališče; izogibamo se uporabi odprtih sej v aplikacijah. Aplikacije, ki veliko uporabljajo aktivne seje, imajo težave v oblačnem okolju, ker to preprečuje njihovo skalabilnost, saj se podatki pri izpadu vozlišča lahko izgubijo. Če ne moremo v celoti izločiti uporabe odprtih sej v aplikacijah, je najboljša praksa, da jih uporabljamo v visoko razpoložljivi shrambi, ločeni od aplikacijskega strežnika; dnevnika ne zapisujemo v datotečni sistem. Ker se vozlišče lahko sesuje ali odstrani, je pomembno, da se podatki, kot so zapisi strežniškega dnevnika, prenesejo na drugo lokacijo; na podatke, kot so IP-naslovi in imena gostiteljev, se ne zanašamo. Naša aplikacija se lahko v vsakem trenutku nahaja na drugem naslovu, zato je pomembno, da se klici storitev iz same aplikacije znajo prilagajati na spremembe IP-naslovov in imena gostiteljev; v aplikaciji se ne kličejo neposredno specifični vmesniki API same infrastrukture. Tako omogočimo, da je naša aplikacija prenosljiva na drug oblak, saj se pri zamenjavi oblaka menjajo tudi poti za klice storitev. V aplikacijo zato vključujemo 5

18 samo dele kode, ki so nujno potrebni za delovanje aplikacije, kodo, ki se navezuje na specifično infrastrukturo, pa izločimo; izogibamo se uporabi nestandardiziranih in zastarelih protokolov. Težava v teh protokolih se pojavi, kadar oblačna infrastruktura privzeto ne podpira teh protokolov, za kar je potrebna dodatna konfiguracija. V primeru selitve aplikacije na drug oblak je vsakič potrebna dodatna konfiguracija aplikacije; ne zanašamo se na specifične funkcionalnosti operacijskih sistemov. Ker je prednost oblačnih aplikacij njihova prenosljivost, se ne moremo zanašati, da bo vedno nameščena na istem operacijskem sistemu. V ta namen uporabljamo storitve, ki so zgrajene na podlagi nekih standardov. Če se temu ne moremo izogniti, je primerno uporabiti kakšno knjižnico, ki zna naloge izvajati na različnih operacijskih sistemih; ročni inštalaciji aplikacije se izogibamo. Ker se oblačna okolja zelo hitro kreirajo in brišejo, je pomembno, da je pri inštalaciji aplikacije čim manj ročnega nameščanja in konfiguriranja. Da se temu izognemo, moramo ohraniti postopek inštalacije aplikacije čim krajši, za samo inštalacijo pa uporabimo različne skriptne mehanizme. Aplikacija, ki jo izdelujemo ali pa nalagamo v oblak, mora biti storitveno orientirana. To pomeni, da so funkcionalnosti aplikacije izpostavljene kot neke storitve. Pomembno je, da za uporabo teh storitev ni potrebno predhodno znanje delovanja aplikacije. Do teh storitev se mora dostopati prek poenotenega vmesnika, ki se skozi čas čim manj spreminja. Lastnosti takšnih aplikacij so [2]: naloge se v aplikaciji izvajajo asinhrono. To pomeni, da se naloge izvajajo ločeno od glavnega procesa; storitve so samozadovoljive in šibko sklopljene. To pomeni, da se storitve ne smejo zanašati na druge storitve za opravljanje neke naloge, uporabljajo pa samo tiste objekte in podatke, ki so za opravilo tiste naloge nujno potrebni. Pomembno je, da imajo te storitve standardizirano obliko vhoda in izhoda podatkov; 6

19 aplikacije so brez stanja. Takšne aplikacije v svojih storitvah ne uporabljajo podatkov s stanji. V primerih, kjer se uporabi takih podatkov ne gre izogniti, aplikacije uporabljajo predpomnjenje; storitve so idempotentne. Če kličemo neko storitev večkrat z enakimi vhodnimi parametri, mora ta vedno vrniti enak odgovor; varnost podatkov. Aplikacije temeljijo na varnih standardih in omogočajo vgrajeno varnost. Za prenos podatkov se uporabljajta protokola, kot sta SSL in HTTPS, za varen dostop do storitev se uporabljajo mehanizmi avtentikacije 1 in avtorizacije 2, za shrambo podatkov pa se uporabljajo različni kriptirni algoritmi; storitve nimajo vmesnih stanj. To pomeni, da se morajo storitve vedno obnašati na predvidljiv način. Predvidljiv način pomeni, da če kličemo neko storitev, pričakujemo odgovor, tudi če je ta odgovor napaka. 2.1 Oblačno računalništvo Oblačno računalništvo je model za omogočanje dostopa do omrežja deljenih in prilagodljivih računalniških virov (npr. omrežja, strežniki, hramba podatkov, aplikacij in storitev), ki jih je mogoče nadzorovati in upravljati z minimalnim naporom in minimalno interakcijo ponudnika storitev [3]. Podjetje Gartner definira računalništvo v oblaku kot slog računalništva, pri katerem so prilagodljive in elastične IT-rešitve dostavljene kot storitev z uporabo internetnih tehnologij [4]. Vsakdanjim uporabnikom to predstavlja preproste storitve, kot so na primer hramba podatkov (npr. Dropbox), elektronska pošta (npr. Gmail) in druge. Podjetja uporabljajo te storitve na naprednejšem nivoju. Ker se zaradi velike konkurence na trgu hitro spreminjajo potrebe samega trga, morajo konstantno prilagajati svoje storitve oziroma izdelke, ki jih ponujajo. Organizacije, ki uporabljajo IT-podporo, so tako uspešnejše na področju 1 Avtentikacija preverjanje istovetnosti identitete 2 Avtorizacija pooblastitev 7

20 zanesljivosti, uporabniške izkušnje in ugleda. Leta 2017 je predvideno, da bo 50 % celotne porabe IT-storitev potekalo zunaj IT-organizacije [5]. Model oblačnega računalništva je sestavljen iz petih bistvenih karakteristik, treh modelov storitev in štirih modelov namestitve. Bistvene karakteristike [3]: na zahtevo samopostrežne storitve: uporabniku se s to vrsto storitev enostransko omogoči dostop do storitev, kot sta strežniški čas in spletna hramba podatkov. Dostopa lahko kadarkoli, brez interakcije ponudnika storitev; širok dostop do omrežja: storitve so dostopne prek omrežja in dostopane z uporabo standardnih mehanizmov, ki promovirajo uporabo heterogenih tankih ali debelih odjemalskih okolij mobilne naprave, tablice, prenosniki in osebni računalniki; akumulacija virov: ponudnikovi računalniški viri so zbrani, da služijo več uporabnikom hkrati. Ti uporabljajo različne najemniške modele z različnimi fizičnimi in virtualnimi viri. Viri so dodeljeni in odvzeti dinamično, glede na to, koliko jih uporabnik potrebuje. Uporabnik ima le občutek, kje se ti viri nahajajo, vendar na splošno nima nadzora in informacije o točni lokaciji. Nekateri ponudniki omogočajo izbiro širše lokacije na primer država, regija in datacenter. Ti viri so na primer hramba podatkov, moč procesiranja, količina pomnilnika in hitrost omrežne povezave; elastičnost: viri se dodeljujejo in odvzemajo avtomatično, kar pomeni, da se sproti prilagajajo z zahtevami uporabnika. Uporabniku so ti viri prikazani kot neomejeni, zato so mu lahko dodeljeni kadarkoli in v poljubni količini; merjenje storitev: oblačni sistemi avtomatsko nadzorujejo in optimizirajo porabo računalniških virov z metrikami, ki so določene za posamezne storitve. Uporabnik in ponudnik imata pregled nad porabo virov, lahko pa jo tudi nadzorujeta in modificirata. Modeli storitev [3]: program kot storitev (SaaS): ta vrsta storitev ponuja uporabo aplikacij, ki so že nameščene na oblačni infrastrukturi. Te aplikacije so dostopne z različnih 8

21 odjemalcev skozi suhe odjemalce, na primer spletni brskalniki (logika se izvaja na strežniku, brskalnik prikaže rezultate), in debele odjemalce, na primer aplikacija, ki jo imamo nameščeno na napravi (logika se izvaja na napravi, prav tako na njej poteka prikaz). Uporabnik tukaj nima pregleda in nadzora nad oblačno infrastrukturo, razen manjših nastavitev; računalniško okolje kot storitev (PaaS): ta vrsta storitev uporabniku ponuja računalniško okolje, v katerega lahko namesti aplikacije, ki jih je izdelal sam ali pa kupil, pod pogojem, da so bile te aplikacije narejene s programskimi jeziki, knjižnicami, storitvami oziroma orodji, ki jih to okolje podpira. Uporabnik nima nadzora in dostopa do omrežnih nastavitev, strežniških nastavitev, operacijskega sistema ali shrambe podatkov; infrastruktura kot storitev (IaaS): ta vrsta storitev omogoča uporabniku, da upravlja procesiranje, shrambo podatkov, omrežje in ostale glavne vire. Uporabnik lahko namešča in poganja svojo programsko opremo, kot so operacijski sistemi in aplikacije. Uporabnik nima dostopa do nivoja nižje infrastrukture, ima pa nadzor nad operacijskim sistemom, shrambo podatkov in v nekaterih primerih nad omrežnimi nastavitvami na primer požarnim zidom. Modeli namestitve [3]: zasebni oblak: oblačna infrastruktura se uporablja znotraj ene same organizacije in jo lahko uporablja več poslovnih enot. Infrastruktura je lahko v lasti in nadzorovana s strani organizacije same, tretje osebe ali pa obeh hkrati. Nameščena je lahko znotraj ali zunaj poslovnih prostorov organizacije; oblak skupnosti: oblačno infrastrukturo uporablja specifična skupnost uporabnikov iz organizacij, ki imajo skupne interese na primer poslanstvo, varnostne zahteve ali politiko. Oblačna infrastruktura je lahko v lasti in nadzorovana s strani več organizacij v skupnosti, s strani tretje osebe ali pa obeh hkrati. Infrastruktura je lahko nameščena znotraj ali zunaj poslovnih prostorov organizacij; 9

22 javni oblak: oblačna infrastruktura je omogočena za uporabo širši publiki. Lahko je v lasti in pod nadzorom podjetja, akademske ali državne ustanove oziroma kombinacije le-teh. Infrastruktura je nameščena v prostorih ponudnika oblačnih storitev; hibridni oblak: oblačna infrastruktura je mešanica dveh ali več različnih infrastruktur (zasebna, skupnostna, javna). Posamezne entitete so povezane s standardizirano ali lastniško tehnologijo, ki omogoča prenosljivost podatkov in aplikacij na primer za razporeditev obremenitev med oblaki. 2.2 Ogrodja za razvoj spletnih aplikacij Ogrodje za razvoj spletnih aplikacij je tip ogrodja, ki je posebej zasnovano, da pomaga razvijalcem zgraditi spletne aplikacije. Ta ogrodja v večini primerov ponujajo podobne funkcionalnosti. Z uporabo primernega ogrodja lahko razvijalec prihrani veliko časa pri izgradnji aplikacije [6]. Nekatera izmed trenutno priljubljenih ogrodij so [7]: ASP.NET, AngularJS, Ruby on Rails, ASP.NET MVC, Django, React, Laravel, Angular, Spring, Meteor. Vsako izmed ogrodij ima različne značilnosti. Z njegovo uporabo se razvijalec izogne ponovni implementaciji enakih funkcionalnosti za dele aplikacij, ki jih izdela. Glavne funkcionalnosti, ki jih ponujajo ogrodja za razvoj spletnih aplikacij, so [6]: obstoj podatkov: glavna značilnost vseh spletnih aplikacij je shranjevanje informacij in izgradnja vsebine na podlagi shranjenih informacij. V nasprotju s 10

23 statičnimi vsebinami se te izdelujejo dinamično na podlagi obstoječih podatkov. Pri obstoju podatkov ogrodje lahko pomaga s funkcionalnostmi, kot so konsistenten API za dostop do več podatkovnih sistemov, avtomatična ali poenostavljena shramba, pridobitev podatkovnih objektov, izboljšava performančnosti, preverjanje integritete podatkov in druge; upravljanje sej in avtentikacija uporabnika: statične spletne strani večinoma ne razlikujejo med uporabniki. Dinamične spletne aplikacije v večini primerov potrebujejo uporabniške račune, med podstranmi pa prenašajo različne podatke. Nekateri spletni strežniki omogočajo osnovno obstojnost sej, vendar sta še vedno potrebni implementacija upravljanja uporabniških računov in specifična logika aplikacije. Ogrodja tako omogočajo implementirane rešitve za prijavljanje uporabnikov, registracijo in ponastavitev gesel, nekatera tudi administratorsko upravljanje uporabnikov; avtorizacija, avtentikacija: včasih je potrebno, da se strani ali pa deli strani spletne aplikacije prikazujejo samo prijavljenim uporabnikom. Ogrodja imajo to možnost, da lahko avtenticirajo uporabnika, še preden se stran sploh naloži. Ko je uporabnik avtenticiran, lahko ogrodje preverja posebna dovoljenja za tega uporabnika. Dovoljenja je mogoče upravljati na različne načine. Ogrodje večinoma omogoča dostop na podlagi dodeljevanja vlog, s katerimi razvijalec v kodi ali pa administrator določata dostop do vsebin; predpomnjenje: da je spletna aplikacija hitrejša, razvijalci pogosto predpomnijo določene vsebine, da ne rabijo biti vedno znova generirane na primer cenik. Ogrodja lahko ponujajo skupen vmesnik do diska ali baze podatkov prodpomnjenih vsebin; predloge: predloge spletnih strani pomagajo pri ločevanju poslovne in prikazne logike, kar se smatra kot dobra praksa. Ogrodje lahko omogoča enega ali več načinov uporabljanja predlog. Najpogosteje bo ogrodje ustvarilo razvijalsko definirana polja oziroma strukturo podatkov, dostopno znotraj predlog. Sistem predlog je lahko samo nekaj preprostega, kot na primer zamenjava ključne 11

24 besede, lahko pa je tudi dovolj robusten, da samodejno zgenerira obrazce iz parametrov; administratorski vmesnik: v veliko primerih dinamične spletne strani potrebujejo del, ki je specifično narejen samo za administratorje. Na tem delu se nastavljajo nastavitve strani in spreminjajo podatki. Administratorji včasih dodajajo uporabnike, upravljajo dovoljenja, spreminjajo vsebino strani, izdelujejo poročila itd. Ogrodja za razvoj spletnih aplikacij lahko pomagajo pri izdelovanju nadzornih plošč za administratorje. Z generacijo navigacijskih struktur zagotavljajo skupnim vnosnim poljem, kot je na primer datum, že vnaprej pripravljene elemente ter avtomatsko generirajo strani za urejanje in strani za prikaz seznamov nekih modelov. Ugotovili smo, da spletne aplikacije iz zahtev HTTP gradijo primerne odgovore in jih vračajo odjemalcu. Za razvijanje poslovne in prikazne logike se uporabljajo različni vzorci. Med bolj priljubljene vzorce spada vzorec MVC. Vzorec bomo obravnavali v poglavju 3 kot del komponente MVC v ogrodju ASP.NET Core. 12

25 3 ASP.NET CORE Ogrodje ASP.NET Core je celotna prenova njegovega predhodnika ASP.NET. Je odprtokodno "cross-platform" ogrodje za izgradnjo modernih aplikacij, ki temeljijo na spletu in oblačnih storitvah. Z njim je mogoče razvijati različne aplikacije, kot so spletne aplikacije, aplikacije za internet stvari in poslovni del logike za mobilne naprave. Aplikacije, ki so izdelane z ogrodjem ASP.NET Core, lahko poganjamo na ogrodju.net Core in originalnem ogrodju.net. Načrtovano je bilo z namenom, da bi zagotavljalo optimizirano ogrodje za razvoj aplikacij, ki so kasneje naložene na oblak ali pa se poganjajo na napravi. Sestoji iz modularnih komponent, ki porabljajo minimalne vire, kljub temu pa ohranijo prilagodljivost pri izdelavi rešitve. Aplikacije ASP.NET Core je mogoče poganjati ne le na operacijskem sistemu Windows, temveč tudi na drugih operacijskih sistemih, kot sta Mac in Linux [8]. Prva različica ASP.NET je bila predstavljena razvijalcem leta Ker se je v takratnem času začel množično razvijati internet, je podjetje Microsoft poskušalo ustvariti način izgradnje aplikacij, kakršnega so bili razvijalci namiznih aplikacij vajeni. Na knjižnici ASP.NET je bilo zgrajeno ogrodje ASP.NET Web Forms. Slednje deluje po principu namiznih aplikacij. Z ogrodjem so poskušali skriti kompleksnost protokola HTTP in označevalnega jezika HTML, saj je veliko razvijalcem, ki so uporabljali njihove tehnologije, bilo to takrat neznano. Aplikacije v tem ogrodju so delovale tako, da se je z modeliranjem uporabniškega vmesnika gradilo med seboj povezane komponente. Ogrodje je potem samo znalo pretvoriti te komponente v kodo HTML in povezati poslovni del logike z dogodki, ki so se zgodili na uporabniškem vmesniku. S časom so nastopile težave zaradi različnih pomanjkljajev v zasnovi ogrodja. Ena izmed težav je na primer bila, da je ogrodje imelo težavo s težo stanj pogledov. To pomeni, da se je morala za vsako spremembo prikaza na strani celotna stran ponovno naložiti, kar pomeni, da se je moralo za vsako majhno spremembo po žici prenašati veliko podatkov. Ostale težave, ki so nastale, so bile na primer težava z ohranjanjem življenjskih ciklov strani, omejen nadzor nad kodo HTML, slaba testabilnost itd. Kasneje je podjetje Microsoft na ogrodju ASP.NET razvilo novo ogrodje, imenovano 13

26 ASP.NET MVC. Ogrodje je odpravljalo težave, s katerimi se je srečevalo ogrodje ASP.NET Web Forms. Z ogrodjem so se kasneje ponovno izkazale težave, saj so pri njegovi izdelavi morali sprejeti kompromise, ker je bila knjižnica ASP.NET prvotno namenjena za ogrodje Web Forms. Kot rešitev te kompleksnosti je bilo ogrodje.net v celoti prenovljeno in je tako nastalo ogrodje.net Core. Glavna značilnost tega ogrodja je, da je zgrajeno na enak način kot ogrodje.net, vendar ne vsebuje specifičnih vmesnikov za izdelavo Windows aplikacij. Zaradi tega ogrodje.net Core omogoča razvoj aplikacij "cross-platform". ASP.NET Core MVC sedaj predstavlja del funkcionalnosti ogrodja ASP.NET Core, ponuja pa enake funkcionalnosti kot ogrodje ASP.NET MVC [9]. 3.1 Struktura projekta Preden se lotimo podrobnejše obravnave funkcionalnosti ogrodja, bomo spoznali strukturo projekta in proučili, kako so ti elementi med seboj povezani. Ob kreiranju aplikacije ASP.NET v orodju Visual Studio ta ustvari osnovno datotečno strukturo projekta, ki je prikazana na sliki 1. Slika 1: Datotečna struktura projekta Elementa "Connected Services" in "Dependencies" sta nepomembna elementa projekta, ki ju orodje Visual Studio samodejno prikaže in ju ne bomo obravnavali. Pomembni elementi so "Program", "Startup", "wwwroot" in "Properties". V mapi "Properties" se hranijo nastavitvene datoteke "JSON", ki vsebujejo podatke o nastavitvah v različnih delih aplikacije. Mapa "wwwroot" je osnovna mapa, kjer se hranijo statične datoteke, kot so knjižnice JavaScript, stili CSS, slike, dokumenti ipd. Statične datoteke in delo z njimi bomo obravnavali v podpoglavju 3.3. V razredu Program se ustvari metoda Main, ki ustvari 14

27 gostitelja, kot je prikazano z izvorno kodo 1. V vsebini metode so odstranjeni za zagon neključni elementi. public static void Main(string[] args) var host = new WebHostBuilder().UseKestrel().UseStartup<Startup>().Build(); host.run(); Izvorna koda 1: Vsebina metode Main V metodi Main zgradimo objekt razreda "WebHostBuilder", ki uporablja vzorec "Builder", da ustvari gostitelja spletne aplikacije [10]. Namen vzorca "Builder" je ločiti proces konstrukcije od njegove predstavitve tako, da ima isti proces konstrukcije več različnih predstavitev. Vzorec deluje tako, da v objektu, imenovanem direktor (v našem primeru je to metoda Main), zgradimo objekt graditelja (v našem primeru je to razred "WebHostBuilder"). Ta razred deduje od vmesnika "IWebHostBuilder". Objekt zgradimo tako, da z razširitvenimi metodami razredov pomočnikov dodamo naloge na ta objekt, naloge pa se izvajajo zaporedno. Razširitvene metode so v različnih dodatnih razredih, vsi ti razredi pa prav tako dedujejo od vmesnika "IWebHostBuilder [11]. Te metode definirajo spletni strežnik v tem primeru določimo strežnik Kestrel in razred za zagon aplikacije Startup. Metoda Build zgradi objekt IWebHost, ki je kasneje podan v metodo Run, ta pa pripravi aplikacijo, da posluša za prihajajoče zahteve HTTP. Metoda "UseStartup" specificira razred, ki se kliče ob zagonu aplikacije (v našem primeru je to razred Startup) [10]. Razred Startup je vstopna točka naše aplikacije in je obvezen. Ogrodje omogoča, da specificiramo več različnih razredov Startup, ki se kličejo glede na namestitveno okolje (razvoj, testiranje, produkcija itd.). Razred mora definirati metodo Configure, opcijsko pa tudi metodo ConfigureServices [10]. Vsebina razreda Startup in njegovi metodi so prikazani z izvorno kodo 2. 15

28 public class Startup public void ConfigureServices(IServiceCollection services) public void Configure(IApplicationBuilder app) Izvorna koda 2: Vsebina razreda Startup Ogrodje v razredu Startup z injiciranjem odvisnosti zagotavlja naslednje storitve [12]: IApplicationBuilder, ki se uporablja za izgradnjo cevi zahtev. Na voljo je v metodi Configure; IHostingEnvironment, ki priskrbi trenutno ime okolja, direktorij aplikacije, direktorij vsebine in ponudnika datotek. Na voljo je v konstruktorju in metodi Configure; ILoggerFactory, ki priskrbi mehanizme za ustvarjanje dnevnika. Na voljo je v konstruktorju in metodi Configure; IServiceCollection, ki služi kot zabojnik dodanih storitev. Implementacija metode ConfigureServices ni obvezna. Uporablja se za nastavitev storitev, ki jih v aplikaciji uporabljamo. Metoda se kliče, ko je aplikacija zagnana prvič, deklarirana pa mora biti z javnim modifikatorjem, da lahko okolje dostopa do vsebine metapodatkov. Storitve se dodajajo v zabojnik z uporabo injiciranja odvisnosti, saj ima ogrodje že vgrajenega. Injiciranje odvisnosti bomo predstavili v podpoglavju 3.9. Pomembno je, da se ta metoda kliče pred metodo Configure [13]. V metodi Configure nastavljamo, kako se aplikacija odzove na različne zahtevke http, in na splošno upravljamo cevovod zahtev. V njej se konfigurirajo komponente, imenovane Middleware. Metoda mora obvezno sprejemati parameter IApplicationBuilder. Storitvi IHostingEnvironment in ILoggerFactory pa sta opcijski. Ko storitev dodamo v zabojnik v metodi ConfigureServices, je na voljo v metodi Configure [13]. 16

29 3.2 Middleware in upravljanje napak Middleware je komponenta, ki sestavlja cev aplikacije za obdelavo zahtev in odgovorov. Vsaka komponenta izbira, ali bo poslala zahtevek v naslednjo v cevovodu, njen namen pa je, da opravi različne naloge pred in po izvajanju naslednje. Za izgradnjo teh cevovodov se uporabljajo delegati zahtev, ki upravljajo posamezne zahteve HTTP. Delegati zahtev se konfigurirajo z razširitvenimi metodami "Run", "Map" in "Use" na objektu "IApplicationBuilder", ki ga pridobimo kot parameter metode Configure. Posamezni delegat lahko specificiramo med vrsticami kot anonimno metodo ali pa ga definiramo v drugem razredu. Vsaka komponenta v cevi je odgovorna za klic naslednje metode v cevi oziroma za prekinitev verige, če je to potrebno. Pomembno je, v kakšnem vrstnem redu dodajamo te komponente zaradi performančnosti, varnosti in funkcionalnosti [14]. Komponente Middleware si lahko predstavljamo kot čebulne obročke, kjer se komponente dodajajo po plasteh v neko združeno celoto. Na sliki 2 so prikazane osnovne komponente, ki jih orodje Visual Studio samodejno ustvari pri kreiranju projekta, če uporabljamo predlogo MVC. Ti čebulni obročki delujejo tako, da zahteva vstopi z zunanje strani in nadaljuje proti sredini. Zahteva je obdelana po plasteh, pri čemer ena izmed plasti predstavlja komponento Middleware. Če komponenta uspešno procesira zahtevo ali pa se zgodi napaka, se krog prekine, odjemalcu pa se vrne odgovor. Če pride zahteva do zadnje plasti, še vedno pa ni odgovora, bo aplikacija javila napako. V prejšnjem odstavku smo omenili, da je vrstni red teh komponent pomemben zaradi funkcionalnosti, varnosti in performančnosti. Iz slike je razvidno, da je zunanji obroček upravljanje napak, za njim pa takoj identiteta. Upravljanje napak deluje tako, da "lovi" napake. Zelo je pomembno, da je ta komponenta na prvem mestu, da kakšna napaka ne uide, kar bi lahko povzročilo, da se aplikacija sesuje. Druga plast, imenovana identiteta, takoj preveri avtentikacijo in avtorizacijo, nato pa lahko nadaljnji obročki strežejo datoteke in obravnavajo zahteve [15]. 17

30 Slika 2: Struktura cevovoda s komponentami Middleware [15] Z izvorno kodo 3 je prikazana uporaba razširitev "Map", "Run" in "Use". Razširitev "Map" se uporablja za razširitev cevovoda zahtev v več vej, kar v našem primeru pomeni, da bomo na drugem naslovu URI dobili drugačen odgovor. Razširitev "Use" v našem primeru ustvari upravljavca napak, ki "lovi" napake in ga doda v cevovod s komponentami. Razširitev "Run" je vedno zadnja komponenta, ki zaključi cikel in vrača odgovor. Če na odjemalcu pride do zahteve "/veja1", se bo v tem primeru izpisalo "To je veja 1", medtem pa se bodo vse druge zahteve obravnavale kot privzeta veja, ki bo izpisala "Privzeta veja". private static void Branch(IApplicationBuilder app) app.run(async context => await context.response.writeasync("to je veja 1."); ); public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory) app.useexceptionhandler("/error"); app.map("/veja1", Branch); app.run(async (context) => await context.response.writeasync("hello World!"); ); Izvorna koda 3: Uporaba razširitev "Map", "Run" in "Use" 18

31 3.3 Statične datoteke in ponudniki datotek Da lahko dostopamo do datotek, je v ogrodju ASP.NET Core omogočena abstrakcija datotečnega sistema z uporabo ponudnikov datotek. Aplikacija ASP.NET Core uporablja ponudnike datotek, na primer, kadar z vmesnikom IHostingEnvironment dostopa do vsebine aplikacije in mape "wwwroot", uporabljamo statične datoteke, s komponento Middleware MVC dostopamo do pogledov ipd. Vmesnik IFileProvider ponuja naslednje storitve [16]: IFileInfo, ki se uporablja za dostop do podatkov datotek; IDirectoryContents, ki se uporablja za dostop do podatkov direktorija; IChangeToken, ki se uporablja za opozorila o spremembi datotek. Obstajajo trije načini implementacije vmesnika IFileProvider [16]: PhysicalFileProvider oziroma fizični ponudnik datotek omogoča dostop do nekega direktorija in njegovih otrok. Pri implementaciji omeji dostop na samo določen direktorij, tako da je dostop do datotečnega sistem zunaj njega onemogočen. Ko implementiramo to vrsto ponudnika, moramo specificirati pot direktorija, katerega vsebino bo stregel; EmbeddedFileProvider oziroma vgrajen ponudnik datotek omogoča dostop do datotek iz paketov oziroma "assemblyjev". V ogrodju ASP.NET Core so to na primer različne nastavitvene datoteke; CompositeFileProvider oziroma kompozitni ponudnik datotek združuje ostale ponudnike in zagotovi samostojen vmesnik za uporabo funkcionalnosti. Statične datoteke so viri, s katerimi razpolaga ASP.NET Core in jih dostavlja odjemalcem. Večinoma so v mapi "wwwroot". Do njih lahko dostopamo z relativno potjo same datoteke. Statične datoteke so večinoma stili CSS, koda JavaScript, slike in drugi viri. Da lahko do njih dostopamo, moramo najprej dodati komponento Middleware, ki omogoči dostop do datotek. Komponento konfiguriramo tako, da v metodi "Configure" objektu IApplicationBuilder pripnemo razširitev "UseStaticFiles", kot je prikazano z izvorno kodo 4. Če dodamo komponento brez parametrov, bo ogrodje privzeto streglo z datotekami, ki so 19

32 v mapi "wwwroot". Ta komponenta ne zagotavlja preverjanja avtorizacije ali avtentikacije. Vse datoteke, ki jih na ta način strežemo, so javno dostopne. Če želimo uporabljati avtorizacijo ali avtentikacijo, moramo našo aplikacijo skonfigurirati tako, da se do teh datotek dostopa prek kontrolerjev ali drugače [17]. public void Configure(IApplicationBuilder app) app.usestaticfiles(); Izvorna koda 4: Dodana komponenta za statične datoteke 3.4 Usmerjanje Pri razvoju programske opreme usmerjanje služi za razporejanje vhodnih zahtev primernim upravljalcem in generiranje poti URL, uporabljenih v odgovorih. Usmerjanje uporabljamo za namene, kot so [18]: optimizacija spletnih strani. Če na naši spletni strani oziroma aplikaciji uporabljamo naslove URL, ki so poimenovani logično glede na vsebino strani, nas bodo spletni iskalniki ovrednotili višje kot sicer. Prav tako je uporabniku prijaznejše brskanje po preprostih in logičnih naslovih URL; dostopanje do virov. Z usmerjanjem lahko dostopamo do statičnih datotek, kot so slike, datoteke pdf in druge, kar prek kontrolerjev. Na podlagi zahtev, ki pridejo v našo aplikacijo, se lahko odločimo, kakšno kodo bomo izvedli; iz nabora naslovov URL lahko izločimo dolge naslove in končnice datotek. Tako dosežemo krajše in bolj logične naslove URL, tudi takrat, ko v naši aplikaciji uporabljamo različne filtre. S skrivanjem končnic datotek prav tako skrijemo okolje, v katerem delamo, in tako dodatno povečamo varnost aplikacije. Predloge poti URL so definirane v aplikaciji, konfigurirane pa so takrat, ko se aplikacija zažene. Z uporabo predloge lahko iz poti URL izluščimo podatke in jih uporabimo pri obdelavi zahtev. Ko pride zahtevek v aplikacijo, ta poišče ustrezno predlogo, ki se ujema s potjo URL, prav tako pa je mogoče ta postopek obrniti in iz predloge zgenerirati pot URL, ki se uporablja na primer pri preusmeritvah. Usmerjanje se ročno konfigurira s komponento 20

33 "RouterMiddleware". Če uporabljamo komponento MVC, ki jo bomo predstavili v podpoglavju 3.13, je usmerjanje v njej že omogočeno [19]. Za primer prikaza usmerjanja bomo z izvorno kodo 5 predstavili tipično strukturo poti, ki jo uporabljajo aplikacije ASP.NET Core MVC. Ustvarjena je predloga "default". Vsebina predloge je sestavljena iz treh delov. Ti deli so kontroler, akcija in opcijska identifikacijska številka. Po tej predlogi se bo zahteva URL, ki bo vstopala v aplikacijo, primerjala, če se ujema s samo predlogo, nato pa bo usmerjena v kontroler in akcijo z enakim imenom. Predloga je zgrajena po strukturi vzorca MVC. routes.maproute( name: "default", template: "controller=home/action=index/id?"); Izvorna koda 5: Predloga poti tipične strukture aplikacije MVC Predloga se ujema z naslovi URL, kot je na primer "/Urnik/Profesorji/5". Iz zahtevka se izluščijo podatki v objekt " controller = Urnik, action = Profesorji, id = 5". Vrednosti se določijo tako, da se pot URL razdeli na segmente, nato pa se vsak segment dodeli primernemu parametru z imenom. Parametri morajo biti poimenovani, definirani pa so z zavitimi oklepaji. V našem primeru se bo zahteva preusmerila na kontroler Urnik z metodo Profesorji, kot parameter pa se bo v metodo prenesla številka Prepisovanje in preusmeritve zahtev URL Prepisovanje zahtev URL pomeni preoblikovanje zahtev na podlagi nekih vnaprej določenih pravil. To ustvari abstrakcijo med lokacijami virov in njihovimi naslovi, tako da lokacije in naslovi niso tesno povezani. Preoblikovanje zahtev URL se uporablja v naslednjih primerih [20]: pri premikanju in menjavi strežniških virov začasno ali trajno, kadar želimo zagotoviti stabilne lokatorje za te vire; pri porazdelitvi procesiranja zahtev čez več aplikacij ali pri porazdelitvi procesiranja virov po območjih ene aplikacije; 21

34 pri odstranjevanju, dodajanju ali reorganiziranju segmentov URL pri dohodnih zahtevah; pri optimiziranju javnih zahtev URL za spletne brskalnike, pri preusmerjanju nezanesljivih zahtev k zanesljivim, pri preprečevanju povezovanja slik z zunanjimi viri. Komponenta Middleware za zahteve ponuja možnosti, da zahtevo preusmerimo ali pa prepišemo. Preusmerjanje zahteve URL je opravilo odjemalca, kjer je odjemalcu podano navodilo, da je vir na drugem naslovu in mora dostopati do njega drugje. To pomeni, da postopek dostopanja do vira pri preusmeritvi sestoji iz šestih korakov. Ti koraki so [20]: 1. odjemalec zahteva vir; 2. strežnik najde vir, ki je na drugi lokaciji; 3. strežnik obvesti odjemalca, da je vir na drugi lokaciji; 4. odjemalec zahteva novi vir; 5. strežnik najde novi vir; 6. strežnik vrne vir odjemalcu. Pri prepisovanju zahteve URL, ki se izvaja na strani strežnika, skrajšamo postopek dostopa do vira na 3 korake. Ti koraki so [20]: 1. odjemalec zahteva vir; 2. strežnik najde vir, ki je na drugi lokaciji in prepiše zahtevo URL; 3. strežnik vrne vir odjemalcu. Z izvorno kodo 6 je prikazan primer implementacije za preusmeritev in prepis vira. var options = new RewriteOptions().AddRedirect("Preusmeritev/Vir1/(.*)", "Vir2/$1").AddRewrite("Prepis/Vir1/(.*)", "Vir2/$", skipremainingrules: true); app.userewriter(options); Izvorna koda 6: Primer implementacije za preusmeritev in prepis zahtev URL 22

35 V metodah "Redirect" in "Rewrite" prvi parameter predstavlja pot, do katere odjemalec dostopa, drugi parameter pa lokacijo, kjer se vir nahaja. Parameter "skipremainingrules" je pri prepisovanju obvezen, njegov namen pa je, da damo aplikaciji vedeti, ali preskoči nadaljnja pravila v primeru, da se zahteva ujema. Na primerih izpisov v nadaljevanju je prikazano dogajanje v konzolnem oknu strežnika. Na primeru izpisa 1 je prikazano, kaj strežnik naredi v primeru preusmeritve, na primeru izpisa 2 pa, kaj naredi v primeru prepisa zahtev. Primer izpisa 1: Potek preusmeritve zahteve URL Primer izpisa 2: Potek prepisovanja zahteve URL 3.6 Spletni vtičniki "WebSocket" je protokol, ki omogoča dvosmerno komunikacijo med odjemalcem, ki uporablja nezaupno kodo v nadzorovanem okolju, in oddaljenim gostiteljem, ki se je odločil za komunikacijo s to kodo. Namen tega protokola je, da zagotovi dvosmerno komunikacijo med aplikacijami in strežniki, ki se ne zanašajo na zahteve HTTP. Uporablja se pri aplikacijah, ki potrebujejo realnočasovno posodabljanje nekih podatkov. Protokol sestoji iz dveh delov: iz rokovanja in prenosa podatkov. Najprej se morata odjemalec in strežnik rokovati, da si izmenjata potrebne podatke za vzpostavitev povezave [21]. 23

36 Podatki, ki se za odprtje povezave pošljejo iz odjemalca, so prikazani na primeru izpisa 3. Prva vrstica se imenuje vrstica zahtevka oziroma "Request-Line", ki mora po standardu RFC2616 vsebovati metodo, zahteve URI, verzijo protokola, vrstica pa se zaključi z zaključnimi znaki "CRLF". S to vrstico naslovimo vtičnik, da lahko na enem IP-naslovu hkrati uporabljamo več odprtih povezav. Ostali atributi, ki so tukaj pomembni za odprtje povezave, so [22]: "Host", ki vsebuje podatke o gostitelju, da lahko odjemalec in strežnik potrdita gostitelja, ki ga uporabljata; "Connection", ki specificira nastavitve, ki so zaželene za ta tip povezave. V tem primeru je to menjava protokola; "Upgrade", ki pove strežniku, da gre za nadgraditev protokola ali za zamenjavo. V našem primeru je zahtevana zamenjava protokola za WebSocket; "Sec-WebSocket-Version", ki pove zahtevano verzijo protokola WebSocket; "Sec-WebSocket-Key", ki vsebuje ključ, ki je potreben za strežnik, da odjemalcu dokaže, da je uspešno prejel njegovo zahtevo za povezavo WebSocket; "Sec-WebSocket-Extensions", ki vsebuje podatke o uporabljenih razširitvah odjemalca. GET ws://localhost:65400/ws HTTP/1.1 Host: localhost:65400 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Accept-Encoding: gzip, deflate, br Accept-Language: en-us,en;q=0.8 Sec-WebSocket-Key: 4mPKAlJLzDZNuy1fLR8vHA== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Primer izpisa 3: Vsebina rokovanja odjemalca 24

37 Odgovor strežnika na odjemalčevo zahtevo je prikazan na primeru izpisa 4. Prva vrstica v odgovoru strežnika se imenuje statusna vrstica "Status-Line", ki vsebuje različico protokola, statusno kodo z njenim tekstom, konča pa se prav tako z znaki "CRLF". Oznaka 101 v statusni vrstici označuje uspešno rokovanje. Atributa "Connection" in "Upgrade" zaključita posodabljanje zahteve. Atribut "Sec-WebSocket-Accept" odjemalcu pove, ali bo strežnik zahtevo sprejel, vsebuje pa zgoščeno vrednost oziroma "hash" odjemalčevega ključa z istim imenom in dodanim globalnim unikatnim identifikatorjem GUID. Ti atributi so prav tako preverjeni s strani odjemalca. Če se podatki ne ujemajo s pričakovanimi, se povezava ne vzpostavi [22]. HTTP/ Switching Protocols Connection: Upgrade Date: Wed, 09 Aug :29:47 GMT Server: Kestrel Upgrade: websocket Sec-WebSocket-Accept: 1AkLEa6fjFtkz5mPmzJev10xcAQ= Primer izpisa 4: Vsebina rokovanja strežnika Ko se rokovanje uspešno zaključi, se lahko začne izmenjava podatkov. Odpre se dvosmerna povezava, kjer si lahko odjemalec in strežnik izmenjujeta podatke drug z drugim. Podatke, ki se pošiljajo po žici, imenujemo sporočila [22]. Če uporabljamo spletne vtičnike na ogrodju ASP.NET Core, potrebujemo različico 1.1. Za delo s spletnimi vtičniki obstaja bogatejša knjižnica, ki se imenuje "SignalR", vendar deluje samo na ogrodju ASP.NET. Za ASP.NET Core je ta knjižnica še v razvoju [23]. 3.7 Globalizacija in lokalizacija Globalizacija in lokalizacija sta pojma, ki pomenita prilagoditev aplikacije na neko kulturo oziroma področje. Globalizacija je po definiciji proces zasnovanja in razvijanja programske opreme, ki deluje v več kulturah in lokacijah. Sam proces vsebuje identificiranje kulture, ki mora biti podprta, zasnovanje funkcionalnosti, ki podpirajo to kulturo, in pisanje kode, ki pravilno deluje v podprtih kulturah in lokacijah. V praksi to pomeni uporabo različnih 25

38 znakov, formatiranje datuma in časa, pretvorbo med valutami in enotami, smer pisanja oziroma branja itd. Ko je naša aplikacija globalizirana, se izvede lokalizacija. Lokalizacija je proces adaptiranja aplikacije na posamezno kulturo in lokacijo. Pri procesu lokalizacije uporabniški vmesnik prevajamo in prilagajamo [24]. Za uporabo storitve lokalizacije v aplikaciji je treba definirati mapo, kjer se bodo viri nahajali. Z izvorno kodo 7 je prikazan primer implementacije dodane lokalizacije v storitve, kjer določimo, da bomo uporabljali lokalizacijo na pogledih, za pot do virov pa bomo uporabljali enako pot kot v primeru pogleda, v katerem uporabljamo lokalizacijo. Viri se bodo nahajali v mapi "Resources". Na primeru je uporabljena storitev MVC, saj ima že implementirane vse potrebne funkcionalnosti. services.addmvc().addviewlocalization( LanguageViewLocationExpanderFormat.Suffix, opts => opts.resourcespath = "Resources"; ); Izvorna koda 7: Primer implementacije storitev lokalizacije Za uporabo lokalizacije skrbi vmesnik "IStringLocalizer<T>", če delamo z razredi, oziroma "IViewLocalizer", če delamo s pogledi. Objekta z injiciranjem odvisnosti dodamo v del kode, kjer ju potrebujemo. Ta delujeta tako, da prek indeksa poiščete ključ v virih in vrneta njegovo vrednost. Da lahko ta objekta dostopata do virov, je pomembno, da so ti na pravilni lokaciji in da so pravilno poimenovani. Tukaj sta na voljo dva načina poimenovanja. Prvi način je, da datoteko poimenujemo enako kot pot datoteke, v kateri bomo vir uporabljali. Drugi način je, da je datoteka v enaki datotečni strukturi kot datoteka, v kateri jo uporabljamo. Na koncu vsakega vira je treba dodati še predpono jezika, v katerega prevajamo [25]. Na sliki 3 je prikazan primer poimenovanja virov, pri čemer sta uporabljeni predponi "sl" in "fr", saj je vir preveden v francoščino in slovenščino. Če primerjamo datoteke na sliki, se datoteka "Index.cshtml", v kateri vključimo lokalizacijo, nahaja na lokaciji 26

39 "/Views/Home/*" in datoteka "Index.sl" na lokaciji "/Resources/Views/Home/*". Datoteka "Index.fr" pa je poimenovana "Views.Home.*". Razlika pri poteh je v mapi "Resources", saj je v razredu "Startup" definirano, da so viri v tej mapi. Slika 3: Primer poimenovanja datotek.resx Viri so v datotekah ".resx", kamor dodajamo ključe in vrednosti v tabele. Ključi predstavljajo besedo/besedno zvezo/poved v privzetem jeziku aplikacije, vrednost pa prevod le-te. Na sliki 4 je prikazan primer vsebine datoteke ".resx". V našem primeru so ključi v angleščini, njihove vrednosti pa v slovenščini. Slika 4: Primer vsebine datoteke.resx Ko želimo uporabljati te vrednosti, na primer v pogledih, moramo z injiciranjem odvisnosti dodati vmesnik "IViewLocalizer" in z uporabo indeksa pridobiti te vrednosti. Z izvorno kodo 8 je prikazan primer uporabe lokalizacije in injiciranja odvisnosti. Če brskalnik zahteva stran v slovenskem jeziku, se bo v viru s prevodi poiskala vrednost "Home Page", uporabniku pa se bo izpisalo "Domača stran". Če bo brskalnik zahteval jezik, ki ga naša aplikacija ne podpira, se bo trenutna vrednost "Home Page" vzela kot privzeta [26]. 27

40 @using IViewLocalizer Localizer Page"]</h2> Izvorna koda 8: Uporaba lokalizacije Izbran jezik brskalnika se med brskalnikom in strežnikom izmenjuje v glavi zahtevka v atributu "accept-language". Za dobro prakso se izogibamo uporabi privzetega jezika brskalnika in ga pripnemo kot del vsebine piškotka. Na primeru izpisa 5 sta prikazana oba podatka, ki ju odjemalec pošlje na strežnik v glavi zahtevka. Podatek o jeziku se kasneje v aplikaciji iz piškotka izlušči in uporabi kot jezik, v katerem bo aplikacija prikazana. GET / HTTP/1.1 Host: localhost:55605 Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q =0.8 Accept-Encoding: gzip, deflate, br Accept-Language: sl,en-us;q=0.8,en;q=0.6 Cookie:.AspNetCore.Antiforgery.59S8cr2hQO0=CfDJ8D3yk02tXshHple9PArkGgBIjYsNjddzHkbb AUB0EFUuvmzSDnxJ7QkzTUFEfXEk7mD0CCHH_jcsx_StCE_rcODuCCIH7wX36NeZhbA70 ygyggn8e42jrzw9pfiyieog9jsyhr0k8e3otabdd4lfcnq;.aspnetcore.culture=c%3dsl- SI%7Cuic%3Dsl-SI Primer izpisa 5: Izbran jezik v glavi zahtevka in piškotku 3.8 Dnevniki Dnevniki so zelo kritičen in pomemben del naše aplikacije. So preprosti zapisi o obnašanju naše aplikacije, ki pomagajo pri raziskovanju napak, optimizaciji itd. Pred ogrodjem ASP.NET Core so se za delo z dnevniki uporabljale neodvisne knjižnice drugih proizvajalcev, kot so "Elmah", "Loggr", "NLog" in "Serilog". Ogrodje ASP.NET Core ima sedaj privzeto vgrajeno to funkcionalnost, prav tako pa omogoča uporabo drugih knjižnic [27]. 28

41 Za uporabo vgrajenega dnevnika se uporablja objekt ILoggerFactory, ki ga injiciranje odvisnosti dostavi v metodo Configure v razredu Startup. Zapise v dnevnikih razvrščamo po različnih nivojih, s pomočjo katerih razlikujemo med pomembnostjo posameznih zapisov. Ti nivoji so [28]: Trace ali 0. nivo. Ta nivo sporočil je namenjen razvijalcu za razhroščevanje napak. Sporočila vsebujejo občutljive podatke aplikacije in se ne uporabljajo v produkcijskih okoljih, zato so privzeto onemogočena; Debug ali 1. nivo. Ta nivo sporočil se uporablja za kratkoročne namene med razvijanjem in razhroščevanjem; Information ali 2. nivo. Ta nivo sporočil se uporablja za dogodke o glavnem delovanju aplikacije. Njihova vsebina so praviloma podatki o zahtevi odjemalca in odgovoru strežnika; Warning ali 3. nivo. Ta nivo sporočil se uporablja za nepričakovane in nenormalne dogodke v aplikaciji. Mednje spadajo napake oziroma ostali vzroki, zaradi katerih se aplikacija ne zaustavi, so pa še vseeno pomembni; Error ali 4. nivo. Ta nivo sporočil se uporablja za napake in izjeme, zaradi katerih se aplikacija zaustavi. Ta vrsta sporočila sporoča o napakah v trenutnih procesih oziroma aktivnostih in ne o splošnih napakah aplikacije. Primer trenutnega procesa je na primer procesiranje zahteve HTTP; Critical ali 5. nivo. Ta nivo sporočil se uporablja za napake, ki jih moramo nujno in takoj obravnavati. Primer teh napak je na primer uhajanje podatkov, premajhen prostor na disku itd. Sporočila lahko zapisujemo in prikazujemo na različne načine. Ogrodje ima vgrajene funkcionalnosti, ki se uporabljajo z različnimi vrstami dnevnikov. Funkcionalnosti, ki so privzeto podprte in se dodajo kot razširitvene metode na objekt ILoggerFactory, so [29]: AddConsole, ki se uporablja za zapisovanje v konzolno okno. Ta možnost ima številne probleme glede performančnosti, zato se uporablja samo za namene razvoja; 29

42 AddDebug, ki se uporablja za zapisovanje v okno razhroščevalnika. Ta možnost ima prav tako probleme s performančnostjo, zato se uporablja samo za namene razvoja; AddEventSource, ki se uporablja samo na operacijskem sistemu Windows z datotekami ETL. Za branje teh zapisov se uporabljajo knjižnice drugih proizvajalcev; AddEventLog, ki se uporablja na operacijskem sistemu Windows. Metoda zapiše vsebino sporočila kot dogodek v pregledovalnik dogodkov; AddAzureWebAppDiagnostic, ki se uporablja z diagnostiko oblačne infrastrukture Azure. Na primeru izpisa 6 je prikazan primer vsebine dnevniških zapisov, ki smo ga zapisali v tekstovno datoteko. Za zapisovanje sporočil smo uporabili knjižnico, imenovano Serilog, ki smo jo z orodjem NuGet dodali kot paketek v aplikacijo. Slednjo smo uporabili kot razširitveno metodo vmesnika ILoggerFactory v metodi Configure. Zaradi predolge dolžine zapisov smo en zapis prikazali v dveh vrsticah dve ločeni vrstici, ki jima sledi prazna vrstica, sta en zapis. Zapisi v našem primeru vsebujejo podatke o datumu, času, časovnem pasu, ID-ju zahtevka, nivoju sporočila, tipu zahteve, zahtevanem URL-ju, času za izvedbo, vrsti odgovora in druge. Viri so zahtevani na privzetem naslovu aplikacije, ki jo orodje Visual Studio zgradi samodejno ob uporabi predloge MVC. Ob zagonu aplikacije sta zahtevana vir "/api/values" in ikona "favicon.ico" [30] T14:23: :00 0HL6BFH6EBU70 [INF] Request starting HTTP/1.1 GET (e5be5b71) T14:23: :00 0HL6BFH6EBU70 [INF] Request finished in ms 404 (15c52c40) T14:23: :00 0HL6BFH6EBU71 [INF] Request starting HTTP/1.1 GET (e5be5b71) T14:23: :00 0HL6BFH6EBU71 [INF] Request finished in ms 404 (15c52c40) Primer izpisa 6: Vsebina dnevniškega zapisa 30

43 3.9 Injiciranje odvisnosti Injiciranje odvisnosti je tehnika, s katero dosežemo šibko sklopljenost med objekti in njihovimi odvisnostmi. Izogibamo se instanciranju objektov, prav tako se ne sklicujemo na konkretne implementacijske razrede, temveč zgolj na generične vmesnike. Pred ogrodjem ASP.Net Core so se za injiciranje odvisnosti uporabljale knjižnice drugih proizvajalcev. Sedaj ima ogrodje to funkcionalnost vgrajeno kot privzeto, prav tako pa omogoča razširitev in uporabo drugih knjižnic. Storitve, ki jih ogrodje dostavlja v objekte skozi njihov konstruktor ali drugače, se hranijo v zabojniku, ki ga imenujemo zabojnik injiciranja odvisnosti oziroma Dependency Injection container. Ta zabojnik predstavlja objekt IServiceCollection v razredu Startup v metodi ConfigureServices in deluje tako, da instancira te odvisnosti in upravlja njihov življenjski cikel, po potrebi pa jih dostavlja na mesto, kjer jih objekti zahtevajo [31]. Zabojnik ima tri različne možnosti upravljanja življenjskih ciklov storitev [32]: edinec oziroma Singleton, ki pomeni eno samo instanco. Kreira se samo ena instanca storitev, ki jo uporabljajo vse komponente v aplikaciji; obsežen oziroma Scoped, ki pomeni eno instanco na zahtevo. Ko pride nova zahteva v aplikacijo, se bo znotraj te zahteve uporabila enaka instanca po celi aplikaciji; prehodni oziroma Transient, ki pomeni instanciranje nove storitve vsakič, ko bo ta zahtevana. Ta življenjski cikel je najprimernejši za lahke aplikacije brez stanja. Pri registraciji storitev lahko te registriramo v medsebojni odvisnosti, zato moramo paziti, da komponenta, ki uporablja storitev druge, nima krajšega življenjskega cikla od druge. Če se tega pravila ne držimo, se lahko zgodi, da je storitev izbrisana pred drugo. Poznamo več načinov implementacije vzorca injiciranja odvisnosti [33]: injiciranje prek konstruktorja, ki je najpogostejši način implementacije. Odvisnosti so dostavljene v objekt ob instanciranju tega objekta. Storitev se uporablja znotraj celotnega razreda, zato je ta način primeren takrat, ko je pravilna funkcionalnost celotnega razreda odvisna od te storitve; 31

44 injiciranje lastnosti, ki se uporablja, kadar ima nek razred pogojne odvisnosti oziroma kadar se implementacije teh spreminjajo. Ta način injiciranja ne potrebuje dodajanja ali modifikacije konstruktorja; injiciranje v metodo, ki se uporablja, kadar želimo prenesti storitev v metodo. To storitev v tem primeru uporabljamo samo znotraj te metode. Storitve, ki jih bomo uporabljali, registriramo tako, da jih v razredu Startup pripnemo na objekt IServicesCollection, kjer navedemo objekt in odvisnost, ki jo bo ta objekt uporabljal. Z izvorno kodo 9 je prikazan primer registracije storitve. Zabojniku povemo, da želimo ustvariti novo instanco odvisnosti vsakič, ko je ta odvisnost zahtevana. To storimo z razširitveno metodo ".AddTransient", v njej pa navedemo storitev, ki jo naj instancira. Kot tipa metode sta navedena dva objekta vmesnik in implementacija vmesnika. V tem primeru sta to vmesnik ICenik in razred Cenik. Vmesnik ICenik vsebuje definicijo metod, ki jih je mogoče uporabljati, razred Cenik pa implementacijo teh metod. Tako smo zabojniku povedali, da želimo uporabljati storitev ICenik, katera implementacija je v razredu Cenik. services.addtransient<icenik, Cenik>(); Izvorna koda 9: Registracija storitve Z uporabo vmesnika in njegovo implementacijo želimo doseči šibko sklopljenost. To pomeni, da želimo doseči, da sta uporaba podatkov in odlagališče ločena z nekim vmesnim slojem. Na primer, ko bomo v nadzorniku dostopali do podatkov, želimo ločiti repozitorij in nadzornika tako, da bosta povezana dinamično. V primeru, da zamenjamo repozitorij, nadzornika ne bo treba spreminjati, saj nima neposrednega stika z repozitorijem. Z izvorno kodo 10 je prikazan primer injiciranja odvisnosti v konstruktor. Ko v konstruktorju določimo parameter, se bo ob njegovi izgradnji v zabojniku storitev poiskal objekt enakega tipa, ki bo podan kot parameter v konstruktorju. 32

45 ICenik cenik; public HomeController(ICenik cenik) this.cenik = cenik; Izvorna koda 10: Injiciranje odvisnosti s konstruktorjem Sedaj smo iz zabojnika pridobili objekt ICenik dinamično v konstruktor nadzornika Home. Tako smo dosegli, da spremembe na odlagališču ne bodo vplivale na nadzornika. Na sliki 5 je na poenostavljen način prikazana povezava med nadzornikom, vmesnikom in podatki. Nadzornik prek injiciranja odvisnosti dostopa do vmesnika, vmesnik pa s pomočjo njegove implementacije dostopa do repozitorija podatkov. Slika 5: Povezava med nadzornikom, vmesnikom in podatki 3.10 Namestitvena okolja Ogrodje ASP.NET Core ima vgrajeno podporo za delo z različnimi namestitvenimi okolji. Dodajamo jih kot spremenljivke na nivoju naprave ali pa na nivoju kode. Njihov namen je menjava različnih nastavitvenih datotek na primer pri testiranju aplikacije želimo uporabiti drugo podatkovno bazo kot v fazi produkcije. Prejšnja ogrodja so uporabljala datoteko "web.config", ki je menjala konfiguracijske datoteke med izgradnjo kode, ogrodje ASP.NET Core pa sedaj to izvrši ob zagonu aplikacije [34]. Okolja lahko poljubno dodajamo v seznam spremenljivk, pri čemer se najpogosteje uporabljajo naslednja [35]: razvojno okolje, ki se uporablja, kadar razvijamo aplikacijo. V tem okolju imamo večinoma omogočene funkcije, namenjene izključno razvoju, zato ne želimo, da so te omogočene v končnem izdelku; 33

46 okolje testiranja, ki se uporablja pred produkcijo. V tem okolju izvajamo končne teste aplikacije. Praviloma mora biti to okolje enako produkcijskemu, saj želimo ugotoviti in odpraviti napake, ne da bi to vplivalo na končne uporabnike; produkcijsko okolje, ki je končno okolje aplikacije, ko jo predamo uporabnikom. Zasnovano mora biti tako, da maksimizira varnost, performančnost in robustnost. To okolje se razlikuje od razvojnega tako, da ima vključeno predpomnjenje, uporablja minimalizirane vire, ima izključene diagnostične strani za napake itd. Kot je bilo omenjeno v prejšnjem odstavku, lahko okolja dodajamo na nivoju kode oziroma na nivoju naprave. Orodje Visual Studio omogoča, da te spremenljivke dodajamo kar znotraj orodja samega, ki samodejno doda del kode v nastavitveno datoteko "launchsettings.json". Dodajamo jih v nastavitvah projekta pod zavihkom "Debug" na mestu, ki je prikazano na sliki 6. Slika 6: Dodajanje spremenljivke okolja v orodju Visual Studio Nastavitev spremenljivke okolja v orodju Visual Studio ne pride v poštev v naslednjih primerih [34]: kadar ne uporabljamo orodja Visual Studio ali strežnika IIS Express; kadar poganjamo aplikacijo lokalno in uporabljamo celoten IIS; kadar poganjamo aplikacijo na oddaljeni napravi za testiranje ali produkcijo. V teh primerih moramo dodati spremenljivke v nastavitve naprave [34]. Kadar nastavljamo okoljske spremenljivke za celotno napravo, moramo biti pazljivi, saj bodo vsi projekti in aplikacije na napravi uporabljali to spremenljivko. 34

47 Na napravah Windows to storimo z naslednjim ukazom: "set ASPNETCORE_ENVIRONMENT=Development" v konzolnem oknu; "$Env:ASPNETCORE_ENVIRONMENT = "Development"" v oknu PowerShell. Na napravah Linux in MAC dodamo okolje z dodajanjem ukaza v datoteko ".bashrc" oziroma ".bash_profile": "export ASPNETCORE_ENVIRONMENT=Development". Pri izgradnji projekta orodje Visual Studio samodejno vključi nastavitvene datoteke glede na izbrano okolje v konstruktorju razreda Startup iz objekta IHostingEnvironment. Z izvorno kodo 11 je prikazana vsebina konstruktorja, kjer je označena vrstica kode, s katero se doda nastavitvena datoteka glede na spremenljivko okolja. Orodje izbere tisto datoteko, katere srednji del med pikama se ujema s spremenljivko okolja. public Startup(IHostingEnvironment env) var builder = new ConfigurationBuilder().SetBasePath(env.ContentRootPath).AddJsonFile("appsettings.json", optional: false, reloadonchange: true).addjsonfile($"appsettings.env.environmentname.json", optional: true).addenvironmentvariables(); Configuration = builder.build(); Izvorna koda 11: Konstruktor razreda Startup 3.11 Upravljanje stanja aplikacije Stanje aplikacije pomeni hranjenje manjših uporabniških in splošnih začasnih podatkov aplikacije. Te podatke uporabljamo znotraj aplikacije, do njih pa lahko dostopajo tudi uporabniki. Način hranjenja teh podatkov je odvisen od različnih dejavnikov, kot so velikost podatkov, oblika podatkov, persistenčnost, občutljivost itd. Ogrodje ASP.NET Core omogoča hranjenje in upravljanje teh podatkov na naslednje načine [36]: z zbirko "HTTPContext.Items", s katero shranjujemo podatke, ki so potrebni za samo trenuten zahtevek. Vsebina te zbirke je vzpostavljena in izbrisana za vsako 35

48 zahtevo posebej. Zbirka je preprost slovar, po katerem dostopamo do vrednosti z njihovimi ključi. Najprimernejša uporaba tega načina hranjenja in dostopa do podatkov je med komponentami Middleware; z uporabo piškotkov, kjer se shranjujejo majhni deli podatkov. Ti podatki se pošiljajo na strežnik v glavi vsake zahteve, zato je pomembno, da so ti podatki majhni. Praviloma piškotki vsebujejo samo unikaten identifikator, s katerim dostopamo do podatkov uporabnika, ki so shranjeni na strežniku; z uporabo sej, ki se zanašajo na uporabo unikatnega identifikatorja v piškotku. Pri uporabi sej moramo biti pazljivi glede občutljivosti podatkov, saj seja ni nujno vezana na enega uporabnika. Ta način hranjenja podatkov je primeren, kadar ni pomembna persistenčnost podatkov, podatke pa lahko kadarkoli pridobimo iz druge lokacije; z uporabo predpomnjenja, s katerim shranjujemo in beremo podatke na aplikaciji na podlagi nekih definiranih ključev. Predpomnjenje pomeni hranjenje kopije podatkov na lokaciji, do katere lahko dostopamo hitreje kot do lokacije primarnih podatkov na primer do pomnilnika strežnika dostopamo hitreje kot do njegove podatkovne baze; z naslovi URL. Kadar pošiljamo podatke na strežnik, lahko pošljemo podatke kot del samega naslova URL. Z uporabo te tehnike ni priporočeno pošiljanje občutljivih podatkov, saj se podatki nenehno izmenjujejo med strežnikom in odjemalcem. Ta način je primeren, kadar želimo poslati naslov URL, ki že vsebujejo neko stanje na primer prek socialnega omrežja Facebook želimo poslati YouTube video, ki se začne predvajati ob določenem času; z zunanjimi persistenčnimi shrambami, ki niso neposredno podprte v ogrodju ASP.NET Core. Te shrambe so na primer orodje Entity Framework, različne podatkovne baze, oblačne storitve ipd Strežniki Aplikacija ASP.NET Core je popolnoma ločena od strežniškega okolja, ki jo gosti. Ogrodje podpira gostovanje v različnih strežniških okoljih, prav tako pa je mogoče samozadostno 36

49 gostovanje z uporabo strežnikov Kestrel in WebListener. Aplikacija ASP.NET Core ne posluša zahtev neposredno, temveč se zanaša na implementacijo strežnika HTTP, ki upravlja te zahteve. Privzeti spletni gostitelj teh aplikacij je strežnik IIS Express, ki deluje kot obratni posredniški strežnik (reverse proxy) strežniku Kestrel. Obratni posredniški strežnik se izbira glede na okolje gostiteljskega strežnika [37]: če želimo namestiti aplikacijo na okolje Windows, se uporabi strežnik IIS; če nameščamo aplikacijo v okolje Linux, se uporabita Apache ali Nginx oziroma drugi primerni strežniki. Kestrel je spletni strežnik, ki je zgrajen na osnovi odprtokodne asinhrone vhodno/izhodne knjižnice libuv. Ogrodje ASP.NET Core podpira ta strežnik privzeto. Namenjen je aplikacijam, ki so nameščene v različnih okoljih. Uporaba obratnega posredniškega strežnika je potrebna samo takrat, kadar izpostavimo aplikacijo internetu, pri tem pa uporabljamo strežnik Kestrel. V primeru, da uporabljamo aplikacijo v internem omrežju, to ni potrebno. Uporaba strežnikov IIS, Apache in Nginx brez strežnika Kestrel ni mogoča, saj je ogrodje zasnovano tako, da je zagnano v ločenem procesu, ki zagotavlja konsistentnost na različnih operacijskih sistemih. Obratni posredniški strežnik sprejema zahteve HTTP iz interneta in jih posreduje strežniku Kestrel, kot je prikazano na sliki 7 [38]. Slika 7: Delovanje obratnega posredniškega strežnika in strežnika Kestrel [38] Kadar je Kestrel izpostavljen internetu, je potreben obratni posredniški strežnik zaradi varnostnih razlogov. Ker je strežnik dokaj nov, še ne vsebuje zaščite pred zlorabami. Kestrel prav tako ne podpira deljenja istih vrat v primeru, ko imamo na enem strežniku več aplikacij. Če v aplikaciji pride do napake, se strežnik sesuje in se ne zna samodejno vzpostaviti [38]. 37

50 Modul ASP.NET Core omogoča poganjanje aplikacije na strežniku IIS. Zahtevki, ki prihajajo s spleta, pridejo do strežnika prek vrat 80. Modul, ki deluje v okvirju strežnika IIS, ta zahtevek posreduje na vrata, ki jih uporablja strežnik Kestrel. Ko je zahteva v naši aplikaciji obdelana, jo Kestrel posreduje nazaj na strežnik IIS, ta pa odjemalcu vrne odgovor [39]. Modul ASP.NET Core deluje v okviru strežnika IIS, kot je prikazano na sliki 8. Slika 8: Modul ASP.NET Core [39] WebListener je spletni strežnik ogrodja ASP.NET Core, ki deluje samo v okolju Windows. Ta strežnik je alternativa strežniku Kestrel, uporablja pa se za neposredno komunikacijo s spletom brez potrebe po uporabi obratnega posredniškega strežnika, zato ima dodane nekatere funkcionalnosti, ki jih Kestrel ne podpira na primer avtentikacija Windows, deljenje vrat ipd. Zgrajen je na podlagi gonilnika "Http.Sys", ki je zrela tehnologija in že vsebuje potrebno zaščito proti napadom, robustnost in skalabilnost [40]. Strežnik WebListener zamenja Kestrel, kot je prikazano na sliki 9. Slika 9: Delovanje strežnika WebListener [40] 3.13 Vzorec MVC v okviru ogrodja ASP.NET Core Middleware MVC v ogrodju ASP.NET Core predstavlja ogrodje za izgradnjo spletnih vmesnikov za namensko programiranje in aplikacije. Komponenta MVC je znana po tem, da 38

51 je lahka, odprtokodna in enostavna za testiranje. Deluje po principu vzorca MVC, nekatere izmed funkcionalnosti, ki jih omogoča, pa so [41]: usmerjanje; izgradnja modelov, ki pretvorijo uporabniške podatke, kot so na primer spletni obrazci, v objekte, ki jih lahko nadzornik upravlja; validacija modelov, ki omogoča preverjanje vsebine podatkov na podlagi nekih pravil; injiciranje odvisnosti, ki smo jo spoznali v podpoglavju 3.9; filtri, z uporabo katerih filtriramo različne zahteve. Prijavljene uporabnike lahko od neprijavljenih na primer ločimo tako, da se za neprijavljene uporabnike metoda, ki jo kliče zahtevek, sploh ne izvede; področja, ki razdelijo aplikacijo na več logičnih delov. Kadar imamo delo z večjimi projekti, je to pomembno, saj sta potem vzdrževanje in izgradnja projekta lažja. Komponenta uporablja različne vzorce poimenovanja za povezovanje teh delov aplikacije na primer nadzornik "HomeController" uporablja poglede v mapi "Home", ki so poimenovani glede na ime njegovih metod; spletni vmesniki za namensko programiranje oziroma API-ji. To so zbirke storitev, ki prejemajo in vračajo odgovore; izboljšana testabilnost, ki je posledica injiciranja odvisnosti in uporabe različnih vmesnikov. Ogrodje prav tako vsebuje vgrajene knjižnice, s katerimi se izvajajo testi enot; "Razor View Engine", ki bere kodo C# s pogledov in jo pretvarja v kodo HTML; strogo tipizirani pogledi, s pomočjo katerih lahko nadzorniki pošljejo model v pogled, kar pa omogoča podporo pri pisanju kode; tag pomočniki, ki omogočajo, da strežniški del kode sodeluje pri izgradnji elementov HTML. Uporabljajo se na primer pri izgradnji obrazcev, spletnih povezav in pri nalaganju virov; komponente pogledov, s katerimi ločimo posamezni del logike aplikacije, nato pa jo lahko ponovno uporabljamo. Te komponente ne uporabljajo modelov, temveč 39

52 specifičen del podatkov, ki jim ga podamo. Uporabljajo se na primer pri posodabljanju posameznih delov podatkov v tabelah itd. Vzorec MVC se uporablja za izolacijo poslovne logike od uporabniškega vmesnika. V kratici MVC črka M pomeni model, ki predstavlja podatke aplikacije in pravila, ki se uporabljajo za manipulacijo teh podatkov. Črka V pomeni view oziroma pogled in predstavlja elemente uporabniškega vmesnika, kot so tekst, vnosna polja itd. Črka C oziroma controller predstavlja nadzornika, ki skrbi za povezavo med modelom in pogledom [42]. Glavne prednosti, ki jih vzorec MVC prinaša, so ponovno uporabna in razširljiva koda, ločena poslovna logika od logike uporabniškega pogleda ter lažje vzdrževanje kode [43]. Na sliki 10 je prikazana povezava med komponentami vzorca MVC. Slika 10: Povezava med komponentami MVC [43] 40

53 4 ZMOGLJIVOSTI REŠITEV OGRODJA ASP.NET CORE Do sedaj smo spoznali principe in lastnosti oblačnega računalništva ter funkcionalnosti ogrodja ASP.NET Core. Naslednji korak je, da spoznamo, kako se aplikacije, zgrajene s tem ogrodjem, obnesejo v praksi. V ta namen smo izdelali preprosto spletno aplikacijo, ki smo jo namestili na tri različne strežnike v oblačnem okolju Azure, ki ga bomo predstavili v podpoglavju 4.1. Strežniki, na katere smo nameščali in na njih poganjali aplikacijo, so strežnik IIS na operacijskem sistemu Windows Server 2016, strežnik Nginx na operacijskem sistemu Ubuntu Server in strežnik Apache na operacijskem sistemu Cloudera CentOS 7.2. Ti strežniki so bili uporabljeni kot obratni posredniški strežniki strežnika Kestrel, prav tako pa smo testirali samo strežnik Kestrel na enakih operacijskih sistemih. Vsebina in delovanje nameščene aplikacije sta prikazana v podpoglavju 4.2. Postopki namestitve aplikacije na strežnik bodo prikazani v podpoglavjih 4.3, 4.4 in 4.5. Po namestitvi aplikacije smo z orodjem Apache JMeter, ki ga bomo predstavili v podpoglavju 4.6, izvedli obremenitvene teste za vsak strežnik. Pri testiranju smo strežnikom tudi povečevali zmogljivost, tako da smo jim dodeljevali večjo količino dinamičnega pomnilnika in zmogljivejši procesor z več jedri. Z rezultati testov, ki bodo prikazani v podpoglavju 4.7, smo želeli prikazati razlike maksimalne performančnosti aplikacije na različnih operacijskih sistemih in različnih strežnikih. Za vsako kombinacijo smo poskušali izmeriti maksimalno zmogljivost pri različnem številu prebranih podatkov in maksimalni obremenitvi procesorja. 4.1 Azure Azure je rastoča zbirka integriranih oblačnih storitev, ki jih razvijalci uporabljajo za izgradnjo, namestitev in upravljanje aplikacij prek ponujenih datacentrov. Te zajemajo storitve za izvajanje procesov, analitične storitve, storitve za shranjevanje podatkov, spletne storitve ipd. Uporabniki lahko izbirajo med uporabo teh storitev, s pomočjo katerih razvijajo, nameščajo in skalirajo njihove aplikacije na javnem oblaku [44]. 41

54 Za namestitev naše aplikacije smo v nadaljevanju prikazali potrebne nastavitve, ki smo jih potrebovali za uspešno delovanje aplikacije. Ustvarili smo tri različne virtualne naprave z naslednjimi operacijskimi sistemi: Windows Server 2016 DataCenter, na katerega smo namestili strežnik IIS; Ubuntu Server 17.04, na katerega smo namestili strežnik Nginx; Cloudera CentOS 7.2, na katerega smo namestili strežnik Apache. Da bodo pogoji testiranja enakovredni, smo vse naprave namestili na datacenter "West Europe", ki je na Nizozemskem [45]. Pri kreiranju virtualnih naprav smo izbrali velikost "DS(1)_V2 Standard", katere specifikacije so prikazane na sliki 11. Serije "D" so namenjene za poganjanje aplikacij, ki zahtevajo višjo moč procesiranja in začasno zmožnost trdega diska. Zagotavljajo večje razmerje med procesorsko močjo in pomnilnikom ter uporabljajo trde diske SSD. Serije "Dv2" so nadgradnja serij "D", ki vsebujejo močnejše procesorje. Procesorji teh serij so hitrejši do 35 %. Ti procesorji so "2.4 GHz Intel Xeon E v3" z dodano Intelovo tehnologijo Intel Boost 2.0 [46]. Slika 11: Velikost virtualnih naprav Po uspešnem kreiranju virtualne naprave je treba za kasnejši dostop do spletne aplikacije iz oddaljenega računalnika odpreti dostopne točke. Nastavitve teh točk smo nastavili pod zavihkoma "Inbound security rules" in "Outbound security rules" oziroma vhodna in 42

55 izhodna varnostna pravila, ki so prikazana na sliki 12. Pravilo, imenovano "default-allowssh", je privzeto dodano pravilo, ki omogoča povezavo do naprave prek protokola SSH. Vhodnemu pravilu, imenovanemu "HTTP", smo nastavili prioriteto pravila 1010 in mu dodelili vrata 80. Pri izhodnih varnostnih pravilih smo dodali pravilo, imenovano "site", s prioriteto 100 in mu prav tako dodelili vrata 80. Ta vrata se bodo uporabljala za izmenjavo sporočil strežnika z odjemalcem na podlagi protokola HTTP. Slika 12: Varnostna pravila virtualne naprave Ko smo dodali varnostna pravila, smo še virtualni napravi dodelili statičen IP-naslov in izbrati domeno, kot je prikazano na sliki 13. To smo storili na nastavitvah naprave. IP-naslov je privzeto nastavljen kot dinamičen, zato je pomembno, če želimo uporabljati ime DNS, da ga nastavimo na statičnega. Slika 13: Dodelitev statičnega IP-naslova in izbira domene 43

56 4.2 Aplikacija Z aplikacijo, ki jo izdelujemo, želimo simulirati vsakdanji scenarij uporabe spletnih aplikacij. To pomeni iskanje po nekih podatkih iz podatkovne baze in izpis teh podatkov uporabniku. V aplikaciji, ki jo bomo namestili na strežnik, potrebujemo za pravilno delovanje NuGet paketke, ki so prikazani na sliki 14. Slika 14: Nameščeni NuGet paketki S podatkovno bazo bomo upravljali orodje Entity Framework Core. Na podlagi pristopa "Code First" smo si ustvarili podatkovno bazo iz diagrama, prikazanega na sliki 15. Slika 15: E-R-diagram podatkovne baze Glavni del poslovne logike sta metodi za vpisovanje in izpisovanje podatkov. Metoda za vpisovanje podatkov, imenovana "Napolni", je namenjena samo enkratnemu klicu, deluje pa tako, da ustvari relacije med entitetami, jih napolni z naključnimi podatki in jih vstavi v podatkovno bazo. Namen te metode je, da se izognemo prenašanju celotne podatkovne baze na strežnik. Metoda vpiše en zapis "Država", pet zapisov "Kraj" in dvajset zapisov "Naslov" v podatkovno bazo. Nizi znakov, ki so vstavljeni kot podatki, so generirani naključno izmed nabora angleških črk A Z in števil

57 Metoda za iskanje in izpis podatkov iz podatkovne baze, imenovana "Index", deluje tako, da določi naključno spremenljivko, ki ima dva znaka, nato pa primerja, če ime naslova vsebuje ta dva znaka. Če najde zapis Naslov, ki vsebuje ta dva znaka, ga shrani v seznam, zraven pa še ohrani relaciji entitet Kraj in Država. Seznam najdenih podatkov na koncu posreduje v pogled, ki jih prikaže uporabniku na zaslonu. Ko imamo podatke v podatkovni bazi, klic kontrolerja "Index" izpiše podatke uporabniku, kot je prikazano na sliki 16. Uporabniku se izpišejo še podatki o številu vseh zapisov in številu najdenih zapisov. Slika 16: Izpis podatkov uporabniku Pri izdaji aplikacije smo pri nastavitvah gostitelja naredili spremembo. Ko smo izdali aplikacijo za strežnik IIS, uporabimo nastavitve gostitelja, kot so prikazane z izvorno kodo 12. Ko smo izdali aplikacijo za strežnika Apache in Nginx, smo odstranili vrstico ".UseIISIntegration()". var host = new WebHostBuilder().UseKestrel().UseContentRoot(Directory.GetCurrentDirectory()).UseIISIntegration().UseStartup<Startup>().Build(); host.run(); Izvorna koda 12: Nastavitve gostitelja 45

58 Ko nameščamo aplikacijo na strežnike, moramo preveriti, da povezava do podatkovne baze ustreza strežniku. Povezava do podatkovne baze je v datoteki "appsettings.json" pod spremenljivko "DefaultConnection", njena vrednost pa je: "Server=localhost;Database=NasaBaza;Uid=sa;Pwd=Geslo;" za strežnika Apache ter Nginx; "Server=localhost\\SQLEXPRESS;Database=NasaBaza;Trusted_Connection=True" za strežnik IIS. 4.3 Windows Server 2016 in IIS V tem poglavju bomo predstavili namestitev aplikacije na strežnik IIS, ki deluje na operacijskem sistemu Windows Server Za pravilno delovanje aplikacije potrebujemo naslednje komponente: nameščen strežnik IIS;.NET Core Windows Server Hosting bundle; nameščen strežnik SQL Express; orodje SQL Server Management Studio. Z orodjem Server Manager smo namestili spletni strežnik IIS [47]. Najprej smo prenesli izdano različico naše aplikacije na strežnik. Nato smo v orodju IIS Manager dodali novo spletno stran v datoteko "Sites". Spletni strani smo dodelili ime "NasaAplikacija", nahajala pa se bo na lokaciji "C:\NasaAplikacija". Za ime gostitelja smo ji določili ime DNS, ki smo si ga izbrali na portalu Azure. Aplikaciji smo določili protokol HTTP na vratih 80. Vsebina nastavitev je prikazana na sliki

59 Slika 17: Dodajanje spletne strani na IIS V tem koraku je bil ustvarjen nov aplikacijski bazen. Za pravilno delovanje aplikacije smo morali prilagoditi nastavitve aplikacijskega bazena. Pod izbiro.net CLR smo izbrali nastavitev "No Managed Code", kot je prikazano na sliki 18. Slika 18: Nastavitve aplikacijskega bazena "No Managed Code" Da bo naša aplikacija lahko dostopala do lokacije, ki smo jo določili ob kreiranju spletne strani, moramo dodati dovoljenja za njen aplikacijski bazen na to mapo. V nastavitvah varnosti datoteke smo dodali novega uporabnika, imenovanega "IIS AppPool\NasaAplikacija", in mu določili popoln nadzor nad mapo. Dodajanje uporabnika je prikazano na sliki

60 Slika 19: Dodajanje dovoljenj mapi aplikacije Iz Microsoftove spletne strani smo namestili SQL Server 2016 Express Edition in orodje SQL Server Management Studio. Da lahko naša aplikacija dostopa do podatkovne baze, smo s pomočjo orodja SSMS dodali aplikacijski bazen v prijave na nivoju strežnika SQL [48]. Ustvarili smo novo prijavo v datoteki "Logins" in dodali aplikacijski bazen, kot je prikazano na sliki 20. Slika 20: Dodajanje aplikacijskega bazena v prijavo strežnika SQL Iz Microsoftove spletne strani smo namestili še ".NET Core Windows Server Hosting bundle", ki je na sistem namestil komplet "ASP.NET Core Runtime", knjižnico.net Core in modul ASP.NET Core. Če smo vse korake uspešno opravili, mora naša aplikacija sedaj pravilno delovati. Da lahko dostopamo do aplikacije z uporabo imena DNS, je treba še 48

61 povezati IP-naslov strežnika z imenom DNS. To storimo v datoteki "hosts", ki se nahaja na lokaciji "C:\Windows\System32\drivers\etc", če privzamemo, da imamo nameščen operacijski sistem na pogonu C. V datoteko smo na koncu dodali vsebino, ki je prikazana na sliki 21. Slika 21: Vsebina datoteke "hosts" 4.4 Ubuntu in Nginx V tem poglavju bomo prikazali namestitev aplikacije na strežnik Nginx, ki deluje na operacijskem sistemu Ubuntu Server Za pravilno delovanje aplikacije bomo potrebovali naslednje komponente: nameščen razvijalski paket.net Core; nameščen strežnik SQL Express; nameščen strežnik Nginx. Ko smo kreirali virtualno napravo Ubuntu Server, smo se nanjo povezali prek protokola SSH z orodjem Putty. Za prijavo smo uporabili uporabniško ime in geslo, ki smo ga določili ob kreiranju virtualne naprave. Ko se povezujemo na napravo, uporabimo IP-naslov, ki je določen na portalu Azure, in vrata 22. Na napravo smo najprej namestili knjižnico.net Core. Ustvarili smo "apt-get feed", ki gosti naše paketke. To smo storili tako, da smo v konzolnem oknu pognali naslednje ukaze [49]: sudo sh -c 'echo "deb [arch=amd64] yakkety main" > /etc/apt/sources.list.d/dotnetdev.list' sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys B02C46DF417A

62 sudo apt-get update Nazadnje smo pognali še ukaz, ki namesti razvijalski komplet.net Core SDK: sudo apt-get install dotnet-dev V naslednjem koraku smo namestili strežnik SQL. To smo storili tako, da smo najprej uvozili javno odlagališče GPG-ključev z naslednjim ukazom [50]: curl sudo apt-key add Registrirali smo repozitorij Microsoft SQL Server Ubuntu: sudo add-apt-repository "$(curl Nato smo zagnali naslednja ukaza za namestitev strežnika SQL: sudo apt-get update sudo apt-get install -y mssql-server Po uspešni namestitvi smo strežnik SQL dokončno konfigurirali, kjer smo nastavili administratorsko geslo in različico strežnika. Za različico strežnika smo izbrali različico 3 - Express. To smo storili z naslednjim ukazom: sudo /opt/mssql/bin/mssql-conf setup Z naslednjim ukazom smo preverili, ali je strežnik pravilno nameščen in aktiven: systemctl status mssql-server Status pravilno nameščenega strežnika je prikazan na primeru izpisa 7. 50

63 Primer izpisa 7: Aktiven strežnik SQL na operacijskem sistemu Ubuntu Ko smo uspešno namestili strežnik SQL in razvijalski komplet.net Core SDK, moramo najprej prenesti našo aplikacijo na napravo. Najprej smo ustvarili novo mapo, imenovano "aspnetcore", na lokaciji "/var/". To smo storili z ukazom: sudo mkdir /var/aspnetcore Da smo lahko aplikacijo prenesli v to mapo, smo ji morali nastaviti drugega lastnika. Za lastnika mape smo uporabili uporabniško ime, s katerim smo se na napravo povezali, prenos aplikacije pa smo izvedli z orodjem "FileZilla". To smo storili z naslednjim ukazom: sudo chown -R LASTNIK /var/aspnetcore V naslednjem koraku smo namestili strežnik Nginx [51]. Z naslednjima ukazoma smo ga namestili in pognali storitev: sudo apt-get install nginx sudo service nginx start V tem koraku je do strežnika Nginx že mogoče dostopati prek imena DNS. Da lahko dostopamo do naše aplikacije, moramo nastaviti Nginx tako, da bo deloval kot obratni posredniški strežnik. Z naslednjim ukazom smo odprli nastavitveno datoteko strežnika: sudo nano /etc/nginx/sites-available/default Strežnik moramo konfigurirati tako, da bo prejemal zahteve HTTP na vratih 80 in jih posredoval na vrata Da smo to dosegli, smo vso vsebino datoteke izbrisali in jo zamenjali z vsebino nastavitvene datoteke 1. 51

64 server listen 80; location / proxy_pass proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; Nastavitvena datoteka 1: Nastavitve strežnika Nginx Nato smo ustvarili storitev, ki upravlja proces Kestrel. Datoteko procesa smo ustvarili z naslednjim ukazom: sudo nano /etc/systemd/system/kestrel.service V storitvi moramo specificirati delovni direktorij in vstopno točko aplikacije. Naš delovni direktorij je mapa "/var/aspnetcore", vstopna točka aplikacije pa "NasaAplikacija.dll". Vsebina storitve je prikazana z vsebino nastavitvene datoteke 2. [Unit] Description=Nasa aplikacija! [Service] WorkingDirectory=/var/aspnetcore ExecStart=/usr/bin/dotnet /var/aspnetcore/nasaaplikacija.dll Restart=always RestartSec=10 SyslogIdentifier=dotnet-example User=ImeUporabnika [Install] WantedBy=multi-user.target Nastavitvena datoteka 2: Nastavitve storitve za strežnik Nginx 52

65 Storitev smo pognali z naslednjima ukazoma: systemctl enable kestrel.service systemctl start kestrel.service Če smo vse korake uspešno izvedli, smo storitev uspešno zagnali, naša aplikacija pa uspešno deluje. Na primeru izpisa 8 je prikazana vsebina, ki se izpiše, če je storitev aktivna. To preverimo z naslednjim ukazom: systemctl status kestrel.service Primer izpisa 8: Uspešno pognana storitev 4.5 CentOS in Apache Za nameščanje aplikacije na strežnik Apache smo uporabili operacijski sistem Cloudera CentOS 7.2. Za pravilno delovanje aplikacije potrebujemo naslednje komponente: nameščen razvijalski paket.net Core SDK, nameščen strežnik SQL Express, nameščen strežnik Apache. Po kreaciji virtualne naprave smo se nanjo povezali prek protokola SSH z orodjem Putty. Za prijavo smo uporabili uporabniško ime in geslo, ki smo ga določili ob kreiranju virtualne naprave na portalu Azure. Pri povezovanju smo uporabili IP-naslov, ki je bil dodeljen naši napravi, in vrata 22. Ko smo se uspešno povezali, smo najprej namestili razvijalski paket.net Core SDK. To smo storili z uporabo naslednjih ukazov [52]: sudo yum install libunwind libicu 53

66 curl -ssl -o dotnet.tar.gz sudo mkdir -p /opt/dotnet && sudo tar zxf dotnet.tar.gz -C /opt/dotnet sudo ln -s /opt/dotnet/dotnet /usr/local/bin Na naslednjem koraku smo namestili strežnik SQL [53]. Uporabilli smo ukaz "wget" za kopiranje repozitorija v direktorij: sudo wget -O /etc/yum.repos.d/mssql-server.repo Nato smo namestili strežnik SQL z naslednjim ukazom: sudo yum install mssql-server -y Ko smo dokončno namestili strežnik SQL, smo ga morali še konfigurirati. Kot različico strežnika smo izbrali Express različico (3), prav tako pa smo morali nastaviti administratorsko geslo. To smo storili z naslednjim ukazom: sudo /opt/mssql/bin/mssql-conf setup Če smo strežnik SQL pravilno namestili, se prikaže rezultat, ki je prikazan na primeru izpisa 7. Če je strežnik aktiven, smo preverili z naslednjim ukazom: systemctl status mssql-server Ko smo uspešno namestili strežnik SQL in razvijalski komplet.net Core SDK, moramo najprej prenesti našo aplikacijo na napravo. Najprej smo ustvarili novo mapo, imenovano "aspnetcore" na lokaciji "/var/". To smo storili z ukazom: sudo mkdir /var/aspnetcore Da smo lahko aplikacijo prenesli v to mapo, smo ji morali nastaviti drugega lastnika. Za lastnika mape smo uporabili uporabniško ime, s katerim smo se na napravo povezali, prenos aplikacije pa smo izvedli z orodjem "FileZilla". To smo storili z naslednjim ukazom: sudo chown -R LASTNIK /var/aspnetcore 54

67 Na naslednjem koraku smo namestili strežnik Apache [54]. Najprej smo z naslednjim ukazom posodobili paketke: sudo yum update -y Nato smo z naslednjim ukazom namestili strežnik Apache: sudo yum -y install httpd mod_ssl Ustvarili smo novo konfiguracijsko datoteko na lokaciji "/etc/httpd/conf.modules.d/". Datoteko "kestrel.conf" smo ustvarili z naslednjim ukazom: sudo nano /etc/httpd/conf.modules.d/kestrel.conf Namen te datoteke je, da konfiguriramo strežnik Apache kot obratni posredniški strežnik, ki posluša zahteve na vratih 80 in jih posreduje na vrata Kot vsebino ustvarjene datoteke smo uporabili vsebino nastavitvene datoteke 3. <VirtualHost *:80> ProxyPreserveHost On ProxyPass / ProxyPassReverse / ErrorLog /var/log/httpd/kestrel-error.log CustomLog /var/log/httpd/kestrel-access.log common </VirtualHost> Nastavitvena datoteka 3: Nastavitve strežnika Apache Z naslednjim ukazom preverimo, ali je sintaksa konfiguracijske datoteke pravilna: sudo service httpd configtest Če je vsebina datoteke pravilna, poženemo strežnik Apache z naslednjima ukazoma: sudo systemctl restart httpd sudo systemctl enable httpd 55

68 Ko je strežnik uspešno zagnan, moramo ustvariti novo storitev. To storimo z naslednjim ukazom: sudo nano /etc/systemd/system/kestrel.service V ustvarjeno datoteko moramo specificirati naš delovni direktorij, vstopno točko aplikacije, čas ponovnega zagona, uporabnika ipd. Vsebina je prikazana z nastavitveno datoteko 4. [Unit] Description=Nasa aplikacija! [Service] WorkingDirectory=/var/aspnetcore ExecStart=/usr/local/bin/dotnet /var/aspnetcore/nasaaplikacija.dll Restart=always RestartSec=10 SyslogIdentifier=dotnet-example User=ImeUporabnika [Install] WantedBy=multi-user.target Nastavitvena datoteka 4: Nastavitve storitev strežnika Apache Ko ustvarimo storitev, jo moramo še zagnati. V našem primeru je strežnik zahteval geslo za uporabnika "root", ki pa v tem primeru ni enako kot geslo, ki smo ga določili na portalu Azure. Da spremenimo geslo uporabnika "root", uporabimo naslednji ukaz: sudo passwd Nato storitev poženemo z naslednjima ukazoma: systemctl enable kestrel.service systemctl start kestrel.service Če smo vse pravilno namestili, je strežnik aktiven in aplikacija dostopna. Pri klicu ukaza preverimo, ali je storitev uspešno zagnana, primeru izpisa 8 pa prikazuje rezultat: systemctl status kestrel.service 56

69 4.6 Apache JMeter Apache JMeter je odprtokodno orodje za testiranje zmogljivosti in funkcionalnosti aplikacij. Uporablja se za testiranje performančnosti statičnih in dinamičnih virov dinamičnih spletnih aplikacij. Uporablja se za simuliranje težkih obremenitev strežnika, skupin strežnikov in omrežja, s simulacijo pa lahko analiziramo splošno performančnost pod različnimi obremenitvenimi pogoji. Orodje deluje na nivoju protokola, zato ne izvaja funkcij JavaScript, ne podpira stilov CSS in ne izrisuje elementov HTML [55]. Izdelali smo teste, ki so pošiljali zahtevke na strežnik, medtem pa smo merili maksimalno prepustnost na sekundo. Na sliki 22 so prikazani nastavitve časa pošiljanja zahtevkov in število uporabnikov za strežnike z enojedrnim procesorjem in 3,5 GB pomnilnika. Število uporabnikov pomeni število poslanih zahtevkov na časovno enoto v sekundah. Zahtevke smo pošiljali tako dolgo, da se je krivulja prepustnosti stabilizirala. Za strežnike z dvojedrnim procesorjem in 7 GB pomnilnika smo izbrali 100 zahtevkov na sekundo. S temi parametri so bili strežniki obremenjeni približno med 95 % in 100 %. Slika 22: Nastavitve niti v orodju Apache JMeter Poslan zahtevek je metoda "GET", ki je poslana prek protokola HTTP na ime DNS strežnika, kot je prikazano na sliki

70 Slika 23: Nastavitve zahtevka v Apache JMeter 4.7 Rezultati testiranja Z izvajanjem testov smo želeli ugotoviti, ali se aplikacija ASP.NET Core obnese različno na drugačnih strežnikih in operacijskih sistemih. Prav tako smo želeli ugotoviti, ali obstaja razlika pri uporabi strežnika Kestrel samostojno in uporabi strežnika Kestrel z obratnim posredniškim strežnikom. Izvedli smo teste tudi za predhodno ogrodje ogrodja ASP.NET Core, imenovano ASP.NET MVC 5. Teste za aplikacijo, narejeno z ogrodjem ASP.NET MVC 5, smo izvajali samo na strežniku IIS na operacijskem sistemu Windows Server, saj je ni mogoče namestiti in poganjati na drugih strežnikih. Teste smo izvajali na strežnikih Apache, Nginx in IIS na operacijskih sistemih CentOS, Ubuntu Server in Windows Server. Najprej smo izvajali teste in primerjali prepustnost za 100 zapisov v podatkovni bazi. Prepustnost predstavlja, koliko takšnih zahtevkov je strežnik zmožen opraviti v časovni enoti. Rezultati meritev so zapisani v tabeli 1 in prikazani na grafu 1. Tabela in graf vsebujeta zapise podatkov o maksimalnem številu zahtevkov na sekundo za enojedrni in dvojedrni procesor za različne strežnike. 58

71 100 zapisov 1 jedro 2 jedri CentOS - Apache, Kestrel 383,53 643,28 CentOS - Kestrel 415,03 653,90 Ubuntu - Kestrel 434,67 573,62 Ubuntu - Nginx, Kestrel 386,63 575,83 Windows - IIS MVC 5 399,68 835,18 Windows - IIS, Kestrel 451,12 868,93 Windows - Kestrel 587, ,70 Tabela 1: Rezultati meritev pri 100 zapisih Maksimalna prepustnost pri 100 zapisih 1200, ,00 800,00 600,00 400,00 200,00 0,00 CentOS - Apache, Kestrel CentOS - Kestrel Ubuntu - Kestrel Ubuntu - Nginx, Kestrel Windows - IIS MVC 5 Windows - IIS, Kestrel Windows - Kestrel 1 jedro 2 jedri Graf 1: Prikaz meritev pri 100 zapisih 59

72 Pri drugem merjenju smo povečali število podatkov podatkovne baze za petkratnik predhodnega. Rezultati meritev prepustnosti za 500 zapisov v podatkovni bazi so zapisani v tabeli 2 in prikazani na grafu zapisov 1 jedro 2 jedri CentOS - Apache, Kestrel 253,35 505,73 CentOS - Kestrel 240,48 473,92 Ubuntu - Kestrel 313,73 484,47 Ubuntu - Nginx, Kestrel 300,10 501,55 Windows - IIS MVC 5 290,18 578,08 Windows - IIS, Kestrel 311,22 594,82 Windows - Kestrel 368,03 681,65 Tabela 2: Rezultati meritev pri 500 zapisih 800,00 Maksimalna prepustnost pri 500 zapisih 700,00 600,00 500,00 400,00 300,00 200,00 100,00 0,00 CentOS - Apache, Kestrel CentOS - Kestrel Ubuntu - Kestrel Ubuntu - Nginx, Kestrel Windows - IIS MVC 5 Windows - IIS, Kestrel Windows - Kestrel 1 jedro 2 jedri Graf 2: Prikaz meritev pri 500 zapisih 60

73 Pri tretjem merjenju smo prav tako povečali število podatkov v podatkovni bazi za petkratnik predhodnjega. Rezultati meritev prepustnosti za 2500 zapisov v podatkovni bazi so zapisani v tabeli 3 in prikazani na grafu zapisov 1 jedro 2 jedri CentOS - Apache, Kestrel 108,67 234,90 CentOS - Kestrel 110,08 209,37 Ubuntu - Kestrel 129,35 239,20 Ubuntu - Nginx, Kestrel 133,98 246,50 Windows - IIS MVC 5 137,12 280,43 Windows - IIS, Kestrel 134,33 264,85 Windows - Kestrel 150,37 267,82 Tabela 3: Rezultati meritev pri 2500 zapisih 300,00 Maksimalna prepustnost pri 2500 zapisih 250,00 200,00 150,00 100,00 50,00 0,00 CentOS - Apache, Kestrel CentOS - Kestrel Ubuntu - Kestrel Ubuntu - Nginx, Kestrel Windows - IIS MVC 5 Windows - IIS, Kestrel Windows - Kestrel 1 jedro 2 jedri Graf 3: Prikaz meritev pri 2500 zapisih 61

74 Iz rezultatov meritev je razvidno, da se je aplikacija ASP.NET Core z uporabo strežnika Kestrel obnesla najbolje v 5/6 primerov. V 1/6 primerov vseh meritev se je najbolje obnesla aplikacija ASP.NET MVC 5 pri 2500 prebranih podatkih. En primer predstavljajo vse meritve, opravljene na podlagi procesorja z enakim številom jeder in enakim številom prebranih zapisov iz podatkovne baze. Iz rezultatov meritev pri uporabi posredniških strežnikov in aplikacije ASP.NET Core je razvidno, da se je najbolje obnesel strežnik IIS na operacijskem sistemu Windows v 6/6 primerov. Če primerjamo rezultate meritev na operacijskem sistemu Windows, ugotovimo, da se je v 5/6 primerov najbolje obnesla aplikacija ASP.NET Core z uporabo strežnika Kestrel, v 1/6 primerov pa aplikacija ASP.NET MVC 5. Če primerjamo rezultate meritev samo za spletni strežnik IIS, se je aplikacija aplikacija ASP.NET Core najbolje obnesla v 5/6 primerov, aplikacija ASP.NET MVC 5 pa v 1/6 primerov. V nadaljevanju bomo prikazali, kako se razlike maksimalne prepustnosti pri višanju prebranih podatkov izenačijo. Ker se je aplikacija ASP.NET Core z uporabo strežnika Kestrel oziroma z uporabo posredniškega strežnika izkazala kot večinski zmagovalec, bomo v nadaljevanju primerjali odstopanje ostalih meritev glede na slednjo. V tabeli 4 smo izračunali, kolikšno odstopanje v maksimalni prepustnosti imata strežnika Apache in Nginx glede na strežnik IIS pri uporabi aplikacije ASP.NET Core na enojedrnem procesorju. Prav tako smo prikazali maksimalno odstopanje pri 100 zapisih, 500 zapisih in 2500 zapisih. 62

75 Obratni posredniški strežnik 1 jedro 100 zapisov 500 zapisov 2500 zapisov CentOS - Apache, Kestrel -14,98 % -18,59 % -19,11 % Ubuntu - Nginx, Kestrel -14,29 % -3,57 % -0,26 % Windows - IIS, Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -14,98 % -18,59 % -19,11 % Tabela 4: Primerjava razlik posredniških strežnikov na enem jedru V tabeli 5 smo izračunali odstopanje maksimalne prepustnosti strežnikov Apache in Nginx glede na strežnik IIS na dvojedrnem procesorju. Iz zapisov maksimalnega odstopanja za vsak stolpec je razvidno, da se razlika z več zapisi zmanjšuje. Obratni posredniški strežnik 2 jedri 100 zapisov 500 zapisov 2500 zapisov CentOS - Apache, Kestrel -25,97 % -14,98 % -11,31 % Ubuntu - Nginx, Kestrel -33,73 % -15,68 % -6,93 % Windows - IIS, Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -33,73 % -15,68 % -11,31 % Tabela 5: Primerjava razlik posredniških strežnikov na dveh jedrih V tabeli 6 so prikazani izračuni odstopanj maksimalne prepustnosti aplikacije ASP.NET Core z uporabo strežnika Kestrel na različnih operacijskih sistemih na enojedrnem procesorju. Kestrel 1 jedro 100 zapisov 500 zapisov 2500 zapisov CentOS - Kestrel -29,35 % -34,66 % -26,79 % Ubuntu - Kestrel -26,01 % -14,75 % -13,98 % Windows - Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -29,35 % -34,66 % -26,79 % Tabela 6: Primerjava razlik strežnika Kestrel na enem jedru V tabeli 7 so prikazani izračuni odstopanj maksimalne prepustnosti aplikacije ASP.NET Core z uporabo strežnika Kestrel na različnih operacijskih sistemih na dvojedrnem procesorju. Iz 63

76 zapisov maksimalnega odstopanja ugotovimo, da se z večanjem števila zapisov manjšajo razlike odstopanja. Kestrel 2 jedri 100 zapisov 500 zapisov 2500 zapisov CentOS - Kestrel -39,77 % -30,48 % -21,82 % Ubuntu - Kestrel -47,17 % -28,93 % -10,69 % Windows - Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -47,17 % -30,48 % -21,82 % Tabela 7: Primerjava razlik strežnika Kestrel na dveh jedrih V tabeli 8 so prikazani izračuni odstopanj za aplikacijo ASP.NET MVC na strežniku IIS in aplikacijo ASP.NET Core na strežnikih IIS in Kestrel. Vse trije primeri so uporabljali operacijski sistem Windows in enojedrni procesor. Iz zapisov maksimalnega odstopanja je razvidno, da se razlika z večanjem števila prebranih zapisov zmanjša. Core - MVC 5 1 jedro 100 zapisov 500 zapisov 2500 zapisov Windows - IIS MVC 5-31,96 % -21,15 % -8,81 % Windows - IIS, Kestrel -23,21 % -15,44 % -10,66 % Windows - Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -31,96 % -21,15 % -10,66 % Tabela 8: Primerjava razlik aplikacij ASP.NET Core in MVC 5 na enem jedru V tabeli 9 so prikazani izračuni odstopanj za aplikaciji ASP.NET MVC in Core na operacijskem sistemu Windows z dvojedrnim procesorjem. Iz izračunov odstopanj je razvidno, da se odstopanje zmanjša z večanjem števila prebranih zapisov. V primeru, ko smo testirali aplikacijo z 2500 zapisi v podatkovni bazi, se je ogrodje ASP.NET MVC 5 obneslo bolje kot ogrodje ASP.NET Core. 64

77 Core - MVC 5 2 jedri 100 zapisov 500 zapisov 2500 zapisov Windows - IIS MVC 5-23,07 % -15,19 % 4,71 % Windows - IIS, Kestrel -19,97 % -12,74 % -1,11 % Windows - Kestrel 0,00 % 0,00 % 0,00 % Maksimalno odstopanje: -23,07 % -15,19 % 4,71 % Tabela 9: Primerjava razlik aplikacij ASP.NET Core in MVC 5 na dveh jedrih Izračuni maksimalnega odstopanja za posamezno število zapisov v podatkovni bazi v 4/6 primerov kažejo, da se z večanjem števila prebranih podatkov odstopanje zmogljivosti zmanjšuje. Iz tega lahko sklepamo, da je velikost odstopanja obratno sorazmerna s številom prebranih zapisov. Odstopanja pri 100 prebranih zapisih so največja, najmanjša pa pri 2500 zapisih. 65

78 5 SKLEP Ugotovili smo, da uporaba ogrodja za razvoj spletnih aplikacij pohitri razvoj aplikacije, poveča produktivnost in izboljša testabilnost. Zaradi velikega števila različnih naprav, tehnologij in drugih dejavnikov je primeren razvoj oblačnih storitev, saj omogoča nadgrajevanje in prilagajanje aplikacij ter hitro in učinkovito menjavo operacijskih sistemov in tehnologij. Ogrodje ASP.NET Core je novo ogrodje na tržišču, ki prinaša mnoge prednosti. Te prednosti so na primer asinhrono delovanje, sposobnost razvijanja oblačnih storitev ter lahkih in prenosljivih aplikacij. Iz opravljenih testov lahko sklepamo, da se aplikacija še vedno najbolje obnese na operacijskem sistemu Windows. Izmerjeni rezultati aplikacije kažejo, da ko se število procesiranih podatkov poveča, se posledično zmanjša število procesiranih zahtevkov in razlike njihovih odstopanj. Iz tega lahko sklepamo, da so maksimalna odstopanja aplikacije ASP.NET Core obratno sorazmerna s številom procesiranih podatkov. Najboljše rezultate je dosegel strežnik Kestrel na operacijskem sistemu Windows, vendar ga zaradi varnostnih pomanjkljivosti ni smotrno uporabljati kot samostojni strežnik, ki je izpostavljen spletu. V ta namen ga uporabljamo v kombinaciji z obratnim posredniškim strežnikom. Samostojna uporaba strežnika Kestrel na drugih operacijskih sistemih je malenkost hitrejša v primerjavi z uporabo posredniškega strežnika na enakem operacijskem sistemu, vendar prihaja tudi do odstopanj. Teoretično gledano, je hitrost z uporabo obratnega posredniškega strežnika nižja kot pri samostojni uporabi strežnika Kestrel. Aplikacija, zgrajena z ogrodjem ASP.NET Core, je v primerjavi z njegovim predhodnikom ASP.NET MVC 5 hitrejša, kadar upravlja manjše število podatkov in veliko število zahtevkov. Ko se število procesiranih podatkov poviša, se število zahtevkov približno izenači. Aplikacija, zgrajena z ogrodjem ASP.NET MVC 5, se je izkazala za hitrejšo v primerjavi z aplikacijo ASP.NET Core, kadar je iskala rezultate po podatkovni bazi z 2500 zapisi (pri uporabljenem 66

79 strežniku Kestrel). Kadar smo pri aplikaciji ASP.NET Core uporabljali posredniški strežnik IIS, se je tudi aplikacija ASP.NET MVC 5 izkazala za hitrejšo pri 2500 zapisih. Pri meritvah testiranj prihaja do odstopanj. Aplikacijo smo namestili s pomočjo oblačnih storitev Azure, zato nad fizičnimi računalniki nismo imeli neposrednega nadzora, do strežnika pa smo dostopali prek internetne povezave. Časovni razpon med vsemi izvedenimi testi je bil približno pet ur. Zaradi teh dejavnikov je mogoče, da je med samim testiranjem prišlo do izpada omrežja, napak v datacentru itd. Primerjava strežnikov Apache, Nginx ter IIS ni bila izvedena na enakem operacijskem sistemu. Če primerjamo operacijska sistema Ubuntu Server in Cloudera CentOS, sta oba zgrajena na osnovi Linuxa, vendar so tudi tukaj mogoča potencialna odstopanja v performančnosti. Pri pisanju diplomskega dela je bilo uporabljeno ogrodje ASP.NET Core različice 1.1. Če bi želeli točnejše podatke, bi morali izvajati performančne teste na lokalnem strežniku prek interne omrežne povezave. Prav tako bi lahko izvajali teste na zmogljivejših računalnikih. Primerjali bi procesorje z več jedri in opazovali pohitritev procesa pri več dodanih jedrih. Pri opazovanju pohitritve bi lahko določili delež maksimalne pohitritve po Amdahlovem zakonu. Če bi izvajali obremenitvene teste za večji razpon prebranih podatkov, bi lahko opazovali krivuljo performančnosti in določili točko izenačitve razlik odstopanj. 67

80 6 LITERATURA [1] Top 9 rules for cloud applications. [Na spletu]. Dostopno: 4_brown.html. [Dostopano: 07-jul-2017]. [2] Cloud Computing - Building Cloud Ready Applications Sogeti Labs. [Na spletu]. Dostopno: [Dostopano: 07-jul-2017]. [3] P. Mell in T. Grance, The NIST Definition of Cloud Computing Recommendations of the National Institute of Standards and Technology. [4] Cloud Computing - Gartner IT Glossary. [Na spletu]. Dostopno: [Dostopano: 03-jun-2017]. [5] Software 2020: Rearchitecting for the Digital World. [Na spletu]. Dostopno: [Dostopano: 03-jun-2017]. [6] Web application framework - DocForge. [Na spletu]. Dostopno: plication_framework. [Dostopano: 08-jun-2017]. [7] Web framework rankings HotFrameworks. [Na spletu]. Dostopno: [Dostopano: 04-jun-2017]. [8] Introduction to ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 12-jun-2017]. [9] A. FREEMAN, Pro ASP.NET Core MVC. Berkeley, CA: Apress, [10] ASP.NET Core fundamentals Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 09-jul- 2017]. [11] E. Gamma, R. Helm, R. Johnson, in J. Vlissides, Design Patterns: Elements of Reusable Software. Addison-Wesley, [12] Application Startup ASP.NET documentation. [Na spletu]. Dostopno: 68

81 available-in-startup. [Dostopano: 04-jul-2017]. [13] Understanding Startup Class In ASP.NET Core. [Na spletu]. Dostopno: [Dostopano: 05-jul-2017]. [14] ASP.NET Core Middleware Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 09-jul-2017]. [15] Error Handling in ASP.NET Core - Dusted Codes. [Na spletu]. Dostopno: [Dostopano: 28-jun-2017]. [16] File Providers in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 15-jul-2017]. [17] Working with static files in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 09-jul-2017]. [18] 5 Ways to Build Routing in ASP.NET Core - Stormpath User Identity API. [Na spletu]. Dostopno: [Dostopano: 14- jul-2017]. [19] Routing in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 09-jul-2017]. [20] URL Rewriting Middleware in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 09-jul-2017]. [21] G. Sadasivan, J. Brownlee, B. Claise, in J. Quittek, Architecture for IP flow information export. RFC Editor. [22] P. J. Leach, T. Berners-Lee, J. C. Mogul, L. Masinter, R. T. Fielding, in J. Gettys, Hypertext Transfer Protocol -- HTTP/1.1. [23] WebSockets support in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: 69

82 [Dostopano: 09-jul-2017]. [24] Overview of Globalization and Localization. [Na spletu]. Dostopno: [Dostopano: 29-jun-2017]. [25] Table of Language Culture Names, Codes, and ISO Values Method [C++]. [Na spletu]. Dostopno: [Dostopano: 09-avg-2017]. [26] Adding Localisation to an ASP.NET Core application. [Na spletu]. Dostopno: [Dostopano: 30-jun-2017]. [27] Working With Built-in Logging Framework In ASP.NET Core. [Na spletu]. Dostopno: [Dostopano: 15-jul-2017]. [28] Logging in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 15-jul-2017]. [29] Logging In ASP.net Core - Dot Net Core Tutorials. [Na spletu]. Dostopno: [Dostopano: 15-jul-2017]. [30] ASP.NET Core File Logging in one line of code. [Na spletu]. Dostopno: [Dostopano: 15-jul- 2017]. [31] Dependency Injection in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 17-jul-2017]. [32] ASP.NET Core Dependency Injection Deep Dive - Joonas W s blog. [Na spletu]. Dostopno: [Dostopano: 17-jul- 2017]. [33] Implementation of Dependency Injection Pattern in C#. [Na spletu]. Dostopno: 70

83 dependency-injection-pattern-in-csharp. [Dostopano: 17-jul-2017]. [34] Environments In ASP.net Core - Dot Net Core Tutorials. [Na spletu]. Dostopno: [Dostopano: 18-jul-2017]. [35] Working with Multiple Environments Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 18-jul-2017]. [36] Managing Application State ASP.NET documentation. [Na spletu]. Dostopno: [Dostopano: 19-jul-2017]. [37] Servers ASP.NET documentation. [Na spletu]. Dostopno: [Dostopano: 20-jul-2017]. [38] Kestrel web server implementation in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 20-jul-2017]. [39] ASP.NET Core Module Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 06-avg-2017]. [40] WebListener web server implementation in ASP.NET Core Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 20-jul-2017]. [41] Overview of ASP.NET Core MVC Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 20-jul- 2017]. [42] Simple Example of MVC (Model View Controller) Design Pattern for Abstraction CodeProject. [Na spletu]. Dostopno: View-Controller-Design. [Dostopano: 12-jun-2017]. [43] MVC Architecture - Google Chrome. [Na spletu]. Dostopno: 71

84 [Dostopano: 12-jun-2017]. [44] What is Microsoft Azure (Windows Azure)? - Definition from WhatIs.com. [Na spletu]. Dostopno: [Dostopano: 03-avg-2017]. [45] Azure Regions Microsoft Azure. [Na spletu]. Dostopno: [Dostopano: 03-avg-2017]. [46] Azure Windows VM sizes - General purpose Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 03-avg-2017]. [47] Host ASP.NET Core on Windows with IIS Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 06-avg-2017]. [48] How to add the ApplicationPoolIdentity to a SQL Server Login Eric Parvin. [Na spletu]. Dostopno: [Dostopano: 06-avg- 2017]. [49] Get Started with.net Core. [Na spletu]. Dostopno: nuxubuntu. [Dostopano: 05-avg-2017]. [50] Get started with SQL Server 2017 on Ubuntu Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 05-avg-2017]. [51] Host ASP.NET Core on Linux with Nginx Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 05-avg-2017]. [52] Get Started with.net Core. [Na spletu]. Dostopno: nuxcentos. [Dostopano: 05-avg-2017]. [53] How To Install Microsoft SQL Server On CentOS Linux. [Na spletu]. Dostopno: 72

85 [Dostopano: 05-avg-2017]. [54] Host ASP.NET Core on Linux with Apache Microsoft Docs. [Na spletu]. Dostopno: [Dostopano: 05-avg-2017]. [55] Apache JMeter - Apache JMeter TM. [Na spletu]. Dostopno: [Dostopano: 02-avg-2017]. 73

86 7 PRILOGA Pri kreiranju projekta smo uporabili prazno predlogo ASP.NET Core 1.1 brez avtentikacije. Struktura projekta, lokacija datotek, nameščeni NuGet paketki: 74