Bankovní institut vysoká škola Praha zahraničná vysoká škola Banská Bystrica

Transcription

1 Bankovní institut vysoká škola Praha zahraničná vysoká škola Banská Bystrica Katedra kvantitatívnych metód a informatiky Informačné systémy klient-server zaloţené na programovaní serverovskej strany v jazyku JAVA Bakalárska práca Rudolf Vidlička Informačné technológie Vedúci práce: doc. RNDr. Juraj Pančík, CSc. Banská Bystrica apríl 2014

2 Vyhlásenie: Vyhlasujem, ţe som bakalársku prácu vypracoval samostatne a s pouţitím uvedenej literatúry. Svojím podpisom potvrdzujem, ţe odovzdaná elektronická verzia práce je identická s jej tlačenou verziou a som oboznámený so skutočnosťou, ţe sa práca bude archivovať v kniţnici BIVŠ a ďalej bude sprístupnená tretím osobám prostredníctvom internej databázy elektronických vysokoškolských prác. V Banskej Bystrici dňa Rudolf Vidlička

3 Poďakovanie Rád by som v prvom rade poďakoval doc. RNDr. Jurajovi Pančíkovi CSc., vedúcemu mojej bakalárskej práce, za jeho cenné rady, pripomienky a názory. Osobitné poďakovanie patrí mojej ţene a deťom za ich podporu, trpezlivosť a pochopenie. Vo Vlčkovciach

4 Anotácia práce VIDLIČKA, Rudolf: Informačné systémy klient-server zaloţené na programovaní serverovskej strany v jazyku JAVA. [Bakalárska práca]. Bankovní institut vysoká škola Praha, zahraničná vysoká škola Banská Bystrica. Katedra kvantitatívnych metód a informatiky. Vedúci práce: doc. RNDr. Juraj Pančík, CSc. Rok obhajoby: Počet strán: 45. Hlavným cieľom tejto práce je opísať moderné podnikové informačné systémy zaloţené na aplikačných serveroch a overiť moţnosti a techniky práce s aplikačnými servermi na báze technológie JAVA EE. Čiastkovým cieľom je aj overenie inštalácie aplikačného servera a realizácie vybranej aplikácie JAVA EE na vybranom serveri. Kľúčové slová: Informačný systém, serverovská strana, Java EE

5 Annotation VIDLIČKA, Rudolf: Client-server based information systems with server side JAVA programming language. [Bachelor thesis]. College of Banking Prague, foreign university Banska Bystrica. Department of Quantitative Methods and Computer Science. Supervisor: doc. Dr.. Juraj Pančík, PhD. Year of defense: Number of pages: 45 The main objective of this work is to describe the modern enterprise information systems based on application servers and verify the capabilities and techniques of application servers based on Java EE technologies. Part of the objective is the installation application server and implement selected Java EE applications on this application server. Keywords: Information system, server side, Java EE

6 Obsah Úvod Vymedzenie pojmov v predmetnej oblasti Informačný systém Nadobudnutie informačného systému Fázy tvorby informačného systému Modely pre návrh informačného systému Pouţitie waterfall modelu pre návrh informačného systému Vývojové fázy softwarového produktu po dokončení Poţadované vlastnosti informačného systému Architektúra klient-server Klient Server Microsoft.NET Vlastnosti Common Language Runtime ASP.NET Java Java SE Java EE Databázový systém Dvojúrovňová architektúra Trojúrovňová architektúra klient server Analytická časť Technológia.NET a ASP.NET Webforms alebo MVC Webforms

7 2.2.2 Programovanie Webforms v ASP.NET Model view controller Java EE Common Gateway Interface Servlety Ţivotný cyklus servletu Java Server Pages Javabeans Aplikačné servery Apache Tomcat Glassfish Wildfly Jetty Prípadové štúdie Inštalácia serveru Glassfish Získanie aplikačného serveru Glassfish Základné konfigurácie serveru Glassfish Moţnosti nasadenia webovej aplikácie na Glassfish server Aplikácia ATM terminál Remote Procedural Call Implementácia servletu Štruktúra aplikácie Anvil Pripojenie do databázy Spustenie aplikácie Diskusia k dosiahnutým výsledkom Záver Zoznam pouţitej literatúry

8 Zoznam obrázkov Zoznam pouţitých tabuliek Zoznam pouţitých skratiek

9 Úvod Informačné technológie a informačné systémy sú v súčasnej modernej dobe neoddeliteľnou súčasťou tak pracovného, ako aj súkromného ţivota. Vo veľkej miere ovplyvňujú spôsob myslenia a konanie ľudí. Informačné technológie prenikli do prevaţnej väčšiny oblastí ľudskej činnosti a toto odvetvie sa ďalej dynamicky rozvíja. Podniky a organizácie sú neustále nútené vyvíjať, inovovať a dopĺňať svoje informačné systémy z dôvodu zniţovania nákladov, zvyšovania schopnosti konkurencie či produktivity a udrţanie kroku s konkurentmi. Preto je veľmi dôleţité, aby sa k vývoju a tvorbe informačných systémov pristupovalo metodicky. Zanedbanie podstatných aspektov môţe viesť k neúspešnému projektu, čo znamená premrhané peniaze a čas. Stanoveným cieľom tejto bakalárskej práce je opísať moderné informačné systémy, opísať technológiu a techniky pouţívané pri programovaní serverovskej strany v jazyku Java. Porovnať dve technológie, ktoré sú pouţívané pri tvorbe informačných systémov. Práca je rozdelená na tri základné časti. V prvej časti je analyzovaný informačný systém v teoretickej rovine. V druhej analytickej časti je realizované porovnanie medzi dvoma technológiami: Java EE a.net. Následne sú opísané najznámejšie aplikačné servery. V poslednej časti je opísaný postup inštalácie Glassfish servera a následné spustenie a prevádzka vlastnej aplikácie ATM terminálu. 9

10 1 Vymedzenie pojmov v predmetnej oblasti 1.1 Informačný systém Informačný systém je súbor ľudí, technických prostriedkov a metód, zabezpečujúcich zber, prenos, uchovanie a spracovanie dát za účelom tvorby a prezentácie informácií pre potreby pouţívateľov činných v systémoch riadenia. (MOLNÁR, 1992) Obrázok 1-1 Model informačného systému (STRNÁD, 2009 str. 26) Procedúry: sú kroky definujúce špecifické pouţitie systémových elementov alebo procedurálneho kontextu, v ktorom sa systém nachádza. Databáza: je veľká organizovaná skupina informácií sprístupňovaná softwarom, ktorý je integrálnou súčasťou systémových funkcií. Hardware: týmto pojmom definujeme fyzickú časť počítača. Jedná sa o súbor všetkých elektronických a elektrotechnických zariadení, z ktorých je samotný počítač zloţený. Hardware by sme mohli rozdeliť na vnútorný hardware a vonkajšie periférie. Software: pod týmto pojmom rozumieme programové vybavenie počítača. Jedná sa o súbor počítačových programov, postupov, údajov a príslušnej dokumentácie. Bez príslušného softwaru, by bol daný počítač nepouţiteľný. Software dovoľuje pouţívať počítač v súlade s potrebami a predstavami pouţívateľa. (PCrevue, 2007) Dokumentácia: je dôleţitý komponent IS. Slúţi na komunikáciu, kontrolu, monitoring, tvorbu a údrţbu IS. Písanie dokumentácie IS sa povaţuje za jedno z najnáročnejších aktivít tvorby IS vzhľadom na čas. (RESEARCHGATE, 2013) 10

11 Ľudia: ľudí, ktorí pracujú s IS, môţeme rozdeliť do dvoch základných skupín: 1. Koncový pouţívatelia: môţu sa tieţ nazývať klienti. Sú to ľudia, ktorí pouţívajú IS alebo informácie produkované daným systémom. Môţu to byť účtovníci, predajcovia, úradníci, zákazníci alebo manaţéri. 2. IT špecialisti: sú to ľudia, ktorí sa podieľajú na tvorbe a prevádzke daného IS. Môţu to byť systémoví analytici, dizajnéri, programátori, testeri, technici atď. (UOTECHNOLOGY, 2011) Nadobudnutie informačného systému Pre kaţdú organizáciu je zaobstaranie nového IS kľúčovou témou. V súčasnosti majú organizácie široké spektrum moţností zaobstarania nového IS. Je potrebné, aby manaţment podniku vedel analyzovať svoje poţiadavky. Po dôkladnej analýze sa musí rozhodnúť pre najvhodnejšiu alternatívu. Na výber je 8 základných variant (obrázok 2). Kaţdá z daných variant má svoje pozitíva a negatíva. Vhodnosť alternatívy je silno ovplyvnená veľkosťou a typom organizácie. Obrázok 1-2 Alternatívy získania aplikácie (BRUCKNER, 2012 str. 80) IASW (individuálny aplikačný softvér) Aplikácia je vyvinutá presne na mieru danej organizácii a presne spĺňa poţiadavky podnikových procesov. V aplikácii sa nenachádzajú ţiadne nadbytočné funkcionality. Ak si organizácia zaobstará takúto aplikáciu, môţe získať veľkú výhodu pred svojou konkurenciou. 11

12 TASW (typový aplikačný softvér) Aplikácia je vytvorená teamom špecialistov, ktorí sa zameriavajú na tvorbu softvéru pre danú oblasť (účtovníctvo, výroba automobilov). Celkové náklady na tvorbu aplikácie bývajú obvykle veľmi vysoké. Cena licencie pre daný produkt však nie je aţ taká vysoká, pretoţe sa náklady rozdelia medzi viacerých zákazníkov. Čas zavádzania je podstatne kratší ako pri IASW. Je to spôsobené tým, ţe sa inštaluje uţ hotový a vyskúšaný produkt a pri jeho inštalácii sa môţu pouţiť skúsenosti s inštaláciou v iných organizáciách. Nevýhodou je, ţe máloktorý podnik dokáţe vyuţiť celú funkcionalitu aplikácie. To znamená, ţe zaplatil aj za niečo, čo nepotrebuje. Vhodnými oblasťami, kde je lepšie uprednostniť TASW pred IASW sú napríklad účtovníctvo, kancelárske programy, riadenie dokumentov, správa miezd, grafické programy. (VORÍŠEK, 2008 s. 59) 1. Integrovaný balík Ďalší z moţných variantov obstarania nového IS je forma integrovaného balíka. V tejto forme sa celý balík zaobstará u jedného dodávateľa. Tento variant má výhodu v tom, ţe dodávateľ garantuje kompatibilitu a integritu produktu. 2. Integrované komponenty Podľa tohto variantu budú jednotlivé komponenty zakúpené alebo vyvinuté zvlášť a následne sa integrujú do jednotného celku. Nikto z dodávateľov negarantuje kompatibilitu v rámci nového IS. Výhodou tejto formy je, ţe organizácia sa môţe rozhodnúť, ktoré komponenty zakúpi od ktorého dodávateľa, pretoţe nie všetky komponenty budú vystihovať jeho poţiadavky. 3. Vlastné zdroje Tento variant obstarania IASW/TASW bol najviac rozšírený v minulom storočí. Vzhľadom na to, ţe vývoj softvéru je náročný na čas a financie, táto forma zaobstarania softvéru je na ústupe. Vyţaduje si zamestnať väčšie mnoţstvo vysoko špecializovaného personálu. Takto vyvinuté aplikácie sú ľahko škálovateľné. Pri zmene podnikových procesov je ľahké prispôsobiť aplikáciu novým poţiadavkám. 4. Outsourcing Outsourcing sa stal hlavným trendom v posledných 20 rokoch. Pri tomto variante sa zaobstaranie celého alebo len časti IS zverí externej firme. Medzi klady tohto variantu patrí: Niţšie náklady. Sprehľadnenie nákladov. 12

13 Integrácia komponentov garantovaná dodávateľom. Rýchla realizácia. Profesionálne riešenia. Zápory outsourcingu pri zaobstaraní IS: Riziko úniku citlivých informácií. Strata kontroly nad procesom. Problémy s kvalitou pri výbere neprofesionálnej spoločnosti. Riziko bankrotu spoločnosti zabezpečujúcej outsourcing. Skryté náklady Fázy tvorby informačného systému Ţivotný cyklus Projekty, v ktorých sa vytvára nový IS, alebo sa výraznou mierou inovuje uţ existujúci IS, sa realizuje v niekoľkých fázach. Fázy tvorby podľa metodiky MMDIS sú: úvodná štúdia globálna analýza a návrh detailná analýza implementácia zavádzanie/zavedenie prevádzka a údrţba vyradenie (BRUCKNER, 2012 s. 166) Modely pre návrh informačného systému Pre návrh IS môţeme pouţiť rôzne modely. Kaţdý model má svoje prednosti a nedostatky, preto sa nedá pouţiť pri návrhu IS univerzálny model. Developeri sa rozhodujú pre konkrétny model podľa konkrétnych podmienok a špecifických cieľov. Pri navrhovaní systémov môţeme pouţiť aj SDLC štandardy (Software Development Life Cycle). SDLC je proces, ktorý sa skladá zo série plánovaných aktivít, ktoré pomáhajú developerom navrhovať, vytvárať a testovať vysoko kvalitný softvér. 13

14 Model Big Bang Takýto jednoduchý model je vhodný len pre veľmi malé projekty, pri ktorých nie je podstatný termín dodania výsledného produktu. Analýza a špecifikácia fáz sa nevytvára. Je potrebné, aby boli hneď na začiatku známe všetky poţiadavky na tento mini IS. Na tvorbe projektu podľa tohto modelu sa podieľajú maximálne dvaja aţ traja developeri. (TUTORIALPOINT, 2013) Iteratívny model Základná idea tohto modelu je tvorba IS pomocou iteračných (opakujúcich) sa cyklov. V takomto modeli iteratívny proces začína jednoduchou implementáciou malého mnoţstva softvérových poţiadaviek. V ďalšom kroku sa iteratívne pridávajú nové verzie pokiaľ nie je IS kompletný a pripravený na spustenie. Špirálový model Špirálový model je veľmi obľúbený a rozšírený medzi software developermi. Tento model v sebe zlučuje idey iteratívneho a systematického vodopádového modelu. Špirálový model má štyri fázy. Softvérový projekt opakovane prechádza všetkými fázami: identifikácia, dizajn, programovanie (construct or build), analýza rizík a vyčíslenie. Waterfall (vodopádový) model Waterfall model bol prvý SDLC model, ktorý bol pouţitý na zvýšenie šancí na úspech projektu. Podľa tohto modelu sa celý projekt rozdelí na oddelené časti. Rozdelené časti sa graficky uloţia pod seba mierne zošikmené doprava. Takto graficky znázornený model vyzerá ako vodopád, podľa čoho dostal aj svoje pomenovanie. Sekvenčne rozdelené fázy logicky nasledujú po sebe. Po dokončení kaţdej časti sa pristúpi k jej hodnoteniu. Ak dokončená časť vyhovuje všetkým poţiadavkám, začne sa pracovať na časti nasledujúcej. V model V model: je známy aj pod menom verifikačný a validačný model. Tento SDLC model sa zobrazuje v diagrame v tvare veľkého V, podľa ktorého dostal aj svoje pomenovanie. V tomto vysoko organizovanom modeli po kaţdej fáze produkčného cyklu priamo nasleduje testovacia fáza. Nasledujúca fáza začne aţ po úspešnom dokončení a otestovaní predchádzajúcej časti. Kaţdá testovacia fáza obsahuje niekoľko validačných procesov ako napríklad testovanie jednotiek, integračný test, systémový test, akceptačný test. (TUTORIALPOINT, 2013) 14

15 1.1.4 Pouţitie waterfall modelu pre návrh informačného systému 1 Štúdia realizovateľnosti Úlohou tejto štúdie je zistiť, či je prakticky moţné daný projekt realizovať. Na posúdenie, či je moţné prakticky realizovať daný projekt, musia projektanti úspešne odpovedať na päť základných otázok: Technická realizovateľnosť Existujú technológie, ktoré dokáţu implementovať navrhnutý systém? Ekonomická realizovateľnosť Bude navrhovaný systém finančne efektívny? Neprevýšia náklady systému jeho benefity? Bude IS hodnotný aj v budúcnosti? Legislatívna realizovateľnosť Existujú alebo v blízkej budúcnosti môţu existovať nejaké konflikty s legislatívou? Prevádzková realizovateľnosť Sú súčasné práce a procedúry adekvátne na podporu nového systému? Časovo plánová realizovateľnosť Ako dlho sa bude systém vyvíjať? Bude systém vyvinutý v dohodnutom časovom pláne? 2 Analýza poţiadaviek Na začiatku tejto fázy je potrebné zozbieranie dostatočného mnoţstva detailov o súčasnom stave systému (ak v organizácii v súčasnosti nejaký IS jestvuje). Dáta sú zhromaţďované na pochopenie problematiky a vytvorenie primeraného riešenia. Tieto detaily je moţné získať nasledovnými spôsobmi: 1. Interview s pouţívateľmi na rôznych stupňoch, od koncových pouţívateľov aţ po senior manaţment. Analytik, ktorý vykonáva interview, musí mať vysoké komunikačné schopnosti. Je veľmi potrebné, aby analytik pouţíval metódu aktívneho počúvania. Pri aktívnom počúvaní, analytici reflektujú a sumarizujú hlavné idey a pocity hovoriaceho. Aktívni počúvajúci podporujú hovoriacich a sú nestranní. Otázky by mali byť kladené tak, aby vylákali ambiciózne odpovede. 2. Preskúmanie súčasných podnikových systémov danej organizácie môţe tieţ obsahovať cenné informácie. 3. Pozorovanie súčasných procedúr. Analytici musia stráviť čas v rôznych oddeleniach organizácie. Časové alebo podmetové štúdie môţu ukázať, kde 15

16 a ktoré procedúry môţu byť efektívnejšie alebo odhaľujú takzvané úzke hrdlo (bottlenecks). Systémoví analytici by mali opísať a zaznamenať, ako dáta a informácie prúdia v organizácii. Na opis toku informácií sa môţu pouţiť diagramy dátových tokov. Na základe získaných dát a informácií musia systémoví analytici navrhnúť, čo bude nový systém robiť (nie ako by to chcel robiť). Musia urobiť analýzu nákladov a benefitov, zváţiť moţné hardvérové konfigurácie. Na záver musia vytvoriť odporúčania. 3 Systém dizajn V tejto fáze tvorby musia systémoví analytici špecifikovať nasledovné aspekty nového systému: Hardvérové platformy aké typy počítačov, sietí, médií, serverov, vstupných a výstupných zariadení. Software programovací jazyk, databázy. Vstupy obrazové dizajny. Výstupy dokumenty, screen layout, validačné procedúry. Testovací plán spôsob a hĺbka testovania systému. Plán konverzie spôsob, akým bude nový systém implementovaný. Dokumentácia vytvorenie dokumentácie daného systému a operácií. Na základe dokumentácie bude neskôr vytvorený pouţívateľský manuál. 4 Modelovanie a testovanie V tejto fáze prebieha samotné kódovanie (programovanie) a prvotné testovanie nového systému. Súbeţne prebieha aj akvizícia nového hardvéru a následné jeho inštalácia. Inštalácia nového hardvéru moţno vyvolá nákladné preklady káblov v kanceláriách. Neodmysliteľnou súčasťou tejto fázy je aj zaškoľovanie nových pouţívateľov na nový systém. Ďalej prichádza na rad konverzia master súborov na nový systém alebo vytvorenie nových master súborov. (TEACH-IT, 2013) Testovanie nového IS sa môţe uskutočňovať v rôznych oblastiach: Testovanie programových jednotiek: pri tejto kontrole sa testujú jednotlivé programové jednotky. Na testovanie sa pouţívajú testovacie dáta. Systémové testovanie: toto testovanie skúma, či všetky programové súčasti pracujú spoločne ako bolo plánované. 16

17 Kapacitné testovanie: pri tomto testovaní sa pouţíva veľké mnoţstvo skutočných dát. Kapacitné testovanie skúma schopnosť nového systému zvládať spracovávať veľké mnoţstvo dát. 5 Konverzia Známe sú viaceré moţnosti prechodu na nový systém. Ak sa jedná o celkom nový systém, môţe sa začať pouţívať hneď po úspešne zvládnutom školení. Ak sa však v organizácii uţ nachádza nejaký starší systém, môţu sa pouţiť následné typy konverzií: Priama konverzia: pouţívatelia prestanú pouţívať starý systém jedného dňa a začnú hneď pouţívať nový systém. Takáto zmena sa spravidla uskutočňuje cez víkend alebo cez iné voľno. Paralelná konverzia: starý systém pokračuje zároveň so systémom novým niekoľko týţdňov alebo mesiacov. Fázová konverzia: pouţíva sa pri veľkých systémoch, ktoré môţu byť rozdelené do individuálnych modulov. Individuálne moduly môţu byť implementované oddelene a v rozdielnom čase. Pilotná konverzia: nový systém bude najskôr pouţitý iba časťou organizácie, napríklad iba jednou pobočkou. 6 Poimplementačné zhrnutie Po ukončení konverzie nastane čas na analýzu a zhrnutie úspechov alebo neúspechov danej fázy. Takéto zhrnutie môţe odhaliť určité nedostatky. Po identifikácii a analýze týchto nedostatkov môţe nastať poţiadavka na: Programovacie dodatky: chýbajú menej podstatné časti IS, ktoré je potrebné doprogramovať. Úprava administratívnych postupov: postupy v organizácii nie sú totoţné s postupmi v IS a je potrebné ich prepracovať. Modifikácia reportov: je potrebné modifikovať reporty. Potreba nových programov: je potrebné zakúpiť chýbajúce aplikácie. 7 Údrţba systému Perfekcionistická údrţba: pod týmto pojmom sa rozumie, ţe aj keď systém pracuje dostačujúco, je tu stále miesto na zlepšovanie. Adaptabilná údrţba: všetky systémy sa dokáţu adaptovať na prípadné zmeny v organizácii. 17

18 Korigujúca údrţba: Aj napriek tomu, ţe bol systém testovaný, môţu sa objaviť chyby. Je potrebné, aby boli všetky chyby odstránené v čo najkratšom čase. Prototyp je funkčný model informačného systému, ktorý bol vytvorený na pochopenie poţiadaviek IS. Vytváranie prototypu IS je veľmi účinný nastroj na odhaľovanie nedostatkov systému. V skorom štádiu produkcie IS môţe poukázať na nedorozumenia medzi software developermi a koncovými pouţívateľmi. Taktieţ je moţné odhaliť chýbajúce alebo duplicitné funkcie systému. Nekompletné alebo nekonzistentné uţívateľské poţiadavky musia byť odhalené. Verzia prototypu musí byť rýchlo dostupná na demonštráciu realizovateľnosti pre manaţment. Prototypová verzia môţe byť niekedy pouţitá na tréningové účely predtým ako je doručená finálna verzia. V praxi sa môţeme stretnúť s veľkým mnoţstvom prototypových verzií. 1. Pilotný prototyp: pouţíva sa na testovanie realizovateľnosti projektu. 2. Modelovací prototyp: pouţíva sa na tvorbu a pochopenie pouţívateľských poţiadaviek. 3. Throw Away prototyp: slúţi na testovanie počiatočných poţiadaviek systému, ale nikdy nie je pouţitý pre finálnu verziu produktu. 4. Evolučné prototypy: vytvárajú sa v kaţdej fáze tvorby IS. Kaţdý prototyp je bliţšie k finálnej verzii. (TEACH-IT, 2013) Vývojové fázy softwarového produktu po dokončení Úvodná fáza Je vţdy najväčšou výzvou pre producenta produktu. Táto fáza býva najnáročnejšia na financie. V tejto fáze prebiehajú prvé inštalácie produktu pre zákazníkov. O tom, či je produkt zrelí na tento krok, nerozhoduje vývojové oddelenie, ale marketingové oddelenie. Zákazníci, ktorí si vybrali produkt v tomto štádiu čelia veľkému riziku. Môţe nastať situácia, keď sa produkt neosvedčí, alebo sa z rôznych príčin neudrţí na trhu dostatočne dlho, aby dosiahol ďalšie fázy vývoja. Panuje tieţ obava, ţe produkt uţ nebude podporovaný v budúcnosti. Na druhej strane, ak sa organizácia rozhodne pre tento konkrétny produkt v tejto fáze, môţe získať veľkú konkurenčnú výhodu. Aj producent projektu čelí veľkému riziku. Môţe panovať obava, či sa mu finančné prostriedky vloţené do vývoja a marketingu vrátia. (VORÍŠEK, 2008 str. 64) 18

19 Fáza rastu V tejto fáze prechádza produkt ďalším vývojom. Tento vývoj by sme mohli rozdeliť do dvoch skupín. Do prvej skupiny patrí rozširovanie, začleňovanie nových prvkov a zväčšovanie počtu technologických platforiem, na ktorých produkt bude pracovať, alebo ide o pridávanie nových unikátnych funkcií či funkcionalít. Do druhej skupiny patrí zlepšovanie uţ existujúcich funkcií. Môţe sa jednať o zvýšenie bezpečnosti, stability systému, skracovanie doby odozvy, vylepšovanie uţívateľského prostredia. S fázou rastu súvisí aj rast počtu klientov, ktorí si inštalujú produkt. V tejto fáze prechádza produkt z finančného hľadiska bodom zvratu a začína generovať zisk. Výrobca sa musí vyhnúť rizikovým faktorom, a to hlavne zníţeniu kvality sluţieb, ktorá môţe v krajnom prípade viesť k zrušeniu produktu. (VORÍŠEK, 2008 str. 65) Fáza dospelosti V tejto fáze produkt prechádza iba malými zmenami, ktoré nie sú pracovne náročné a ktoré zásadne nemenia funkcionalitu produktu. Hlavná náplň práce pre výrobcu sa sústreďuje na údrţbu. Fáza dospelosti si pre výrobcu nevyţaduje ţiadne mimoriadne finančné náklady. Počet zákazníkov, ktorí si kupujú produkt dosiahol vrchol a začína pomaly klesať. V tejto fáze uţ zákazník nemôţe očakávať, ţe získa nejakú konkurenčnú výhodu. Pre zákazníka je nákup tohto produktu spojený s minimálnym rizikom. Jediné, čoho sa musí zákazník obávať je, ţe produkt rýchlo zastará. (VORÍŠEK, 2008 str. 65) Záverečná fáza Ak sa na trhu uţ objavili konkurenčné produkty, ktoré tento produkt prekonávajú vo väčšine jeho hlavných parametrov, dostáva sa produkt do svojej záverečnej fázy. Ak sú konkurenčné produkty dokonalejšie, ponúkajú viac funkcionalít, pouţívajú modernejšie technológie, pracujú rýchlejšie alebo sú bezpečnejšie, nebude chcieť výrobca do tohto produktu ďalej investovať ţiadne finančné prostriedky. Pre zákazníka je investícia do takéhoto produktu viac ako diskutabilná. V tejto fáze produkt neprináša ţiadnu konkurenčnú výhodu, práve naopak. (BRUCKNER, 2012 str. 86) Do záverečnej fázy sa produkt môţe dostať aj bez toho, aby sa dostal do fázy rastu alebo dospelosti. Príčin môţe byť viacero, napríklad krach výrobcu, ktorý produkt vyvíjal Poţadované vlastnosti informačného systému. Kaţdý informačný systém by mal plniť kritériá, ktoré si jeho tvorcovia stanovili. Tieto kritériá si developeri stanovili na základe analýzy poţiadaviek zadávateľa, diskusiou 19

20 s pouţívateľmi, alebo na základe najlepších praktík. Poţadované vlastnosti by mali byť adekvátne súčasnému stavu informačných technológií. Musia zodpovedať poţiadavkám zadávateľov na funkcionalitu ich business procesov. Nemali by obsahovať zbytočné, nefunkčné alebo chybné prvky. Taktieţ je veľkou chybou, ak informačný systém obsahuje duplicitné časti, alebo sú informácie ukladané v rôznych formátoch. Za problém sa tieţ pokladá, ak dve aplikácie v jednom informačnom systéme pouţívajú rôzne klávesové skratky. (BRUCKNER, 2012 str. 120) Dostupnosť Veľkou chybou aplikácie je, ak je z rôznych dôvodov nedostupná pouţívateľovi alebo procesu, ak si to vyţadujú. V dnešnej dobe je uţ štandardom, ţe aplikácie sú dostupné 24 hodín denne 365 dní v roku viacerými komunikačnými kanálmi. Štandardne sa dodávateľ písomne zaväzuje dodrţať poţadovanú dostupnosť. Tá sa zvyčajne definuje na čas, keď je systém dostupný. Tento údaj sa môţe uvádzať v percentách. Napríklad v zmluve môţe byť uvedené, ţe dostupnosť neklesne pod hranicu 95 percent za rok a zvyšných 5 percent bude vyhradených na údrţbu. Toto je veľmi dôleţité uviesť v zmluve, pretoţe príliš časté alebo príliš dlhé výpadky môţu mať veľký dopad na podnikanie. Dostupnosť, ktorá sa blíţi k 100 percentám je veľmi finančne nákladná a klient si musí uvedomiť, ţe sa to premietne do koncovej ceny aplikácie. Dĺţka odozvy Príliš dlhá odozva systému môţe zásadným spôsobom zníţiť kvalitu produktu. Odpoveď na uţívateľskú poţiadavku nesmie byť príliš dlhá, aby nenarúšala plynulú prácu pouţívateľa, alebo plynulosť riadeného procesu. Ak so systémom pracuje človek, potom sa za dostatočne rýchlu odozvu povaţuje odpoveď od jednej do troch sekúnd. Ak informačný systém riadi nejaký technologicko-informačný systém (výrobnú linku v automobilke) doba odozvy sa musí pohybovať v milisekundách. Skracovanie dĺţky odozvy je podobne ako pri dostupnosti finančne a technologicky náročné. Vzniká tu potreba pouţívania výkonnejších prenosových ciest, výkonnejších databázových systémov, výkonnejších procesorov, väčších a výkonnejších pamätí. Samotné zvýšenie týchto parametrov však nemusí priniesť poţadovaný efekt. Uţ pri počiatočnom návrhu systému sa musí dopredu stanoviť, koľko poţiadaviek dokáţe systém spracovať a akú bude mať dobu odozvy. (BRUCKNER, 2012 str. 121) 20

21 Zhoda s legislatívou Dodávateľ systému musí dbať o to, aby produkt, ktorý ponúka, bol v súlade so zákonmi, ktoré platia v danej krajine. Ak organizácia vyvinula produkt vo vlastnej réţii, musí poveriť zodpovednú osobu, ktorá bude sledovať zmeny legislatívy a podľa toho následne zmení produkt, aby bol v zhode s novou legislatívou. Ak si však organizácia zaobstarala informačný systém formou outsourcingu, musí mať v zmluve zakotvené, ţe prípadné zmeny legislatívy dodávateľ v stanovenej lehote aktualizuje v IS. Uţívateľská prívetivosť Uţívateľsky neprívetivý systém môţe zásadným spôsobom narúšať prácu uţívateľov. Z tohto dôvodu sa renomovaní developeri snaţia vyvíjať svoj produkt tak, aby obsahoval viac uţívateľských rozhraní. Funguje to tak, ţe rôzne uţívateľské rozhrania vyvolávajú rovnakú funkcionalitu aplikácie. Diferentné rozhrania, ktoré budú vyhovovať poţiadavkám dobre zaškoleným ako aj príleţitostným pouţívateľom daného systému. Skúseným pouţívateľom, ktorí často pracujú s daným systémom viac, vyhovuje uţívateľské prostredie, ktoré je stručné a rýchle. Pre menej skúsených pouţívateľov, ktorí občas pracujú so systémom, bude viac vyhovovať uţívateľské prostredie, ktoré je plné nápovedí, komentárov a návodov. Takéto rozsiahle uţívateľské rozhranie pomáha pochopiť ako systém pracuje, ako chápať zobrazené dáta, aké sú ďalšie moţnosti práce a aké sú riziká straty údajov. Skúsení developeri nezabúdajú ani na hendikepovaných pouţívateľov, ktorí majú svoje špecifické poţiadavky. Tieto rozsiahle uţívateľské rozhrania majú vplyv na výkon a údrţbu systému, čo sa často premieta do zvýšenia nákladov. (BRUCKNER, 2012 str. 122) Flexibilita Ďalšou poţiadavkou na informačný systém je jeho flexibilita. V tejto dobe je nutné, aby sa informačný systém dal prispôsobiť novým poţiadavkám rýchlo a lacno. Pre uţívateľov je najvýhodnejšie, ak sa drobné zmeny, napríklad výška DPH, dajú meniť v nadstaveniach aplikácie a nie aţ zmenou zdrojového kódu. (BRUCKNER, 2012 str. 123) Otvorenosť Ak je niektorá aplikácia uţ zastaraná, alebo je potrebné ju z nejakého dôvodu zameniť za inú, je veľmi výhodné ak IS túto zmenu podporuje. Dobrá otvorenosť systému zniţuje náklady na údrţbu. 21

22 Štandardizácia Z hľadiska zniţovania nákladov je nutné, aby boli všetky zdroje, procesy a sluţby štandardizované. Je chybou, ak rôzne aplikácie toho istého systému fungujú na rôznych platformách. Je tieţ problém, ak aplikácie majú podobnú alebo rovnakú funkcionalitu. Výkonnosť a efektivita Je nutné, aby informačný systém uţ pri svojom návrhu mal definované ciele z hľadiska výkonnosti. Výborne navrhnutý IS je taký, ktorý pomáha k celkovej výkonnosti organizácie. Zvyšovanie výkonu systému je priamo úmerné zvyšovaniu jeho ceny a nákladom na jeho údrţbu a prevádzku. Je potrebné podrobne sledovať, aby cena za zvýšenie výkonu nebola vyššia ako prínos, ktorý má IS pre organizáciu. Na posudzovanie prínosov sa musia stanoviť kritériá. Pre kaţdé kritérium sa musia stanoviť cieľové hodnoty a čas, dokedy majú byť dosiahnuté. Aby bolo moţné sledovať či prostriedky vloţené do zvyšovania výkonnosti boli adekvátne, musíme priebeţne sledovať stanovené kritéria a porovnávať ich so stanovenými cieľmi. (BRUCKNER, 2012 str. 124) Bezpečnosť IS Informačná bezpečnosť: Je to bezpečnosť informačných systémov, informačných technológii, všetkých informácií uloţených v systéme, ale aj všetkých ostatných aktív. Informačná bezpečnosť sa zvyšuje implementáciou ISMS (Information Security Management System), ktorého úlohou je minimalizovať riziko a zaručiť kontinuitu všetkých procesov, ktoré súvisia s chodom daného IS. Informačná bezpečnosť sa zvyšuje implementáciou sady opatrení. Tieto opatrenia je potrebné zaviesť pre splnenie bezpečnostných zámerov organizácie. Potrebné podmienky na ISMS definuje norma ISO/IEC 27001:2005. (SEARCHSECURITY.TECHTARGET, 2013) Na bezpečnosť IS sa môţeme pozerať z týchto základných hľadísk: 1. Chyba údrţby: Chybám údrţby sa môţeme vyhnúť, ak vyhotovíme procedúry údrţby, ktoré budú riadne zdokumentované a zároveň bude monitorovaná práca servisného technika, ktorý vykonáva pravidelnú údrţbu systému. 2. Zlomyseľný kód: Jedná sa o rôzne malware. Zlomyseľný kód môţe váţne poškodiť informačný systém. Môţe dôjsť k prezradeniu hesiel, ku krádeţi dôverných informácií alebo dokonca k celkovému znefunkčneniu celého IS. Pouţívaním antivírusov a dodrţiavaním bezpečnostných pravidiel môţeme toto riziko zníţiť na akceptovateľnú úroveň. (STRNÁD, 2009 str. 221) 3. Predstieranie identity pouţívateľa: Na obídenie autorizácie sa môţe pouţiť postup, pri ktorom sa páchateľ snaţí predstierať, ţe je oprávnený pouţívateľ systému. Pri 22

23 úspešnom pokuse môţe páchateľ získať citlivé informácie, heslá, dáta. (STRNÁD, 2009 str. 223) 4. Chyby pouţívateľa: Všetci pouţívatelia IS by mali absolvovať školenie ako správne pracovať s daným systémom. Toto školenie by malo zabezpečiť, aby sa pouţívatelia vyhli chybám, ktoré môţu mať za následok stratu informácií alebo znefunkčnenie systému. (STRNÁD, 2009 str. 227) 5. Zlyhanie softvéru: Pri zlyhaní softvéru môţe dôjsť k zničeniu integrity dát alebo informácií, ktoré sú daným softvérom spracovávané. Najúčinnejšie protiopatrenia sú časté vytvárania záloh dát a informácií, údrţba a testovanie softvéru. Dobrou praktikou je aj čo najskoršie oznamovanie nesprávnej funkčnosti softvéru. (STRNÁD, 2009 str. 222) 6. Porucha dodávky prúdu: Tento problém sa dá ľahko vyriešiť inštaláciou prepäťovej ochrany a pouţívaním zálohového zdroja energie. (STRNÁD, 2009 str. 224) 7. Technické zlyhanie hardvéru: Pri zlyhaní hardvéru môţe prísť k strate informácií a dát, ktoré sú v danej chvíli týmto hardvérom spracovávané, alebo sú na ňom uloţené. Medzi najúčinnejšie protiopatrenia patria: a. dodrţiavanie prevádzkových procedúr: b. pravidelná kontrola a údrţba hardvéru kvalifikovaným personálom, c. testovanie a benchmark výkonu hardvéru. Hardvér, ktorý je optimálne nakonfigurovaný, má niţší sklon k zlyhaniu. (STRNÁD, 2009 str. 228) 8. Opotrebovanie pamäťových médií: Môţe nastať situácia, pri ktorej príde k strate alebo nedostupnosti dát vinou opotrebenia pamäťových médií. Takúto hrozbu môţeme zníţiť zálohou kľúčových dát, ako aj pravidelnou údrţbou a kontrolou pamäťových médií. Pravidelná verifikácia zisťuje, či dáta neboli uloţené chybne alebo nie sú poškodené. Na obnovu stratených alebo poškodených informácií sa pouţívajú informácie z pravidelných záloh. Ďalším prvkom na ochranu uloţených dát a informácií je pouţitie kryptografických prostriedkov. (STRNÁD, 2009) 9. Chyby pri prenose: Podobne ako pri technickom zlyhaní hardvéru aj chyba pri prenose dát cez kabeláţ môţe viesť k strate integrity informácií. Takýmto chybám sa môţeme vyhnúť plánovaním prenosovej kapacity káblov alebo starostlivým uloţením kabeláţe. Následne je odporúčané pouţiť kontrolné súčty alebo redundantné kódy v komunikačných protokoloch. (STRNÁD, 2009 str. 225) 23

24 10. Neautorizovaný prístup k počítačom, dátam, sluţbám, aplikáciám a pamäťovým médiám: Medzi priority kaţdej organizácie by malo patriť zamedzenie prístupu do svojho informačného systému neautorizovaným osobám. Takýto útok môţe mať fatálne následky. Môţe dôjsť k ukradnutiu kľúčových informácií, k ich zmene alebo ich zničeniu. Medzi najpouţívanejšie protiopatrenia patria: a. Riadenie a audit logického prístupu. b. Oddeľovanie sietí. c. Riadenie logického prístupu. d. Riadenie fyzického prístupu. e. Riadenie médií. (STRNÁD, 2009) 1.2 Architektúra klient-server Model klient-server bol populárny mnoho rokov pred tým neţ sa osobné počítače stali beţnou alternatívou staršej mainframovej architektúry. Model klient-server môţe byť pouţitý tak na internete, ako aj na lokálnej sieti. Klientsky počítač a server sú zvyčajne dve rozdielne zariadenia. Túto architektúru by sme si mohli zjednodušene predstaviť ako počítačovú sieť zloţenú zo serveru na jednej strane a viacero klientskych počítačov na strane druhej. Princíp architektúry klient-server je zasielanie poţiadaviek z klientskych počítačov na server. Server nasledovne túto poţiadavku spracuje a odpoveď pošle späť na klientsky počítač. Základným príkladom architektúry klient-server môţe byt internet. Pri zadaní adresy do internetového prehliadača vyšleme poţiadavku na internetový server. Internetový server na základe tejto poţiadavky pošle klientskemu počítaču HTML stránku. Internetový prehliadač túto stránku následne zobrazí na obrazovku. (SHARP, 2006) Klient Klient je počítač, mobil, na ktorom je spustená aplikácia, ktorá poskytuje pouţívateľské rozhranie (GUI). Klient je zodpovedný za prezentovanie sluţieb v pouţiteľnej forme, ktoré získal zo serveru. (PCMAG, 2013) Tenký klient Pojem tenký klient vychádza z mimoriadne úsporného vyuţívania zdrojov ako aj prenosových kapacít komunikačných liniek. (ORACLE, 2013) Takáto architektúra sa pouţívala v podnikových sieťach oveľa skôr ako osobné počítače. Tenký klient je počítač alebo počítačový program. Takýto klienti sú centrálne spravované počítače, ktoré sú 24

25 súčasťou širšej počítačovej infraštruktúry. Tenkí klienti nemajú DVD-rom a harddisk. Takáto pracovná stanica si vystačí len s monitorom klávesnicou, myšou a obmedzeným výkonom, potrebným na komunikáciu so serverom. Pri plnení úloh sú úplne závislí od svojho servera. Dôvody, prečo sa čoraz viac ľudí rozhodujú pre tenkého klienta: 1. Redukcia nákladov na administráciu a podporu: Manaţovať tenkých klientov je jednoduchšie pretoţe operačný systém je centralizovaný. Centralizovaný operačný systém, ktorý sa nachádza na jednom mieste, dokáţe spravovať oveľa niţší počet administrátorov. Administrátori môţu aplikovať updaty, patche, inštalovať nové aplikácie, odstraňovať vírusy na centrálnom serverovskom termináli. Tieto zmeny, ktoré administrátori uskutočnia centrálne na serverovskom termináli sa prejavia pre všetkých tenkých klientov, ktorých môţu byť stovky, alebo dokonca tisíce. Takéto zmeny sa na klientskej strane uskutočnia automaticky, bez toho, aby musel administrátor fyzicky navštíviť čo i len jednu pracovnú stanicu tenkého klienta. 2. Ľahký manaţment licencií: Vďaka centralizácií je oveľa jednoduchšie spravovať softvérové licencie a následné ich monitorovať. Aj vykonanie auditu takejto infraštruktúry je oveľa jednoduchšie, pretoţe je potrebné vykonať audit len centrálneho servera a nie kaţdého jedného klienta. 3. Celosvetový prístup k súborom a aplikáciám: Architektúra tenkého klienta podporuje pouţívanie podnikových súborov kdekoľvek na svete. Zamestnanci môţu pouţívať dáta a informácie doma alebo na pracovných cestách, čím sa zvyšuje ich produktivita práce. 4. Pridanie alebo nahradenie tenkého klienta: Pri architektúre klient-server je sprevádzkovanie nového zariadenia len otázkou pár minút. To isté platí aj pri technickej poruche uţ existujúceho zariadenia, ktoré sa jednoducho vymení za nový fungujúci kus. Je tieţ dôleţité mať nejaké náhradné zariadenie k dispozícii. 5. Vyššia spoľahlivosť: Keďţe zariadenia tenkých klientov neobsahujú pohyblivé mechanické súčiastky, je tu oveľa niţšie riziko ich pokazenia. V prípade pokazenia tenkého klienta, dôleţité dáta nie sú stratené, pretoţe sú uloţené na serveri. Centralizovaný úloţný systém dovoľuje rýchle a efektívne obnovenie po poruche zariadenia. 6. Úspora finančných prostriedkov: Zariadenia tenkého klienta sú finančne oveľa menej náročné ako klasické osobné počítače. Morálne opotrebovanie týchto zariadení je asi dvakrát pomalšie. Ďalším nezanedbateľným aspektom je spotreba elektrickej energie. Tenkí klienti spotrebúvajú vďaka absencii pohyblivých 25

26 mechanických častí asi trikrát menej elektrickej energie ako beţné osobné počítače. (2X, 2010) Fat klient Fat klient je na sieť pripojený osobný počítač. Tento osobný počítač má nainštalovaný svoj vlastný operačný systém a iné aplikácie na svojom harddisku. Aj väčšina dát je uloţená lokálne. Cieľový pouţívateľ si môţe sám manaţovať inštaláciu nových aplikácií. Výhodou tohto klienta je, ţe dokáţu pracovať aj bez pripojenia na sieť. Fat klient môţe vyuţívať architektúru tenkého klienta, ak je pripojený na sieť. (IFS.HOST.CS.ST.ANDREWS, 2013 s. 20) Server V modeli klient-server je server špeciálne navrhnutým počítačom, ktorý čaká na klientske poţiadavky. Ak server zaznamená, ţe klientský počítač poslal poţiadavku, spracuje ju a výsledok pošle späť. Server je pasívny, zatiaľ čo čaká na klientsku poţiadavku. Počas tohto čakania môţe server vykonávať iné činnosti alebo vykonávať údrţbu. Na rozdiel od klienta, server by mal pracovať neustále. Klient môţe pracovať len ak vyţaduje nejakú sluţbu. Jeden server dokáţe obslúţiť poţiadavky od viacerých klientov súčasne. Ak nastane táto situácia, server zaznamená všetky poţiadavky do zástupu. Následne sa server snaţí spracovávať klientske poţiadavky formou FIFO (prvý dovnútra prvý von). Ak server obslúţi všetky poţiadavky klientov, pokračuje v čakaní. Niektoré poţiadavky od klientov môţu mať rozdielnu prioritu spracovania. Na rozlíšenie priorít poţiadaviek musí server obsahovať metódy na identifikáciu priorít. (MITCHELL Bradley, 2013) Na efektívne uspokojovanie klientskych poţiadaviek, klientsky program musí pouţívať interface alebo protokol definovaný serverom. Dobre navrhnutý interface určuje ako sa budú posielať správy, aké správy budú podporované a ako budú vyzerať odpovede zo serveru. Server je takisto modulárne navrhnutý. Pod týmto pojmom sa rozumie moţnosť vylepšiť funkcionalitu komponentu servera bez toho, aby to nejako obmedzilo klientov. (NI, 2013) 1.3 Microsoft.NET.NET Framework 4.5 je developerská platforma na tvorbu aplikácií pre Windows,Windows phone,windows server a Windows Azure. Pozostáva z Common language runtime (CLR) a.net Framework class library. CLR obsahuje triedy, interfaces, 26

27 values, types. NET Frameworks je technológia, ktorá podporuje tvorbu a pouţívanie najnovšej generácie aplikácií a XML Web services. NET Framework je dizajnovaná na plnenie rôznych cieľov napríklad: Poskytnúť konzistentné objektovo orientované prostredie, ktoré minimalizuje konflikty verzií Vlastnosti Common Language Runtime Je to časť NET framework, ktorá manaţuje spúšťanie programov písaných v jednom z mnohých podporovaných jazykoch. Dovoľuje im pouţívať a vymieňať si beţné objektovo orientované triedy, písané v ktoromkoľvek z týchto jazykov. CLR je porovnateľné s Java virtual machine, ktorú vyvinulo Sun Microsystems pre spúšťanie programov kompilovaných v jazyku Java. Programátori programujúci vo Visual Basicu, Visual C++ alebo C#, kompilujú svoje programy do medziformy pomocou Common Intermediate Language. Výsledkom je súbor, ktorý môţe byť manaţovaný alebo spúšťaný v CLR. Údaje o programátorovi, prostredí a programe sú uloţené spoločne s skompilovaným súborom ako metadata. Metadata, uloţené v skompilovanom programe prezradia CLR, ktorý programovací jazyk bol pouţitý, ktorá verzia a ktoré triedy budú pouţívané programom. CLR povoľuje, aby inštancia triedy písaná v jednom jazyku mohla volať metódy triedy, ktoré boli napísané v inom jazyku. CLR ďalej obsahuje garbage collector, ktorý uvoľňuje nadbytočné objekty z pamäti ASP.NET ASP.NET je framework, ktorý bol vytvorený spoločnosťou Microsoft. Tento framework bol vytvorený na tvorbu dynamických webových stránok. Táto platforma poskytuje programovací model, infraštruktúru a rôzne sluţby, potrebné pri vytváraní robustných webových aplikácií. ASP.NET je súčasťou Microsoft.NET platformy. 1.4 Java Java je objektovo orientovaný programovací jazyk. V súčasnosti patrí medzi najpouţívanejšie a najrozšírenejšie programovacie jazyky. Od svojho vzniku prešla celým radom vylepšení. K najvýznamnejším vylepšeniam patrili verzie J2SE5 a JavaSE7. Java vznikla v roku1991 v spoločnosti Sun Microsystems pod názvom Oak. Názov Java dostala aţ v roku Svoj veľký rozvoj zaznamenala vďaka tomu, ţe bola univerzálne pouţiteľná na tvorbu softvéru pre spotrebnú elektroniku. Java umoţňovala, aby bolo 27

28 moţné napísať program, skompilovať ho a spustiť na rôznych platformách. Postupom času sa našla nová oblasť uplatnenia Javy. V časoch, keď sa začal masívne rozširovať internet, zaznamenala svoj najväčší rozvoj. Pomohla vyriešiť dva z najväčších problémov internetu: prenositeľnosť a bezpečnosť. V čase, keď sa začal rozširovať internet boli WWW stránky statické. Na vyriešenie tohto problému firma Sun vyvinula Applet. Applet je malý program, ktorý je prenosný cez internet. Funguje to tak, ţe ak pouţívateľ vo svojom web prehliadači klikne na odkaz, ktorý obsahuje applet, ten sa automaticky stiahne cez internet a spustí. Hlavné vyuţitie appletov je na zobrazovanie dát poskytovaných serverom, poskytovanie jednoduchých funkcií, alebo spracovanie vstupu pouţívateľa. Applet umoţňuje, aby boli niektoré funkcie presunuté zo serveru na klienta. Na prvý pohľad sa môţe zdať, ţe applet predstavuje potenciálne bezpečnostné riziko. Vzhľadom na to, ţe zo serveru sa môţe spolu s apletom stiahnuť aj vírus alebo iný nebezpečný kód. Na zabránenie tomuto riziku bol vyvinutý mechanizmus, ktorý bráni appletu pristupovať k systémovým častiam počítača. (SCHILDT, 2012 s. 25) Java a bajtový kód Bajtový kód byte code je vysoko optimalizovaná sada inštrukcií. Táto forma inštrukcií je spúšťaná na virtuálnom stroji Javy (Java virtual machine). Skutočnosť, ţe programy v Jave sú spúšťané v JVM, je ich obrovská výhoda. Tento fakt pomohol vyriešiť hlavné problémy spojené s webom. Prenositeľnosť: Program, ktorý bol napísaný v jave a následne preloţený do bajtového kódu je moţné spúšťať v kaţdom prostredí v ktorom bol implementovaný Java virtual machine. Ako náhle v zariadení existuje balíček (JVM) môţe na danom zariadení beţať ľubovoľný Java program bez ohľadu na platformu. Bezpečnosť: Vzhľadom na to, ţe všetky applety, ktoré boli stiahnuté zo serveru na základe klientskej poţiadavky sa spúšťajú v sandboxe, zabezpečuje sa adekvátna ochrana systému počítača pred potenciálne neţiaducim kódom. (SCHILDT, 2012 s. 27) Objektovo orientované programovanie Programovací jazyk Java je objektovo orientovaný. Všetky programy, ktoré boli napísané v Jave do istej mieri spĺňajú tuto formuláciu. Poznáme tri princípy objektovo orientovaného programovania. Zapúzdrenie: mechanizmus, ktorý zabezpečuje ochranu dát a kódu. Ak sú dáta a kód samostatnými entitami, môţe prísť k narušeniu bezpečnosti nesprávnym pouţitím zvonku. To sa môţe stať ak, sú nesprávne dáta volané správnou metódou alebo nesprávna metóda volá správne dáta. V OOP jazyku musíme dáta a kód zatvoriť do takzvanej čiernej 28

29 skrinky. Takto prepojené dáta sa nazývajú objekt. Vo vnútri objektu sú dáta a kód takto zapuzdrené čiţe skryté. Základnou jednotkou zapúzdrenia je trieda. Trieda definuje formu objektu. Trieda môţe obsahovať jednu alebo viacero metód. Na riadenie prístupu k metódam sa pouţívajú tri špecifikátory prístupu: public, protected a private. Polymorfizmus Je to schopnosť objektu nadobudnúť viacero foriem. Objekt sa môţe správať tak ako by bol objektom jedného zo svojich nadtypov. Dedičnosť Dedičnosť je proces, keď jeden objekt získava vlastnosti iného objektu. Dedičnosť nám umoţňuje odvodiť triedu od inej triedy. Odvodená trieda môţe zdediť všetky metódy autentickej triedy a môţe k nim pripojiť nové metódy. Pomocou dedičnosti stačí triede definovať len tie metódy, ktoré ju robia jedinečnou. Svoje všeobecné metódy môţe zdediť od svojho rodiča. (SCHILDT, 2012 s. 31) Java SE Platforma Java standard edition (SE) sa pouţíva na tvorbu Java aplikácií pre desktopy a servery. Java ponúka bohaté uţívateľské rozhranie, výkon, prenosnosť a bezpečnosť, ktorú dnešné aplikácie poţadujú. (ORACLE, 2013) Obrázok 1-3 Komponenty Java SE (ORACLE, 2013) 29

30 Java runtime enviroment (JRE) Java runtime enviroment (JRE) poskytuje kniţnice, Java virtual machie a ostatné komponenty potrebné pre fungovanie appletov, alebo aplikácií písaných v programovacom jazyku Java. Dopĺňa dve kľúčové technológie, ktoré sú súčasťou JRE: Java plug-in a Java web start. Java development kit (JDK) Java development kit je nadstavba, ktorá rozširuje JRE o kompilátor a debuger. Tieto dva komponenty sú potrebné na tvorbu a monitorovanie aplikácií. Najaktuálnejšia verzia JDK je momentálne JDK 7u45. Java virtual machine (JVM) JVM bola opisovaná v podkapitole Java. Java SE API Java SE obsahuje bohatú sadu API, ktorá dovoľuje developerom vytvárať sofistikované aplikácie. Týmto aplikáciám poskytuje základnú systémovú podporu, ako aj komplexnejšie funkcionality ako napríklad viacvláknové programovanie a objektovú manipuláciu na vzdialených hostoch. Java API obsahuje kniţnice, ktoré sú logicky rozdelené podľa funkcionality: Language Base Integration Ui toolkit (ORACLE, 2013) Java EE V minulosti tieţ označovaná ako J2EE. Java EE je postavená na platforme Java SE. Poskytuje API (Application Programming Interface) a prostredie na tvorbu celého spektra viac úrovňových, škálovateľných, spoľahlivých a bezpečných sieťových aplikácií. Java EE sa objavila na konci 90. rokov a rozšírila jazyk Java na robustnú softvérovú platformu. Táto platforma je určená na podnikových aplikácií. (GONCALVES, 2013 s. 2) Architektúra Java EE je súbor špecifikácií, implementovaný rozdielnymi kontajnermi. Kontajnery sú Java EE prostredia, ktoré poskytujú spoľahlivé sluţby komponentom. Tieto komponenty pouţívajú presne definovane kontrakty na komunikáciu s Java EE infraštruktúrou a s inými komponentmi. Obrázok č. 4 opisuje logické vzťahy medzi 30

31 kontajnermi. Šípky reprezentujú protokol, pouţitý na prístup k inému kontajneru. Napríklad: Web kontajner hosťuje servlet, ktorý môţe pristupovať k EJB kontajneru prostredníctvom protokolu RMI-IIOP. Obrázok 1-4 Sluţby poskytované kontajnermi (GONCALVES, 2013 str. 5) Komponenty Java EE prostredie definuje štyri typy komponentov, ktorých implementáciu musí podporovať. Applety: sú to (GUI) aplikácie, ktoré sú spúšťané vo webovom prehliadači. Aplikácie : sú programy, ktoré sú spúšťané na klientskej strane. Spravidla majú GUI, ktorý ma prístup ku všetkým funkcionalitám JavaEE middle tier. Webové aplikácie : (servlety, servletove filtre, web event listeners, JSP a JSF stránky) sú spúšťané vo webovom kontajnery a odpovedajú na HTTP poţiadavky webových klientov. Enterprise aplikácie: (Enterprise java beans, java message services, timer services) sú spúšťané vo EJB kontajnery. EJB sú kontajnery pre spracovanie transakčnej business logiky. (GONCALVES, 2013 s. 3) Kontajnery Infraštruktúra Java EE je rozdelená do logických domén, ktoré sa nazývajú kontajnery. Kaţdý kontajner má špecifickú úlohu, podporu sady API a ponúka sluţby komponentom. Podľa druhu vyvíjanej aplikácie sa musí zvoliť príslušný kontajner. Napríklad, ak je úlohou vytvoriť web aplikáciu, pouţije sa JSF, spolu s EJB Lite a vloţí sa to do webového kontajnera. Alebo, keď je potrebné vytvoriť web aplikáciu, ktorá bude vzdialeno volať business tier a pouţívať asynchrónne volania, bude potrebné k predchádzajúcemu riešeniu pripojiť ešte aj EJB kontajner. Java EE má štyri kontajnery: Applet kontajner 31

32 Aplikačný klient kontajner Web kontajner EJB kontajner Sluţby Kontajnery poskytujú podporné sluţby pre svoje komponenty. Obrázok č.4 ukazuje, ktoré sluţby poskytuje, ktorý kontajner. Napríklad web a EJB kontajner poskytuje konektory na prístup k EIS (Enterprise information system), ale applet kontajner alebo ACC kontajner ho neobsahuje. Sieťové protokoly Podľa obrázku č.4,komponenty v kontajneroch sú vyvolávané protokolmi HTTP/HTTPS, RMI-IIOP. (GONCALVES, 2013 s. 6) 1.5 Databázový systém Veda, obchod,vzdelávanie, ekonomika, právo, kultúra všetky tieto oblasti ľudskej práce sú kriticky závislé od dát. Databázy majú kľúčovú úlohu v modernom uchovávaní a spracovávaní dát. Sú to databázy, ktoré uchovávajú obrovské mnoţstvá dát najrôznejšieho druhu. Uţitočné informácie sa získavajú zo spracovania dát. Dobre načasované, relevantné informácie sú kľúčom k dobrým rozhodnutiam. Dobré rozhodnutia sú kľúčové k úspechu organizácie. Databázový systém (DBS) sa skladá z dvoch častí, prvá časť je samotná databáza (BD), ktorá uchováva dáta a druhá časť DBMS, ktorá obsahuje opis a štruktúru dát uloţených v databáze. Opis a štruktúra je uloţená v systémovom katalógu (metadata). Pre DBMS je charakteristická dátová abstrakcia, to znamená, ţe programy, ktoré vytvárajú DBMS, sú nezávislé od toho ako sú dáta štruktúrované. Pouţívatelia môţu definovať rôzne pohľady na dáta. To znamená, ţe podmnoţiny databázy alebo virtuálne dáta sú odvodené z databázy, ale nie sú v nej explicitne umiestnené. Tento systém ďalej umoţňuje sprostredkovanie dát a spracovávanie transakcií (prístup do databázy viacerých pouţívateľov v rovnakom čase). Konzistencia databázy je zaručovaná zamedzením neautorizovaného prístupu. Ďalšou schopnosťou DBMS je prezentovať zloţité vzťahy medzi dátami tak, aby zmeny dát a prehľadávanie prebiehali s maximálnou efektívnosťou. V neposlednom rade obsahuje funkcie na odstránenie redundancie dát a podporu pre obnovu a zotavenie po chybách. (SHERIFF, 2006) 32

33 Pri návrhu DBS sa pouţíva trojúrovňová architektúra DBMS Externá schéma: pohľad pre pouţívateľa Konceptuálna schéma: logický pohľad Interná schéma: fyzické uloţenie dát Rozdelenie DBMS Podľa dátového modelu: Relačné Sieťové Hierarchické Objektovo-orientované Podľa počtu pouţívateľov Jedno pouţívateľské Viac pouţívateľské Podľa počtu miest, do koľkých je databáza distribuovaná: Centralizované Distribuované Homogénne Heterogénne Dvojúrovňová architektúra V dnešnej dobe je väčšina konfigurácií klient-server zaloţená na dvojúrovňovej architektúre. Tento model sa tieţ nazýva two tier a je zloţený z klienta a dáta servera. Na strane klienta sa nachádzajú prezentačné sluţby, prezentačná logika a aplikačná logika. Na strane servera sa nachádzajú dátové a súborové sluţby. Tento model má výhodu v tom, ţe má minimálne poţiadavky na server, pretoţe väčšina záťaţe je na klientovi a vlastnej sieti. 33

34 Obrázok 1-5 Dvojvrstvová architektúra (PCMAG, 2013) Dvojúrovňová architektúra klient-server, klient heavy Pri projektovom návrhu musí návrhár rozhodnúť o optimálnom umiestnení aplikačnej logiky. Ak sa rozhodne, ţe presunie časť aplikačnej logiky na stranu serveru, výrazne týmto zredukuje záťaţ na klientskej strane. Môţe sa vyuţiť mechanizmus uloţených procedúr (stored procedures). Uloţené procedúry sa v mnohom podobajú na programy alebo procedúry, ktoré poznáme z procedurálnych programovacích jazykov. Môţu mať vstupné a výstupné parametre. Môţeme v nich pouţívať lokálne premenné, globálne premenné, cykly alebo podmienky. Je tieţ moţné volať z jednej uloţenej procedúry inú procedúru. Po svojom vykonaní uloţená procedúra vracia status hodnotu indikujúcu, či daná uloţená procedúra prebehla. (HOTEK, 2009 s. 199) Implementáciou aplikačnej logiky na server sa zníţi zaťaţenie siete. Funguje to tak, ţe sa neposielajú celé SQL výrazy z klienta na server a medzivýsledky späť zo serveru, ale celé spracovanie môţe byť na strane servera. (SHERIFF, 2006 s. 564) Trojúrovňová architektúra klient server Niekedy sa nazýva aj three tier. Trojúrovňová architektúra klient-server môţe vyriešiť niektoré nedostatky predchádzajúcej architektúry. Tato architektúra obsahuje klienta, aplikačný server a dátový server. Tento model je rozčlenený podľa obsahu nasledovne: Klient obsahuje: Prezentačné sluţby Prezentačnú logiku Aplikačný server obsahuje: Logiku Aplikácie 34

35 Dátový server obsahuje: Dátové sluţby Logiku dát Súborové sluţby. Obrázok 1-6 Trojvrstvová architektúra (PCMAG, 2013) Hlavné výhody tohto systému vyplývajú z rozdelenia práce medzi klientskym systémom a databázovým serverom, keďţe väčšinu databázového spracovania vykonáva server, nie je rýchlosť DBMS limitovaná rýchlosťou klientovej pracovnej stanice. Takéto rozdelenie zniţuje záťaţ siete, ktorá spája jednotlivé segmenty. Namiesto prenosu celých databáz je komunikácia obmedzená len na dotazy smerované na server. Databázové servery, na ktorých sú uloţené procedúry, ešte viac redukujú sieťovú prevádzku. Tento systém ďalej udrţuje integritu dát, čo je zabezpečené tým, ţe pouţívatelia nemajú priamy prístup k dátam uloţeným na serveri. K dátam môţu pristupovať len prostredníctvom DBMS. DBMS poskytuje sluţby ochrany dát, akými sú šifrovanie, zrkadlenie alebo zdvojovanie disku. Ďalej je potrebné spomenúť aj nezávislosť na pracovnej stanici alebo platforme. Ďalšou výhodou three tier architektúry je, ţe dokáţe zvládnuť aj transakcie v rámci distribuovaných databáz. Na tento účel pouţíva two-phase commit. Ďalším plusom je aj centralizovanie aplikačnej logiky, čo veľmi uľahčuje realizáciu prípadných zmien. (SHERIFF, 2006 s. 26) Medzi nevýhodu systému klient-server by sme mohli zaradiť moţné preťaţenia serverov zo strany klientov. Ak musí server simultánne spracovať veľké mnoţstvo klientskych poţiadaviek, môţe to viesť k spomaleniu alebo dokonca pádu servera. Ak centrálny server prestane z akéhokoľvek dôvodu pracovať, celá sieť nemôţe fungovať. 35

36 Avšak, veľa klient-server sietí má záloţný server, ktorý poskytuje podporu, ak hlavný server prestane pracovať. (EHOW, 2013) Architektúra klient-server býva veľmi nákladná na inštaláciu a prevádzku. Taktieţ býva veľmi náročná na IT špecialistov, ktorí sa starajú o údrţbu a iné technické detaily. 2 Analytická časť V analytickej časti sú opísané dve technológie, ktoré sa najčastejšie pouţívajú na tvorbu klient- server aplikácií. Sú to ASP.NET a Java EE. 2.1 Technológia.NET a ASP.NET ASP.NET(Active server pages) je skriptovací jazyk na serverovskej strane. Je to jeden z frameworkov.net. Túto technológiu vyvinula spoločnosť Microsoft v roku ASP.NET 4.0 je technológia na prenos interaktívnych web aplikácií cez internet alebo cez intranet. Obsahuje veľké mnoţstvo predvolených prvkov ako sú textové polia, tlačidlá, obrázky, rámce. Tieto prvky sa dajú ľubovoľné pretvárať, konfigurovať alebo inak manipulovať a slúţia na vytváranie HTML stránok. Tieto stránky sa budú dať zobrazovať v najčastejšie pouţívaných internetových prehliadačoch. Spomínaná technológia pomáha vyriešiť problémy so statickými webovými stránkami. Statické webové stránky bývajú jednoducho uloţené na serveri. Ak pouţívateľ zašle poţiadavku na server, server mu zašle webovú stránku presne takú, aká je uloţená na serveri. Teda, statické web stránky zobrazujú tie isté informácie pre všetkých pouţívateľov. Hlavným problémom takýchto stránok je, ţe sa ťaţko udrţiavajú a majú aj iné veľké obmedzenia. Statické stránky nemajú ţiadnu personalizáciu a interakciu. Sú vhodné len na zobrazovanie obsahu, ktorý nepotrebuje byť často alebo vôbec aktualizovaný. Na vyriešenie týchto problémov začali vznikať serverovské programovacie jazyky. Tieto jazyky umoţňujú pozmeniť HTML stránku ešte skôr, ako je odovzdaná klientovi. Týmto sa umoţnilo vytvárať interaktívne prvky. Medzi najznámejšie interaktívne prvky patria diskusné fóra k článkom, hviezdičkové hodnotenia, anketa, kontaktný formulár. (TVORBA-STRANOK, 2013) ASP.NET je spustený na serverovskej strane. Na základe klientskej poţiadavky vytvorí príslušnú webovú stránku a zašle ju späť klientovi. Klient vidí uţ len výslednú HTML stránku, ktorá má však v mnohých prípadoch koncovku.aspx. 36

37 Najpouţívanejšie serverovské programovacie jazyky pre webové stránky sú PHP, ASP.NET a Java. ( Na tvorbu ASP.NET stránok sa najčastejšie pouţívajú programovacie jazyky Visual Basic alebo C#. Moţné je pouţiť ľubovoľný programovací jazyk, ktorý je kompatibilný s modulom CLR. (MICROSOFT, 2013) Bezproblémová funkčnosť webovej stránky ASP.NET si vyţaduje umiestnenie na serveri, ktorý podporuje ASP.NET aplikácie. Microsoft IIS (Internet information services) webový server je najpouţívanejšia platforma pre takéto webové stránky. Dajú sa pouţiť aj open-source systémy Linux, ale tie poskytujú menšiu podporu pre aplikácie ASP.NET. (TECHTERMS, 2013) Teoreticky je moţné inštalovať ASP.NET stránku aj na web server Apache. Pri inštalácii Visual Studia Express, ktorá je zadarmo, získate rovnako zadarmo inštaláciu servera pre svoj počítač. Takýto server slúţi na tvorbu a ladenie web stránok. C# je OOP jazyk, ktorý sa beţne pouţíva na tvorbu web stránok. Odvodený je z viacerých programovacích jazykov ako C++ a Java. C# je vhodný na programovanie serverovskej strany webových aplikácii. C# je silno typový jazyk. Typová bezpečnosť je veľmi výhodná pre web, pretoţe odstraňuje chyby vznikajúce z nekontrolovateľnej manipulácie s premennými alebo s pamäťou. Kaţdý objekt v programe je typový tak, ako aj referencia, ktorá naň ukazuje. Kaţdý typ je zodpovedný za prístupové práva ku svojim členom. (CS.VSB, 2013). Ďalšou z výhod je moţnosť pouţiť.net framework, ktorý je veľmi uţitočný na serveri, pretoţe obsahuje kniţnice a funkcie. 2.2 Webforms alebo MVC Spoločnosť Microsoft ponúka dva spôsoby tvorby webových stránok. Sú to Webforms alebo MVC. Obe tieto technológie pristupujú k tvorbe webových aplikácií z iného uhla pohľadu Webforms Webforms sa dajú spôsobom vytvárania prirovnať ku klasickým Winforms (klasické formulárové aplikácie z desktopu). Po otvorení web dizajnéra vo Visual Studiu sa poskladá cieľový formulár z poloţiek v toolboxe. Toolbox obsahuje celú sadu nástrojov ako sú napríklad textové polia, tlačidlá, polia, kalendáre. Týmto elementom je následné potrebné priradiť vlastnosti alebo udalosti. Takáto aplikácia má vlastnosti Winforms, s tým rozdielom, ţe má zloţitejšiu logiku. Docieliť to, aby sa Webform aplikácia správala ako desktopová aplikácia, si vyţaduje doplniť Viewstate. Je to z toho dôvodu, ţe protokol 37

38 HTTP je bezstavový(stateless). (ASPNET.4GUYFROMROLLA, 2007) Vývojári, ktorí pracujú na tvorbe Webforms aplikácie, musia vyriešiť problém spravovania komunikácie medzi klientom a vzdialeným serverom. Je potrebné, aby bola známa aj história tejto komunikácie. Mal by sa uchovávať zapísaný text v textboxoch alebo vybrané dátumy v kalendároch. Server si neuchováva informácie o stave aplikácie. Spracováva poţiadavky od klienta a na ich základe vygeneruje HTML stránku. Ak server doručí stránku klientovi, všetky informácie na serveri zaniknú. Na druhej strane nie je potrebné, aby sa všetky druhy informácií uchovávali, ak sa jedná o ten istý formulár. Niekedy je potrebné udrţať stav formulára. Toto sa dá vyriešiť pomocou Viewstate. Táto technika vyzerá v praxi nasledovne. Klient vyplní formulár s veľkým mnoţstvom informácií. Po odoslaní poţiadavky na server, server vráti výsledok na základe odoslaných údajov. V prípade nesprávnosti údajov ohlási tieto problémy pouţívateľovi. Pouţívateľ sa musí vrátiť späť k formuláru a opraviť chybné informácie. Po opätovnom načítaní formulára, pouţívateľ zistí, ţe všetky zloţito zadané údaje vo vyplnenom formulári boli zmazané. Preto je potrebné stav formulára udrţiavať. Vo Viewstate sa to rieši pomocou skrytých formulárových polí. Formulárové polia uchovávajú na výslednej HTML stránke stav aplikácie a odošle ho s ďalšou poţiadavkou na server. Server konštruuje stránku podľa poţadovaných poţiadaviek, uskutoční poţadované zmeny, vygeneruje Viewstate a stav zabudne. Celá táto činnosť sa vykonáva na pozadí, takţe pouţívateľ má pocit, ţe pracuje s klasickou Winforms aplikáciou. Nevýhodou je zvýšená veľkosť HTML stránky, ktorá obsahuje Viewstate. Webforms je v súčasnej dobe pokladaný za zastaraný koncept, ale pouţíva sa stále Programovanie Webforms v ASP.NET Pre vývoj Webform aplikácie sa dá pouţiť aj obyčajný poznámkový blok, ktorý je súčasťou operačného systému Windows. Ak však chcete vyuţiť kompletné moţnosti ASP.NET, je odporúčané si stiahnuť a nainštalovať Visual Studio. Je moţné si zvoliť voľne dostupný program Visual Studio Express Edition. Tento program nám dovoľuje tvoriť stránku v troch reţimoch: Design: - Tento reţim ukazuje stránku tak, ako bude vyzerať vo webovom prehliadači. Otvorením poloţky toolbox sa nám zobrazí celá paleta pouţívateľských komponentov. Z tejto palety je moţné pohodlne myšou popremiestňovať ţelané komponenty na tvorenú stránku. Táto moţnosť je vhodná aj pre začiatočníkov pretoţe syntax stránky tvorí Visual Studio automaticky. 38

39 Profesionálni programátori túto moţnosť nevyuţívajú, pretoţe nemajú dostatočnú kontrolu nad samotným kódom. Source: - V tomto reţime je moţné vidieť kód stránky, ktorý sa skladá z ASP.NET a HTML kódu. V tomto reţime majú programátori nad kódom úplnu kontrolu. Split:- V tomto reţime sa okno rozdelí na dve časti. Vo vrchnej časti sa nachádza kód (source) stránky a v spodnej časti sa nachádza dizajn stránky. Stlačením pravého tlačidla myši získame prístup ku kódu v programovacom jazyku (napr. C#), kde je moţné zvoleným elementom pridávať vlastnosti. Je tu napríklad moţnosť prisúdiť konkrétnemu tlačidlu kód, ktorý sa vykoná v prípade ţe pouţívateľ stlačil dané tlačidlo. Pridanie serverového komponentu Normálne HTML elementy sú povaţované za text a neodvolávajú sa na server. Ak však prvok obsahuje kód runat= server, povaţuje sa za serverovský komponent. Kaţdý jeden serverovský komponent musí začínať tagom ASP. Potom nasleduje názov daného komponentu. Ďalej nasleduje povinná vlastnosť runat= server a identifikátor. Komponenty sa zapisujú párovými alebo nepárovými tagmi. Dôleţitou vlastnosťou ASP.NET je, ţe dovoľuje programovať webové stránky pomocou event-based modelu. Tento model je podobný ako pri klientských aplikáciách. Dalo by sa to vysvetliť na jednoduchom príklade nasledovne: Ak je pridané tlačidlo na ASP stránku, je potrebné dopísať obsluţnú rutinu pre prípad, ţe tlačidlo bude stlačené. Aj keď je to beţné na webových stránkach, ktoré pracujú výhradne s klientskym skriptom, ASP.NET prenáša tento model na spracovanie na server. Udalosti, ktoré sú vyvolané serverovskými ovládacími prvkami pracujú trochu odlišne ako tradičné HTML stránky alebo webové aplikácie klientskej bázy. Rozdiel plynie najmä z dôvodu oddelenia samotného miesta, kde je udalosť spracovávaná. V aplikáciách postavených na klientskej báze sú udalosti odchytávané a spracovávané na strane klienta. Vo ASP.NET sú však udalosti pochádzajúce od klienta spracovávané na serverovskej strane. Pre udalosti, ktoré sa uskutočnia na klientskej strane vytvorí ASP.NET server control event model mechanizmus, ktorý tieto udalosti zachytí, identifikuje a presmeruje na server cez HTTP. Stránka musí správne identifikovať aká udalosť nastala a následne volať na serveri príslušnú metódu s príslušným kódom. Zodpovedajúca metóda udalosť následne spracuje. Server controls sa rozdeľujú na: HTML server controls 39

40 HTML server controls majú pôvod vo HTML controls, ale sú obohatené o funkciu, ktorá ich umoţňuje spracovávať na serverovskej strane. Sú to HTML elementy, ktoré obsahujú runat= server atribút. Tieto sa mapujú jedna k jednej k zodpovedajúcemu HTML tagu. Obsahujú dodatočné automatické state manaţment. Web sever controls Web server controls sú umiestnené vo ASP.NET stránke. Sú spracovávané ASP.NET runtime. Kaţdý controls má určité vlastnosti, metódy a udalosti. Vývojári vytvárajú stránku prostredníctvom manipulácie s takýmito objektmi, ich vlastnosťami, metódami a udalosťami. Server controls sú objektovo orientované. Majú štandardizovanú sadu vlastností a udalostí. Nie sú priamo mapované (spájané) ku HTML elementom na báze jedna k jednej. Najznámejšie server controls sú: 1. Validation controls 2. Datasource controls 3. Data wiew controls 4. Personalization controls 5. Login security controls 6. Master pages 7. Navigation controls 8. Rich controls (TUTORIALSPOINT, 2013) Model view controller Model view controller (MVC) je o niečo novší koncept ako Webforms. Prináša iný pohľad na tvorbu aplikácií. MVC rozdeľuje webovú aplikáciu na tri časti: Controler: je riadiaci komponent, ktorý prijíma dáta/udalosti od pouţívateľov a následne komunikuje s modelom. Model: je súčasťou aplikácie, ktorá implementuje logiku. View: je šablóna, do ktorej sa vloţia dáta a vzniká výsledná HTML stránka. Cieľom tohto konceptu je zjednodušiť architektúru webovej aplikácie. (COX, 2008) 2.3 Java EE Java Enterprice Edition (JEE) by sa do slovenčiny dalo voľne preloţiť ako Java pre podnikovú sféru. Java EE bola pôvodne vyvinutá ako podniková aplikačná platforma. Jej 40

41 účelom je tvorba robustných webových sluţieb, ktoré sa budú jednoducho vyvíjať a nasádzať. Java EE reprezentuje univerzálny štandard v podnikovej IT. Má za úlohu uľahčiť vývoj, nasadenie a manaţment aplikácií, ktoré sú viacúrovňové a serverovsky orientované. Java EE je určená na tvorbu webových aplikácií, ktoré sú schopné obslúţiť veľké mnoţstvo pouţívateľov súčasne. Dokáţu pracovať s veľkým mnoţstvom dát v databázach. Umoţňujú spoluprácu s ďalšími systémami. Tieto webové aplikácie sú robustné, spoľahlivé a bezpečné. (GONCALVES, 2013) V súčasnosti je najnovšia verzia Java EE7. Táto verzia dovoľuje vývojárom vytvárať dynamické aplikácie v HTML5. Novinkou je Websocket protokol, ktorý urýchľuje komunikáciu. Úlohou JEE je poskytnúť veľké mnoţstvo hotových štandardizovaných komponentov. Tieto komponenty umoţňujú rýchlo a efektívne tvoriť webové aplikácie. JEE podobne ako konkurenčné ASP.NET pracuje na architektúre klient-server. JEE je tradične spustená na aplikačnom serveri Common Gateway Interface Je povaţovaný za prvú praktickú technológiu určenú na tvorbu dynamického serverovského obsahu. Pouţitím CGI server posunul pouţívateľskú poţiadavku na externý program. Tento program sa spustil, vytvoril určený obsah a poslal ho späť pouţívateľovi. Takáto funkcionalita bola obrovským zlepšením oproti statickému obsahu. CGI si rýchlo získal popularitu a následne sa stal štandardom pre tvorbu dynamických web stránok. CGI bol originálne navrhnutý ako štandardná metóda, ktorá podáva informáciu ako má web server komunikovať s externou aplikáciou. Funkcionalita, ktorá dovoľovala generovať dynamické web stránky, bola vlastne len vedľajší efekt. (FALKNER JAYSON, 2004 s. 2) CGI pracuje tak, ţe kaţdá pouţívateľská poţiadavka vytvorila nový proces na serveri. (obrázok 2-1) Pre server sa stávalo veľmi náročné, keď CGI vytváral vţdy nový proces na základe pouţívateľskej poţiadavky. Týmto sa výrazne limitoval počet konkurenčných pouţívateľov, ktorých mohol server obsluhovať Servlety Primárnym cieľom Servletov bolo poskytnúť Java alternatívu pre CGI. Servlety boli navrhnuté tak, aby vyriešili ich hlavné nedostatky. Ich prvá verzia bola vytvorená na obsluhu poţiadavkou dynamického obsahu zasielaného cez HTTP. Neskoršie verzie Java Servlet API predstavili moţnosti správy session. Dnes sú uţ servlety integrálnou súčasťou J2EE architektúry. (FALKNER JAYSON, 2004 s. 32) Java Servlet API je špecifikovaný 41

42 vo Java.servlet a Javax.servlet.HTTP balíčkoch. Java Servlet je trieda, ktorá implementuje Java.servlet, Servlet interface alebo javax.servlet.http.httpservlet triedu. Táto trieda poskytuje abstrakciu potrebnú pre všetky servlety, ktoré komunikujú cez HTTP. (Allamaraju, 2001 str. 80) Podobne, ako CGI aj servlety nechávajú rovnaký program vytvoriť dynamickú odozvu. Na rozdiel od CGI však servlety majú iný ţivotný cyklus. Servletovský ţivotný cyklus povoľuje, aby rovnaký proces obsluhoval viac klientskych poţiadaviek. (obrázok 2-1) Táto moţnosť výrazne zníţila záťaţ serveru tým, ţe jeden hlavný proces spoločne vyuţíva zdroje jedného zo servletov na uspokojenie viacerých pouţívateľských poţiadaviek. Keďţe servlety vyriešili najčastejšie nedostatky CGI, stali sa populárnym riešením pre serverovské funkcionality. Java Servlety sú efektívnym riešením na tvorbu dynamického obsahu web stránok. Výhody servletu vznikli z pouţitia Java platformy a interakcie so servlet kontajnerom. Servlet kontajner poskytuje manaţment ţivotného cyklu. Obrázok 2-1 Rozdiel medzi ţivotným cyklom CGI a ţivotným cyklom servletu. (FALKNER JAYSON, 2004 s. 2-5) Ţivotný cyklus servletu Ţivotný cyklus servletu by sa dal rozdeliť na tri fázy: Inicializácia: je prvá fáza ţivotného cyklu servletu. Táto fáza sa rovnako, ako fáza deštrukcie vykoná iba jedenkrát. V tejto fáze sa inicializujú a vytvoria zdroje, ktoré bude servlet vyţadovať. Všetky servlety musia implementovať javax.servlet.servlet interface. Tento interface definuje 42