1 Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Diplomová práce Docházka a výkazy práce pro systém ...
Za´padoˇceska´ univerzita v Plzni Fakulta aplikovany´ch vˇed Katedra informatiky a vy´poˇcetn´ı techniky
Diplomov´ a pr´ ace Doch´ azka a v´ ykazy pr´ ace pro syst´ em IMIS na platformˇ e Android
Plzeˇ n 2013
Martin Kadlec
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 13. srpna 2013 Martin Kadlec
Podˇ ekov´ an´ı Na tomto m´ıstˇe bych chtˇel podˇekovat Ing. Jiˇr´ımu Jansovi a Ing. Ladislavovi Peˇsiˇckovi za ˇcas vˇenovan´ y konzultac´ım a podnˇetn´e n´avrhy pˇri zpracov´an´ı moj´ı diplomov´e pr´ace.
Abstract Attendance and work records for the IMIS system on Android platform This thesis deals with design and implementation of mobile application for attendance and work records in company. Thesis analyzes architecture of current system and finds a way how to integrate new application to it. Thesis presents development of a RESTful web service on Java EE server and creation of an Android RESTful web service client, while respecting requirements of users and functionality of present system.
´ 1 Uvod T´emˇeˇr v kaˇzd´e organizaci existuje potˇreba evidovat doch´azku zamˇestnanc˚ u. Evidence se vyuˇz´ıv´a jednak pˇri kontrole plnˇen´ı pracovn´ıch povinnost´ı a rovnˇeˇz pˇri zpracov´an´ı mzdov´e agendy. V mnoha organizac´ıch je nav´ıc potˇreba evidovat odvedenou pr´aci. Evidenci lze vyuˇz´ıt pro pr˚ ubˇeˇzn´e sledov´an´ı n´aklad˚ u projektu, mˇeˇren´ı v´ ykonnosti zamˇestnanc˚ u ˇci anal´ yze proces˚ u v organizaci. Syst´em pro evidenci by mˇel kl´ast minim´aln´ı poˇzadavky na zamˇestnance a plnit tak svou funkci s minim´aln´ımi n´aklady. Syst´em by rovnˇeˇz mˇel podporovat Business Intelligence ˇcinnosti. V t´eto diplomov´e pr´aci se konkr´etnˇe zab´ yv´am syst´emem pro evidenci doch´azky a v´ ykaz˚ u pr´ace IMIS vyvinut´em ve spoleˇcnosti CCA Group a.s.. Spoleˇcnost tento syst´em pouˇz´ıv´a pro svoje intern´ı potˇreby a rovnˇeˇz jej implementovala u nˇekter´ ych sv´ ych z´akazn´ık˚ u. C´ılem pr´ace je vybrat a implementovat zvolenou funkˇcnost souˇcasn´eho syst´emu pro mobiln´ı zaˇr´ızen´ı na platformˇe Android. Implementovan´e ˇreˇsen´ı m´a vyuˇz´ıvat vlastnost´ı specifick´ ych pro mobiln´ı zaˇr´ızen´ı. Uˇzivateli m´a pˇrin´est moˇznost snadn´eho a rychl´eho pouˇzit´ı pˇri sluˇzebn´ıch cest´ach ˇci v pˇr´ıpadech, kdy pouze nem´a sv˚ uj pracovn´ı poˇc´ıtaˇc po ruce. Tak´e uvaˇzuje moˇznost, ˇze se uˇzivatel nenach´az´ı v dostupnosti firemn´ı s´ıtˇe a umoˇzn ˇuje nˇekterou ˇcinnost i v offline reˇzimu. Nejprve bude nast´ınˇena problematika evidence doch´azky a v´ ykaz˚ u pr´ace a bude pops´ana technologie pouˇzit´a v souˇcasn´em syst´emu (kap. 2). Kapitola 3 se vˇenuje anal´ yze ˇreˇsen´ı, popisuje v´ ybˇer vhodn´e architektury a s t´ım souvisej´ıc´ı v´ ybˇer vhodn´e webov´e sluˇzby. D´ale analyzuje vyuˇzitelnost k´odu souˇcasn´eho syst´emu pro novou aplikaci. Nakonec se vˇenuje problematice synchronizace dat mezi mobiln´ı aplikac´ı a datab´az´ı organizace. V kapitole 4 je pops´an zp˚ usob zabezpeˇcen´ı implementovan´e aplikace. Kapitola 5 se vˇenuje implementaci webov´e sluˇzby. V kap. 6 bude ˇcten´aˇr sezn´amen s kompletn´ım seznamem funkc´ı implementovan´e klientsk´e aplikace. Posledn´ı kapitola se d´ale vˇenuje problematice v´ yvoje aplikace pro platformu Android a popisuje komponenty pouˇzit´e v implementovan´e aplikaci.
1
2 Souˇcasn´y syst´em Integrovan´ y manaˇzersk´ y informaˇcn´ı syst´em (IMIS) je souˇca´st´ı informaˇcn´ıho syst´emu Ramses ERP vyvinut´eho spoleˇcnost´ı CCA Group a.s.. Jedn´a se o modulov´ y ERP syst´em zab´ yvaj´ıc´ı se oblastmi podnikov´ ych financ´ı, kontrolov´an´ım n´aklad˚ u, personalistikou a ˇcinnostmi podporuj´ıc´ı obchod. Spoleˇcnost tento syst´em sama vyuˇz´ıv´a pro svoje intern´ı potˇreby.
2.1
Vybran´ a funkcionalita
V t´eto pr´aci se zamˇeˇruji na funkcionalitu z oblasti syst´emu vˇenuj´ıc´ı se personalistice. Konkr´etnˇe se jedn´a o moduly pro z´apis pˇr´ıchod˚ u a odchod˚ u na pracoviˇstˇe a vykazov´an´ı proveden´e pr´ace. Jedn´a se o ˇcinnosti, kter´e zamˇestnanec prov´ad´ı jako kaˇzdodenn´ı rutinu a z´aroveˇ n jsou to ˇcinnosti s nejˇsirˇs´ı skupinou uˇzivatel˚ u v r´amci podniku.
2.1.1
Evidence doch´ azky
Doch´azkov´ y syst´em slouˇz´ı k evidenci doch´azky zamˇestnanc˚ u, kter´a se n´aslednˇe vyuˇz´ıv´a k pˇr´ıpravˇe podklad˚ u pro zpracov´an´ı mzdov´e agendy. Eviduje se kaˇzd´ y pˇr´ıchod i odchod z pracoviˇstˇe spoleˇcnˇe s u ´ˇcelem ud´a´ losti. Uˇcel ud´alosti je d˚ uleˇzit´ y, protoˇze d´elka pracovn´ı pˇrest´avky ˇci odchod z pracoviˇstˇe k l´ekaˇri jsou legislativnˇe oˇsetˇren´e z´aleˇzitosti. ˇ Kaˇzd´a ud´alost se zaznamen´av´a s pˇresnost´ı na minuty. Casov´ a osa s pr˚ ubˇehem bˇeˇzn´eho pracovn´ıho dne je zobrazena na obr. 2.1. 4.7.2013 7:00
4.7.2013 11:00
4.7.2013 13:00
4.7.2013 18:01
Příchod Normální
Odchod Oběd
Příchod Normální
Odchod Normální
07:00 - 11:00 Pracovní přítomnost
11:00 - 13:00 Oběd
13:00 - 18:00 Pracovní přítomnost
ˇ Obr´azek 2.1: Casov´ a osa bˇeˇzn´eho pracovn´ıho dne 2
Souˇcasn´y syst´em
Vybran´a funkcionalita
Na obr´azku 2.2 je zn´azornˇen pracovn´ı den se sluˇzebn´ı cestou. Zamˇestnanec nejprve zad´a pˇr´ıchod do norm´aln´ı pracovn´ı doby a s minutov´ ym odstupem n´asleduje sluˇzebn´ı odchod. Po skonˇcen´ı pracovn´ı doby mus´ı podobnˇe zadat i n´avrat. Nejprve zad´a pˇr´ıchod do norm´aln´ı pracovn´ı doby a s minutov´ ym odstupem n´asleduje norm´aln´ı odchod. Logiˇctˇejˇs´ı by bylo zad´avat zaˇc´atek a konec dne sluˇzebn´ı cesty pomoc´ı jedn´e ud´alosti, ale pouˇzit´ y zp˚ usob je nutn´ y z hlediska integrace se souˇcasn´ ym syst´emem. 4.7.2013 8:01
4.7.2013 8:02
4.7.2013 8:03
4.7.2013 8:04
Příchod Normální
Odchod Služebně
Příchod Normální
Odchod Normální
08:01 - 08:02 Pracovní přítomnost
08:02 - 08:03 Služební nepřítomnost
08:03 - 08:04 Pracovní přítomnost
ˇ Obr´azek 2.2: Casov´ a osa pracovn´ıho dne se sluˇzebn´ı cestou
V pˇr´ıpadˇe v´ıcedenn´ı nemoci ˇci sluˇzebn´ı cesty je vykazov´an kaˇzd´ y den samostatnˇe.
2.1.2
Vykazov´ an´ı odveden´ e pr´ ace
Vykazov´an´ı odveden´e pr´ace je jedn´ım ze zp˚ usob˚ u pro pr˚ ubˇeˇznou kontrolu aktivit zamˇestnanc˚ u. Ve firmˇe prob´ıh´a souˇcasnˇe v´ıce projekt˚ u a bez v´ ykaz˚ u by bylo velmi tˇeˇzk´e sledovat pr˚ ubˇeˇznˇe n´aklady jednotliv´ ych projekt˚ u. D´ıky evidenci je moˇzn´e sledovat produktivitu jednotliv´ ych zamˇestnanc˚ u stejnˇe jako nal´ezt slab´a m´ısta v pracovn´ım procesu. V´ ykazy pr´ace jsou propojeny s doch´azkov´ ym syst´emem a je moˇzn´e porovn´avat v´ ystupy z tˇechto syst´em˚ u. Pˇri evidov´an´ı odveden´e pr´ace je nutn´e pˇridˇelit odpracovan´ y ˇcas konkr´etn´ım projekt˚ um.
3
Souˇcasn´y syst´em
2.1.3
Pouˇzit´a technologie
Motivace
Motivac´ı pro vznik t´eto pr´ace bylo vytvoˇrit mobiln´ı aplikaci umoˇzn ˇuj´ıc´ı prov´adˇet kaˇzdodenn´ı agendu - zad´avat pˇr´ıchody, odchody a v´ ykazy pr´ace pro zamˇestnance, kteˇr´ı ˇcasto cestuj´ı a p˚ usob´ı mimo s´ıdlo organizace. Tak´e snaha o vyuˇzit´ı moˇznost´ı mobiln´ıho zaˇr´ızen´ı. Aplikace umoˇzn´ı pohodln´e zad´av´an´ı u ´daj˚ u a pˇrinese moˇznost m´ıt poˇzadovan´e informace po ruce. V´ ysledn´a mobiln´ı aplikace nem´a nahradit vybran´e ˇc´asti pouˇz´ıvan´eho syst´emu, ale poskytnout efektivnˇejˇs´ı alternativu ve vybran´ ych ˇcinnostech.
2.2
Pouˇ zit´ a technologie
Souˇcasn´ y syst´em je postaven na Oracle technologii. Jako uˇzivatelsk´e rozhran´ı pouˇz´ıv´a Oracle Forms a data jsou ukl´ad´ana v Oracle datab´azi.
2.2.1
Oracle Forms
Oracle Forms[18] je softwarov´ y produkt vyvinut´ y spoleˇcnost´ı Oracle. Slouˇz´ı k vytv´aˇren´ı formul´aˇr˚ u, kter´e interaguj´ı s Oracle datab´az´ı. Jako programovac´ı jazyk vyuˇz´ıv´a PL/SQL. Produkt byl p˚ uvodnˇe pouˇz´ıv´an jako termin´alov´e rozhran´ı pro komunikaci se serverem. Pozdˇeji byl pˇrepracov´an do architektury klient-server. Prostˇred´ı bˇehu zajiˇst’uje defaultn´ı spr´avu transakc´ı. D´ıky tomu je Oracle Forms siln´ y n´astroj pro efektivn´ı v´ yvoj aplikac´ı, jejichˇz prim´arn´ım c´ılem je pˇr´ıstup k dat˚ um uloˇzen´ ych v datab´azi.
PL/SQL PL/SQL (Procedural Language/Structured Query Language) je procedur´aln´ı nadstavba jazyka SQL od firmy Oracle zaloˇzen´a na programovac´ım jazyku Ada.
4
Souˇcasn´y syst´em
2.2.2
Pouˇzit´a technologie
Architektura
Oracle Forms pouˇz´ıv´a client-server architekturu. Klient funguje jako tlust´ y klient, kter´ y se kromˇe zobrazen´ı dat star´a o business logiku aplikace. Serverem je myˇslen datab´azov´ y server. Architektura je zn´azornˇena na obr. 2.3.
Forms runtime Prezentační vrstva Aplikační vrstva SQL Správce dat PL/SQL Engine
Databázový server
Klient
Obr´azek 2.3: Klient-server architektura Oracle Forms aplikace
Forms prostˇ red´ı bˇ ehu • Prezentaˇ cn´ı vrstva Zobrazuje informace pro uˇzivatele formou grafick´eho uˇzivatelsk´eho rozhran´ı. Kontroluje zad´avan´e vstupy. • Aplikaˇ cn´ı vrstva Star´a se o proveden´ı aplikaˇcn´ı logiky. • Spr´ avce dat ˇ ıd´ı datab´azov´e Star´a se o zpracov´an´ı dat se kter´ ymi formul´aˇr pracuje. R´ transakce. • PL/SQL Engine Komponenta kter´a zpracov´av´a PL/SQL k´od. Star´a se o proveden´ı procedur´aln´ıho (PL) k´odu a SQL k´od pˇred´av´a ke zpracov´an´ı datab´azi.
Datab´ aze Datab´aze obsahuje data a k´od, kter´ y s tˇemito daty pracuje (triggery, procedury, funkce).
5
Souˇcasn´y syst´em
2.2.3
Pouˇzit´a technologie
Komponenty formul´ aˇ re
Z hlediska architektury se Oracle Forms aplikace skl´ad´a z tˇechto celk˚ u (obr. 2.4):
Moduly Modul formul´ aˇ re Modul formul´aˇre je hlavn´ı komponenta aplikace. Poskytuje k´od nezbytn´ y pro interakci s u ´loˇziˇstˇem a uˇzivatelsk´ ym rozhran´ım. Data poskytovan´a datab´az´ı jsou reflektovan´a v prvc´ıch uˇzivatelsk´eho rozhran´ı jako jsou textov´a pole, zaˇskrt´avac´ı pol´ıˇcka, pˇrep´ınaˇce, tlaˇc´ıtka atd. Formul´aˇr je logicky organizov´an do blok˚ u. Existuj´ı dva typy blok˚ u: • Datov´ y blok Datov´ y blok zobrazuje zdrojov´a data a poskytuje abstrakci pro zp˚ usob jak´ ym jsou tato data z´ısk´av´ana. Blok m˚ uˇze b´ yt asociov´an s datab´azovou tabulkou, datab´azov´ ym pohledem, uloˇzenou procedurou, dotazem do datab´aze nebo transakˇcn´ım triggerem. Asociace datov´eho bloku a datab´azov´ ych dat standardnˇe umoˇzn ˇujˇe pˇr´ıstup k tˇemto dat˚ um a jejich modifikaci. Datov´e bloky mohou b´ yt navz´ajem sv´az´any vztahem rodiˇc - potomek. Takov´ y vztah pˇredstavuje relaci 1:N datab´azov´ ych tabulek. Oracle Forms zajiˇst’uje to, ˇze pˇri spojen´ı mezi master a detail bloky se zobraz´ı pouze ty detail bloky, kter´e jsou v´az´any na master blok pˇres ciz´ı kl´ıˇc. ˇ ıd´ıc´ı blok • R´ ˇ ıd´ıc´ı blok Pˇredstavuje blok, kter´ y nem´a vztah k datab´azov´e tabulce. R´ m˚ uˇze obsahovat jak´ekoli prvky uˇzivatelsk´eho rozhran´ı. Prvky mohou slouˇzit k uloˇzen´ı doˇcasn´ ych promˇen´ ych nebo k zobrazen´ı dat, kter´e nemaj´ı pˇr´ımou vazbu s datab´az´ı.
Modul menu Modul obsahuje hierarchii menu. Kaˇzd´e menu obsahuje zvoliteln´e poloˇzky. Kaˇzd´ y formul´aˇr obsahuje defaultn´ı menu obsahuj´ıc´ı pˇr´ıkazy pro z´akladn´ı DML operace s datab´az´ı CRUD.
Modul PL/SQL knihovny Modul obsahuje znovu vyuˇziteln´ y k´od, kter´ y m˚ uˇze b´ yt vyuˇzit jin´ ymi formul´aˇri, menu ˇci knihovnami. Programov´e jednotky 6
Souˇcasn´y syst´em
Pouˇzit´a technologie
knihovny mohou b´ yt funkce, procedury a bal´ıˇcky. Programov´e jednotky jsou spouˇstˇeny na stranˇe klienta. Mohou obsahovat business logiku. Knihovny jsou nez´avisl´e na formul´aˇri, jsou zav´adˇeny dynamicky a mohou b´ yt z´aroveˇ n vyuˇz´ıv´any v´ıce formul´aˇri. ˇ s´ı Modul knihovny objekt˚ u Modul obsahuje znovu vyuˇziteln´e objekty. Reˇ uskladnˇen´ı, spr´avu a distribuci tˇechto objekt˚ u, kter´e mohou b´ yt vyuˇzity jin´ ymi formul´aˇri, menu ˇci knihovnami. Vyuˇz´ıv´an´ı tohoto modulu pˇrin´aˇs´ı pˇr´ınosy v podobˇe u ´spory pamˇeti pˇri bˇehu aplikace.
Obr´azek 2.4: Komponenty Oracle Forms aplikace[20]
7
Souˇcasn´y syst´em
Pouˇzit´a technologie
Triggery Aplikace v Oracle pracuje s n´asleduj´ıc´ımi typy trigger˚ u: • Block-processing triggers - jsou spouˇstˇeny pˇri ud´alosti na poloˇzce patˇr´ıc´ı tomuto bloku. • Interface event triggers - jsou spouˇstˇeny pˇri ud´alosti v uˇzivatelsk´em rozhran´ı formul´aˇre. • Master-detail triggers - jsou spouˇstˇeny pˇri ud´alosti souvisej´ıc´ı se vztahem rodiˇc - potomek na dan´ ych bloc´ıch. Napˇr. pˇri zmˇenˇe poloˇzky rodiˇce pˇr´ısluˇsn´ y trigger zobraz´ı pˇr´ısluˇsn´e poloˇzky v bloku potomka. • Message-handling triggers - zpracov´avaj´ı zobrazen´ı chybov´ ych ˇci informaˇcn´ıch zpr´av. • Navigational triggers - jsou spouˇstˇeny pˇri navigaci po poloˇzk´ach formul´aˇre. • Query-time triggers - jsou spouˇstˇeny na u ´rovni bloku pˇred a po dotazu do datab´aze. • Validation triggers - jsou spouˇstˇeny pˇri validaci z´aznamu v poloˇzce. • Transactional triggers - vyvolaj´ı se pˇri r˚ uzn´ ych ud´alostech souvisej´ıc´ı s interakc´ı s datov´ ym u ´loˇziˇstˇem. Pokud se jedn´a o datov´ y blok, kter´ y je sv´az´an s tabulkou v datab´azi, prostˇred´ı bˇehu automaticky zajiˇstuje DML pro tyto bloky. Pokud v´ yvoj´aˇr poˇzaduje nestandardn´ı akci pˇri tˇechto u ´konech, provede pˇrekryt´ı tˇechto trigger˚ u s vlastn´ı definovanou akc´ı.
8
Souˇcasn´y syst´em
2.2.4
Vybran´e formul´aˇre
Uˇ zivatelsk´ e rozhran´ı
Pˇri pohledu na uˇzivatelsk´e rozhran´ı se Oracle Forms aplikace skl´ad´a z tˇechto objekt˚ u (obr. 2.5):
Obr´azek 2.5: Objekty uˇzivatelsk´eho rozhran´ı Oracle Forms aplikace[20]
Pl´atno je objekt, na kter´ y je nakresleno cel´e GUI formul´aˇre, tedy vˇsechny viditeln´e objekty. Okno ohraniˇcuje plochu pl´atna, kter´a bude zobrazena. Pl´atno je zobrazeno v oknˇe. Blok sdruˇzuje jednotliv´e poloˇzky, jeˇz se vztahuj´ı ke stejn´emu datab´azov´emu objektu.
Seznam hodnot Seznam hodnot je prvek uˇzivatelsk´eho rozhran´ı, kter´ y uˇzivateli nab´ız´ı v´ ybˇer hodnot. V´ ybˇer m˚ uˇze b´ yt na z´akladˇe pevnˇe dan´ ych dat ˇci dotazem do datab´aze.
2.3
Vybran´ e formul´ aˇ re
V t´eto kapitole jsou pops´any formul´aˇre pro vybranou funkˇcnost syst´emu. Konkr´etnˇe se jedn´a o formul´aˇre pro z´apis pˇr´ıchod˚ u a odchod˚ u na pracoviˇstˇe a vykazov´an´ı proveden´e pr´ace. 9
Souˇcasn´y syst´em
2.3.1
Vybran´e formul´aˇre
Z´ apis pˇ r´ıchod˚ u a odchod˚ u
Obr´azek 2.6: Formul´aˇr pro z´apis pˇr´ıchod˚ u a odchod˚ u • Poloˇzky bloku pro z´apis doch´azky K´ od - identifik´ator zamˇestnance. Heslo - heslo zamˇestnance. Pokud heslo nem´a, z˚ ust´av´a pr´azdn´e pole. Druh - druh ud´alosti, pˇr´ıchod ˇci odchod. K´od ud´alosti. Popis - dopln´ı se automaticky podle k´odu ud´alosti. Pozn´ amka - voliteln´a pozn´amka. Datum - datum ud´alosti. ˇ Cas - ˇcas ud´alosti. • Pole Denn´ı z´aznamy - zobrazuje denn´ı doch´azku formou strukturovan´eho ˇretˇezce. • Pole s tlaˇc´ıtky - umoˇzn ˇuje akce, kter´e nejsou pro potˇreby c´ılov´e aplikace relevantn´ı.
10
Souˇcasn´y syst´em
2.3.2
Vybran´e formul´aˇre
V´ ykaz pr´ ace
Obr´azek 2.7: Formul´aˇr pro pracovn´ı v´ ykazy • Poloˇzky bloku Uˇzivatel zobrazuj´ı identifikaci uˇzivatele. D´ale jsou zde statistiky stav˚ u, ve kter´ ych se nach´az´ı v´ ykaz. V posledn´ım ˇra´dku je zobrazen mˇes´ıˇcn´ı souˇcet odpracovan´eho a vyk´azan´eho ˇcasu. • V bloku Datum je zobrazen mˇes´ıˇcn´ı kalend´aˇr. • V bloku V´ykaz pr´ace - hodiny jsou v´ ykazy pro zvolen´ y den: Stav v´ ykazu - vypsan´ y, potvrzen´ y, schv´alen´ y, uzavˇren´ y. Zak´ azka - identifikace zak´azky. Pracoviˇ stˇ e - identifikace pracoviˇstˇe. Hl´ aˇ sen´ı - chybov´e hl´aˇsen´ı, kter´e bylo podnˇetem pro tento u ´kol. Organizace - identifikace organizace. Popis ˇ cinnosti - zamˇestnanc˚ uv popis odveden´e ˇcinnosti. • V bloku V´ykaz pr´ace - Km jsou v´ ykazy j´ızd pro zvolen´ y den: Auto - identifikace vozidla. Km - poˇcet ujet´ ych km. • Pole se statistikami zobrazuje denn´ı souˇcet odpracovan´e doby, vyk´azan´e doby, ujet´ ych km. • Pole s tlaˇc´ıtky - jedin´a relevantn´ı akce je zmˇena zobrazovan´eho mˇes´ıce.
11
3 Anal´yza V t´eto kapitole je analyzov´an souˇcasn´ y syst´em a navrˇzeno ˇreˇsen´ı c´ılov´e aplikace. Nejprve pop´ıˇsu zvolenou architekturu a s t´ım souvisej´ıc´ı v´ ybˇer typu webov´e sluˇzby. D´ale popisuji datovou vrstvu jak souˇcasn´eho syst´emu tak i c´ılov´e aplikace a popisuji nˇekter´e v´ yhrady k datov´e vrstvˇe souˇcasn´eho syst´emu. Popisuji kde vˇsude se nach´az´ı business logika relevantn´ı pro funkˇcnost c´ılov´e aplikace a moˇznosti vyuˇzit´ı souˇcasn´eho k´odu. Popisuji zp˚ usob synchronizace dat mezi klientskou aplikac´ı a podnikovou datab´az´ı. Nakonec zmiˇ nuji nˇekter´e aspekty t´ ykaj´ıc´ı se uˇzivatelsk´eho rozhran´ı c´ılov´e aplikace.
3.1
Architektura ˇ reˇ sen´ı
Pˇri n´avrhu architektury jsem se rozhodoval mezi tˇremi variantami: pˇr´ım´e spojen´ı Android aplikace ke vzd´alen´e datab´azi pomoc´ı JDBC, synchronizaci dat se vzd´alenou datab´az´ı pomoc´ı Oracle Database Mobile Server a nakonec s vyuˇzit´ım webov´e sluˇzby, kter´a by slouˇzila jako rozhran´ı mezi klientskou aplikac´ı a datab´azov´ ym serverem.
3.1.1
Pˇ r´ım´ e pˇ ripojen´ı k datab´ azi
Pˇrestoˇze pˇr´ım´e pˇripojen´ı k Oracle datab´azi pomoc´ı JDBC je moˇzn´e, tuto variantu jsem zam´ıtl. Pˇripojen´ı pomoc´ı JDBC je prim´arnˇe urˇceno pro stabiln´ı s´ıt’ov´e pˇripojen´ı, kter´e m´a malou odezvu a n´ızkou ztr´atu paket˚ u. Vyuˇzit´ı JDBC by pˇrineslo probl´emy v podobˇe ˇspatn´e odezvy aplikace, kv˚ uli znovu navazov´an´ı spojen´ı a vytv´aˇren´ı nov´ ych datab´azov´ ych relac´ı, kter´e musely b´ yt v d˚ usledku ztr´aty konektivity ukonˇceny. Vzhledem k tomu, ˇze p˚ uvodn´ı Forms aplikace funguje jako tlust´ y klient, prov´ad´ı veˇskerou business logiku. Tato logika je zapotˇreb´ı ke spr´avn´e funkˇcnosti syst´emu. Bylo by tedy nutn´e pˇren´est tuto logiku na stranu klienta a potˇreba komunikace se vzd´alenou datab´az´ı by byla vˇetˇs´ı neˇz k pouh´emu pˇrenesen´ı dat.
12
Anal´yza
3.1.2
Architektura ˇreˇsen´ı
Oracle Database Mobile Server
Oracle Database Mobile Server 11g[17] je server zajiˇst’uj´ıc´ı synchronizaci dat mezi Oracle datab´az´ı a mobiln´ımi zaˇr´ızen´ımi. Kl´ıˇcovou vlastnost´ı tohoto produktu je synchronizaˇcn´ı j´adro, kter´e je schopno zajistit synchronizaci velk´eho poˇctu mobiln´ıch zaˇr´ızen´ı se vzd´alen´ ym datab´azov´ ym syst´emem. Pˇrestoˇze bylo toto synchronizaˇcn´ı j´adro navrˇzeno pro stabiln´ı pˇripojen´ı, je schopn´e zajistit spolehlivou funkci i pˇri nestabiln´ım pˇripojen´ı. V pˇr´ıpadˇe, ˇze je spojen´ı pˇreruˇseno, synchronizace je pozastavena a po nav´az´an´ı spojen´ı pokraˇcuje v m´ıstˇe pˇreruˇsen´ı. D´ale umoˇzn ˇuje ˇsifrov´an´ı dat pro pˇrenos i pro jejich persistenci. Tato varianta byla zam´ıtnuta, protoˇze ˇreˇs´ı pouze synchronizaci dat a neumoˇzn ˇuje zajistit proveden´ı business logiky. Dalˇs´ım d˚ uvodem je skuteˇcnost, ˇze jej´ı pouˇzit´ı by vyˇzadovalo zakoupen´ı licence pro tento server. Server je moˇzn´e spustit na serverech Oracle WebLogic Server a Oracle Glassfish. Mobiln´ı klient, kter´ y bˇeˇz´ı na stranˇe mobiln´ıho zaˇr´ızen´ı zajiˇst’uje spr´avu zaˇr´ızen´ı nutnou k synchronizaci. Tento klient je dostupn´ y pro platformy Java, Android, Blackberry, Windows a Linux.
3.1.3
Webov´ a sluˇ zba
Jako pouˇzitou architekturu jsem zvolil pouˇzit´ı webov´e sluˇzby, kter´a bude fungovat jako rozhran´ı mezi klientskou aplikac´ı a datab´azov´ ym serverem. Android klient v t´eto architektuˇre funguje jako tenk´ y klient spravuj´ıc´ı jen ˇc´ast funkˇcnosti z p˚ uvodn´ıho tlust´eho klienta. Business logika je um´ıstˇena na stranˇe webov´e sluˇzby. D´ıky tomu, ˇze webov´a sluˇzba bude um´ıstˇena v bl´ızkosti firemn´ı datab´aze, dojde k minimalizace odezvy pˇri zajiˇstˇen´ı business logiky syst´emu. Mezi klientem a webovou sluˇzbou budou pˇren´aˇsena pouze data, kter´a jsou opravdu nutn´a. Z pohledu rozˇsiˇritelnosti syst´emu o dalˇs´ı mobiln´ı platformy se ˇreˇsen´ı pomoc´ı webov´e sluˇzby jev´ı rovnˇeˇz v´ yhodnˇe. Business logika by nebyla implementov´ana ani na klientsk´ ych aplikac´ıch jin´ ych platforem. Pˇri zmˇenˇe logiky bude potˇreba u ´pravy v k´odu pouze na stranˇe webov´e sluˇzby. C´ılov´a architektura je vyobrazena na obr´azku 3.1.
13
Anal´yza
3.1.4
Architektura ˇreˇsen´ı
Zvolen´ a architektura
Android aplikace funguje jako tenk´ y klient, kter´ y se pˇripojuje k webov´e sluˇzbˇe. Webov´a sluˇzba pˇristupuje k samotn´e datab´azi. Jednotliv´e komponenty jsou zobrazeny na obr. 3.1 a pops´any n´ıˇze: • Android - aplikace je podporovan´a od API 10. Obsahuje persistentn´ı u ´loˇziˇstˇe. Pro komunikaci s webovou sluˇzbou je urˇcena AsyncTask komponenta, kter´a ukl´ad´a z´aznamy do datab´aze. Z´aznamy z datab´aze jsou zobrazeny v uˇzivatelsk´em rozhran´ı AsyncActvity. Kromˇe tohoto scen´aˇre se nav´ıc bude u ´loˇziˇstˇe automaticky synchronizovat s datab´azov´ ym serverem prostˇrednictv´ım webov´e sluˇzby (nen´ı zobrazeno na obr. 3.1). • Webov´a sluˇzba - je implementov´ana v Java EE 6. Dodrˇzuje RESTful principy s vyuˇzit´ım Java API pro RESTful webov´e sluˇzby (JAXRS) 1.1. Webov´a sluˇzba zpˇr´ıstupˇ nuje data pro klienta prostˇrednictvn´ım Provider komponent zpracov´avaj´ıc´ı HTTP poˇzadavek. Data jsou z´ısk´av´ana z datab´aze pomoc´ı DAO (Data Access Object) objekt˚ u. Jako produkˇcn´ı aplikaˇcn´ı server bude pouˇzit GlassFish 4. • Datab´azov´ y server - hostuje datab´azi Oracle 10g, kter´a obsahuje data ke kter´ ym Android aplikace pˇristupuje. Nav´ıc obsahuje datab´azov´e procedury a funkce, kter´e jsou souˇca´st´ı bussines logiky pouˇz´ıvan´e v souˇcasn´em syst´emu.
«zařízení» Android zařízení Android aplikace
«zařízení» Aplikační server
«zařízení» Databázový server
«prostředí běhu» Servlet kontejner
«databázový systém» Oracle 10g
HTTP AsyncTask Provider
AsyncActivity
JDBC DAO
Obr´azek 3.1: Diagram nasazen´ı
14
Anal´yza
3.2
V´ybˇer typu webov´e sluˇzby
V´ ybˇ er typu webov´ e sluˇ zby
Po zvolen´ı architektury vyuˇz´ıvaj´ıc´ı webovou sluˇzbu n´asleduje v´ ybˇer vhodn´eho typu webov´e sluˇzby. V u ´vahu pˇrich´az´ı varianty ˇreˇsen´ı s vyuˇzit´ım SOAP protokolu ˇci REST architektury.
3.2.1
Representational State Transfer
Representational State Transfer[2] (REST) je architektonick´ y styl pro distribuovan´ y syst´em. Architektura vyuˇz´ıv´a tˇechto vlastnost´ı: Klient-server Vyuˇz´ıv´a se architektura klient-server z d˚ uvodu rozdˇelen´ı zodpovˇednost´ı pro komponenty syst´emu (Separation of concerns). Klient je zodpovˇedn´ y za uˇzivatelsk´e rozhran´ı, d´ıky tomu je z´ısk´ana vˇetˇs´ı pˇrenositelnost na jin´e platformy. Na stranˇe serveru, kter´ y je zodpovˇedn´ y za datovou vrstvu, se z´ısk´a v´ yhoda vˇetˇs´ı ˇsk´alovatelnosti. Bezestavost Komunikace prob´ıh´a bezestavovˇe. Kaˇzd´ y poˇzadavek mus´ı obsahovat vˇsechny informace nutn´e k jeho vyˇr´ızen´ı. Pokud je nutn´e pamatovat si stav, je to zodpovˇednost´ı klienta. D´ıky tomu se zvyˇsuje spolehlivost syst´emu, protoˇze to usnadˇ nuje zotaven´ı se ze stavu ˇca´steˇcn´eho selh´an´ı. Tak´e se zvyˇsuje ˇsk´alovatelnost, protoˇze server si nemus´ı udrˇzovat informaci o stavu a d´ıky tomu potˇrebuje m´enˇe zdroj˚ u. Rovnˇeˇz je snazˇs´ı takov´ y server implementovat. Mezipamˇ et’ Data pˇrij´ıman´a jako odpovˇed’ ze serveru mus´ı b´ yt oznaˇcena, zda mohou b´ yt uloˇzena do mezipamˇeti klienta ˇci nikoli. Pokud jsou uloˇzena, klient je m˚ uˇze vyuˇz´ıt opakovanˇe. D´ıky tomu je sn´ıˇzen poˇcet interakc´ı. Jednotn´ e rozhran´ı Zdroje jsou identifikov´any pomoc´ı URI, kter´e ale nez´avis´ı na tom, jak´ ym zp˚ usobem budou data vr´acena klientovi. Kaˇzd´ y poˇzadavek na server obsahuje informaci, jak´ ym zp˚ usobem maj´ı b´ yt data zpracov´ana (pomoc´ı MIME hlaviˇcky HTTP poˇzadavku). V´ıcevrstevn´ y syst´ em Klient nemus´ı z´ısk´avat data pˇr´ımo ze serveru, na kter´ y se obrac´ı. Server m˚ uˇze fungovat jako prostˇredn´ık, kter´ y je s´am v roli klienta v˚ uˇci jin´emu uzlu syst´emu. Rozdˇelen´ı syst´emu do v´ıce vrstev m˚ uˇze b´ yt vyuˇzito k zapouzdˇren´ı zastaral´ ych sluˇzeb, k ochranˇe 15
Anal´yza
V´ybˇer typu webov´e sluˇzby
nov´ ych sluˇzeb pˇred zastaral´ ymi klienty ˇci zjednoduˇsen´ı komponent d´ıky sd´ılen´ı zˇr´ıdka vyuˇz´ıvan´ ych sluˇzeb. Jin´ ym pˇr´ınosem m˚ uˇze b´ yt zlepˇsen´ı ˇsk´alovatelnosti d´ıky rozloˇzen´ı z´atˇeˇze mezi v´ıce uzl˚ u na stejn´e vrstvˇe syst´emu. K´ od na poˇ z´ ad´ an´ı Server m˚ uˇze klientovi poskytovat k´od, kter´ y je spustiteln´ y na stranˇe klienta a pˇrin´est tak dalˇs´ı funkcionalitu.
RESTful web API Syst´em kter´ y vyuˇz´ıv´a principy REST se oznaˇcuje jako RESTful. RESTful webov´e API je webov´e API vyuˇz´ıvaj´ıc´ı HTTP a REST principy. Jedn´a se o kolekci zdroj˚ u s tˇemito definovan´ ymi aspekty: • z´akladn´ı URI pro webov´e API • typ internetov´eho m´edia dat poskytovan´ ych API (JSON, XML nebo jin´ y splˇ nuj´ıc´ı hypertextov´e standarty) • mnoˇzina operac´ı podporovan´a webov´ ym API pomoc´ı HTTP method – k z´ısk´an´ı zdroje se pouˇz´ıv´a GET metoda – k aktualizaci zdroje se pouˇz´ıv´a PUT metoda – k vytvoˇren´ı zdroje se pouˇz´ıv´a POST metoda – ke smaz´an´ı zdroje se pouˇz´ıv´a DELETE metoda • API mus´ı b´ yt ˇr´ızeno hypertextovˇe
3.2.2
Simple Object Access Protocol
Simple Object Access Protocol (SOAP) je standardizovan´ y protokol pro v´ ymˇenu dat mezi webov´ ymi sluˇzbami. Protokol ˇr´ıd´ı v´ ymˇenu zpr´av mezi poskytovatelem a konzumentem sluˇzby. Komunikace prob´ıh´a vˇetˇsinou pomoc´ı HTTP protokolu, kter´ y je pouˇzit z d˚ uvodu lepˇs´ı prostupnosti pˇres zabezpeˇcuj´ıc´ı s´ıt’ov´e prvky. Existuje nˇekolik r˚ uzn´ ych druh˚ u ˇsablon pro komunikaci na protokolu SOAP. Nejzn´amˇejˇs´ı z nich je RPC ˇsablona, kde jeden z u ´ˇcastn´ık˚ u komunikace funguje jako klient a druh´ y jako server. Server odpov´ıd´a na poˇzadavky klienta. 16
Anal´yza
V´ybˇer typu webov´e sluˇzby
Na obr. 3.2 je zn´azornˇen vztah z´akladn´ıch technologi´ı pouˇz´ıvan´ ych u webov´e sluˇzby vyuˇz´ıvaj´ıc´ı SOAP protokol.
Obr´azek 3.2: Vztah tˇr´ı z´akladn´ıch technologi´ı (SOAP, WSDL a UDDI) webov´ ych sluˇzeb[10]
Webov´ a sluˇ zba Poskytovatel sluˇzby. Ke sluˇzbˇe se pˇristupuje pomoc´ı endpoint URL. Endpoint URL definuje um´ıstˇen´ı sluˇzby, kde poskytovatel oˇcek´av´a pˇr´ıchoz´ı poˇzadavky. Klient Konzument sluˇzby, kter´ y si v UDDI registru vyhled´a poˇzadovanou sluˇzbu. N´aslednˇe sestav´ı zpr´avu podle specifikace a kontaktuje poskytovatele. UDDI[14] (Universal Description, Discovery, and Integration) registr je m´ısto, kter´e poskytuje informace o dostupn´ ych sluˇzb´ach a jejich poskytovatel´ıch. WSDL[22] (Web Services Description Language) je jazyk, kter´ ym je popisov´ana funkcionalita poskytovan´a webovou sluˇzbou. WSDL soubor poskytuje strojovˇe ˇciteln´ y popis toho, jak m˚ uˇze b´ yt sluˇzba vol´ana, jak´e parametry oˇcek´av´a a jak´e datov´e struktury vrac´ı.
17
Anal´yza
3.2.3
Datov´a vrstva
Od˚ uvodnˇ en´ı v´ ybˇ eru
Vzhledem k tomu, ˇze webov´a sluˇzba m´a slouˇzit ke spr´avˇe vzd´alen´e datab´aze, jev´ı se REST se svoj´ı CRUD matic´ı operac´ı jako jasn´a volba. Pˇri pouˇzit´ı REST spoleˇcnˇe s pˇrenosem dat ve form´atu JSON bude objem pˇrenesen´ ych dat mal´ y, coˇz je d˚ uleˇzit´e, protoˇze klientskou aplikac´ı m´a b´ yt mobiln´ı zaˇr´ızen´ı. Webovou sluˇzbu vyuˇz´ıvaj´ıc´ı REST bude ve srovn´an´ı se SOAP snadnˇejˇs´ı implementovat. Jedinou nev´ yhodou bude bezestavovost komunikace, kter´a pˇrin´aˇs´ı nutnost prov´adˇen´ı procesu autentizace pro kaˇzd´ y poˇzadavek.
3.3
Datov´ a vrstva
V t´eto kapitole analyzuji datovou vrstvu syst´emu. Identifikuji datov´e entity, kter´e jsou relevantn´ı pro zkoumanou ˇca´st syst´emu a popisuji nˇekter´e nedostatky pouˇz´ıvan´eho datov´eho sch´ematu.
3.3.1
Datov´ y model
V n´asleduj´ıc´ım diagramu (obr. 3.3) zobrazuji entity nach´azej´ıc´ı se v syst´emu, kter´e jsou relevantn´ı pro zkoumanou ˇca´st syst´emu. Dalˇs´ı tabulky a ˇc´ıseln´ıky jsou pro jednoduchost vypuˇstˇeny. Zaměstnanec
-zaznamenává -je zaznamenán
*
1
1 -vykazuje
1
Záznam 1
-je vykazován
-je
Výkaz
-je -vztahuje se
*
-vztahuje se
*
*
Osoba 1
Den 1
Obr´azek 3.3: Diagram relevantn´ıch entit nach´azej´ıc´ıch se v syst´emu
18
Anal´yza
Datov´a vrstva
Jednotliv´e entity a jejich popis: Z´ aznam Pˇr´ıchod nebo odchod na pracoviˇstˇe. Obsahuje informaci o ˇcase, datu, u ´ˇcelu a pˇr´ıpadnˇe zamˇestnanc˚ uv kr´atky popis ud´alosti. V´ ykaz Pracovn´ı v´ ykaz. Obsahuje informaci o ˇcase, datu, osobˇe zadavatele, osobˇe ˇreˇsitele, vykazovan´e dobˇe, vazbu na zak´azku ˇci chybov´e hl´aˇsen´ı, stav v´ ykazu, zamˇestnanc˚ uv popis ˇcinnosti. Zamˇ estnanec Zamˇestnanec a jeho pˇr´ısluˇsnost k pracovn´ımu oddˇelen´ı, funkce, vedouc´ı pracovn´ık a typ u ´vazku. Osoba Podrobnˇejˇs´ı informace o osobˇe zamˇestnance, jm´eno, pracovn´ı zkratka. Den Den ke kter´emu se v´aˇze v´ ykaz ˇci z´aznam. Slouˇz´ı k rozliˇsen´ı pracovn´ıch dn˚ u a sv´atk˚ u.
3.3.2
Datov´ y model v mobiln´ı aplikaci
Na stranˇe Android aplikace budou persistentnˇe ukl´ad´any pouze tyto entity: Z´ aznam Pˇr´ıchod nebo odchod na pracoviˇstˇe pro uˇzivatele, kter´ y rovnˇeˇz vytv´aˇr´ı z´aznamy prostˇrednictv´ım mobiln´ı aplikace. D´ale z´aznamy ostatn´ıch uˇzivatel˚ u, kter´e si uˇzivatel st´ahne k prohl´ıˇzen´ı. V´ ykaz V´ ykazy pr´ace kter´e si uˇzivatel st´ahne k prohl´ıˇzen´ı. Zamˇ estnanec Lok´aln´ı datab´aze zamˇestnanc˚ u, kde se ukl´adaj´ı z´akladn´ı u ´daje spoleˇcnˇe s informac´ı o posledn´ı doch´azkov´e ud´alosti. Datab´aze zamˇestnanc˚ u bude slouˇzit pro naplnˇen´ı rozbalovac´ı nab´ıdky pro v´ ybˇer zamˇestnance, kter´a bude souˇca´st´ı uˇzivatelsk´eho rozhran´ı. Dalˇs´ı vyuˇzit´ı je pro zobrazen´ı seznamu pˇr´ıtomn´ ych zamˇestnanc˚ u. Data budou ukl´adan´e ve tˇrech tabulk´ach SQLite datab´aze. Datov´ y model nebude ˇreˇsit referenˇcn´ı integritu tˇechto tabulek. Zajiˇstˇen´ı referenˇcn´ı integrity je z´aleˇzitost´ı datab´aze syst´emu a jej´ı zajiˇstˇen´ı na stranˇe klienta je zbyteˇcn´e.
19
Anal´yza
3.3.3
Datov´a vrstva
Pr´ ace s datem a ˇ casem
Pˇri n´avrhu datov´eho modelu jsem ˇreˇsil probl´em pomoc´ı jak´eho datov´eho typu vyjadˇrovat u ´daj o ˇcase ˇci datu. V Oracle datab´azi je pouˇzit datov´ y typ Date. SQLite datab´aze nab´ız´ı tˇri zp˚ usoby jako ukl´adat informaci o ˇcase: • TEXT podle ISO8601 normy ve form´atu ”YYYY-MM-DD HH:MM:SS.SSS”. • REAL podle Juli´ansk´eho kalend´aˇre, poˇcet dn´ı od poledne 24. Listopadu roku 4714 pˇred Kristem (Greenwichsk´eho ˇcasu). • INTEGER jako Unix Time, poˇcet sekund 1970-01-01 00:00:00 UTC. Pro uloˇzen´ı v SQLite datab´azi jsem zvolil typ INTEGER. V aplikaci (Android klient, webov´a sluˇzba) jsem se rozhodl reprezentovat ˇcasov´ y u ´daj pomoc´ı primitivn´ıho typu long. Mˇel jsem k tomu ˇradu dobr´ ych d˚ uvod˚ u: • odpad´a starost s form´atem data pˇri serializaci a deserializace JSON ˇretˇezce • snadn´e porovn´av´an´ı hodnot pomoc´ı relaˇcn´ıch oper´ator˚ u • sn´ıˇz´ı se poˇcet konverz´ı v aplikaci (napˇr. pro v´ ypoˇcet pozice pro vykreslen´ı komponenty v UI) Tak´e jsem se ujistil, ˇze rozsah typu long je pro potˇreby aplikace dostaˇcuj´ıc´ı. Srovn´an´ı pouˇzit´ ych datov´ ych typ˚ u je zn´azornˇeno v tabulce 3.1. Datov´ y typ Oracle Date SQLite INTEGER Java long
Minim´aln´ı hodnota January 1, 4712 BCE
Maxim´aln´ı hodnota December 31, 4712 CE
Pˇresnost s
2.12.292269055 BC
17.8.292278994 AD
ms
2.12.292269055 BC
17.8.292278994 AD
ms
Tabulka 3.1: Datov´e typy reprezentuj´ıc´ı ˇcasov´ yu ´daj
20
Anal´yza
3.3.4
Datov´a vrstva
V´ yhrady k datov´ e vrstvˇ e
Pˇri pr´aci s datovou vrstvou aplikace jsem vyhodnotil nˇekter´e vlastnosti jako d˚ usledek ˇspatn´eho n´avrhu datov´eho sch´ematu.
Tabulka bez prim´ arn´ıho kl´ıˇ ce Tabulka pro evidenci doch´azkov´ ych ud´alosti neobsahuje prim´arn´ı kl´ıˇc. To je velk´ y probl´em, protoˇze klient mˇen´ıc´ı data potˇrebuje jednoznaˇcnˇe identifikovat z´aznam. Absenci prim´arn´ıho kl´ıˇce lze vyˇreˇsit indentifikac´ı z´aznamu pomoc´ı pseudosloupce ROWID. Hodnota ROWID se skl´ad´a z tˇechto hodnot: • • • •
ˇc´ıslo datov´eho objektu ˇc´ıslo datov´eho bloku v souboru, kde se z´aznam nach´az´ı pozice ˇr´adku v datov´em bloku ˇ ıslo souboru je relaˇc´ıslo datov´eho souboru, kde se z´aznam nach´az´ı. C´ tivn´ı vzhledem k tabulkov´emu prostoru.
Pomoc´ı ROWID lze tedy jednoznaˇcnˇe identifikovat z´aznam. Bohuˇzel kv˚ uli tomu, ˇze jeho hodnota je relativn´ı vzhledem k tabulkov´emu prostoru, tak jeho pouˇzit´ı jako unik´atn´ıho identifik´atoru m˚ uˇze selhat v tˇechto situac´ıch: • z´aznam je fyzicky pˇrem´ıstˇen do jin´eho tabulkov´eho prostoru ˇci jin´e datab´aze, v tom pˇr´ıpadˇe bude vygenerov´an nov´ y ROWID a z´aznam uloˇzen´ y na klientovi bude odkazovat na neexistuj´ıc´ı um´ıstˇen´ı ˇci v horˇs´ım pˇr´ıpadˇe na existuj´ıc´ı ale jin´ y z´aznam • pokud uˇzivatel smaˇze z´aznam prostˇrednictv´ım jin´eho klienta zat´ımco m´a z´aznam uloˇzen´ y na sv´em mobiln´ım zaˇr´ızen´ı, m˚ uˇze rovnˇeˇz doj´ıt k situaci, kdy z´aznam uloˇzen´ y na klientovi bude odkazovat na neexistuj´ıc´ı um´ıstˇen´ı nebo na existuj´ıc´ı ale jin´ y z´aznam Vhodn´ ym ˇreˇsen´ım by byla zmˇena datab´azov´eho sch´ematu tabulky pro z´aznam doch´azkov´ ych ud´alost´ı a to pˇrid´an´ım prim´arn´ıho kl´ıˇce. Vzhledem k tomu, ˇze se se z´aznamy pro doch´azku po zpracov´an´ı aktu´aln´ı mˇes´ıce jiˇz d´ale nepracuje, tak pˇr´ıpadn´a zmˇena starˇs´ıch dat nem˚ uˇze nap´achat re´aln´e ˇskody.
21
Anal´yza
Business logika
Sch´ ema pro doch´ azku Z´aznam o pˇr´ıchodu ˇci odchodu reprezentuje vˇzdy jeden z´aznam pro kaˇzdou z tˇechto ud´alost´ı. Pˇri pr´aci s tˇemito daty na aplikaˇcn´ı vrstvˇe je nutn´e vˇzdy sp´arovat pˇr´ıchody a odchody t´ ykaj´ıc´ı se dan´eho zamˇestnance. Je na zv´aˇzen´ı, zda nemohlo b´ yt datov´e sch´ema navrˇzen´e l´epe (napˇr. pˇr´ıchod ˇci odchod by pˇredstavoval jeden z´aznam v tabulce nebo pokud by kaˇzd´ y odchod odkazoval na pˇr´ısluˇsn´ y pˇr´ıchod). Kromˇe jednoduˇsˇs´ıho zpracov´an´ı na aplikaˇcn´ı vrstvˇe by byla rovnˇeˇz snazˇs´ı kontrola chybn´eho vstupu, kdy zamˇestnanec omylem zad´a dva pˇr´ıchody ˇci odchody n´asleduj´ıc´ı po sobˇe. Takov´a kontrola se v souˇcasnosti v syst´emu neprov´ad´ı.
Datum a ˇ cas oddˇ elenˇ e Datum a ˇcas doch´azkov´e ud´alosti se uchov´av´a oddˇelenˇe, kdy kaˇzd´a z tˇechto hodnot m´a sv˚ uj pˇr´ısluˇsn´ y sloupec. Je na zv´aˇzen´ı, zda tyto u ´daje nemˇely b´ yt ukl´ad´any jako jedna hodnota. ˇ jako re´ Cas aln´ eˇ c´ıslo Jako ˇspatn´e rozhodnut´ı hodnot´ım skuteˇcnost, ˇze u ´daj o ˇcase je reprezentov´an jako re´aln´e ˇc´ıslo nab´ yvaj´ıc´ı hodnot <0.0, 24.0>. Tento fakt pˇrin´aˇs´ı komplikace ´ pˇri pˇrevodu ˇc´ısla na hodiny a minuty. Udaj o ˇcase by mohl b´ yt reprezentov´an jako cel´e ˇc´ıslo pˇredstavuj´ıc´ı minuty.
3.4
Business logika
Pˇri anal´ yze zdrojov´eho k´odu zkouman´e ˇca´sti souˇcasn´eho syst´emu jsem indentifikoval k´od v tˇechto um´ıstˇen´ıch: • triggery, kter´e jsou souˇc´ast´ı vybran´ ych formul´aˇr˚ u • knihovny vyuˇz´ıvan´e vybran´ ymi formul´aˇri • datab´azov´e triggery, funkce a procedury Veˇsker´ y k´od je naps´an v jazyce PL/SQL. 22
Anal´yza
3.4.1
Business logika
Triggery formul´ aˇ re
Z mnoˇziny trigger˚ u (zm´ınˇen´ ych v 2.2.3) pouˇzit´ ych ve formul´aˇr´ıch bude nutn´e implementovat triggery pracuj´ıc´ı na datov´em bloku a validaˇcn´ı triggery. Ostatn´ı typy trigger˚ u nemaj´ı v kontextu implementovan´e aplikace smysl. Konkr´etnˇe se jedn´a o tyto: Block-processing triggery: On-Delete, On-Insert, On-Update, Pre-Delete, Pre-Insert, Pre-Update Validation triggery: When-Validate-Item
3.4.2
Datab´ azov´ e triggery
Datab´azov´e triggery se prov´adˇej´ı pˇri definovan´ ych ud´alostech jako vloˇzen´ı, zmˇena ˇci smaz´an´ı z´aznamu do konkr´etn´ı tabulky. Jejich ˇcinnost prov´ad´ı datab´aze a to bez ohledu na to, kter´ y klient k datab´azi pˇristupuje. Jejich funkˇcnost tedy z˚ ust´av´a nezmˇenˇena pˇri pouˇzit´ı spoleˇcnˇe s webovou sluˇzbou.
3.4.3
Datab´ azov´ e uloˇ zen´ e funkce a procedury
Funkce a procedury uloˇzen´e v Oracle datab´azi lze volat z aplikace prostˇredky jazyka Java. Slouˇz´ı k tomu rozhran´ı java.sql.CallableStatement. Uk´azka vol´an´ı uloˇzen´e funkce z Javy se nach´az´ı ve v´ ypisu k´odu 3.1. V´ ypis k´odu 3.1: Vol´an´ı uloˇzen´e procedury C a l l a b l e S t a t e m e n t c a l l a b l e S t a t e m e n t = conn . p r e p a r e C a l l ( ”{ ? = c a l l IMISOID HESLO WRAPPER( ? , ? ) } ”) ; callableStatement . setString (2 , icp ) ; callableStatement . setString (3 , heslo ) ; callableStatement . registerOutParameter (1 , OracleTypes .NUMBER) ; c a l l a b l e S t a t e m e n t . executeUpdate ( ) ; BigDecimal b o o l = c a l l a b l e S t a t e m e n t . ge t B igD e c imal ( 1 ) ;
23
Anal´yza
Business logika
Funkce vracej´ıc´ı typ BOOLEAN Probl´em nast´av´a, pokud uloˇzen´a funkce vrac´ı typ BOOLEAN. Ovladaˇc datab´aze Oracle JDBC nepodporuje typ BOOLEAN jako n´avratov´ y datov´ y ˇ typ [16]. Reˇsen´ım je pouˇzit´ı obaluj´ıc´ı procedury, kter´a zpracuje v´ ysledek volan´e procedury vracej´ıc´ı BOOLEAN, ale sama vrac´ı podporovan´ y datov´ y typ (napˇr. NUMBER). K´od obaluj´ıc´ı procedury se nach´az´ı ve v´ ypisu k´odu 3.2. V´ ypis k´odu 3.2: Obaluj´ıc´ı procedura FUNCTION IMISOID HESLO WRAPPER( PIcp i n Varchar2 , PHeslo i n Varchar2 ) RETURN NUMBER AS myvar b o o l e a n ; BEGIN myvar := c c a p h e s l o p k g . SpravneHeslo ( PIcp , PHeslo ) ; IF myvar THEN RETURN 1 ; ELSE RETURN 0 ; END IF ; END;
3.4.4
Forms knihovny
Dalˇs´ı zdrojov´ y k´od pouˇz´ıvan´ y formul´aˇri se nach´az´ı v knihovn´ach. Aˇckoli se jedn´a o nez´avisl´e jednotky, nen´ı zp˚ usob jak pouˇz´ıt procedury v nich obsaˇzen´e z prostˇred´ı jazyka Java.
3.4.5
Shrnut´ı
ˇ ast souˇcasn´eho k´odu zajiˇst’uj´ıc´ı business logiku formul´aˇr˚ C´ u bude muset b´ yt pˇreps´ana do jazyka Java. Tento pˇrepsan´ y k´od bude um´ıstˇen do webov´e sluˇzby. Konkr´etnˇe se jedn´a o zdrojov´ y k´od um´ıstˇen´ y v souˇcasn´ ych formul´aˇr´ıch a knihovn´ach, kter´e jsou jimi pouˇz´ıv´any. K´od um´ıstˇen´ y na stranˇe datab´aze lze vyuˇz´ıt a nebude muset b´ yt pˇreps´an. 24
Anal´yza
3.5
Synchronizace dat
Synchronizace dat
V souˇcasn´em syst´emu uˇzivatel zad´av´a data prostˇrednictv´ım pˇr´ısluˇsn´eho formul´aˇre. Zmˇeny jsou aplikov´any bezprostˇrednˇe po uloˇzen´ı bˇehem datab´azov´e transakce. Mobiln´ı klient pˇrin´aˇs´ı nov´ y zp˚ usob pouˇzit´ı - data lze zadat i v reˇzimu offline, kdy mobiln´ı klient nen´ı v dosahu webov´e sluˇzby. Tato data jsou uloˇzena persistentnˇe na stranˇe klienta a jsou synchronizov´ana aˇz ve chv´ıli, kdy je moˇzn´a komunikace s webovou sluˇzbou. Synchronizace se t´ yk´a pouze dat pro doch´azku uˇzivatele. Ostatn´ı data jsou prostˇrednictv´ım mobiln´ıho klienta pouze zobrazov´ana. Je tˇreba poˇc´ıtat s t´ım, ˇze z´aznamy pˇridan´e na stranˇe klienta v reˇzimu offline nemus´ı b´ yt pˇrijaty pˇri synchronizaci z d˚ uvodu poruˇsen´ı business pravidel a uˇzivatel by mˇel b´ yt o t´eto skuteˇcnosti vhodnˇe informov´an.
3.5.1
Obousmˇ ern´ a synchronizace
Pˇri obousmˇern´e synchronizaci se odes´ılaj´ı data ze strany klienta na server tak i opaˇcn´ ym smˇerem ze serveru na klienta. Klienta lze navrhnout tak, aby si uchov´aval informaci o zmˇen´ach na svoj´ı stranˇe. Pˇri anal´ yze datab´azov´eho sch´ematu pro doch´azku v souˇcasn´em syst´emu jsem zjistil, ˇze datab´aze neuchov´av´a informaci o zmˇen´ach na svoj´ı stranˇe. Beze zmˇeny t´eto skuteˇcnosti nen´ı moˇzn´e sledovat zmˇeny na stranˇe datab´aze. V´ ysledkem je ponˇekud neefektivn´ı zp˚ usob synchronizace, kdy klient odes´ıl´a na server pouze zmˇeny, zat´ımco ze serveru stahuje vˇsechna data pro dan´eho uˇzivatele a obdob´ı. Celkov´ y pr˚ ubˇeh synchronizace je zn´azornˇen v diagramu 3.4. Klient nejprve odeˇsle vˇsechny svoje zmˇeny na server. Pot´e smaˇze vˇsechna u ´spˇeˇsnˇe odeslan´a data. Bez smaz´an´ı by nebylo moˇzn´e zjistit, ˇze na serveru doˇslo ke zmˇenˇe ˇci smaz´an´ı dat jin´ ym klientem. Pot´e uˇz zb´ yv´a pouze staˇzen´ı aktu´aln´ıch dat ze serveru. Data, kter´a na klientovi nebyla smaz´ana z d˚ uvodu ne´ uspˇeˇsn´eho odesl´an´ı na server, z˚ ust´avaj´ı do t´e doby, neˇz uˇzivatel tato data uprav´ı tak, aby vyhovovala bussines pravidl˚ um. Dalˇs´ım d˚ uvodem pro ne´ uspˇeˇsnou synchronizaci m˚ uˇze b´ yt pˇreruˇsen´ı spojen´ı. Data z˚ ust´avaj´ı na klientovi, aˇz do doby u ´spˇeˇsn´eho pokusu o synchronizaci.
25
Anal´yza
Synchronizace dat
Získej všechny přidané nebo změněné záznamy na klientovi
Synchronizuj záznam se serverem [neexistuje] [existuje nezpracovaný] Smaž na klientovi všechny záznamy, které byly úspěšně synchronizovány
Získej všechny záznamy ze serveru [neexistuje]
Zpracuj záznam ze serveru [existuje nezpracovaný]
Obr´azek 3.4: Diagram aktivit pro pr˚ ubˇeh synchronizace
Diagram 3.5 podrobnˇeji rozepisuje pr˚ ubˇeh pˇrijet´ı z´aznamu ze serveru.
[záznam s tímto server ID na klientovi neexistuje] Přidání záznamu na straně klienta
Obr´azek 3.5: Diagram aktivit pro pˇrijet´ı z´aznamu ze serveru
Diagram 3.6 podrobnˇeji rozepisuje pr˚ ubˇeh odesl´an´ı poˇzadavku na server. Pokud klient nem´a server ID z´aznamu, znamen´a to, ˇze z´aznam byl vytvoˇren na stranˇe klienta a odes´ıl´a se poˇzadavek na vytvoˇren´ı. Pokud klient zn´a server ID m˚ uˇze poˇzadovat smaz´an´ı nebo aktualizaci z´aznamu.
26
Anal´yza
Synchronizace dat
[označen jako smazaný]
[potvrzeno] Odešli na server požadavek na smazání
Smaž záznam na klientovi
[server nepotrvdil smazání]
[neoznačen jako smazaný] [klient zná server ID záznamu]
[potvrzeno] Odešli na server požadavek na aktualizaci
Označ jako synchronizovaný
[přijata odpověď s popisem chyby]
[klient nezná server ID záznamu]
Označ jako chybný [potvrzeno a přijato server ID] Odešli na server požadavek na vytvoření
Ulož server ID a označ jako sync. [přijata odpověď s popisem chyby]
Označ jako chybný
Obr´azek 3.6: Diagram aktivit pro odesl´an´ı poˇzadavku na server
3.5.2
Obousmˇ ern´ a synchronizace s u ´ pravou datab´ aze
Jin´a varianta ˇreˇsen´ı probl´emu synchronizace dat, kter´a se snaˇz´ı eliminovat nedostatky pˇredchoz´ı varianty, by vyˇzadovala zmˇeny v datab´azov´em sch´ematu souˇcasn´eho syst´emu. U kaˇzd´eho z´aznamu by byla pˇrid´ana informace o posledn´ı zmˇenˇe z´aznamu s vhodnou ˇcasovou pˇresnost´ı. Pokud by doˇslo k poˇzadavku na smaz´an´ı z´aznamu, nebyl by z´aznam skuteˇcnˇe smaz´an, ale pouze nastaven pˇr´ıznak smazan´eho z´aznamu. Pˇri pouˇzit´ı tohoto ˇreˇsen´ı by bylo moˇzn´e synchronizovat obˇema smˇery pouze zmˇeny ze strany klienta i serveru. Klient, kter´ y iniciuje synchronizaci nejprve odeˇsle na server poˇzadavek, ke kter´emu pˇripoj´ı u ´daj o ˇcasu proveden´ı posledn´ı synchronizace. Server odes´ıl´a ke klientovi pouze ty data, kter´a se zmˇenila po tomto term´ınu. Pot´e klient odes´ıl´a svoje zmˇeny na server. 27
Anal´yza
3.5.3
Uˇzivatelsk´e rozhran´ı
ˇ sen´ı koliz´ı Reˇ
Kolize teoreticky nastane vˇzdy, kdyˇz se v dobˇe od posledn´ı synchronizace zmˇen´ı stejn´a data jak na serveru, tak v zaˇr´ızen´ı. Vzhledem k tomu, ˇze server neukl´ad´a informaci o ˇcase posledn´ı synchronizace a nen´ı tedy moˇzn´e zjistit, ˇze v˚ ubec doˇslo ke zmˇenˇe dat, tak mobiln´ı klient vˇzdy pˇrep´ıˇse z´aznam na serveru.
3.5.4
Srovn´ an´ı
V obou pˇr´ıpadech ˇreˇsen´ı je inici´atorem synchronizace klient. Druh´a varianta by oproti prvn´ı pˇrinesla u ´sporu mnoˇzstv´ı pˇrenesen´ ych dat. Vzhledem k tomu, ˇze druh´a varianta by vyˇzadovala zmˇenu v datab´azov´em sch´ematu souˇcasn´eho syst´emu, zvolil jsem prvn´ı variantu i pˇresto, ˇze z hlediska efektivity synchronizace je to horˇs´ı ˇreˇsen´ı.
3.6
Uˇ zivatelsk´ e rozhran´ı
Uˇzivatelsk´e rozhran´ı souˇcasn´eho syst´emu je desktopov´e rozhran´ı. Pˇri implementaci mobiln´ıho klienta budou muset b´ yt respektov´any vlastnosti takov´eho zaˇr´ızen´ı jako je velikost displeje ˇci nepohodlnost pouˇz´ıv´an´ı softwarov´e kl´avesnice. Uˇzivatel mobiln´ıho zaˇr´ızen´ı nebude muset zad´avat veˇsker´e vstupy jako na formul´aˇri 2.6, protoˇze zaˇr´ızen´ı si bude pamatovat jeho identitu. D´ale bude vhodn´e vyuˇz´ıt nˇekter´e komponenty poskytovan´e Android SDK jako je napˇr. widget pro kalend´aˇr.
28
4 Zabezpeˇcen´ı V n´asleduj´ıc´ı kapitole se zab´ yv´am zabezpeˇcen´ım aplikace. Popisuji nˇekolik moˇzn´ ych variant z hlediska ovˇeˇrov´an´ı identity uˇzivatele. Na z´avˇer vysvˇetluji v´ ybˇer zvolen´eho ˇreˇsen´ı.
4.1
Autentizace a autorizace
Pˇri anal´ yze souˇcasn´eho syst´emu jsem zjistil, ˇze informace o doch´azce a v´ ykazech zamˇestnanc˚ u jsou dostupn´e vˇsem ostatn´ım uˇzivatel˚ um (´ udaje t´ ykaj´ıc´ı se nadˇr´ızen´ ych pracovn´ık˚ u jsou dostupn´e i podˇr´ızen´ ym). Dalˇs´ı zaj´ımavost´ı je, ˇze heslo pouˇz´ıvan´e k zad´an´ı doch´azky je pro uˇzivatele nepovinn´e (m´a ho jen ten uˇzivatel, kter´ y si ho nastavil).
Autentizace Autentizace je proces ovˇeˇren´ı proklamovan´e identity subjektu. Uˇzivatel se identifikuje pomoc´ı sv´eho uˇzivatelsk´eho jm´ena a hesla.
Autorizace Autorizace je proces z´ısk´av´an´ı souhlasu s proveden´ım nˇejak´e operace. Uˇzivatel mus´ı zad´avat sv´e pˇr´ıstupov´e u ´daje pˇri zad´an´ı kaˇzd´eho z´aznamu doch´azky.
Riziko poˇ skozen´ı syst´ emu Webov´a sluˇzba umoˇzn ˇuje ˇcten´ı a u ´pravu doch´azkov´ ych dat a d´ale ˇcten´ı dat o v´ ykazech pr´ace a zamˇestnanc´ıch. D´ale pouˇz´ıv´a nˇekter´e datab´azov´e objekty jako jsou procedury a funkce, kter´e pracuj´ı s tˇemito daty. Je vhodn´e aby aplikace mˇela pˇr´ıstup pouze k tˇem datab´azov´ ym objekt˚ um, kter´e jsou relevantn´ı pro navrˇzenou funkˇcnost aplikace. To je vhodn´e pro maxim´aln´ı zabezpeˇcen´ı
29
Zabezpeˇcen´ı
VPN pro vzd´alen´y pˇr´ıstup
okoln´ıho syst´emu a minimalizaci pˇr´ıpadn´ ych rizik pˇri zneuˇzit´ı ˇci chybˇe v aplikaci. Toto je zodpovˇednost´ı datab´azov´eho administr´atora organizace a v t´eto pr´aci se touto problematikou d´ale nezab´ yv´am.
HTTP Basic autentizace Klient pos´ıl´a autentizaˇcn´ı hlaviˇcku jako souˇca´st HTTP poˇzadavku na server. Jm´eno a heslo je zasl´ano jako jeden textov´ y ˇretˇezec oddˇelen´ y dvojteˇckou. V´ ysledn´ y ˇretˇezec je pot´e zak´odov´an metodou Base64. Uˇzivatelsk´e jm´eno a heslo se tedy pos´ıl´a v zak´odovan´e podobˇe. Nejedn´a se ale o kryptografick´e zabezpeˇcen´ı pˇrihlaˇsovac´ıch u ´daj˚ u. Pouˇzit´ı t´eto metody pˇredpokl´ad´a pouˇzit´ı zabezpeˇcen´eho komunikaˇcn´ıho kan´alu mezi klientem a serverem.
4.2
VPN pro vzd´ alen´ y pˇ r´ıstup
Virtu´aln´ı priv´atn´ı s´ıt’ je prostˇredek pro propojen´ı poˇc´ıtaˇc˚ u v prostˇred´ı ned˚ uvˇeryhodn´e s´ıtˇe. D´ıky VPN spojen´ı mohou poˇc´ıtaˇce komunikovat tak, jako by byly souˇca´st´ı d˚ uvˇeryhodn´e s´ıtˇe.
Vlastnosti pˇ ripojen´ı VPN • Zapouzdˇren´ı Pˇri pouˇzit´ı technologie VPN jsou data zapouzdˇrena pomoc´ı hlaviˇcky obsahuj´ıc´ı smˇerovac´ı informace, kter´a umoˇzn ˇuje pr˚ uchod dat pˇres tranzitn´ı s´ıt’. • Ovˇeˇrov´an´ı Klient a VPN server se vz´ajemnˇe ovˇeˇruj´ı na u ´rovni poˇc´ıtaˇce. Android m´a integrovanou podporu pro VPN vyuˇz´ıvaj´ıc´ı protokoly PPTP, L2TP a IPSec. ˇ • Sifrov´ an´ı dat Pro utajen´ı dat bˇehem jejich pˇrenosu sd´ılenou nebo veˇrejnou tranzitn´ı s´ıt´ı jsou data na stranˇe odes´ılatele zaˇsifrov´ana a na stranˇe pˇr´ıjemce ˇ deˇsifrov´ana. Sifrov´ an´ı a deˇsifrov´an´ı je zaloˇzeno na tom, ˇze odes´ılatel i pˇr´ıjemce pouˇz´ıvaj´ı spoleˇcn´ y ˇsifrovac´ı kl´ıˇc.
30
Zabezpeˇcen´ı
Autentizace proti datab´azi
Webov´a sluˇzba je tedy um´ıstˇena na serveru uvnitˇr firemn´ı s´ıtˇe. Pokud klient chce komunikovat s webovou sluˇzbou, mus´ı tak ˇcinit prostˇrednictv´ım s´ıtˇe VPN.
4.3
Autentizace proti datab´ azi
Klient i server jsou souˇca´st´ı jedn´e VPN s´ıtˇe, kter´a zajiˇst’uje d˚ uvˇeryhodn´ y komunikaˇcn´ı kan´al. Klient pos´ıl´a na server HTTP poˇzadavek, jehoˇz souˇc´ast´ı je autentizaˇcn´ı hlaviˇcka nesouc´ı uˇzivatelsk´e jm´eno a heslo. Webov´a sluˇzba ovˇeˇr´ı jm´eno a heslo pomoc´ı datab´azov´e procedury. Jm´eno a heslo uˇzivatele je uloˇzeno v datab´azi. Implementovan´e ˇreˇsen´ı je zn´azornˇeno na obr. 4.1 kter´ y zobrazuje sekvenˇcn´ı UML diagram v pˇr´ıpadˇe u ´spˇeˇsn´e autentizace.
Webová služba
Klient
Databáze
HTTP AUTH AUTH OK
HTTP
Obr´azek 4.1: Diagram aktivit pˇri u ´spˇeˇsn´e autentizaci
31
Zabezpeˇcen´ı
4.4
Autentizace proti LDAP
Autentizace proti LDAP
Alternativn´ım ˇreˇsen´ım by bylo ovˇeˇrov´an´ı uˇzivatel˚ u pomoc´ı LDAP adres´aˇre. Organizace jiˇz LDAP pouˇz´ıv´a v nˇekter´ ych dalˇs´ıch firemn´ıch syst´emech. Toto ˇreˇsen´ı se liˇs´ı v tom, ˇze dotaz na ovˇeˇren´ı identity uˇzivatele prob´ıh´a k LDAP adres´aˇri a nikoli k datab´azi. Implementovan´e ˇreˇsen´ı je zn´azornˇeno na obr. 4.2, kter´ y zobrazuje sekvenˇcn´ı UML diagram v pˇr´ıpadˇe u ´spˇeˇsn´e autentizace.
Webová služba
Klient
LDAP
Databáze
HTTP AUTH AUTH OK
HTTP
Obr´azek 4.2: Diagram aktivit pˇri u ´spˇeˇsn´e autentizaci
4.4.1
LDAP
Directory Access Protocol (LDAP) je internetov´ y protokol definuj´ıc´ı pˇr´ıstup k distribuovan´e adres´aˇrov´e sluˇzbˇe. Podle tohoto protokolu jsou jednotliv´e poloˇzky na serveru ukl´ad´any formou z´aznam˚ u a uspoˇr´ad´any do stromov´e struktury. Protokol LDAP byl navrˇzen v souladu se sadou standard˚ u X.500 vyvinut´ ych pro adres´aˇrov´e sluˇzby v poˇc´ıtaˇcov´ ych s´ıt´ıch. Protokol LDAP je jejich odlehˇcenou verz´ı. Aplikace funguje na b´azi klient-server. Klient se pˇri komunikaci se serverem autentizuje. Prostˇrednictv´ım klienta lze pˇrid´avat, modifikovat a mazat z´aznamy na serveru. 32
Zabezpeˇcen´ı
Autentizace proti LDAP
Sch´ ema ´ Ukolem informaˇcn´ıho modelu LDAP je definovat datov´e typy a informace, kter´e lze v adres´aˇrov´em serveru ukl´adat. Data jsou uchov´av´ana ve stromov´e struktuˇre pomoc´ı z´aznam˚ u. Z´aznam pˇredstavuje souhrn atribut˚ u (dvojice jm´eno - hodnota). Atributy nesou informaci o stavu dan´eho z´aznamu. Z´aznam uloˇzen´ y v adres´aˇri mus´ı odpov´ıdat pˇr´ıpustn´emu sch´ematu. Sch´ema pˇredstavuje soubor povolen´ ych objektov´ ych tˇr´ıd a k nim n´aleˇz´ıc´ıch atribut˚ u. Uk´azka sch´ematu definuj´ıc´ı strukturu z´aznamu zamˇestnance: objectclass ( 1.1.2.2.2 NAME ’zamestnanec’ DESC ’zamestnanec firmy’ SUP osoba MUST ( jmeno $ identifikacniCislo ) MAY zkratkaZamestnance ) Objekt popisuj´ıc´ı zamˇestnance dˇed´ı od objektu osoba, vyˇzaduje povinn´ y atribut jmeno a identifikacniCislo a nepovinn´ y atribut zkratkaZamestnance.
Funkˇ cn´ı model Funkˇcn´ı model umoˇzn ˇuje pomoc´ı z´akladn´ıch operac´ı manipulovat a pˇristupovat k z´aznam˚ um v adres´aˇri a mˇenit ˇci zjiˇst’ovat tak jejich stav. • Autentizaˇcn´ı operace: Slouˇz´ı k pˇrihl´aˇsen´ı a odhl´aˇsen´ı uˇzivatele pro komunikaci s adres´aˇrov´ ym serverem. Jsou jimi m´ınˇeny pˇredevˇs´ım operace bind a unbind. Na u ´spˇeˇsn´em proveden´ı operace bind z´avis´ı v´ ysledky aktualizaˇcn´ıch a dotazovac´ıch operac´ı nad adres´aˇrem. • Aktualizaˇcn´ı a dotazovac´ı operace: Kaˇzd´ y adres´aˇrov´ y server podporuje z´akladn´ı operace s daty, jako je vyhled´av´an´ı, pˇrid´av´an´ı, maz´an´ı, porovn´av´an´ı a modifikace z´aznam˚ u. Tyto operace b´ yvaj´ı ˇcasto spjat´e s nastaven´ım bezpeˇcnostn´ıho modelu.
LDAP URL Um´ıstˇen´ı zdroje je v LDAP specifikov´ano pomoc´ı URL, kter´e m´a n´asleduj´ıc´ı tvar: 33
host - dom´ena nebo IP adresa port - s´ıt’ov´ y port (defaultnˇe 389) DN - v´ yznaˇcn´e jm´eno pouˇzit´e jako z´aklad pro vyhled´av´an´ı attributes - seznam atribut˚ u scope - specifikuje vyhled´avac´ı rozsah filter - filtrovac´ı krit´erium extensions - rozˇs´ıˇren´ı
Shrnut´ı
Hlavn´ım prvkem zabezpeˇcen´ı je VPN pˇr´ıstup. Uˇzivatel bez pˇr´ıstupu do firemn´ı VPN nem˚ uˇze komunikovat s webovou sluˇzbou. Od uˇzivatele se oˇcek´av´a, ˇze si nakonfiguruje VPN pˇripojen´ı v nastaven´ı Android mobiln´ıho zaˇr´ızen´ı. Pouˇzil jsem ˇreˇsen´ı autentizace proti datab´azi, protoˇze se shoduje se zp˚ usobem ovˇeˇrov´an´ı v souˇcasn´em syst´emu. St´avaj´ı ˇreˇsen´ı pomoc´ı Oracle Forms aplikace pouˇz´ıv´a rovnˇeˇz ovˇeˇren´ı uˇzivatele dotazem k datab´azi, tzn. ovˇeˇren´ı se dˇeje na aplikaˇcn´ı vrstvˇe. Je nutn´e d´ıvat se na pravidlo dobrovoln´eho hesla jako na firemn´ı pravidlo, kter´e m˚ uˇze b´ yt kdykoli zruˇseno. V pˇr´ıpadˇe zruˇsen´ı tohoto pravidla by se s nejvˇetˇs´ı pravdˇepodobnost´ı uplatnilo ovˇeˇrov´an´ı proti LDAP adres´aˇri.
34
5 Webov´a sluˇzba Na z´akladˇe anal´ yzy v sekci 3.1 byla identifikov´ana nutnost vytvoˇren´ı webov´e sluˇzby, kter´a dosud v syst´emu neexistuje. Webov´a sluˇzba je implementov´ana v souladu s REST architekturou.
5.1
N´ avrh REST URI
Pˇri n´avrhu REST sluˇzby je nejprve nutn´e identifikovat vˇsechny zdroje, kter´e webov´a sluˇzba zpˇr´ıstupˇ nuje[12]. Jedn´a se o u ´daje o doch´azce zamˇestnanc˚ u, v´ ykazech pr´ace a zamˇestnanc´ıch samotn´ ych. Poskytovan´e sluˇzby pro zdroj doch´azky zamˇestnanc˚ u (tzn. jejich pˇr´ıchody a odchody) zobrazuje tabulka 5.1. Sluˇzba umoˇzn ˇuje operace CRUD na datov´em zdroji zamˇestnanc˚ u a d´ale zjiˇstˇen´ı souˇctu doby v zamˇestn´an´ı.
GET
events/{icp}?from={from}&to={to} Z´ısk´a vˇsechny ud´alosti zamˇestnance za dan´e obdob´ı Parametry: • icp - identifik´ator zamˇestnance • from - datum zaˇca´tku obdob´ı • to - datum konce obdob´ı
events/time/{icp}?from={from}&to={to} Z´ısk´a souˇcet pˇr´ıtomnosti zamˇestnance za dan´e obdob´ı Parametry: • icp - identifik´ator zamˇestnance • from - datum zaˇca´tku obdob´ı • to - datum konce obdob´ı Tabulka 5.1: Sluˇzby pro ud´alosti doch´azky
Poskytovan´e sluˇzby pro zdroj s u ´daji o zamˇestnanc´ıch zobrazuje tabulka 5.2. Umoˇzn ˇuje z´ıskat z´akladn´ı u ´daje o zamˇestnanc´ıch a tak´e jejich posledn´ı doch´azkovou ud´alost.
GET
employees/{icp} Z´ısk´a u ´daje o zamˇestnanci identifikovan´em pomoc´ı parametru Parametry: • icp - identifik´ator zamˇestnance
GET
employees/all/{icp} Z´ısk´a seznam vˇsech zamˇestnanc˚ u, kteˇr´ı jsou aktu´alnˇe v zamˇestnaneck´em pomˇeru, obsahuje informaci zda jsou tito zamˇestnanci podˇr´ızen´ı vzhledem k zamˇestnanci identifikovan´em pomoc´ı parametru Parametry: • icp - identifik´ator zamˇestnance
36
Webov´a sluˇzba
GET
N´avrh REST URI
employees/lastevents Z´ısk´a posledn´ı ud´alost v doch´azce vˇsech zamˇestnanc˚ u, kteˇr´ı jsou aktu´alnˇe v zamˇestnaneck´em pomˇeru
GET
employees/lastevents/{icp} Z´ısk´a posledn´ı ud´alost v doch´azce zamˇestnance identifikovan´em pomoc´ı parametru
Tabulka 5.2: Sluˇzby pro zamˇestnance
Poskytovan´e sluˇzby pro zdroj s v´ ykazy pr´ace zobrazuje tabulka 5.3. Umoˇzn ˇuje z´ıskat v´ ypis v´ ykaz˚ u pr´ace a souˇcet vyk´azan´e doby. GET
records/{kodpra}?from={from}&to={to} Z´ısk´a vˇsechny v´ ykazy pr´ace zamˇestnance za dan´e obdob´ı Parametry: • kodpra - identifik´ator zamˇestnance (zkratka) • from - datum zaˇca´tku obdob´ı • to - datum konce obdob´ı
GET
records/time/{icp}?from={from}&to={to} Z´ısk´a souˇcet vyk´azan´eho ˇcasu zamˇestnance za dan´e obdob´ı Parametry: • icp - identifik´ator zamˇestnance • from - datum zaˇca´tku obdob´ı • to - datum konce obdob´ı
Tabulka 5.3: Sluˇzby pro v´ ykazy pr´ace
37
Webov´a sluˇzba
5.2
Implementace
Implementace
Pˇri implementaci byla pouˇzita knihovna Jersey[19] na stranˇe serveru, kter´a je referenˇcn´ı implementac´ı JAX-RS 1.1[15]. Na stranˇe klienta byla pouˇzita knihovna Spring pro Android.
5.2.1
Pouˇ zit´ı JAX-RS
Java API for RESTful Services (JAX-RS) je API navrˇzen´e pro snadn´ y v´ yvoj aplikac´ı vyuˇz´ıvaj´ıc´ıch REST architekturu. API vyuˇz´ıv´a anotace jazyka Java, kter´e definuj´ı zdroje a operace nad tˇemito zdroji. Na z´akladˇe tˇechto anotac´ı jsou vygenerov´any tˇr´ıdy a artefakty, kter´e jsou souˇc´ast´ı aplikace. Zde je v´ yˇcet anotac´ı pouˇzit´ ych v aplikaci: • GET, POST, PUT, DELETE Metoda s touto anotac´ı zpracuje pˇr´ısluˇsn´ y HTTP poˇzadavek. • Path Anotace specifikuje URL, na kter´em bude metoda provedena. Hodnota anotace je relativn´ı v˚ uˇci um´ıstˇen´ı Java tˇr´ıdy. • Provider Anotace oznaˇcuje tˇr´ıdy, kter´e rozˇsiˇruj´ı JAX-RS prostˇred´ı bˇehu. Jedn´a se o Entity Providers - ˇr´ıd´ı mapov´an´ı datov´ ych reprezentac´ı na ekvivalentn´ı Java objekty, Exception Providers - ˇr´ıd´ı mapov´an´ı Java vyj´ımek na instance tˇr´ıdy Response JAX-RS prostˇred´ı. • PathParam Urˇcuje parametr, kter´ y je extrahov´an z hierarchick´e ˇc´asti URI. • QueryParam Urˇcuje parametr, kter´ y je extrahov´an z dotazovac´ı ˇca´sti URI. • Consumes Pomoc´ı anotace je specifikov´an MIME typ reprezentace zdroje, kter´ y server dok´aˇze zpracovat pˇri klientovu poˇzadavku. • Produces Pomoc´ı anotace je specifikov´an MIME typ reprezentace zdroje pouˇzit´eho pˇri odpovˇedi na klient˚ uv poˇzadavek. Ve v´ ypisu k´odu 5.1 je uk´azka pouˇzit´ı pro z´ısk´an´ı seznamu doch´azkov´ ych ud´alost´ı uˇzivatele.
38
Webov´a sluˇzba
Komunikace s klientem
V´ ypis k´odu 5.1: Uk´azka pouˇzit´ı JAX-RS @Path ( ”/ e v e n t s ”) public c l a s s EventsProvider { @GET @Path ( ”{ username } ”) @Produces ( MediaType . APPLICATION JSON + ”; c h a r s e t=u t f −8”) p u b l i c Response ge t E v e n ts Fo r U s e r ( @PathParam ( ”username ”) S t r i n g username , @QueryParam ( ”from ”) S t r i n g from , @QueryParam ( ” t o ”) S t r i n g t o ) throws E xce ption { ... } }
5.3
Komunikace s klientem
Na stranˇe Android aplikace jsem pouˇzil knihovnu Spring pro Android [8]. Kl´ıˇcovou tˇr´ıdou t´eto knihovny je org.springframework.web.client.RestTemplate, kter´a usnadˇ nuje komunikaci s HTTP serverem a vynucuje si dodrˇzov´an´ı RESTful princip˚ u. Tˇr´ıda spravuje HTTP spojen´ı a extrahuje v´ ysledek poˇzadavku. Uk´azka pouˇzit´ı t´eto tˇr´ıdy se nach´az´ı ve v´ ypisu k´odu 5.2. Nejdˇr´ıve je nutn´e vytvoˇrit HTTP hlaviˇcku. V hlaviˇcce se nastav´ı parametry: • Autentizace: Zde je pouˇzita HTTP Basic autentizace vytvoˇren´ım instance HttpAuthentication. V instanci jsou nastaveny pˇrihlaˇsovac´ı u ´daje uˇzivatele. • Typ dat v poˇzadavku: Datov´ y typ, kter´ y je pouˇzit v poˇzadavku. Vyskytuje se pouze u nˇekter´ ych HTTP metod. V aplikaci se pouˇz´ıv´a pouze typ JSON. • Typ dat v odpovˇedi: Seznam datov´ ych typ˚ u, kter´e mohou b´ yt pˇrijaty. V implementovan´e aplikaci se jedn´a pouze o typ JSON. Vytvoˇren´ y objekt hlaviˇcky je n´aslednˇe pˇred´an v konstruktoru objektu HttpEntity. D´ale je nutn´e vytvoˇrit instanci RestTemplate. Zde je nutn´e nastavit HttpComponentsClientHttpRequestFactory objekt, kter´ y je zodpovˇedn´ y za 39
Webov´a sluˇzba
Komunikace s klientem
vytv´aˇren´ı HTTP spojen´ı a konvertor obsahu MappingJacksonHttpMessageConverter zodpovˇedn´ y za pˇrevod Java objektu na JSON ˇretˇezec urˇcen´ y k odesl´an´ı. Posledn´ım u ´kolem je nastavit poˇzadovanou HTTP metodu, nastavit URL c´ılov´e sluˇzby spoleˇcnˇe s parametry a nastavit objekt oˇcek´avan´ y jako odpovˇed’. Poˇzadavek se provede pomoc´ı metody exchange(). Uk´azka ve v´ ypisu 5.2 pˇredstavuje poˇzadavek na z´ısk´an´ı seznamu zamˇestnanc˚ u ze serveru. V´ ypis k´odu 5.2: Uk´azka pouˇzit´ı RestTemplate HttpHeaders r e q u e s t H e a d e r s = new HttpHeaders ( ) ; H t t p A u t h e n t i c a t i o n authHeader = A u t h e n t i c a t i o n U t i l . createAuthHeader ( c o n t e x t ) ; r e q u e s t H e a d e r s . s e t A u t h o r i z a t i o n ( authHeader ) ; requestHeaders . setAccept ( C o l l e c t i o n s . s i n g l e t o n L i s t ( MediaType . APPLICATION JSON ) ) ; HttpEntity
