ORGANIZATOR

CASE d.o.o.

ORGANIZACIJSKI I PROGRAMSKI ODBOR

TOMISLAV BRONZIN mag. ing. el.

ANTE POLONIJO

MISLAV POLONIJO

ZLATKO SIROTIĆ univ.spec.inf.

Izdavač: CASE d.o.o., Rijeka

Urednik: Mislav Polonijo

Priprema za tisak: CASE d.o.o., Rijeka

Tisak: CASE d.o.o., Rijeka

ISSN 1334-448X UDK 007.5 : 621.39 : 681.324

Copyright "Case", Rijeka, 2017

Sva prava pridržana. Niti jedan dio zbornika ne smije se reproducirati u bilo kojem obliku ili na bilo koji način, niti pohranjivati u bazu podataka bez prethodnog pismenog dopuštenja izdavača, osim u slučajevima kratkih navoda u stručnim člancima. Izrada kopija bilo kojeg dijela zbornika zabranjena je.

Case d.o.o., Antuna Barca 12, 51000 Rijeka tel: 051/217-875, tel/fax: 051/218-043, e-mail: case@case.hr, internet: www.case.hr

S A D R Ž A J

AUTOMATIZACIJA POSLOVNIH PROCESA KORIŠTENJEM JAVNE INFORMACIJSKE INFRASTRUKTURE

Slaven Brumec 5

RAZVOJ APLIKACIJA ZA INTERNET STVARI

Tonko Kovačević, Silvano Jenčić, Đoni Garmaz, Marko Meštrović 15

PRIJEDLOG METODOLOGIJE IZGRADNJE I KLASIFIKACIJE RESTful WEB SERVISA

Alen Šljivar, Marin Kaluža 27

WEB ARHITEKTURE KOJE MIJENJAJU 'SVIJET'

Vedran Zdešić 37

GO PROGRAMSKI JEZIK - OO PROGRAMIRANJE BEZ KLASA I NASLJEĐIVANJA

Damir Vuk 45

PARALELNO PROGRAMIRANJE U JAVI

Zlatko Sirotić 55

KRIPTOGRAFIJA U ORACLE BAZI PODATAKA

Zlatko Sirotić 67

2 UVOD

27. KONFERENCIJA CASE - UVOD

Konferencija CASE tradicionalno sa bavi razvojem informacijskih sustava CASEdev (prvi dan 27.02.) a u

posljednje vrijeme i razvojem mobilnih rješenja CASEmobile (drugi dan 28.02.).

CASEdev – Modeliranje, projektiranje i razvoj IS

Mogućnosti (i zahtjevi) koje pruža trend digitalizacije, brzina razvoja tehnologija i promjene u poslovnom okruženju danas izrazito povećavaju ulogu i važnost informacijskih (pod)sustava pri realizaciji poslovnih ciljeva. Često se zbog hitnosti potreba, parcijalnih uvida ili drugih razloga, kupuju ili razvijaju informatička rješenja koja možda zadovoljavaju potrebe jednog djela organizacije ili poslovnog procesa, a koja se ne povezuju dovoljno s drugim dijelovima, tako da se agilnost i konkurentnost cijeloga sustava ne povećava u skladu s očekivanjima, ili se čak i smanjuje. S rastom kompleksnosti nekoga sustava raste i složenost usklađivanja i osiguranja sinergije svih njegovih dijelova. To možemo provjereno i uspješno riješiti upotrebom koncepta arhitekture poslovnog sustava (odnosno „Enterprise Arhitekture“ ili skraćeno „EA“), koji usklađuje elemente s ciljevima cjeline. U uvodnom predavanju predstaviti ćemo, kako EA podržava agilnu i optimalnu digitalizaciju poslovnih sustava te kakvu ulogu pri tome imaju modeli (poslovnih procesa, podataka i sl.) i usklađivanje parcijalnih potreba i interesa unutar istog poslovnog sustava.

Projektiranje i izvedba IS se sve više temelji i na javnoj informacijskoj infrastrukturi i automatizaciji provedbe poslovnih procesa. Javnu informacijsku infrastrukturu čine baze podataka javnih ustanova te programska sučelja za pristup tim podacima. Automatizaciju poslovnih procesa korištenjem te infrastrukture pokazati ćemo na primjeru projektiranja i razvoja SEOP-a (Sustava evidencije otočkih prava) na povlašteni prijevoz, te praćenje izdavanja i utroška povlaštenih putnih karata u obalnom linijskom pomorskom prometu. SEOP je heterogeni informacijski sustav koji koristi javnu informacijsku infrastrukturu i omogućuje potpunu interoperabilnost svih svojih sudionika iz javnog i privatnog sektora. Glavno svojstvo SEOP-a jest rad u realnom vremenu. Poslovni procesi čije je izvođenje nekada podrazumijevalo dugotrajnu razmjenu mnoštva papirnih dokumenata između građana, tvrtki i raznih javnih ustanova sada se provode trenutno, automatizirano i bez papira. Cijeli sustav je transparentan i proširiv drugim funkcionalnostima. Pri projektiranju je korišten BPMN 2.0, a u izvedbi web-servisi i softverska arhitektura servisne sabirnice.

Nova Microsoft poslovna platforma za razvoj aplikacija (Microsoft Business App Platform) omogućava razvoj multiplatformskih poslovnih aplikacija, automatizira poslovne procese na jednoj ili više platformi, sve uz minimalno ili nikakvo pisanje programskog koda. Koristi snagu Office 365, Azure ili drugih Cloud platformi na novi način. Omogućava naprednim korisnicima da sami kreiraju aplikativna rješenja korištenjem tehnologija PowerBI, PowerApps & Microsoft Flow, te mogu koristiti već pripremljene komponente (napravljene prema Microsoft Common Data Modelu) za izradu poslovnih rešenja. Mogu se i spajati putem konektora i gatewaya na postojeće servise u računalnom oblaku i on-premise. Objasniti ćemo kako developeri i sistem administratori mogu proširiti pojedine elemente MS Business App

Platforme i time podržati specifičnije scenarije upotrebe, te bitno skratiti vrijeme potrebno za isporuku IT rješenja.

Posebno predavanje posvećujemo važnosti podataka (i informacija) koja je danas veća nego ikada (a taj trend se još i povećava). Zbog toga poseban naglasak ćemo dati ulozi arhitekture podataka i ovladavanja podacima (Data Governance), kao jednom od ključnih dijelova EA.

Portfolio and Project Management (PPM) -Upravljanje projektima i portfeljima je disciplina koja je na području upravljanja projektima rasprostranjena, no međutim na području upravljanja portfeljima su potrebe uglavnom prepuštene „excelu“ i „osjećajima“. Upravljanje s portfeljem projekata postaje dodatan problem kada u nekom poslovnom sustavu imamo više projekata i kada dođe do potrebe promjene prioriteta. Za svaku promjenu nekog stanja poslovnog sustava, često zahtijevaju nepredviđene nove projekte ili veće promjene u postojećim projektima, a svaka takva promjena zahtjeva usklađivanja koja je teško ovladati. Svi nivoi izvješćivanja o tekućim aktivnostima, upotrebi ljudskih i drugih resursa itd. moraju biti dovoljno transparentni i ujedno dovoljno konzistentni za pravilni uvid u postojeću situaciju, a agilni odgovor na nove potrebe dodatno još zahtjeva i promptni pregled svih bitnih posljedica (na raspoložive resurse i sl.) bilo koje od ponuđenih opcija.

CA PPM“ tvrtke Computer Associates (jedne od najvećih svjetskih softverskih poduzeća), je vodeći svjetski alat za područje PPM. Biti će predstavljena upotreba alata pri različitim područjima ovladavanja portfelja (projekata, aplikacija, novih proizvoda, usluga…), a pri ovladavanju područja portfelja projekata će između ostalog biti predstavljeno cjelovito ovladavanje ljudskim resursima (od pregleda vremenske raspoloživosti članova projektnih timova, do raspoloživosti njihovih znanja i vještina). Posebno će biti predstavljen i način osiguranja potpunog nadzora nad postojećim stanjem (konzistentno, na svim nivoima detalja, od elementarnih podataka, do zbirnih podataka na nivou cijelog poslovnog sustava) te kako se na temelju „što ako“ uvida optimalno odlučiti tada, kada je potrebno implementirati promjene.

Kompanije koje žele biti ispred konkurencije moraju stalno nalaziti načine za isticanje - povećanje brzine inovacija i razine produktivnosti. Jedan od najboljih načina jest upotreba računalstva u oblaku, tj. računalne infrastrukture kao usluge (IaaS), kao troškovno efikasnog, pouzdanog, prilagodljivog i sigurnog modela u usporedbi s tradicionalnim kapitalno intenzivnim modelom vlasništva nad lokalnom računalnom infrastrukturom. Infrastruktura u oblaku omogućava inovacije, veću produktivnost uz uštede od oko 75%.

Govorit ćemo o ovim prednostima, pokazati nekoliko studija slučaja kako pristupiti ovoj temi te razmotriti daljnje mogućnosti korištenja računalstva u oblaku.

Microsoft Teams je novi Office 365 servis koji nudi potpuno novo iskustvo suradnje unutar timova korištenjem objedinjenih alata koji timovi trebaju, a služi za okupljanje ljudi, razgovora i sadržaja kako bi se omogućila veća produktivnost i fleksibilnost rada. Microsoft Teams je integriran s poznatim aplikacijama Office 365 i izgrađen je od temelja na globalnom sigurnom Microsoft oblaku. Dođite pogledajte konkretan demo u kojem će biti prikazano kako Teams unaprjeđuje dnevne aktivnosti unutar tima i omogućava članovima

UVOD 3

tima budu bolje informirani, brže i bolje komuniciraju i da postignu više.

Nova Opća uredba o zaštiti osobnih podataka predstavlja veliki implementacijski izazov za mnoge organizacije koje obrađuju osobne podatke korisnika. Naime Uredba zahtijeva primjenu odgovarajućih tehničkih i organizacijskih mjera za zaštitu osobnih podatka odnosno primjereno upravljanje informacijskom sigurnošću. Navedeno ima također značajan utjecaj na razvoj softvera budući da organizacije moraju uložiti značajne napore u svrhu implementacije sigurnosti u sve faze razvoja. Ovo izlaganje fokusirat će se na tehnički aspekt Uredbe s posebnim naglaskom na najbolju praksu u sigurnom razvoju softvera.

Internet stvari (IoT) podrazumijeva mnoštvo umreženih uređaja za podržavanje različitih aplikacija. Mogućnosti primjene Interneta stvari su široke i raznolike, a prožimaju gotovo svaki aspekt našeg života poput opskrbe, transporta i logistike, zrakoplovne, brodske i automobilske industrije, telekomunikacija, telemedicinskih sustava i zdravstvene njege, brige za starije i nemoćne, energetskih sustava i drugo. Pregled razvojnih platformi i programskih jezika koji se koriste za razvoj aplikacija za Internet stvari dan je u prvom dijelu rada. U drugom dijelu rada, kroz dva primjera, prezentira se pristup razvoju ovih aplikacija koji se primjenjuje na Sveučilišnom odjelu za stručne studije.

Putem različitih platformi, korištenjem različitih oblika korisničkih sučelja, korisnik pristupa softveru i koristi njegove funkcionalnosti. Često softver u svom radu koristi resurse ili aplikativne dijelove drugih sustava čime se ostvaruje softver kao usluga (SaaS). Obzirom da se zbog toga povećava razina distribuiranosti softvera, raste i potreba za izradom web servisa. Representational State Transfer (REST) je paradigma arhitekture web servisa. Radom će se prikazati postupak modeliranja i izgradnje "hipermedijskog" REST web servisa - RESTful web servis. Pokazati će se metodologija koja se može koristiti u razvoju RESTful web servisa. Koristit će se Richardson Maturity Model (RMM) za klasifikaciju web servisa. Metodologijom izgradnje definirati će se koraci koje je potrebno izvršiti u procesu razvoja (modeliranje i izgradnja) RESTful web servisa.

Dati ćemo i pregled trendova u arhitekturi modernih web aplikacija koji su postali standard zadnjih godina, a koji nas prate na prijelazu sa sinkronog na asinkrono, sa ne-testabilnog na testabilno, uz sve više paralelnih zahtjeva na brži dohvat i prikaz sve veće količine podataka i sadržaja, uz neprestano pomicanje granice značenja "agilno", te ubrzanje svih faza procesa životnog ciklusa softvera. Moderne arhitekture podržavaju procese razvoja, ali i integracije, deploymenta, testiranja i automatizacije softverskih produkata, te nisu fokusirane same na sebe, nego vide širu sliku. Cilj predavanja je pokazati momente kada uvodimo neke od takvih komponenata naše arhitekture, te razmotriti opcije za i protiv.

CASEmobile – Programiranje i sigurnost

Razvoj mobilnih aplikacija za sve platforme je danas bitniji nego ikada prije. Ukoliko razvijate „native“ aplikacije imate opciju da razvijate za svaku platformu zasebno ili da koristite alat za razvoj multiplatformskih aplikacija. Sa najnovijom verzijom Xamarin Forms-a, nemate više razloga za razvijati zasebne native aplikacije, što proces razvoja i održavanja cini dužim i skupljim. Na predavanju predstaviti ćemo Xamarin Forms kao alat za kompletan multipatformski razvoj sa Visual Studiom 2015.

NativeScript je open source framework za izradu nativnih mobilnih aplikacija uz pomoć popularnog Angular

JavaScript frameworka kojim razvijamo web aplikacije. JavaScript usprkos svim ožiljcima koje je zadobio u "Ratovima browsera" postaje sve popularniji i popularniji. Široki krug programera i jedinstvo u web svijetu ga dovodi među najpoželjniji izbor za razvoj - kako zbog lakšeg pronalaska članova tima koji ga znaju tako i zbog širine primjene. Razvoj nativnih mobilnih aplikacija do sada je bio ograničen na "velike" ili "specijalizirane" jezike: Javu, Objective-C, C#, Swift. A JavaScript je bio ograničen na razvoj hibridnih mobilnih aplikacija. Kako je nativni razvoj ipak još uvijek u prednosti pred hibridnim došlo je vrijeme da se dva svijeta sudare, i da JavaScript jezikom možemo razvijati nativne aplikacije. Predavanje će pokazati što nam je sve potrebno za započeti s izradom NativeScript aplikacija te kako ova tehnologija funkcionira.

Suvremeni razvoj aplikacija sve je više okrenut mobilnim aplikacijama što sa sobom nosi niz prednosti, ali također stvara i nove izazove. Različite platforme, pojava Internet of Things uređaja, stalno skraćivanje rokova i smanjenje budžeta razvoja samo su neki od izazova s kojima se susreću razvojni timovi.

Da li je moguće brzo razvijati kvalitetni softver za različite platforme? Da li je jedan programer danas u stanju to sam učiniti? Da li razvijati native aplikacije prilagođene uređaju ili ići na univerzalna rješenja? Što je s podrškom za korporativne baze podataka i da li je moguće integrirati mobilne i cloud platforme s postojećim sustavima?

Predstaviti ćemo programskom jeziku Go, relativno mladi programski jezik opće namjene. Razvijen je za razvoj modernih aplikacija za 21. stoljeće i utemeljen je na idejama konkurentnog programiranja te prenosivosti izvornog koda bez izmjena na različite vrste procesora i operacijskih sustava. Go karakterizira iznimna brzina kompajliranja i izvođenja izvršnog koda, ali isto tako i jednostavnost koncepata jezika. Za razliku od mnogih popularnih skripnih jezika, kao i jezika zasnovanih na virtualnim strojevima, Go je pravi kompajlerski jezik koji generira izvršni binarni kod čija brzina izvođenja je bliska brzini izvođenja C/C++ koda. Go sadrži cijeli eko sustav alata, te omogućuje skalabilni razvoj aplikacija uključujući i one vrlo velike. Pritom je vrijeme kompilacije izuzetno kratko čak i za veoma velike programe. Go ima radikalno drugačiji pristup objektnoj orijentaciji. On nema koncepte klasa i nasljeđivanja. Umjesto toga, on ima koncepte kompozicije, ugradnje i interfejsa. Go je zamišljen kao bolja Java odnosno kao bolji C/C++. Go se razvija kao projekt otvorenog koda, pokrenut od strane malog Google-ovog tima, a nadopunjava se doprinosima mnogih programera iz zajednice otvorenog koda.

Usporediti ćemo rad Java 5/6 Executora, Java 7 ForkJoin frameworka i Java 8 (paralelnog) Streama, na jednom jednostavnom primjeru. Dati ćemo kratak prikaz mikroprocesora i Java konkurentnog programiranja.

Zatim se prikazuju programski kod ta tri rješenja, i rezultat izvođenja sa različitim parametrima (broj Java dretvi i zadataka).

React Native je framework za razvoj nativnih mobilnih aplikacija poseban po tome što u ovo područje donosi rad s JavaScript programskim jezikom. JavaScript i nativna aplikacija - kombinacija koja nam se do nedavno činila nemogućom. Nativni se razvoj pokazao najboljim modelom a razvoj web aplikacija s JavaScript jezikom je dosegnuo vrhunac. Pa je zapravo logična odluka bila povezati ova dva svijeta i omogućiti programerima da znanja stečena u web svijetu prenesu na mobilne aplikacije. Predavanje će pokazati što nam je sve potrebno za započeti s izradom React Native aplikacija te kako ova tehnologija funkcionira.

4 UVOD

Nikada nije bilo lako napraviti dobru poslovnu aplikaciju budući su troškovi njena razvoja veliki i često neisplativi. PowerApps je razvojna platforma za izradu poslovnih aplikacija bez pisanja koda koja ubrzava i mijenja način kako organizacije omogućavaju zaposlenicima nesmetan pristup poslovnim aplikacijama i informacijama. Saznajte kako možete iskoristiti PowerApps danas i zaviriti što tek dolazi na praktičnom primjeru izrade real-life poslovne aplikacije koja radi na mobilnim uređajima, unutar web browsera i na Windowsima.

Temu sigurnosti započeti ćemo sa radom koji daje opću sliku kreiranja prijetnji, fokusira se na funkcionalne sigurnosne zahtjeve i sigurnosne zahtjeve upravljane rizicima.

Današnji informacijski sustavi sve se više okreću mobilnom platformama. Mobilni uređaji ne samo da se koriste za komunikaciju, zabavu i pristup Internetu, već postaju i nezaobilazni dio poslovanja. To sa sobom nosi i skladištenje podataka na samom mobilnom uređaju, a kod nekih sustava lokalni izvor podataka postaje presudan. Obraditi ćemo bitne faktori skladištenja podataka na mobilnim računalima. Koliko popularne baze podataka mogu udovoljiti na takve zahtjeve? Koje se dobre prakse preporučuju u razvoju aplikacija s bazom podataka smještenom na mobilnom uređaju? Ovim ćemo se pitanjem pozabaviti u ovom izlaganju i pokazati primjer baze podataka koja brine o sigurnosti i na mobilnim uređajima i na db serverima i koja postaje sve češći izbor u razvoju mobilnih sustava.

Posebno ćemo se pozabaviti kriptografijom. Dati ćemo osnove kriptografije. Prikazati razliku između simetričnih kriptosustava (koji koriste isti ključ u procesu kriptiranja i procesu dekriptiranja) i asimetričnih kriptosustava (kriptosustava s javnim ključem). Nešto detaljnije će se prikazati asimetrični kriptosustav RSA. Na kraju će kao primjer biti prikazana upotreba kriptografije u Oracle bazi. U prilogu se prikazuje matematička osnova kriptosustava RSA.

Radionice:

Važni dio CASE konferencije su radionice na kojima se praktično prikazuju metode i alati. Ove godine imamo četiri radionice:

1. Upravljanje i praćenje infrastrukture Clouda

Pridružite se IDERA-i za pregled proizvoda Uptime Cloud Monitor (UCM). UCM osigurava bitne sposobnosti praćenja cloud infrastrukture, dajući nam sve što je potrebno za prepoznavanje i brzu reakciju na eventualne probleme i neplanirane situacije u cloud infrastrukturi i to od korisničkog iskustva pa sve do samih baza podataka. Temeljem dubokog poznavanja složenosti današnjih IT infrastruktura, IDERA korisnicima nudi gotovo

prilagodljivo rješenje za pregled rada infrastrukture clouda, upozoravanje o raznim situacijama unutar sustava, kao i bogato izvještavanje uprave o stanju infrastrukture i njenom ponašanju.

Dođite vidjeti kako se UCM može iskoristiti za potrebe upravljanja vaše cloud infrastrukture.

2. Poslovna primjena umjetne inteligencije (strojnog učenja) u medijskoj industriji

Na radionici će biti predstavljeno istraživanje i razvoj koje provodi Data Science odjel Styria grupe. Biti će prikazani poslovni slučajevi i praktični primjeri primjene strojnog učenja u obradi teksta, slike i ostalih podataka. Styria kao najveća medijska kuća u regiji (Njuškalo, Večernji list, 24 sata, Poslovni dnevnik itd.) raspolaže velikom količinom multimedijskih podataka prikladnih za obradu algoritamskim tehnikama. Kako identificirati poslovne prilike? Kako monetizirati podatke? Kako računala razumiju hrvatski jezik? Kako računala razumiju slike? Kako izgleda prvi hrvatski mass-scale ML GPU deployment? Strojno učenje, deep learning, neuronske mreže, NLP i računalni vid samo su neke od tema koje će biti obrađene na predavanju.

3. Kako uspješno započeti da bi uspješnije primijenili Xamarin?

U sklopu Xamarin alata postoji nekoliko alata za stvaranje mini aplikacija i primjera u programiranju, te dokumentiranje. Sa jedne strane ti alati idealni su za početnike za uvođenje u programiranje na vrlo jednostavnim primjerima, a sa druge strane mogu biti alati za dokumentiranje i testiranje "ozbiljnih" projekata i time pružaju most između dva svijeta - apstraktnog učenja i realnih projekata.

Budući da djeca vole istraživati svijet oko sebe rad sa alatima kao što su Xamarin.Inspector ili Workbooks, te Xamarin.UITest pokazati ćemo o kakvim idealnim alatima za uvod u stvaran svijet programiranja sa radi uz pomoć jednog djeteta demonstratora.

4. Jednostavni I brzi razvoj IoT

Internet of Things postaje sve zastupljeniji u IT-u, ali i u svakodnevnom životu kako se sve više pametnih uređaja i senzora spaja na Internet. To sam sobom nosi izazove razvoja softvera koji će koristiti mogućnosti ovih uređaja, ali isto tako povezivanje tog softvera s postojećim poslovnim i dr. IT sustavima.

U ovoj radionici pokazat ćemo na primjeru Embarcadero RAD Studio razvojne okoline da razvoj IoT sustava nije ni težak ni kompliciran i da se takvi sustavi bez većih problema mogu povezivati s drugim poslovnim i sl. sustavima.

Tajnik organizacijskog i programskog odbora

Ante Polonijo

Podaci o autoru:

Ante Polonijo, dipl.ing., dipl.oecc.

CASE d.o.o., Antuna Barca 12, 51000 Rijeka, Croatia

tel. +385 51 217 875, 098/260 509, fax. +385 51 218 043, e-mail: ante@case.hr

PROFESIONALNA KARIJERA:

- predavao Električna mjerenja na srednjoj stručnoj školi za elektroniku, programirao u Cobol-u u “Inžinjerskom birou” (u Zagrebu), organizator informatike i 13 godina šef ERC-a u “HEP DP Elektroprimorje” Rijeka te šef organizacije i programiranja u DINI Omišalj. - Od 1986-2009.g. radi u HGK Županijska komora Rijeka na radnom mjestu savjetnika informatike i statistike, te voditelja odsjeka makroekonomske analize. (Paralelno od 1990-94 radio 1/3 radnog vremena kao voditelj grupe za informatiku u remontnom brodogradilištu “V.Lenac” Rijeka). - Od 2009.g. - Konzultant u tvrtci CASE na poslovima organizacije školovanja i Konferencija (Razvoj SW -CASE, Komunikacijske tehnologije-KOM, e-business-a – e-BIZ, SmartCard, Privatnost). - Bio dugogodišnji član upravnog odbora Hrvatskog informatičkog zbora (udruge informatičara HR), zadužen za školovanje korisnika (ECDL licenca) i organizacija konferencija.

CASE29 5

AUTOMATIZACIJA POSLOVNIH PROCESA KORIŠTENJEM JAVNE INFORMACIJSKE INFRASTRUKTURE

BUSINESS PROCESS AUTOMATION USING PUBLIC INFORMATION INFRASTRUCTURE

Slaven Brumec

SAŽETAK:

Opisali smo projektiranje i izvedbu informacijskih sustava temeljenih na javnoj informacijskoj infrastrukturi. Nju čine baze podataka javnih ustanova te programska sučelja za pristup tim podacima. Korištenjem te infrastrukture moguće je automatizirati provedbu poslovnih procesa tako da hrvatski građani i tvrtke više ne nailaze na birokratske prepreke pri ostvarenju svojih zakonskih prava. Automatizacija poslovnih procesa korištenjem javne informacijske infrastrukture pokazana je na primjeru projektiranja i razvoja SEOP-a. To je informacijski sustav za evidenciju otočkih prava na povlašteni prijevoz te praćenje povlaštenih karti u priobalnom pomorskom prometu. SEOP je heterogeni sustav oslonjen na javnu informacijsku infrastrukturu koji omogućuje potpunu interoperabilnost svih svojih sudionika iz javnog i privatnog sektora te njihov rad u realnom vremenu. Zahvaljujući SEOP-u hrvatski otočani ne moraju čekati u redu za ostvarenje svojih prava niti obilaziti druge javne ustanove, a brodarske tvrtke uvijek pouzdano znaju kome i kada prodati povlaštenu kartu kako bi mogle tražiti naknadu za neostvareni prihod od nadležnih državnih ustanova. Poslovni procesi koji su se nekada provodili uz dugotrajnu razmjenu mnoštva papirnih dokumenata između građana, tvrtki i raznih javnih ustanova sada se provode trenutno, automatizirano i bez papira. Cijeli sustav je transparentan s gledišta poreznih obveznika te proširiv drugim funkcionalnostima. Pri projektiranju je korišten BPMN 2.0, a u izvedbi web-servisi i softverska arhitektura servisne sabirnice. Ključne riječi: SEOP, javna informacijska infrastruktura, servisna sabirnica, BPMN 2.0

SUMMARY:

We described design and development of information systems based on public information infrastructure. That infrastructure consists of public institutions' databases and program interfaces for accessing those databases. By using that infrastructure one can automate business process execution so that Croatian citizens and companies do not need to overcome red tape any more when pursuing their legal rights. Business process automation using public information infrastructure is shown by the example of designing and development of SEOP. That is information system for recording Croatian islanders' right to preferential transport and tracking of preferential tickets in coastal maritime transport. SEOP is heterogeneous system that leans on public information infrastructure and ensures complete interoperability of its participants from public and private sector and enables them for real-time work. Thanks to SEOP, Croatian islanders do not need to wait in queues or overcome the red tape in order to claim their rights, and shipping companies are always sure about to whom and when to sell preferential ticket so that later they can ask appropriate reimbursement for unrealized revenue from the amenable authorities. Business processes that use to be executed with prolonged exchange of many paper documents between citizens, companies, and many public institutions are now performed instantly, automatically, and without papers. Whole system is transparent from taxpayers' point of view and extensible with other functionalities. In design we used BPMN 2.0, and for implementation we used web-services and software architecture of enterprise service bus. Keywords: SEOP, public information infrastructure, enterprise service bus, BPMN 2.0

1. UVOD

Nastojeći revitalizirati hrvatske otoke, Ministarstvo pomorstva, prometa i infrastrukture je 2014. godine propisalo Pravilnik o uvjetima i načinu ostvarivanja prava na povlašteni prijevoz na linijama u javnom pomorskom prijevozu, u skladu sa Zakonom o prijevozu u linijskom i povremenom obalnom pomorskom prometu. Temeljem tog pravilnika, svi stanovnici otoka te tvrtke sa sjedištem na otocima imaju pravo na povlašteni prijevoz (PPP) osoba i vozila. PPP se dokazuje pametnom karticom zvanom otočna iskaznica (OtIs) izdanom na osobu ili vozilo. Ovlast za provedbu i nadzor korištenja PPP dodijeljena je Agenciji za obalni linijski pomorski promet (Agencija ZOLPP) koja je dobila slijedeće zadatke:

1. Postaviti elektronički sustav evidencije otočkih prava (SEOP) za otočane i otočne tvrtke.

2. Organizirati prikupljanje zahtjeva za povlašteni prijevoz, provjeru opravdanosti tih zahtjeva te njihovo odobrenje ili odbijanje.

3. Organizirati izdavanje i dostavu otočne iskaznice odobrenim korisnicima.

4. Omogućiti brodarima upite o pravu na povlašteni prijevoz svakog nositelja otočne iskaznice koji zatraži kupnju povlaštene karte.

5. Omogućiti brodarima dojavu prodaje i iskorištenja ("cvikanja") povlaštenih karti kako bi im se mogla isplatiti novčana naknada za iskorištene povlaštene karte do njihove tržišne cijene.

6. Kontrolirati korištenje prava na povlašteni prijevoz, uključivo i sprečavanje prenošenja tog prava na neovlaštene osobe. Drugim riječima, SEOP treba spriječiti da otočani kupuju povlaštene karte za npr. svoje turiste.

Sustav koji bi trebao omogućiti provedbu tih 6 zadataka također je nazvan SEOP. Ciljevi SEOP-a su:

6 CASE29

Omogućiti dodjelu novčane naknade brodarima temeljem točne količine utrošenih povlaštenih karata, umjesto dodjeljivanja paušalnih naknada.

Posljedično, učiniti korištenje prava na povlašteni prijevoz transparentnim s gledišta poreznih obveznika.

2. FUNKCIONALNOSTI

Projektiranje i izvedba SEOP-a je zahtjevan poslovni poduhvat pa je Agencija ZOLPP ugovorila te poslove s vanjskom tvrtkom koja je ujedno i operator SEOP-a. Operator SEOP-a je potom okupio nekoliko tvrtki za projektiranje i razvoj cijelog sustava. Organizacije uključene u projektiranje, razvoj, testiranje i rad SEOP-a su:

Naručitelj: Agencija ZOLPP. Korisnici: komercijalni brodari i Agencija ZOLPP. Operator: AKD d.o.o. Projektant: Koris d.o.o. Razvoj: Koris d.o.o., AlterInfo d.o.o. i AKD d.o.o.

Tijekom projektiranja SEOP-a uočena su slijedeća kritična poslovna pitanja:

1. Kako organizirati prikupljanje zahtjeva za povlašteni prijevoz te kako te zahtjeve brzo provjeriti i riješiti, po "one stop shop" načelu, bez papirologije i birokratskih zastoja, po mogućnosti u realnom vremenu, izravno na šalteru, bez redova čekanja?

2. Kako znati točnu količinu prodanih i utrošenih povlaštenih karti, po svakom brodaru i liniji te svakom otočaninu ili vozilu? Te informacije su nužne za kontrolu korištenja PPP te točnu refundaciju brodarima.

3. Kako evidentirati prodaju i utrošak povlaštenih karata te povezanih otočnih prava, po mogućnosti također u realnom vremenu, izravno iz prodajne poslovnice ili ulaza na brod

4. Prethodno navedene kritične točke trebalo je riješiti tako da se omogući potpuna interoperabilnost SEOP-a s vanjskim korisnicima, komercijalnim brodarima te možebitnim drugim poslovnim

entitetima u budućnosti.

Za uspješno rješavanje prvog kritičnog pitanja bilo je potrebno uvelike osloniti SEOP na javnu informacijsku infrastrukturu koja bi se iskoristila za provjeru opravdanosti zahtjeva za povlašteni prijevoz. Istovremeno, postalo je jasno da će i SEOP biti dio te javne informacijske infrastrukture jer je iz kritičnih pitanja 2 - 4 jasno da će ga koristiti komercijalni brodari te drugi sudionici u pomorskom prometu. Opći poslovni pogled na SEOP i sudionike uključene njegov u rad prikazan je Slikom 1:

Agencija ZOLPP je vlasnik SEOP-a. Usmjerava razvoj SEOP-a, nadzire korištenje PPP te izdaje suglasnost brodarima za uključivanje u SEOP.

SEOP operator je tvrtka koja vodi bazu podataka otočkih prava (BPOP), izrađuje OtIs, omogućava brodarima trenutnu provjeru PPP i dojavu utroška povlaštenih karata te izvješćuje Agenciju ZOLPP o korištenju PPP.

Šalteri je zbirni naziv za organizaciju koja ima razgranatu mrežu poslovnica u kojima se prikupljaju zahtjevi za povlašteni prijevoz te uručuju OtIs onim korisnicima kojima je takav zahtjev odobren. Ta organizacija (trenutno Hrvatska pošta) sudjeluje u sustavu kao podugovarač SEOP operatora.

Hrvatski otočani (uključivo i otočke tvrtke) su korisnici PPP. Koriste povlašteni prijevoz za sebe ili svoja vozila kod bilo kojeg komercijalnog brodara koji ima koncesiju na nekoj liniji. Korisnik svoje PPP dokazuje važećom OtIs.

Brodar je komercijalni entitet koji prevozi osobe i vozila na linijama za koje ima koncesiju. Provjerava korisnikovo PPP kod Operatora SEOP-a te šalje podatke o utrošenim povlaštenim kartama u BPOP.

Ministarstvo unutarnjih poslova (MUP) omogućuje Operatoru SEOP-a provjeru prebivališta odnosno registracije i vlasništva vozila tražitelja PPP.

CARNet i SRCE omogućuju Operatoru SEOP-a provjeru studentskog odnosno učeničkog statusa tražitelja PPP. Ako je otočanin učenik ili student, onda uz osnovna otočka prava ima još i neka

Slika 1: Poslovni pogled na SEOP

CASE29 7

dodatna. HZMO omogućuje Operatoru SEOP-a provjeru

mirovinskog statusa tražitelja PPP.

Otočanin predaje zahtjev za povlašteni prijevoz na šalteru Hrvatske pošte. Zahtjevom traži izdavanje nove ili produžetak postojeće otočne iskaznice. Podaci o OIB-u osobe ili registarskom broju vozila (upisani na zahtjevu) te eventualnom dodatnom statusu tražitelja (učeničkom, studentskom ili umirovljeničkom) se šalju u SEOP na provjeru da li podnositelj zahtjeva prebiva na otoku ili tamo obavlja gospodarsku djelatnost. Slanje se obavlja web-servisom čiji je izdavač SEOP, a koristi ga odgovarajuća šalterska aplikacija.

Operator SEOP-a automatski provjerava podatke o podnositeljevom prebivalištu ili registraciji vozila upitom na baze podataka koje za osobe i vozila vodi MUP. Ako podnositelj zahtjeva ima pravo na povlašteni prijevoz, onda se provjerava i eventualni dodatni status, učenički, studentski ili umirovljenički, ako ga je tražitelj naveo. Ta provjera se obavlja u bazama podataka koje vode SRCE za učenike, CARNet za studente odnosno HZMO za umirovljenike.

Ako su sve potrebne provjere pozitivne, Operator SEOP-a izdaje novu otočnu iskaznicu na ime podnositelja ili njegovo vozilo i dostavlja je u poslovnicu gdje je zatraženo pravo na povlašteni prijevoz. Time podnositelj zahtjeva postaje korisnik. Šalterski službenik će potom uručiti tu iskaznicu korisniku.

Podaci o korisniku i njegovim PPP čuvaju se su BPOP. Prava na povlašteni prijevoz produžuju se godišnje temeljem obnovljenog zahtjeva korisnika i uz novu provjeru, a nakon pet godina izdaje se nova otočna iskaznica. Komunikacija Operatora SEOP-a s MUP-om te HZMO-om, CARNet-om i SRCE-m u pravilu se obavlja web-servisima.

Korisnik kupuje povlaštenu putnu kartu uz predočenje svoje otočne iskaznice. Brodar provjerava pravo na povlašteni prijevoz upitom na BPOP kod Operatora SEOP-a koristeći Operatorove web-servise. Putna karta se može kupiti na dva mjesta:

U brodarevoj poslovnici gdje se prodaju brodske karte. Poslovnica je opremljena čitačem pametnih kartica te računalom i aplikacijom koji imaju pristup do BPOP. Ta aplikacija je u pravilu program za prodaju karata kojeg je brodar imao davno prije SEOP-a te je samo nadograđen modulom za provjeru PPP i dojavu prodaje povlaštene karte. Ako je korisniku odobreno PPP, ali mu još nije uručena OtIs, on može kupiti povlaštenu kartu predočenjem osobne iskaznice s OIB-om.

Pri ulazu na brod, ako je službenik opremljen mobilnom aplikacijom s čitačem kartica koja ima pristup do BPOP.

Ako korisnik nije potrošio PPP za tekuće razdoblje, Brodar mu izdaje putnu kartu po povlaštenoj cijeni. Podaci o izdanoj karti odmah se šalju web-servisom u BPOP gdje se odmah ažurira korisnikova količina iskorištenog PPP u tekućem razdoblju.

Operator SEOP-a obrađuje podatke o broju prevezenih putnika i vrijednosti povlaštenih vožnji te izrađuje izvješća temeljem kojih Agencija usmjerava i nadzire funkcioniranje SEOP-a i rad Operatora te priprema isplatu naknada za neostvareni prihod ("refundacija") svim Brodarima koji su obavljali povlašteni prijevoz.

Uočljivo je da se kroz SEOP razmjenjuje mnoštvo informacijskih i materijalnih sadržaja. Na Slici 1, plave crtkane strelice označavaju razmjenu informacijskih

sadržaja putem web-servisa. Crvene crtkane strelice označavaju sadržaj razmijenjen putem web-aplikacije. Sive pune strelice označavaju razmjenu materijalnog sadržaja, uključivo i novca.

Usklađena suradnja svih sudionika SEOP-a odvija se u realnom vremenu uz korištenje suvremenih informacijskih tehnologija, napose web-servisa i pametnih kartica. Web-servisi se koriste za razmjenu podataka između sudionika. Pametne kartice imaju memorijski čip za pohranu podataka o korisnikovom pravu na povlašteni prijevoz te služe za vizualnu identifikaciju korisnika jer imaju otisnute njegove osnovne podatke i fotografiju.

Valja naglasiti da SEOP nije namijenjen prodaji putnih karata, nego odobravanju prava na povlašteni prijevoz i nadzor nad korištenjem tih prava. U tom smislu, dva cilja SEOP-a mogu se precizirati kroz slijedeće funkcionalnosti:

1. Zaprimanje i rješavanje zahtjeva za povlašteni prijevoz osoba i vozila.

2. Izrada i izdavanje otočne iskaznice kojom fizičke i pravne osobe ostvaruju pravo na povlašteni prijevoz osoba ili vozila.

3. Provjera stanja prava na povlašteni prijevoz u tekućem razdoblju za osobu ili vozilo s otočnom iskaznicom u trenutku kada se od brodara traži prodaja povlaštene putne karte.

4. Upis izdanih i utrošenih povlaštenih putnih karata u BPOP te povezano ažuriranje iskorištenih prava pojedinačno po svakom korisniku (tj. izdanoj otočnoj iskaznici).

5. Izvještavanje Agencije ZOLPP i Brodara o iskorištenom povlaštenom prijevozu radi naknade za izgubljeni prihod.

3. AUTOMATIZACIJA JAVNOM INFORMACIJSKOM INFRASTRUKTUROM

3.1 One stop shop bez papirologije

Iz "one stop shop" sintagme kritičnog pitanja 1 proizlazi

da SEOP mora od nadležnih javnih ustanova (MUP, CARNet, SRCE i HZMO) dohvaćati sve službene dokumente kojima se provjerava status osobe (otočanin, učenik, student, umirovljenik) ili vlasništvo nad vozilom. Ta obveza proizlazi iz hrvatskih zakona zato što SEOP djeluje u ime Agencije ZOLPP kao javne ustanove koja od drugih javnih ustanova potražuje dokumente potrebne korisnicima njenih usluga.

Hrvatski građani navikli su na sasvim suprotno ponašanje javnih ustanova. Na primjer, one ih često traže "osobnu iskaznicu i domovnicu", iako se bez osobne iskaznice uopće ne može imati domovnica, a ako stranac ima hrvatsku osobnu iskaznicu, na njoj je vidljivo da je strani državljanin. No, čak i da nije tako, za oba dokumenta nadležne su javne ustanove te ako nekoj od njih doista uz osobnu iskaznicu treba i građaninova domovnica, trebala bi ju sama dobaviti, a ne slati građanina po nju. Uza sve to, takva potraživanja su protuzakonita:

1. Zakon o općem upravnom postupku propisuje: "Službena osoba pribavit će po službenoj dužnosti

podatke o činjenicama o kojima službenu

evidenciju vodi javnopravno tijelo kod kojeg se

vodi postupak, odnosno drugo javnopravno tijelo

ili sud." (članak 47, stavka 2)

8 CASE29

2. Zakon o državnoj informacijskoj infrastrukturi propisuje: "Tijela javnog sektora koja vode temeljne registre

obvezna su bez odgode te bez traženja dodatnih

dozvola dostaviti autentične podatke u javni

registar drugog tijela javnog sektora, koji se

odnose na podatke koje drugo tijelo evidentira

temeljem stavka 4. ovoga članka." (članak 9,

stavka 5)

"Tijela javnog sektora koja vode javne registre

dostavit će bez traženja dodatnih dozvola podatke

drugom tijelu javnog sektora koje te podatke

koristi u okviru obavljanja propisanih poslova." (članak 11)

U SEOP-u je "one stop shop" obveza ispunjena prema

zakonu, pri čemu Agencija ZOLPP s drugim javnim ustanovama jest potpisala odgovarajući sporazum, ali kojim su samo dogovoreni tehnički i administrativni aspekti ispunjavanja te obveze, npr. da će dohvat službenih dokumenata iz MUP-a, CARNet-a, SRCE-a i HZMO-a, u ime Agencije ZOLPP obavljati operator SEOP-a tj. tvrtka AKD.

Iz sintagme kritičnog pitanja 1 "bez papirologije" proizlazi da se dohvat podataka iz nadležnih javnih ustanova u SEOP mora obavljati elektroničkim putem. Tehnički aspekti takvog dohvata također su propisani sporazumima između Agencije ZOLPP i nadležnih javnih ustanova. Mogući načini dohvata su web-servisom ili izravnim transferom podataka, pri čemu je web-servis preferiran način zbog razloga objašnjenih dalje u članku.

3.2 Interoperabilan rad u realnom vremenu

U svim kritičnim pitanjima spominje se snažna težnja za postavljanjem SEOP-a tako da radi u realnom vremenu. To znači:

1. Tražitelj zahtjeva odmah dobije odgovor, automatski odobren ili odbijen, čim šalterski službenik upiše njegove podatke. Sukladno tome, otočanin odmah po odobrenju zahtjeva može koristiti svoje pravo na povlašteni prijevoz, barem u početku preko osobne iskaznice i OIB-a, dok mu ne stigne otočna iskaznica.

2. Brodari odmah dojavljuju u SEOP prodaju, utrošak ili storniranje povlaštene karte. SEOP odmah automatski ažurira stanje prava na povlašteni prijevoz za konkretnu osobu ili vozilo te tako omogućuje brodaru da ne proda povlaštenu kartu nekome tko je svoje pravo na povlašteni prijevoz potrošio za trenutno vremensko razdoblje.

3. Podnošenje zahtjeva za povlašteni prijevoz, provjera stanja prava na povlašteni prijevoz te dojava prodaje, utroška i storniranja povlaštenih karti su omogućeni iz bilo koje aplikacije, bez obzira na tehnologiju izvedbe i pokretačku platformu. SEOP omogućuje totalnu interoperabilnost među svim sudionicima.

Zbog ta tri razloga, SEOP je utemeljen na XML web-servisima jer se jedino njima može postići i rad u realnom vremenu, i potpuna interoperabilnost sa svim sudionicima. Alternativa za rad u realnom vremenu, izravan podatkovni transfer (tzv. merge-replikacija podataka) jako ovisi o tehnologiji pohrane tj. sustavu za upravljanje bazama podataka (SUBP) pa ne ispunjava sasvim uvjete interoperabilnosti.

4. TEHNIČKA IZVEDBA SEOP-A

Za pokretanje SEOP-a Operator je odabrao Microsoftov serverski stog: MS SQL Server 2012, Windows Server 2012 i IIS. Izvedbeni timovi su potom odabrali aplikacijsku platformu, izvedbenu tehnologiju i programski jezik koji se dobro uklapaju u odabrani serverski stog: .NET Framework 4.5, WCF, aplikacijski generator Code On Time (ASP.NET) te programski jezici C# (za web-servise, aplikacije i CLR procedure) i T-SQL (za pohranjene procedure).

Na tom stogu i navedenim tehnologijama potom je razvijen SEOP koji izlaže vlastita dva web-servisa s ukupno 13 web-metoda. Istovremeno, SEOP koristi 4 web-servisa s ukupno 5 web-metoda. SEOP je shematski prikazan UML komponentnim dijagramom na slici 2.

Paketi su označeni su cijan bojom. Komponente (sadržane u paketima) su nazvane prema glavnoj DLL datoteci ili bazi podataka. Programske biblioteke su označene žutom bojom. BPOP je svjetlocrvena. Vanjske komponente su sive. Sučelja (interfaces) su metode web-servisa ili pohranjene procedure u bazi podataka (T-SQL ili CLR). Sva sučelja su u boji matične komponente.

Pažljivim proučavanjem komponentnog dijagrama može se uočiti još jedan web-servis SQUID kojemu nema naznaka na slici 1. Naime, kako je objašnjeno u poglavlju 3, pravo na kupnju povlaštenih karti ostvaruje se pametnom karticom zvanom otočna iskaznica. Proizvođač i izdavač otočne iskaznice jest tvrtka AKD koja je istovremeno i operator SEOP-a. AKD proizvodi mnoge službene dokumente i iskaznice za javni i privatni sektor. Zbog sigurnosnih razloga pojedini AKD-ovi odjeli su izolirani kao da se radi o odvojenim tvrtkama te međusobno komuniciraju poput odvojenih tvrtki. Tako i odjel zadužen za SEOP naručuje otočne iskaznice od odjela za proizvodnju iskaznica putem

web-servisa SQUID, metode zaprimiSeopPaket.

Izdavač tog web-servisa jest, dakle, jedan Operatorov odjel, ali koji djeluje poput odvojene tvrtke.

Vanjska komponenta Aplikacija za prodaju karata je sveobuhvatni termin za mnoštvo šalterskih ili mobilnih aplikacija mnogih brodara koje SEOP-u dojavljuju prodaju, utrošak i storniranje povlaštenih karata. U te svrhe koriste SEOP-ov XML web-servis PlovKarte.

4.1 SEOP kao ESB

Uvidom u komponentni dijagram postaje jasno da SEOP spaja mnoštvo poslovnih subjekata u linijskom obalnom pomorskom prijevozu te ga zato možemo smatrati servisnom sabirnicom (Enterprise Service Bus: ESB).

Ne postoji općeprihvaćena definicija servisne sabirnice. Ta riječ se često koristi kao poštapalica u raznim marketinškim kampanjama. Čini nam se da je najispravnije reći da je servisna sabirnica predložak za softversku arhitekturu, pri čemu neki proizvođači softvera izraz ESB koriste za opis rješenja manje ili više napisanih u skladu s takvom idejom softverske arhitekture.

CASE29 9

Slika 2: Komponentni dijagram SEOP-a

10 CASE29

Ideja servisne sabirnice jest da različiti sustavi različitih sudionika ne komuniciraju izravno, nego preko zajedničkih programskih sučelja: API (application programming interface). Prednost takvog pristupa je pojednostavljenje čitavog sustava zbog manje ukupne količine veza i, posljedično, smanjenja količine izravnih, point-to-point, povezivanja sudionika.

Zamislimo sustav sa samo 4 sudionika, tj. 4 heterogena informacijska sustava, kao na Slici 3. Ako svakog sudionika treba povezati sa svim ostalima, broj potrebnih dvosmjernih veza je: n∙(n– 1), pri čemu je n broj sudionika. Veze predstavljaju API-je pa u kontekstu informatičkog povezivanja raznih sudionika moramo razmatrati dvosmjerne veze zato što ako sustav A može pristupiti sustavu B (tj. koristiti njegove API-je), iz toga ne slijedi da sustav B zato može pristupiti sustavu A. Dakle, za 4 sudionika treba programirati ukupno 12 pristupa tuđim API-jima, tj. svaki sudionik treba programirati pristup trima API-jima. Čak i ako se razni sudionici slože u dijeljenju ili otvaranju vlastitih rješenja za pristup tuđim API-jima, ta dobra volja neće biti provediva ako ne koriste istu tehničku platformu. Drugim riječima, sustavi A i B ne mogu zajednički razviti pristup C-ovim API-jima ako A za svoja rješenja koristi Python, a B Javu. Jasno je koliko će se međusobne komunikacije dalje usložniti povećanjem broja sudionika!

Slika 3: Point-to-point integracija poslovnih sustava

Uvođenjem servisne sabirnice prikazane Slikom 4, problematika međusobnog povezivanja raznih sudionika poslovnog sustava se znatno pojednostavnjuje jer je potrebno samo ukupno 2n dvosmjernih veza. Autori servisne sabirnice trebaju razviti korištenje točno onog broja API-ja koliko ima sudionika: n. Svaki sudionik

treba napisati samo jedan API, onaj za pristup ESB-u. ESB se brine za ispravno preusmjeravanje poruka u komunikaciji sudionika tj. između jednog i drugog API-ja sudionika.

Ideja sabirnice odavno se koristi u projektiranju digitalnih sustava, od jednostavnih kontrolera do složenih osobnih računala. Umjesto da hardverske komponente izravno komuniciraju jedna s drugom, one se međusobno povezuju zajedničkom sabirnicom

SEOP je također servisna sabirnica zato što od svojih samih početaka spaja razne sudionike u obalnom pomorskom prometu preko zajedničkih API-ja: otočane, mnoge brodare, Agenciju ZOLPP i javne ustanove u koje bi otočani inače morali osobno dolaziti po potrebne dokumente. Potencijal SEOP-a kao servisne sabirnice je još i veći, npr. šalteri uopće ne moraju biti u nadležnosti jedne ustanove jer je sustav prikupljanja i

odobrenja zahtjeva smišljen tako da taj posao može obavljati više ustanova istovremeno (npr. još i lučke kapetanije uz Hrvatsku poštu.) Kako se SEOP bude proširivao novim funkcionalnostima, i kako budu u Hrvatskoj počeli poslovati novi brodari, tako će se i broj sudionika SEOP-a povećavati, a njegov ESB API također dobivati nove funkcionalnosti.

Slika 4: Integracija poslovnih sustava servisnom sabirnicom

4.2 Web-servisi u SEOP-u

Web-servisi SEOP-a su XML tipa, isto kao i web-servisi javne informacijske infrastrukture korišteni u SEOP-u. Web-servisi općenito su programi koji omogućuju poziv udaljene procedure korištenjem normiranih i otvorenih komunikacijskih protokola i protokola za oblikovanje poruka. Jedan web-servis obuhvaća jednu ili više web-metoda. Web-metoda je zapravo udaljena procedura.

XML web-servisi razmjenjuju poruke u obliku XML datoteka oblikovanih prema SOAP protokolu za poruke (messaging protocol). Primopredaja poruka se najčešće obavlja uobičajenim internetskim protokolima HTTP i HTTPS, ali može i drugima. XML web-servisi su samoopisni stoga što je na njihovom URL-u obično izložena i njihova opisna datoteka, tzv. WSDL (Web-Services Description Language). WSDL je također XML

datoteka gdje su specificirane poruke za poziv web-metoda i očitanje rezultata njihovog rada. Ako WSDL jest izložen, onda se može dohvatiti i pregledati internetskim preglednikom: npr. ako je adresa nekog web-servisa http://moj-web-servis/, onda je WSDL tog web-servisa u pravilu dostupan na http://moj-web-servis/?wsdl

Uz XML web-servise postoje i REST web-servisi koje bi možda bilo bolje nazvati JSON web-servisi jer poruke razmjenjuju u obliku jednostavnih tekstualnih datoteka u JSON formatu (JavaScript Object Notification). Prednost

JSON web-servisa nad XML web-servisima jest upravo jednostavniji oblik JSON poruka od XML poruka. Ta jednostavnost čini JSON web-servise pogodnijima za rad iz JavaScripta, praktički jedinog jezika kojim se može programirati klijentska strana web-aplikacija. Glavni nedostatak JSON web-servisa je upravo manjak WSDL-a, slabija normiranost, uključivo i manjak norme za obradu greški, posljedično slabija podrška u razvojnim alatima te obavezna (a ne opcionalna) dostupnost isključivo preko internetskih komunikacijskih protokola. Zbog svega toga nisu korišteni u SEOP-u.

CASE29 11

5. POSLOVNI PROCESI U SEOP-U

SEOP je od početka projektiran i razvijan korištenjem BPMN 2.0 norme (Business Process Modeling and Notation). Tom normom je propisana:

grafička notacija za dijagrame poslovnih procesa (Business Process Diagram: BPD), uključivo i kolaboracijske dijagrame

grafička notacija za koreografske dijagrame poslovnog procesa te konverzacijske dijagrame poslovnog sustava

formalni opisi grafičkih elemenata BPD-a u obliku UML klasnog dijagrama

precizna značenja grafičkih elemenata BPD-a

Grafičke notacije nisu osmišljene “iz vedra neba”, nego su temeljene na simbolima klasičnih dijagrama toka. Osnovna organizacija za normiranje BPMN-a je Business Process Management Institute (BPMI). Krovna je Object Management Group (OMG), ugledni neprofitni konzorcij za normiranja u informacijskim tehnologijama.

Razvoj BPMN-a motiviran je čestim pitanjem koje se postavlja u analizi i modeliranju poslovnih i drugih procesa: "Koliko detaljno treba modelirati proces?" Jedini ispravan odgovor na to pitanje jest: "Onoliko detaljno koliko znamo o procesu!" Problem odmah postaje uočljiv: razni sudionici posla gledaju na isti poslovni proces iz različitih perspektiva i s drukčijih razina detaljnosti. Posljedica toga jest:

Menadžeri će neki proces vrlo često opisati na osnovnoj, opisnoj razini: pomoću temeljnih aktivnosti i odluka.

Poslovni analitičari ili niži voditelji će isti proces opisati na analitičkoj razini: s preciznim poslovnim detaljima, točnim vremenima i resursima izvršavanja pojedinih aktivnosti, itd., ali bez zalaženja u tehničke detalje.

Radnici, uključivo i informatičare zadužene za neposrednu aplikacijsku podršku, će proces opisati na izvršnoj razini, s mnoštvom tehničkih detalja,

ponekad gubeći širu sliku.

Smisao BPMN-a je uspostava grafičke notacije za opis poslovnog procesa koja će imati dovoljno bogatu semantiku za programere, a dovoljno jednostavnu za poslovne ljude. BPMN je razvijen kao zajednički jezik menadžera, poslovnih analitičara i programera, s ciljem uklanjanja jaza u nerazumijevanju između poslovnog i informatičkog svijeta. U praksi je to izvedeno na slijedeći način:

1. Simboli BPMN-a su preuzeti iz prepoznatljivih klasičnih dijagrama toka: pravokutnik za radnu aktivnost ili potproces, krug za događaj pri provedbi poslovnog slučaja (uključivo početak i kraj), romb za grananje (ekskluzivno, paralelno ili inkluzivno), itd. Takvi simboli ujedno čine osnovnu paletu BPMN-a.

2. Simboli osnovne palete mogu se precizirati dodatnim oznakama ili doradama, ali tako da opstane izvorno značenje. Drugim riječima dorađeni pravokutnici i dalje označavaju radne aktivnosti, dorađeni krugovi događaje, a dorađeni rombovi grananja. Na primjer, pravokutnik sa zupčanikom i dalje označava radnu aktivnost, ali specifično servisnu, tj. onu koja se izvodi automatski bez čovjekovog angažmana. Tako dorađeni simboli čine proširenu paletu BPMN-a.

3. Osoba s općim znanjem o procesu može nacrtati dijagram korištenjem osnovne palete, a osobe s cjelovitim znanjem mogu taj isti dijagram doraditi tako da osnovne simbole preciziraju tj. pretvore u proširene te, po potrebi dodaju još radnih aktivnosti, događaja i skretnica do granica vlastitog znanja o procesu.

Detaljnije o paletama BPMN-a se može pročitati u [2: 33, 85]. Primjer provedbe modeliranja od opisne, preko analitičke, do izvršne može se pročitati u [1: 290]. Za ovaj članak samo ćemo na Slici 5 prikazati model jednog procesa SEOP-a: Obraditi zahtjev za pravo na povlašteni prijevoz osoba.

Proces je prikazan u analitičkome obliku, i to s gledišta

Slika 5: Obraditi zahtjev za PPP osoba

12 CASE29

organizacije koja preko svojeg šalterskog poslovanja ima zadatak prikupljati zahtjeve za PPP (Hrvatska pošta). Budući da je SEOP servisna sabirnica, šaltersko poslovanje nigdje izravno ne vidi javnu informacijsku infrastruktura sa Slike 1, tj. procesne sudionike MUP, CARNet, SRCE i HZMO: oni su s druge strane servisne sabirnice!

Ovako modeliran proces ima tri sudionika: otočanina koji traži PPP, šalterskog službenika organizacije zadužene za zaprimanje takvih zahtjeva i SEOP operatora kod kojeg se zahtjevi automatski provjeravaju te potom odobravaju ili odbijaju. Obrada zahtjeva provodi se u dva koraka: prvo se provjerava ima li osoba prebivalište na otoku, što je preduvjet za ostvarivanje osnovnog prava, a u drugom se ispituje

ima li osoba s osnovnim pravom još i dodatna prava (DP) koja proizlaze iz statusa učenika, studenta ili umirovljenika. Logički najvažniji dio posla odvija se u softveru servisne sabirnice koji je pokrenut kod SEOP operatora.

6. ANALIZA RADA SEOP-a

Rad SEOP-a može se ilustrirati nekim značajnim podacima:

SEOP zaprima zahtjeve za PPP od listopada 2014. U punom pogonu, sa svim opisanim funkcionalnostima, jest od 1. siječnja 2015. Od onda radi non-stop, 24 sata na dan, 7 dana u tjednu, bez ispada.

Slika 6: Povlaštena putovanja u 2015. godini

Slika 7: Povlaštena putovanja u 2016. godini

CASE29 13

Opseg BPOP je reda veličine nekoliko gigabajta. Najveća tablica sadrži nekoliko milijuna zapisa.

Tijekom 2015. kroz SEOP je odobreno 32.094 zahtjeva za PPP koji se odnose na osobe. Do 27. prosinca 2016. odobreno je još 7.536 takvih zahtjeva. Za vozila ti brojevi iznose 14.467 odnosno 6.331.

U SEOP je uključeno 14 brodarskih kompanija čiji brodovi plove na ukupno 53 linije. Za sve njih evidentira se prodaja, utrošak i storniranje povlaštenih karata.

Od posebnog je interesa analiza povlaštenog prijevoza evidentiranog SEOP-om. Na slikama 6 i 7 prikazani su grafovi ukupnog mjesečnog povlaštenog prijevoza za 2015. i 2016. godinu, zbrojeno za osobe i vozila te po svim brodarima.

Prosječan broj povlaštenih putovanja osoba i vozila je porastao od 263 tisuće mjesečno u 2015. godini na 376 tisuća u 2016. godini. Značajan dio tog porasta uzrokovan je povećanim ljetnim prometom u srpnju i kolovozu 2016. spram istih mjeseci u 2015., no porast povlaštenog prijevoza vidljiv je u svim mjesecima 2016. osim prosinca. Siječanj je u obje godine najmanje prometan mjesec, ali unatoč tome je i za to razdoblje broj povlaštenih putovanja povećan sa 148.096 na 255.306. Jedan od uzroka tog općeg porasta svakako je suživljavanje s novim režimom povlaštenog prijevoza, no sasvim sigurno su u pitanju i drugi sociološki te napose gospodarski uzroci čija analiza ipak izlazi daleko van okvira ovoga članka tako da ti uzroci ne mogu biti dalje razmatrani.

Važno je primijetiti da je u te dvije godine kroz SEOP evidentiran utrošak 7.676.146 povlaštenih putnih karata: 3.158.983 u 2015. i 4.517.163 u 2016. Istovremeno, u objema godinama ukupno je prodano samo 5.616 povlaštenih karata za koje nije postojalo pravo na povlašteni prijevoz. Većina tih karata prodana je u trenucima kada prodajne aplikacije pojedinih brodara nisu imale vezu prema SEOP-u, redovito zbog loših internetskih uvjeta na prodajnim mjestima, a ne zbog pada SEOP-a. To znači da stopa greške u ostvarenju prava na povlašteni prijevoz iznosi samo 0,073%, što je doista odličan rezultat rada SEOP-a.

7. ZAKLJUČAK

SEOP je ogledno i inovativno rješenje za "one stop shop" paradigmu i interoperabilnost, i na tehničkoj, i na poslovnoj razini. Tehnologija XML web-servisa na kojoj počiva ta interoperabilnost jest stara gotovo dva desetljeća, ali nam se svejedno čini da se prerijetko koristi, osobito u javnom sektoru. Koncept servisne sabirnice olakšava proširenje sustava kojemu će uskoro biti dodane nove funkcionalnosti, poput

realnovremenske evidencije svih putnika, povlaštenih i običnih.

Informatičko rješenje za sustav evidencije otočnih prava se više puta spominje u Zakonu o prijevozu u linijskom i povremenom obalnom pomorskom prometu, posebice u članku 47 stavku a:

Informatički sustav javnog prijevoza uspostavlja se

radi evidentiranja korisnika javnog prijevoza kroz taj

sustav.

Kroz sustav iz stavka 1. ovoga članka korisnici

povlaštenog prijevoza ostvaruju pravo na taj prijevoz

temeljem izdanih otočnih iskaznica za putnike, vozila i

vinjete za vozila, a ostali korisnici javnog prijevoza

evidentiranjem izdanih karata kroz taj sustav.

Otočna iskaznica za putnike i vozila i vinjete za vozila

koje izdaje Agencija jesu javne isprave.

Agencija može stručno-tehničke poslove izrade

otočnih iskaznica i vinjeta iz stavka 2. ovoga članka te

pohrane podataka o njima, kao i evidentiranje izdanih

karata za ostale putnike povjeriti pravnoj osobi koja

ispunjava odgovarajuće tehničke i kadrovske uvjete te

čije je cjelokupno poslovanje obuhvaćeno

odgovarajućim dokazima kvalitete i informacijske

sigurnosti.

Način evidentiranja izdanih karata korisnika javnog

prijevoza koji nisu korisnici povlaštenog prijevoza te

rok proširenja sustava iz stavka 1. ovoga članka

pravilnikom propisuje ministar.

Vidljivo je da Zakon ukratko opisuje sve funkcionalnosti SEOP-a, prostor za postojanje Operatora te nakanu za proširenjem funkcionalnosti.

SEOP može biti i jest temelj za druge projekte koji se odnose na nadzor prodaje i korištenja dozvoljenih, ali kontroliranih tvari poput pesticida, vatrenog oružja i streljiva, privrednih eksploziva te alkoholnih pića, svinjskih proizvoda i drugih haram proizvoda u islamskim zemljama, itd.

Lako je zamisliti rješenja nalik SEOP-u i u sasvim slobodnim tržištima, bez ikakvih državnih subvencija ili kontroliranih tvari. Na primjer, u uvjetima slobodne tržišne utakmice između većeg broja brodara, vjerojatno bi barem neki od njih imali programe lojalnosti za određene kategorije putnika poput otočana, đaka i studenata. Za provjeru kategorije svakog putnika trebalo bi im svojevrsno mini-SEOP rješenje koje bi također koristilo javnu informacijsku infrastrukturu. Takva rješenja mogla bi se proširivati i unajmiti i drugim zainteresiranim stranama, npr. autoprijevoznicima, koji tako ne bi morali razvijati vlastita.

Literatura:

1 Brumec, J., Brumec, S. (2016). Modeliranje poslovnih procesa. Zagreb.

2 Silver, B. (2011). BPMN Method and Style. Aptos: Cody-Cassidy Press.

Bilješka o autoru:

dr.sc. Slaven Brumec

Koris d.o.o.

Jarnovićeva 54

HR-10000 Zagreb

14 CASE29

dr.sc. Slaven Brumec, dipl.inž.rač. je diplomirao na Fakultetu elektrotehnike i računarstva. Magistrirao je i doktorirao na Fakultetu organizacije i informatike s temom iz mobilnih tehnologija odnosno uslužnog računarstva (cloud computing). Radi u konzultantskoj tvrtki Koris d.o.o. iz Zagreba kao voditelj razvoja i konzultant za modeliranje poslovnih procesa, projektiranje informacijskih sustava i razvoj aplikacija. Prije sadašnjeg zaposlenja radio je na više složenih informatičkih projekta u tvrtkama IN2 i APIS IT u Zagrebu. Na Visokom učilištu Algebra predaje kolegij Modeliranje poslovnih procesa na diplomskom studiju. Objavio je više znanstvenih i stručnih radova u domaćim i inozemnim časopisima i knjigama. Ima certifikate iz Microsoftovih tehnologija i upravljanja poslovnim procesima (OCEB).

CASE29 15

RAZVOJ APLIKACIJA ZA INTERNET STVARI

APPLICATION DEVELOPMENT FOR THE INTERNET OF THINGS

Tonko Kovačević, Silvano Jenčić, Đoni Garmaz, Marko Meštrović

SAŽETAK:

Internet stvari (IoT) podrazumijeva mnoštvo umreženih uređaja za podržavanje različitih aplikacija. Mogućnosti primjene Interneta stvari su široke i raznolike, a prožimaju gotovo svaki aspekt našeg života poput opskrbe, transporta i logistike, zrakoplovne, brodske i automobilske industrije, telekomunikacija, telemedicinskih sustava i zdravstvene njege, brige za starije i nemoćne, energetskih sustava i drugo. Pregled razvojnih platformi i programskih jezika koji se koriste za razvoj aplikacija za Internet stvari dan je u prvom dijelu rada. U drugom dijelu rada, kroz dva primjera, prezentira se pristup razvoju ovih aplikacija koji se primjenjuje na Sveučilišnom odjelu za stručne studije. Ključne riječi: Internet stvari, razvojne platforme, bežični uređaj, korisnička sučelja.

SUMMARY:

Internet of Things (IoT) implies a large number of networked devices to support different applications. Application possibilities of the Internet of Things are wide and varied, and permeate almost every aspect of our life, such as supply, transportation and logistics, aerospace, marine and automotive, telecommunications, telemedicine systems and health care, care for the elderly and persons with disabilities, energy systems and other. Overview of development platforms and programming languages used to develop applications for the Internet of things is given in the first part of the paper. The approach to the development of these applications, applied at the University Department of Professional Studies, is given through two examples in the second part of the paper. Key words: Internet of things, development platforms, wireless device, user interfaces.

1. UVOD

Slika 1. Senzorska platforma Waspmote i Cloud Partner Ecosystem [2]

16 CASE29

Koncept Interneta stvari (eng. Internet of Things, IoT)

podrazumijeva mnoštvo uređaja povezanih na Internet. Na ovaj način omogućena je interakcija ljudi s uređajima i uređaja s uređajima, integrirajući ih u jednu mrežu kojom se upravlja putem web aplikacija. Godine 2011. broj povezanih uređaja na Zemlji premašio je broj ljudi, a očekuje se da će taj broj doseći 26 milijardi do 2020. godine [1]. Mogućnosti primjene Interneta stvari su široke i raznolike, a prožimaju gotovo svaki aspekt našeg života poput opskrbe, transporta i logistike, zrakoplovne, brodske i automobilske industrije, telekomunikacija, telemedicinskih sustava i zdravstvene njege, brige za starije i nemoćne, energetskih sustava i drugo.

Danas postoje mnogobrojna profesionalna rješenja za IoT aplikacije. Na slici 1 vidi se primjer senzorske platforme Waspmote tvrtke Libelium i njenih partnera [2]. Postoji još cijeli niz različitih specijalziranih rješenja za IoT aplikacije različitih tvrtki kao što su: Electric Imp [3], Amazon IoT rješenja [4], Estimote Beacons [5] i druga.

Pored profesionalnih rješenja postoji još cijeli niz dostupnih hardverskih i softverskih platformi za razvoj IoT aplikacija. Inženjeri koji razvijaju ova rješenja susreću se s mnogobrojnim problemima i izazovima kao što su: odabir odgovarajuće hardverske i softverske platforme, implementacija na uređajima s ograničenim resursima u pogledu procesorske snage i raspoložive memorije, ograničenja vezana uz raspoloživu energiju (baterije su često izvori napajanja) i drugo.

Pregled razvojnih platformi i programskih jezika koji se koriste za razvoj aplikacija za Internet stvari dan je u drugom dijelu rada. U trećem dijelu rada, kroz dva primjera, prezentira se pristup razvoju ovih aplikacija koji se primjenjuje na Sveučilišnom odjelu za stručne studije, a zaključci su dani na kraju rada.

2. RAZVOJNE PLATFORME ZA IoT APLIKACIJE

Ovisno o funkcionalnosti uređaja IoT aplikacija mora udovoljiti specifičnim zahtjevima. Primjerice, potrebno je

razviti IoT aplikaciju za bežična osjetila koja mjere kvalitetu zraka (temperaturu, vlažnost, tlak, razne vrste plinova) na određenom području te prikupljene podatke šalju web poslužitelju. Prilikom razvoja ove aplikacije moraju se uzeti u obzir sljedeća ograničenja:

raspoloživa energija (baterijska napajanja), nedostatak tradicionalnih sučelja na uređajima koja

služe za konfiguraciju kao što su: komunikacijsko sučelje, tipkovnica i/ili zaslon osjetljiv na dodire i

ograničena procesorska snaga i raspoloživa memorija.

Iz navedenoga primjera vidljivo je da aplikacija mora udovoljiti specifičnim zahtjevima koji se odnose na bežično osjetilo, a uz to ona mora:

omogućiti mobilnost bežičnih osjetila, imati mogućnost dodavanje novog osjetila u mrežu

ili opoziva osjetila iz mreže, omogućiti rekonfiguraciju mreže ili oporavak od

određenih kvarova, biti skalabilna u velikom rasponu implementacije, biti otporna na interferenciju s drugim uređajima, osigurati sigurnost podataka i komunikacije i biti jednostavna za krajnjeg korisnika.

Uz to, odabir odgovarajuće komunikacijske tehnologije veoma je bitan prilikom razvoja IoT aplikacija. U radu [6] dane su najznačajnije bežične komunikacijske tehnologije pogodne za razvoj IoT aplikacija, a tablica 1 prikazuje neke od njih.

Na osnovu ovih kriterija moguće je odabrati određenu komunikacijsku tehnologiju. Primjerice, za WBAN (eng. Wireless Body Area Network) i PAN (eng. Personal Area Network) mreže odabrat će se neka od niskoenergetskih tehnologija kratkog dosega koja se temelje na standardu IEEE 802.15. kao što su ZigBee SE (eng. ZigBee Smart Energy) ili Bluetooth LE (eng. Bluetooth Low Energy, BLE). U LAN (eng. Local Area Network) mrežama primjenit će se tehnologije kao što su WiFi temeljene na standardu IEEE 802.11 (a, b, g, n i ac), 6LoWPAN koja se temelji na normi IEEE 802.15.4 i primjeni protokola IPv6 ili KNX (EN 50090, ISO/IEC 14543) za aplikacije koje se koriste u pametnim kućama. U MAN (eng. Metropolian Area Network) i

Tablica 1. Bežične komunikacijske tehnologije i njihove značajke

Norma Mreža Frekvencijsko

područje Brzina

prijenosa Doseg Potrošnja Topologija Primjena

Bluetooth PAN 2.4 GHz 700 kbit/s < 30 m Niska Zvijezda Mreža za prijenos

podataka, slušalice

Bluetooth LE

PAN 2.4 GHz 1 Mbit/s 5-10 m Veoma niska

Zvjezda Zdravstvo i rekreacija

RF4CE PAN 2.4 GHz 250 kbit/s 30 m 1-100 mW Zvijezda Potrošačka elektronika

ZigBee LAN 2.4 GHz 250 kbit/s 300 m 1-200 mW Mesh, Zvijezda,

Stablo

Senzorske mreže, automatizacija u industriji i

zgradama

Wi-Fi LAN 2.4 i 5 GHz 11-100 Mbit/s 100 m do 1 W Zvijezda Internet, multimedija

KNX LAN 868 MHz 16.4 kbit/s 800 m 1-25 mW Mesh, Zvijezda,

Stablo Automatizacija zgrada

6LoWPAN LAN 2.4 GHz 250 kbit/s 800 m Veoma niska

Mesh, Zvijezda

Senzorske mreže, automatizacija u industriji i

zgradama

WiMAX MAN 2.3 – 11 GHz 11-100 Mbit/s 50 km Visoka Mesh Širokopojasne Internet

komunikacije

2.5 - 4G *5G

WAN 800 MHz – 2600 MHz

1.8-100 Mbit/s Mobilna mreža

Visoka Mesh Mobilna telefonija i

telemetrija

CASE29 17

WAN (eng. Wide Area Network) mrežama kao pristupne tehnologije između IoT objekata i javne mreže predlažu se WiMAX (IEEE 802.16), neka od tehnologija GSM/GPRS/UMTS/LTE ili neke od pristupnih tehnologija koje koristi kabele ili optičko vlakno (ADSL, FTTH, FTTB). Slika 2. prikazuje ovisnost određenih bežičnih tehnologija o komunikacijskom dosegu i podatkovnoj brzini.

2.1 IoT razvojne platforme

Odabir odgovarajuće razvojne platforme je usko povezan s funkcionalnošću koju će obavljati IoT uređaji. U ovom podpoglavlju dan je pregled najznačajnijih razvojnih platformi, ali gotovo svakodnevno se pojavljuju nove hardverske i softverske platforme.

Danas je vrlo popularna Arduino open source platforma

[7] koja uključuje pločicu s Atmelovim mikrokontrolerom, sučelja koja podržava različite komunikacijske, osjetilne i aktuatorske uređaje uz podršku odgovarajućih C/C++ biblioteka te integriranu razvojnu okolinu (eng. Integrated Development Enviroment, IDE) za pisanje, prevođenje i ubacivanja koda. Ovisno o tipu mikrokontrolera postoje različite verzije Arduina kao što su Uno, Due, Mega 2560, Pro, Leonardo, Nano, Yun i druge.

LabVIEW (eng. Laboratory Virtual Engineering Workbench) [8] je razvojna platforma koju je 1986. g. za potrebe nadzora i upravljanja mjernom instrumentacijom te prikupljanja i analize mjernih podataka (eng. Data Acquisition and Analysis) razvio National Instruments. LabVIEW kao platformu za testne i analitičke mjerne sustave koriste neki od najznačajnijih proizvođača u avionskoj (Airbus) i automobilskoj (Subaru) industriji te distribucijskim energetskim sustavima (National Grid UK). Zbog grafičkog programskog sučelja i

pojednostavljenog pristupa kreiranju automatizacijskih sustava našao je široku primjenu i na sveučilištima širom svijeta. Danas kada je povezivanje uređaja i

senzora preko Interneta postala svakodnevnica LabVIEW ima dodatne prednosti jer nam kroz svoje integrirano grafičko razvojno okruženje omogućava jednostavnije kreiranje online virtualnih laboratorija, automatizacijskih sustava te sustava za daljinsko upravljanje.

Raspberry Pi 2/3 [9] predstavlja vrlo popularnu hardversku platformu koja ima dovoljno rersursa tako da podržava Windows 10 IoT Core ili različite inačice Linux (Noobs, Raspbian) operativnih sustava, a koristi se Python kao programski jezik.

Microsoft se također uključio u IoT svijet s optimiranom verzijom operativnog sustava Windows 10 IoT Core koja koristi Visual Studio i Arduino API. IBM nudi platformu Quarks IoT tools za razvoj IoT aplikacija. BeagleBoard se temelji na ARM procesorima i podržava Linux OS. Intelove razvojne platforme za IoT aplikacije su Galileo i Edison, kao, platforme ConnectCore i Rabbit tvrtke Digi International, kao i Qualcomm platforme [13].

2.2 Operativni sustavi

Postoji cijeli niz operativnih sustava za ugradbene računalne sustave [10], a najznačajniji su:

1. Tiny OS: Open source operativni sustav dizajniran za bežične uređaje male potrošnje, a primjenjuje se programski jezik nesC.

2. Contiki: Open source operativni sustav dizajniran

za ugradbene računalne sustave s malom memorijom (par kilobajta).

3. Mantis: Open source multithreading operativni sustav dizajniran za bežične senzorske platforme.

4. Nano-RK: Predstavlja RTOS (eng. Real-Time Operating System) nastao na Carnegie Mellon University namijenjen za multi-hop bežične senzorske mreže.

Slika 2. Usporedba bežičnih komunikacijskih tehnologija: prikaz funkcijske ovisnosti

komunikacijskog dosega o podatkovnoj brzini

18 CASE29

5. LiteOS: Open source interaktivni UNIX-like operativni sustav dizajniran za bežične senzorske platforme.

6. FreeRTOS: Real-time operaivni sustav namijenjen za ugradbene računalne sustave s više mikrokontrolera. Distribuira se kao GPL (eng. GNU General Public License).

2.3 Programski jezici

Programski jezici nekad su bili specifični za određenu mikrokontrolersku platformu, primjerice koristili su se različiti asemblerski jezici za programiranje ugradbenih sustava (eng. embedded system), ali danas se za IoT aplikacije sve više koriste opći programski jezici koji se koriste i za razvoj drugih aplikacija. Često se postavlja pitanje kako izabrati određeni programski jezik za IoT projekt. Pri izboru određenog programskog jezika treba uzeti u obzir ograničenja koja nameće sklopovlje takvih sustava kao što su:

procesorska snaga, raspoloživa memorija i prostor za pohranu.

IoT programski jezici mogu biti opće poznati kao što su C/C++ i Java ili specifični programski jezici kao što su Googleov Go jezik ili Parasail. Svaki od njih posjeduje određene prednosti ili nedostatke, a ispod slijedi kratki opis naznačajnijih programskih jezika [11,12] koji se koriste za razvoj IoT projekata:

1. C & C++: C programski jezik duboko je ukorijenjen u programiranju ugradbenih računalnih sustava. C++ je njegova objektno orijentirana inačica koja se koristi na svim operativnim sustavima (Winows, Linux, Android, iOS) i različitim ugradbenim sustavima (Arduino, STMicroelectronics, Raspberry PI). Njihova prednost je ta što su dizajnirani specifično za hardver na kojem se izvode, te su stoga pogodni za razvijanje aplikacija u sklopu IoT projekata.

2. Java: Njena prednost u odnosu na C i C++ je ta što je kod manje hardverski specifičan, a samim time više prenosiv na različite platforme uz postojanje odgovarajućih biblioteka. Koristi se kao programska podrška na poslužiteljskoj strani na koju se povezuju IoT uređaji.

3. JavaScipt, Node.js i DeviceJS: Vrlo su popularni jer pokrivaju cijeli IoT sustav, od ugradbenog računalnog sustava do poslužiteljske strane. Koriste se za programiranje osjetila, upravljačkih i komunikacijskih uređaja.

4. Python: Vrlo popularan interpreterski jezik posebno na Raspberry PI platformi. Fleksibilan je, jednostavan za čitanje i pogodan za prezentiranje podataka.

5. Go, Rust i Parasail: Googleov Go, Mozilla-in Rust i Parasail su specifični programski jezici dizajnirani za programiranje ugradbenih računalnih sustava.

6. B#: Za razliku od većine spomenutih programskih jezika B# nije se prilagođavao za ugradbene sustave, nego je upravo razvijen za njihovo programiranje. Ugradbena virtualna mašina (eng. Embedded Virtual Machine, EVM), koja omogućava

da se B# izvršava na različitim platformama, zahtjeva svega 24 KB memorije.

7. Assembler: Primjenjuje se kada se želi optimirati kod kojeg procesor izvršava, a to nije moguće postići primjenom drugih programskih jezika.

Pored navedenih programskih jezika u novije vrijeme sve se više primijenjuju Node-RED [14] vizualni alat za kreiranje IoT aplikacija i protokol za povezivanje MQTT (eng. Message Queue Telemetry Transport) [15].

3. RAZVOJ APLIKACIJA ZA INTERNET STVARI

Prethodna razmatranja pokazala su da je odabir odgovarajuće hardverske i softverske platforme veoma bitan za efikasan razvoj IoT aplikacija. U ovom poglavlju razmatrat će se razvoj IoT aplikacija kroz dva primjera koja se koriste u izvođenju laboratorijskih vježbi na Odsjeku za elektrotehniku Sveučilišnog odjela za stručne studije Sveučilišta u Splitu. U prvom primjeru koristi se LabView programska paltforma i Arduino hardverska platforma. U drugom primjeru pokazana je realizacija bežične senzorske mreže koja se temelji na Arduino hardverskoj platformi, a za razvoj aplikacije koriste se programski jezici C++, NodeJS i JavaScript.

3.1. Primjer 1 - Razvoj IoT aplikacije primjenom LabView platforme

Danas kada je povezivanje uređaja i senzora preko Interneta postala svakodnevnica LabVIEW ima dodatne prednosti jer nam kroz svoje integrirano grafičko razvojno okruženje omogućava jednostavnije kreiranje online virtualnih laboratorija, automatizacijskih sustava te sustava za daljinsko upravljanje.

3.1.1 LabView platforma

LabVIEW se kao razvojna platforma može koristiti na svim računalnim operacijskim sustavima (Windows, Mac OS X i Linux) te na različitim embedded platformama kao što su FPGA (eng. Field Programmable Gate Arrays), DSP (eng. Digital Signal Processors) i mikrokontroleri različitih arhitektura (ARM,

PIC, Atmel AVR, mbed i drugo). Za razliku od alata drugih proizvođača LabVIEW omogućava korištenjem grafičkog korisničkog sučelja integraciju hardvera većine svjetskih proizvođača opreme uz mogućnost primjene gotovih programskih biblioteka za analitičke i procesne funkcije. LabVIEW također omogućava integraciju standardnih programskih kodova kao što su Python, ANCI C ili .NET, kao i mogućnost rada sa softverskim programima i bibliotekama drugih proizvođača. Ovim je postignuto značajno poboljšanje u produktivnosti u odnosu na konvencionalne programske jezike.

LabVIEW, kojeg korisnici zbog svog grafičkog sučelja često nazivaju „G“ jezikom, omogućava pisanje programskog koda pomoću blok dijagrama u kojem se međusobno povezuju funkcijski blokovi preko njihovih ulazno-izlaznih parametara izvedenih kao priključni terminali, slika 3.

Ovi funkcijski blokovi se u LabVIEW terminologiji nazivaju virtualnim instrumentima (eng. Virtual Instruments, VI), a svaki od njih se sastoji od korisničkog sučelja (eng. front panel), blok dijagrama (eng. block diagram) i ikona koje predstavljaju virtualne instrumente, slika 4.

CASE29 19

Korisničko sučelje koristi se za prikaz kontrola i indikatora pomoću kojih korisnik može upravljati ili nadzirati sustav, dok blok dijagram sadrži programski kod određenog VI-a. Ikona vizualno predstavlja VI sa svim priključnim terminalima. Svi funkcijski elementi za korisnička sučelja i blok dijagrame su dostupni na funkcijskim paletama i mogu se sa njih povući na VI postupkom drag & drop. Svaki VI može biti sastavni dio drugog VI-a kao potprogramska cjelina i na taj način omogućiti kreiranje složenijeg programskog koda. Na ovaj način se postiže veća modularnost same aplikacije što dovodi do jednostavnosti izvedbe i lakšeg praćenja funkcija programskih dijelova koda.

Platforma koja se temelji na LabVIEW je pogodna za primjenu u edukaciji jer studenti ne moraju za realizaciju jednostavnih zadaća učiti sintakse različitih programskih jezika. Dovoljno je upoznavanje svojstava, odnosno parametara, pojedinih virtualnih instrumenata kako bi studenti realizirali određene projekte. Uz to, LabVIEW

pruža mogućnost grafičkog prikaza simulacije izvršavanja koda unutar blok dijagrama što pojednostavljuje razumijevanje koda i otkrivanje pogrešaka.

Kao što je prethodno napisano LabVIEW se može koristiti i na platformama ugradbenih računalnih sustava, a tu je zbog svoje ekonomične cijene posebno interesantna Arduino platforma. Inače pisanje aplikacija na samoj Arduino platformi zahtjeva znanje C/C++ jezika kao što će se vidjeti u drugom primjeru. LabVIEW omogućava rad s Arduino platformom primjenom LINX instalacijskog paketa [16]. Ovo omogućava realizaciju Arduino projekta bez pisanja i jedne linije koda. LINX paket sadrži firmware komunikacijskog sučelja i LabVIEW virtualne instrumente neophodne za rad s Arduino platformom. Instalacijski paket za LINX sučelje je besplatan i treba ga instalirati u LabVIEW pomoću VI Package Manager aplikacije.

Slika 4. Prikaz LabVIEW grafičkog razvojnog okruženja

Slika 3. Prikaz blok dijagrama LabVIEW-a

20 CASE29

Kako bi komunikacija između LabVIEW-a i Arduina radila potrebno je prije rada instalirati LINX firmware.

Postupak instalacije prikazan je na slici 5. LINX firmware omogućava pristup hardveru Arduina na fizičkom sloju sa LINX VI-a koje se koriste u aplikaciji LabVIEW-a. Uz to, postoji mogućnost da se LabVIEW VI izvršavaju autonomno na uređaju bez korištenja razvojnog PC-a, ali takvi uređaji trebaju podržavati Linux platformu kao što su: myRIO, Raspberry Pi 2/3, Arduino YUN, BeagleBone, Rabbit i druge.

Službeno, LabVIEW u potpunosti podržava samo Arduino Uno i Mega 2560, ali verzija LabVIEW 2015 ima ugrađenu i mogućnost rada s Leonardo, Nano i Pro Micro, slika 6.

Slika 6. Odabir Arduino mikrokontrolera kod instalacije LINX firmware-a

3.1.1 Primjer realizacije aplikacije

U ovom primjeru pokazat će se upravljanje auto-robotom (eng. robot car) realiziranog na LabVIEW i Arduino platformama. Na slici 7 prikazan je dizajn korisničkog sučelja koje se koristi za upravljanje auto-robotom. Preko korisničkog sučelja može se regulirati brzina i upravljati smjerom vožnje auta te pratiti informacija o udaljenosti prepreke ispred auta. Indikator zelene boje vizualno signalizira kada je udaljenost prepreke od auta manja od 15 cm. Na korisničkom sučelju također se može ručno konfigurirati port

komunikacijskog sučelja te ulazni i izlazni kanali Arduina sa kojih se vrši upravljanje.

Slika 7. Korisničko sučelje LabVIEW aplikacije

Programski dio koda, prikazan na slici 8, izveden je pomoću blok dijagrama, a prikazuje sekvencu za upravljanje autom prema „Naprijed“. Aplikacija sadrži identične sekvence i za ostale smjerove koji su definirani aktiviranjem odgovarajućih kanala na driver-u

motora. Ti kanali su označeni u sekvenci sa oznakama Enab 1 PWM, Enab 2 PWM, Input IN1, Input IN2, Input IN3 i Input IN 4. Motori kotača upravljani su preko L298N Dual H-Bridge motor driver-a. H-Bridge-om

može se upravljati s dva motora preko zasebnih digitalnih ulaza koji se mogu konfigurirati na korisničkom sučelju. U razmatranom primjeru motori dvaju kotača sa svake strane auta su spojeni na isti izlaz drive-a. Svaki izlaz motora je na H-Bridge-u upravljan s 3 ulazna signala. Ulazima Input IN1, Input IN2 i Enab 1 se upravlja kotačima lijeve strane auta, a ulazima Input IN3, Input IN4 i Enab 2 kotačima desne strane auta.

Primjerice, kako bi se ostvarilo okretanje motora, odnosno kotača s lijeve strane u smjeru ''Naprijed'' potrebno je na Input IN1 ulaz dovesti digitalni signal logičkog stanja ''1'', a na ulaz Input IN2 signal logičkog stanja ''0''. Okretanje kotača u suprotnom smjeru postiže se invertiranjem signala na oba ulaza.

Slika 5. Instalacija LINX firmware-a za Arduino platformu

CASE29 21

Zaustavljanje motora je ostvareno dovođenjem signala istog logičkog stanja na oba ulaza Input IN1 i Input IN2. Pomoću ulaza Enab 1 možemo regulirati brzinu okretanja kotača dovođenjem PWM (eng. Pulse Width Modulation) moduliranog signala ili onemogućiti rad

motora ako se na ovaj ulaz dovede logička ''0''. Ultrazvučni senzor na osnovu mjerenja vremena povrata odaslanog signala preračunava udaljenost. Izgled upravljanog auto-robota prikazan je na slici 9.

Slika 9. Izgled auto-robota upravljanog iz LabVIEW aplikacije

3.2 Primjer 2 - Bežična senzorska mreža

U ovom primjeru razmatra se razvoj aplikacije za bežični senzorski čvor koji obavlja sljedeće funkcije:

Mjeri temperaturu i vlažnost zraka, Izmjerene vrijednosti šalje web poslužitelju, Prikuplja podatke od drugih čvorova u lokalnoj

senzorskoj mreži te ih šalje web poslužitelju.

Senzorski čvorovi razvijeni su na hardverskoj platformi Arduino Pro Mini koja ima značajke dane u tablici 1 [19]. Čvor poveznika posjeduje dva radio modula:

nRF24L01+ [17] za komunikaciju u lokalnoj senzorskoj mreži i

ESP8266 [18] koji se koristi za povezivanje senzorskog čvora na web poslužitelj.

Ostali čvorovi u mreži posjeduju nRF24L01+ radio modul za komunikaciju unutar senzorske mreže. Za mjerenje temperature koristi se senzor DHT11, ali je na shemi na slici 13 prikazan senzor RHT03 zbog nepostajanja senzora DHT11 u bazi komponenti.

Tablica 2. Značajke Arduino Pro Mini hardverske platforme

Microcontroller ATmega328

Board Power Supply 5 - 12 V (5V model)

Circuit Operating Voltage

5V

Digital I/O Pins 14

PWM Pins 6

UART 1

SPI 1

I2C 1

Analog Input Pins 6

External Interrupts 2

DC Current per I/O Pin

40 mA

Flash Memory 32KB od kojih 2 KB koristi bootloader

SRAM 2 KB

EEPROM 1 KB

Clock Speed 16 MHz

Zadatak studenata je razviti senzorsku mrežu prema slici 10. Svaki senzorski čvor mjeri temperaturu i vlažnost zraka te izmjerene podatke šalje senzorskom čvoru koji predstavlja komunikacijski poveznik. Komunikacijski poveznik također mjeri temperaturu i vlažnost zraka, prikuplja podatke od drugih senzorskih čvorova te sve podatke šalje web poslužitelju. Podaci se prikupljaju i šalju web poslužitelju svakih 10 minuta.

Slika 8. Blok dijagram LabVIEW aplikacije

22 CASE29

Izgled senzorskog čvora poveznika prikazuje slika 11. Dizajn ostalih senzorskih čvorova je sličan, jedino ne posjeduju radio modul ESP8266. Za izradu aplikacije korišten je programski jezik C++ i Arduino razvojna okolina, slika 12. Shematsko povezivanje upotrijebljenih komponenti realizira se primjenom programa Fritzing [20]. Slika 13 shematski prikazuje senzorski čvor poveznika.

Na slici 12 vide se header datoteke korištenih biblioteka.

Biblioteka RF24 odnosi se na upotrijebljeni radio primopredajnik nRF24L01+, a ovaj modul je povezan s Arduinom pomoću sabirnice SPI (eng. Serial Peripheral

Interface) uz korištenje SPI biblioteke. Veza između wifi

modula ESP8266 i Arduina je serijska, a koristi se biblioteka SoftwareSerial kako bi se definirali pinovi koji se koriste za ovu komunikaciju. Wifi modul ESP8266 za komunikaciju koristi AT naredbe te nije potrebna posebna programska biblioteka za ovaj modul. Upotrijebljeni senzor DHT11 koristi DHT biblioteku. Web poslužitelj realiziran je primjenom programskih jezika NodeJS i JavaScript. Slika 14 prikazuje prikupljene informacije na web poslužitelju.

Slika 10. Senzorska mreža

Slika 11. Senzorski čvor poveznika

CASE29 23

Slika 13. Shematski prikaz senzorskog čvora komunikacijskog poveznika

Slika 12. Arduino IDE

24 CASE29

4. ZAKLJUČAK

Danas postoje mnogobrojne hardverske i softverske platforme za razvoj IoT aplikacija. Zbog toga je odabir odgovarajuće platforme veoma bitan za efikasan razvoj IoT aplikacija. Razmatranja provedena u drugom poglavlju rada dala su kratak pregled odgovarajućih platformi, kao i programskih jezika pogodnih za izradu IoT aplikacija.

Kroz dva primjera u trećem poglavlju rada prikazani su različiti pristupi izrade IoT aplikacija koji se koristi prilikom obavljanja laboratorijskih vježbi na Sveučilišnom odjelu za stručne studije. Prvi pristup koristi LabVIEW vizualno okruženje za razvoj aplikacija, stoga olakšava cijeli postupak izrade aplikacije. Drugi pristup zahtjeva poznavanje C++ programskog jezika, ali je pogodniji prilikom izrade aplikacije za različite ugradbene računalne sustave.

Literatura:

1 Phil Goldstein. Ericsson backs away from expectation of 50B connected devices by 2020, now sees 26B. http://www.fiercewireless.com/wireless/ericsson-backs-away-from-expectation-50b-connected-devices-by-2020-now-sees-26b [Online; accessed 28-10-2015]

2 Libelium. Libelium Adds New Cloud Options to Build the Industrial IoT and Smart Cities. http://www.libelium.com/libelium-new-cloud-options-for-industrial-iot-and-smart-cities/#!prettyPhoto [Online; accessed 18-2-2017]

3 Electric Imp. https://electricimp.com/ [Online; accessed 18-2-2017]

4 Amazon. https://aws.amazon.com/iot/ [Online; accessed 18-7-2016]

5 Estimote. http://estimote.com/ [Online; accessed 1-9-2016]

6 T. Kovačević, S. I. Vrdoljak, S. Jenčić. INTERNET STVARI: NORME BEŽIČNIH KOMUNIKACIJSKIH TEHNOLOGIJA. KOM 2015. Zagreb.

7 Arduino. https://www.arduino.cc/ [Online; accessed 1-2-2017]

8 National Instruments. http://www.ni.com [Online; accessed 1-2-2017]

9 Raspberry PI. https://www.raspberrypi.org/ [Online; accessed 14-1-2017]

10 Postscapes. IoT Software Development Guide. http://www.postscapes.com/internet-of-things-software-guide/ [Online; accessed 10-1-2017]

11 UpWork. Internet of Things: The Tools, Platforms and Programs You Need to Know. https://www.upwork.com/hiring/development/internet-of-things-platforms-and-programs-you-need-to-know/ [Online; accessed 10-1-2017]

12 C. Franklin. 11 IoT Programming Languages Worth Knowing. http://www.informationweek.com/mobile/mobile-applications/11-iot-programming-languages-worth-knowing/d/d-id/1319375?image_number=10 [Online; accessed 1-6-2016]

13 Qualcomm. Internet of Things (IoT) Development Platform. https://developer.qualcomm.com/hardware/iot-cellular-dev [Online; accessed 1-2-2017]

14 Node-RED. https://nodered.org/ [Online; accessed 7-1-2017]

15 MQTT. http://mqtt.org/ [Online; accessed 7-1-2017]

Slika 14. Prikaz prikupljenih informacija na web poslužitelju

CASE29 25

16 LabVIEW LINX. MakerHub. https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:libraries:linx:start [Online; accessed 8-2-2017]

17 Nordic. http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01 [Online; accessed 8-1-2017]

18 ESP8266. https://www.itead.cc/wiki/ESP8266_Serial_WIFI_Module [Online; accessed 8-2-2017]

19 T. Kovačević, M. Čagalj, T. Perković, I. Vuković. POVEZIVANJE BEŽIČNOG SENZORSKOG ČVORA S POSLUŽITELJEM U OBLAKU, CASE 27. Zagreb 2015.

20 Fritzing. http://fritzing.org/home/ [Online; accessed 8 2-2017]

Podaci o autorima:

Tonko Kovačević

Sveučilišni odjel za stručne studije,

Sveučilište u Splitu

Kopilica 5, 21000 Split

e-mail: tkovacev@oss.unist.hr

Đoni Garmaz

Zvonimirova 121

21210 Solin

e-mail: djoni.garmaz@gmail.com

Silvano Jenčić

Sveučilišni odjel za stručne studije,

Sveučilište u Splitu

Kopilica 5, 21000 Split

e-mail: sjencic@oss.unist.hr

Marko Meštrović, student

Sveučilišni odjel za stručne studije Kopilica 5,

21000 Split

e-mail: mm38527@oss.unist.hr

26 CASE29

CASE29 27

PRIJEDLOG METODOLOGIJE IZGRADNJE I KLASIFIKACIJE RESTful WEB SERVISA

A PROPOSAL OF METHODOLOGY FOR CONSTRUCTION AND CLASSIFICATION OF RESTful WEB SERVICES

Alen Šljivar, Marin Kaluža

SAŽETAK:

Putem različitih platformi, korištenjem različitih oblika korisničkih sučelja, korisnik pristupa softveru i koristi njegove funkcionalnosti. Često softver u svom radu koristi resurse ili aplikativne dijelove drugih sustava čime se ostvaruje softver kao usluga (SaaS). Obzirom da se zbog toga povećava razina distribuiranosti softvera, raste i potreba za izradom web servisa. Representational state transfer (REST) je paradigma arhitekture web servisa. Radom će se prikazati postupak modeliranja i izgradnje "hipermedijskog" REST web servisa - RESTful servis. Pokazati će se metodologija koja se može koristiti u razvoju RESTful web servisa. Koristit će se Richardson Maturity Model (RMM) za klasifikaciju web servisa. Metodologijom izgradnje definirati će se koraci koje je potrebno izvršiti u procesu razvoja (modeliranje i izgradnja) RESTful servis. Ključne riječi: SaaS, RMM, RESTful web servis, modeliranje, klasifikacija

ASBTRACT:

User approaches the software and uses its functionalities, through many different platforms and many different forms of user interfaces. Software often uses resources or application parts from other systems, thereby accomplishing software as a service (SaaS). That increases the level of distribution of the software and because of that there is an increasing need for web services development. Representational state transfer (REST) is the architectural style for building web services. The procedure for modelling and building "hypermedia driven" REST web service – RESTful web service, will be shown. Also, there is a proposal of the methodology which can be used for RESTful web service development. Richardson Maturity Model (RMM) will be used for classification of web services. The methodology defines required steps in the development process (design and implementation) of RESTful web service. Key words: SaaS, RMM, RESTful web service, design, classification

1. UVOD

World wide web (Web) je od svojih početaka

strukturiran na način da uključuje pojam resurs. U prvom redu web je bio tek platforma za dijeljenje tekst/HTML datoteka, dokumenata, slika itd. [11]. Danas Web predstavlja velik broj sustava, aplikacija i servisa te omogućuje traženje, agregiranje, kombiniranje, transformiranje, repliciranje, predmemoriranje i arhiviranje informacija koje podupiru današnje digitalno društvo [20]. Web se smatra najuspješnijim distribuiranim sustavom u povijesti i zato svaki građeni Web servis može imati koristi od filozofije REST-a koji koristi njegove ideje i na taj način se dobiva bolji put za izgradnju distribuiranog računalstva [17]. Kako se komunikacija na Web-u događa preko HTTP-a REST je usko povezan s njime i kako bi se razumio REST potrebno je razumjeti i temeljne koncepte HTTP-a (metode, zaglavlja, statusni kodovi) [11].

U radu je pokazan postupak modeliranja i izgradnje RESTful web servisa i definiranje semantike podataka u komunikaciji klijent-poslužitelj. Prikazan je proces definiranja naziva tranzicija i reprezentacija resursa u servisu. Definiran je i postupak odabira tipa medija koji će podržavati hipermediju. Definirana je metodologija razvoja servisa koja koristi UML dijagrame klasa [16] i dijagrame stanja [16][6] te „Seven-step design procedure“ [17]. Dijagram klasa će dati informacije o strukturi sustava i predloške URI-a. Dijagramom stanja se dobivaju informacije o mogućnostima kretanja klijenta kroz različita stanja u servisu i tranzicijama.

„Seven-step-design procedure“ definira odabir javnih imena te tip hipermedije potrebne za definiranje semantike servisa. Pokazat će se kako se prikazanom metodologijom može dostići najviša razina Richardson Maturity modela (RMM) u izgradnji servisa.

2. DOSADAŠNJA ISTRAŽIVANJA

Istraživanje „RESTML: Modeling RESTful Web Services“ [14] objašnjava modeliranje servisa kroz određene stadije definirane od strane autora i koriste se razni UML dijagrami i principi Model-driven architecture

(MDA) pristupa. U radu se koriste UML dijagrami za vizualizaciju i definiranje ponašanja dizajniranog sustava.

Istraživački rad „Hypermedia Types“ [15] autor

identificira devet čimbenika koje tip medija treba podržati da bi bio hipermedijski i da bi time omogućio izgradnju RESTful servisa. U ovom radu neće biti potrebe za definiranjem vlastitog tipa medija, koristiti će se određeni gotovi tipovi medija.

„Seven Step design procedure“ [17] developer-a vodi

kroz sedam koraka i definira se što je na kojem koraku potrebno napraviti da bi se izgradio RESTful servis. Metodologija obuhvaća proces odabira hipermedijskog tipa koji pruža mogućnost definiranja HATEOAS razine RMM-a.

U radu „Modeling behavioral RESTful Web Service Interfaces in UML“ [16] pristupa se modeliranju strukture i sučelja ponašanja RESTful servisa pomoću UML

28 CASE29

dijagrama klasa i stanja. U radu se na temelju izgrađenih UML dijagrama definira Web Application Description Language (WADL) za obuhvaćanje informacija o ponašanju metoda u servisu. WADL nije potreban RESTful servisu jer je servis dokumentiran kroz tip medija korišten za reprezentaciju resursa [9].

3. REST OGRANIČENJA I HTTP

Termin servis se koristi za označavanje bilo kakve softverske funkcije koja obavlja određeni poslovni zadatak, omogućuje pristup datotekama ili obavlja generičku funkciju kao što su autentikacija ili prijava. Za razliku od servisa, web servisi osiguravaju integraciju različitih sustava i dopuštaju ponovnu upotrebu određenih poslovnih funkcija preko HTTP protokola. SOAP/WSDL servisi koriste HTTP samo kao transportni protokol dok REST web servisi koriste HTTP kao aplikacijski protokol koji definira semantiku ponašanja servisa [4]. Da bi se mogao izgraditi REST servis potrebno je poznavati ograničenja REST-a. Ograničenja REST-a predstavio je Roy Fielding [12], a služe za postizanje ciljeva: veća skalabilnost softvera, generalizacija sučelja i neovisan razvoj komponenata [7].

KLIJENT- POSLUŽITELJ (client-server) - Razdvajanje poslužitelja i klijenta. Poslužitelj treba biti odgovoran za spremanje podataka u bazu kao i za poslovnu logiku koja je potrebna za interakciju s njim (autentikacija, autorizacija, validacija podataka itd.). Klijent (Preglednik) je odgovoran za izradu zahtjeva prema servisu, te smisleno korištenje primljenog odgovora. Klijent može biti također servis koji će samo konzumirati podatke dobivene od poslužitelja ali može predstavljati i sučelje s kojim će korisnik imati interakciju kao što je web ili mobilna aplikacija [12].

ZAHTJEVI BEZ STANJA (stateless) - svaki zahtjev sadrži sve potrebne informacije koje će poslužitelj moći pravilno obraditi i kreirati odgovor. Ovime poslužitelj ne treba pamtiti informacije od prijašnjih zahtjeva. Na ovaj način je odgovornost održavanja aplikacijskog stanja klijenta prebačeno na samog klijenta [12].

PREDMEMORIRANJE (caching) – označavanje

odgovora koji će se spremati u pred memoriju (cachable) ili odgovori koji se neće spremati u pred memoriju (non-cacheable). Ako je odgovor označen za pred memoriranje poslužitelj mora definirati vremenski period u kojem će odgovor biti validan. Web servisi obično postižu mogućnost predmemoriranja koristeći HTTP Cache-Control zaglavlja (If-Modified-Since/Last Modifie ili If-None-Match/ETag) [12].

JEDINSTVENO SUČELJE (uniform interface) -

Jedinstveno sučelje definira REST servisu što treba poslužiti i u kojoj formi (dokument, slika itd.). Dokument koji poslužitelj šalje se zove reprezentacija (representation) resursa [17]. HTTP koristi jedinstvenu adresu (URI) za identifikaciju resursa te HTTP metode i statusne kodove za interakciju sa resursima [12]. Statusni kodovi pružaju informacije klijentu o ishodu zahtjeva i metodi tumačenja odgovora. Statusni kod mora vratiti informaciju je li određeni zahtjev uspješno završen ili ne. Ako nije uspješno završen statusni kod daje daljnji trag zašto zahtjev nije uspio. Grupe HTTP statusnih kodova su [11]:

2xx koja govori da je zahtjev završen uspješno i bez grešaka

3xx podrazumijeva preusmjeravanje

4xx se koristi kada je napravljena greška u zahtjevu (neautoriziran pristup resursu, pokušaj korištenja resursa koji ne postoji, nevažeći parametri itd.)

5xx se koristi kada je greška na poslužiteljskoj strani.

SLOJEVITA ARHITEKTURA (Layered architecture) -

Cjelokupna arhitektura servisa dijeli se na pojedinačne slojeve. Svaki sloj mora djelovati samostalno, i vršiti interakciju samo sa njemu susjednim slojevima. To osigurava predvidiv način prijenosa zahtjeva iz klijenta na poslužitelj, bez zaobilaženja slojeva [12].

KOD NA ZAHTJEV (code on demand) - Kod na zahtjev

je jedino ograničenje koje nije obaveznu u REST web servisu. REST omogućuje klijentu proširivost funkcionalnosti sustava na lokalno računalo klijenta [7].

4. RMM

Kako REST nije standard nego apstraktan koncept to otežava izraziti je li servis RESTful ili nije. Za apliciranje REST ograničenja u implementaciji ili klasifikaciji web servisa definiran je Richardson maturity model (RMM). Na temelju njega se ispituje je li određeni web servis RESTful ili nije. Ovaj sustav klasificiranja, pruža dobar način za razmišljanje o servisu, o izgradnji ili klasifikaciji već postojećeg REST servisa, iz perspektive krajnjeg korisnika [13][10]. RMM ima četiri razine (0-3).

Razina 0 (Swamp of POX) - Početna točka modela je

korištenje HTTP protokola kao transportnog protokola za udaljene interakcije, ali bez korištenja mehanizama vezanih uz Web. Servisi u ovoj kategoriji koriste princip jedan URI i jedna vrsta metode. Uglavnom se koristi isti mehanizam kao kod Simple Object Access Protocol (SOAP) servisa [13][10].

Razina 1: Resursi (Resources) - Na ovoj razini RMM-

a definiraju se resursi. To znači da se više ne rade zahtjevi samo na jednu krajnju točku servisa, već se govori o individualnim resursima [10]. Konačan cilj ove razine je da se koristi veći broj URI-ja, gdje je svaki URI ulazna točka za specifičan resurs. Npr. umjesto čitanja svih knjiga (http://example.org/books) moguće je razlikovati pojedine knjige http://example.org/books/1 i http://example.org/books/2 itd.

Razina 2: HTTP metode (HTTP verbs) - Ova razina

definira akcije koje se mogu odrađivati nad resursima i moraju striktno pratiti HTTP konvencije. Ova razina je okarakterizirana kao „sustav više URL-a, više akcija“ [13]. Ovom razinom je definirano kada se koja HTTP metoda koristi i bazira se na sigurnim i idempotentnim svojstvima definiranim u HTTP specifikaciji. U ovom radu će koristiti četiri metode koje su potrebne pri izgradnji REST servisa a to su GET, POST, PUT, DELETE.

Sigurne metode (safe methods) ne smiju provoditi

druge akcije osim dohvaćanja. GET je sigurna metoda i ona se treba koristiti samo za dohvaćanje podataka. Idempotentne metode su one kojima je rezultat većeg

broja istih zahtjeva isti kao i samo jednog zahtjeva [8]. Dok god su parametri zahtjeva nepromijenjeni, zahtjev se može napraviti bilo koji broj puta i resurs će i dalje ostati u istom stanju kao i kad je zahtjev napravljen samo jednom [11]. GET, PUT i DELETE imaju ovo svojstvo. POST metoda nije niti sigurna niti idempotentna i ona se treba koristiti za kreiranje nekog resursa. Većina današnjih servisa se nalazi na ovoj razini i servisi na ovoj razini se često nazivaju RESTful iako ne pokrivaju zadnju HATEOAS razinu [13].

CASE29 29

Razina 3: Hypermedia As The Engine Of Application State (HATEOAS) - Cilj ove razine je pružanje

konzistentnog način korištenja za automatizirane operatere (druge servise). Time je omogućeno korištenje servisa bez potrebe za prethodnim mapiranjem funkcija (resursa). Prilikom pristupanja web stranici korisnik traži određenu informaciju. Kada korisnik traži određenu informaciju pristupa relevantnoj web stranici i to je polazna točka na web stranici. Sve ostale informacije su iz te točke potpuno dostupne i upotrebljive samim kretanjem kroz relevantne poveznice. HATEOAS proširuje ideju web-a na web servise. HATEOAS uklanja potrebu da developer mora održavati dokumentaciju servisa jer sve što klijent treba znati o upotrebi servisa je već definirano kroz HATEOAS [13]. Kao i REST, hipermedija nije jedna dokumentirana tehnologija. Hipermedija je strategija koja treba biti implementirana na različite načine koristeći veći broj tehnologija [17].

5. HATEOAS KLASIFIKACIJA

Tehnologije web-a formiraju tehnološki stog za web servise (URI, HTTP, HTML - Hipermedija). Te tri tehnologije predstavljaju implementaciju svih REST ograničenja na human-readable Web-u [18]. Kod Web servisa postoji veći broj tipova medija koji konkuriraju u preuzimanju mjesta HTML-a odnosno hipermedije [18]. Tipovi medija (media types) su neovisni o platformi i

dizajnirani su za komunikaciju između distribuiranih sustava [3]. U ovom poglavlju će se prikazati klasifikacija servisa temeljena na HATEOAS razini. Za dostizanje HATEOAS razine potrebno je koristiti tip medija koji podržava definiranje poveznica. JSON

*

standard nema hipermedijske sposobnosti jer on definira koncepte kao što su brojevi, liste, znakovni nizovi i objekti ali ne definira koncepte poveznica ili

* JavaScript Object Notation

odnose među njima. Neki hipermedijski tipovi su HAL†,

Siren‡, Collection+JSON

§ [17]. U primjerima klasifikacije

će se prikazati reprezentacija resursa u tijelu HTTP odgovora i tip medija koji se koristi za prijenos informacija i poveznica. Pokazat će se primjer web API-a koji koristi JSON tip medija i prikazati će se Collection+JSON tip medija i njegove funkcionalnosti..

Na slici 1 se nalazi reprezentacija resursa koji sadrži informacije o recenziji traženog filma. U odgovoru je moguće vidjeti ključ (key) „results“ koji sadrži polje (array) kao vrijednost. Polje se sastoji od objekta koji sadrži informaciju na recenziju traženog naslova filma. Da traženi film ima veći broj recenzija ključ „results“ bi sadržavao veći broj objekata. Vraćena reprezentacija nudi poveznicu na članak recenzije filma ali se ne dobivaju poveznice koje bi klijentu mogle dati mogućnosti kretanja kroz nova stanja kao što je npr. poveznica na redatelja i njegove filmove ili na poveznicu recenzenta i njegovu kolekciju tekstova. Daljnje kretanje klijenta treba biti omogućeno kroz poveznice i to definira HATEOAS razina. Analizirani web servis ju ne podržava.

**

Kao što JSON format definira ograničenja nad običnim tekstom tako se kroz JSON bazirane hipermedijske tipove, u ovom primjeru Collection+JSON, uvode ograničenja nad JSON formatom [17]. Collection+JSON objekt mora imati svojstvo „collection“ koji mapira na svojstvo „items“, svojstvo „href“ koje definira poveznice [17]. Sva definirana ograničenja na kraju daju dobro formatiran dokument koji se fokusira na međusobno povezivanje resursa. Na slici 2 se vidi prikaz Collection+JSON odgovora. Reprezentacija resursa mora sadržavati „collection“ objekt sa „version“

† http://stateless.co/hal_specification.html

‡ https://github.com/kevinswiber/siren

§ http://amundsen.com/media-types/collection/

**

http://developer.nytimes.com/movie_reviews_v2.json

Slika 1. JSON odgovor Movie Reviews API**

30 CASE29

svojstvom i poveznicom koja pokazuje na samog sebe - „href“. Kroz svojstvo „links“ definirane su poveznice koje dopuštaju promjenu aplikacijskog stanja od strane klijenta [19].

6. METODOLOGIJA IZGRADNJE RESTFUL WEB SERVISA

Metodologija izgradnje servisa temelji se na korištenju

„Seven-Step Design Procedure“ (SSDP) [17] iz koje su preuzeti određeni koraci, UML class dijagrama za strukturu, te UML dijagram stanja [16] za definiranje ponašanja servisa.

6.1 Model resursa

Prvi korak u SSDP podrazumijeva navođenje svih dijelova informacija koje klijent možda želi izvući iz web servisa ili ih smjestiti u servis [17]. Prema [16] resursi se

Slika 2. Prikaz Collection+JSON odgovora [19]

<<collection>>

books

GET: dohvaća listu knjiga

POST: kreira novu knjigu

shelf

id: int

naziv: varchar(32)

<<collection>>

shelves

POST: kreira novu policu

book

id: int

naziv: varchar(255)

<<collection>>

comments

GET: dohvaća listu komentara

POST: kreira novi komentar

comment

id: int

tekst: varchar(255)

autor: varchar(255)

kategorija: varchar(32)

isbn: varchar(17)

izdavac: varchar(32)

brojStranica: int

godina: year

izdanje: int

jezik: varchar(16)

datumStvaranja: TimeStamp

shelves/{shelfId}

1..*{bookId}

0..*

{commentId}

comments/{commentId}

0..*

1

books/{bookId}

0..*{shelfId}

books/{bookId}0..*

0..*

GET: dohvaća određenu policu

PUT: ažurira određenu policu

GET: dohvaća određenu knjigu

GET: dohvaća određeni komentar

PUT: ažurira određeni komentar

GET: dohvaća listu polica

DELETE: briše određenu knjigu

DELETE: briše određeni komentar

DELETE: briše određenu policu

url: varchar (255)

opis: varchar(255)

datumModificiranja: TimeStamp

Slika 3:Model resursa za sustav „Book Tracker“

CASE29 31

definiraju pomoću UML dijagrama klasa. Dijagramom klasa se definira i model za bazu podataka. U ovom koraku se definira dijagram klasa koji predstavlja strukturu i povezanost resursa u servisu. UML dijagram klasa prikazuje klase i njihove asocijacije (associations). Asocijacija definira vezu između dvije klase [16]. Dijagram klasa treba prilagoditi resursima u REST paradigmi [16]:

Svaka klasa u UML dijagramu predstavlja resurs Klase sa <<collection >> prezentira kolekciju

resursa Atributi klasa su podaci sadržani u resursu Asocijacije prezentiraju veze među resursima Imena uloge na krajevima asocijacije mapiraju

relativan navigacijski put od jednog resursa prema drugom

Mnogostrukost (multiplicity) određuje broj

primjeraka jednog resursa u odnosu na resurs na drugom kraju asocijacije.

Kako RESTful web servis treba pružati jedinstveno sučelje nad svim resursima tako će klase imati jednu od HTTP metoda [16]. Kolekcija resursa ima kardinalnost više na „child resource“. GET metoda na kolekciju resursa vraća listu svih child resource-a koje sadrži.

Kolekcija resursa se također koristi kao početna točka navigacije adresiranja svakog resursa. Navigacija koja se kreće po istoj asocijaciji više od jednom nije validna. Dijagram klasa omogućava da se definira veći broj operacija nad svakom klasom [16]. Na taj način se podržava razina 1 RMM-a koja govori o resursima. Na Slici 3 prikazan je model resursa koji definira kolekcije resursa i pojedini resurs u servisu te predloške URI-a za pristupanje tim resursima. Vitičaste zagrade u URI-ma predstavljaju varijable koje primaju određenu vrijednost.

6.2 Dijagram stanja

UML Protocol State Machine dijagram će se koristiti za prikaz ponašanja servisa. Ovi dijagrami su korisni za prikazivanje različitih stanja u klasi objekata, odnosno u

ovom slučaju resursa, koji mogu postojati određeno vrijeme te za prikazivanje promjena njihovih stanja tijekom vremena [6]. Dijagram se gradi s gledišta klijenta i poslužitelj se zanemaruje. Strelica u dijagramu prikazuje tranziciju stanja pokrenuta HTTP zahtjevom. Svako stanje ima definiranu reprezentaciju resursa. Strelice povezuju stanja na način kako bi to klijent radio [16]. Klijent je svjestan samo trenutnog stanja i dostupnih tranzicija koje to stanje nudi. Poslužitelj poznaje cijeli state dijagram ali ne trenutno stanje na kojem se klijent nalazi. Trenutno stanje se sprema na strani klijenta [5]. U ovom koraku još nije potrebno dodjeljivati specifične HTTP metode tranzicijama stanja ali je potrebno pratiti je li tranzicija stanja sigurna (safe), nesigurna (unsafe) ali idempotentna (idempotent) ili nesigurna i ne idempotentna [17]. Svako stanje aplikacije definira određenu reprezentaciju [17]. Ovaj dio se podudara sa dijagramom resursa gdje su se već definirale HTTP metode ali postoji potreba za nazivom svake tranzicije koju pokreće HTTP metoda kako bi se definirala semantika servisa. Do svake promjene stanja se dolazi URI-em i HTTP metodom koji su definirani kroz dijagram resursa u prethodnom poglavlju, a u ovom dijagramu su definirani semantički nazivi akcija.

Na slici 4 je prikazan dijagram stanja na kojem je vidljivo da su moguća dva početna stanja iz kojih se klijent može kretati. Klijent može zatražiti knjige (list-books) i police (list-shelves) i kroz daljnje tranzicije može mijenjati stanja aplikacije. Tu je vidljivo kako su knjige i police u modelu resursa bili prikazani kao kolekcija resursa te je kroz njega definirano kako se kolekcija resursa koristi kao početna točka navigacije. Komentari su također definirani kao kolekcija resursa. Nema potrebe za definiranjem komentara kao početne točke navigacije jer je mala vjerojatnost da će klijent krenuti od liste komentara do određenog komentara pa prema knjizi na koju se komentar odnosi. URI bi onda izgledao comments/{commentId}/books/{book} a u dijagramu stanja bi se definirala još jedna početna točka sa tranzicijom list-comments prema stanju „comments“.

BOOKS

BOOK

COMMENT

SHELVES

CREATE-BOOK

(unsafe

Non-idempotent)

LIST-BOOKS (safe)

CREATE-COMMENT (unsafe

Non-idempotent)

READ-COMMENTS (safe)

DELETE-COMMENT

(unsafe

idempotent)

SEE-BOOK (safe)

SHELF

EDIT-BOOK

(unsafe

idempotent)

SEE-BOOKS

(safe

idempotent)

SEE-SHELF(safe)

LIST-SHELVES (safe)

CREATE-SHELF

(unsafe

Non-idempotent)FILTERING

{category}or{year}or{ author}

safe

DELETE-BOOK

(unsafe

idempotent)

EDIT-SHELF

(unsafe

idempotent)ADD-BOOK

(unsafe

Non-idempotent)

DELETE-SHELF

(unsafe

idempotent)

EDIT-COMMENT

(unsafe

idempotent)

COMMENTS

SEE-COMMENT

(safe)

READ-BOOK

(safe)

SEE-LIST-BOOKS

(safe)

SEE-LIST-SHELVES

(safe)

SEE-LIST-COMMENTS

(safe)

Slika 4: :State-machine: Book tracker

32 CASE29

Dijagrami stanja i klasa pružaju developeru uvid u

semantiku protokola servisa (koji HTTP zahtjev će klijent napraviti) [17]. Semantika HTTP protokola (protocol semantic) se postigla jer se iz dijagrama stanja (slika 4) može vidjeti da se safe metoda (GET) uvijek koristi kod dohvaćanja reprezentacije resursa. Tranzicije „edit“ i „delete“ koriste nesigurne ali idempotentne metode PUT i DELETE, a tranzicija "insert" koristi nesigurnu i ne idempotentnu metodu POST. Na taj način se analizom HTTP zahtjeva može vidjeti što klijent želi postići: dohvaćanje reprezentacije resursa, brisanje resursa, kreiranje resursa [17]. Kolektivno se HTTP metodama definirala semantika protokola i podržala razina RMM-a koja definira način korištenja HTTP metoda. Nazivi tranzicija i podataka koji će biti poslani u zahtjevima definiraju semantiku aplikacije (application semantic

††). Semantika aplikacije se definira u

sljedećem koraku.

6.3 Javna imena reprezentacija i tranzicija

Atributi iz modela resursa i tranzicija u dijagramu stanja predstavljaju „semantic descriptor“ i „link relations“ [17]. Za nazive sigurnih tranzicija u dijagramu stanja mogu se koristiti registrirana imena u IANA-i

‡‡. Za definiranje

imena reprezentacije (pojedino stanje u dijagramu stanja) i pripadajućih atributa koristi se Schema

§§,

microformats***

, i Dublin Core†††

[1]. To su repozitoriji dobro definiranih i javno podijeljenih imena i kada se ta imena koriste za sučelje servisa veća je vjerojatnost

††

Aplikacijska semantika tumači resurs u smislu koncepta

stvarnog svijeta. Dva HTML dokumenta mogu koristiti

identične oznake (tags) ali imati potpuno različitu

aplikacijsku semantiku – jedan opisuje osobu, a drugi opisuje

medicinski postupak [16] ‡‡

http://www.iana.org/assignments/link-relations/link-

relations.xhtml - IANA je globalni registar link relations-a. §§

www.Schema.org ***

http://microformats.org/ †††

http://dublincore.org/documents/dces/

razumijevanja sučelja web servisa od strane klijenata. Na taj način se može poboljšati upotrebljivost servisa [1]. Atributi u modelu resursa prikazuju interna imena koja se koriste kroz definiranja polja pri izgradnji baze podataka. Kroz dijagram stanja (slika 5) se kroz navedene repozitorije definiraju javna imena u reprezentacijama i tranzicijama resursa koja će biti podijeljena kroz sučelje servisa. Naknadno se kroz servis izvršava mapiranje javnih imena sa internim imenima u bazi podataka [1].

Na slici 5 prikazan je ažurirani dijagram stanja prema Schema.org i IANA repozitorijima. Pomoću schema.org su se definirala javna imena stanja i podataka (atributima iz modela resursa su se definirala javna imena koja će se koristiti u sučelju servisa i zapisana su u pojedinim stanjima u dijagramu stanja). Prema [1] svako stanje je definirano kao „item“ ako je pojedinačni resurs te „list“ ako je kolekcija resursa, tako je stanje „books“ preimenovano u „book list“ a „book“ u „book item“. Kada postoji veza između liste stvari i individualne stvari u listi, u IANA kolekciji se koristi tranzicija collection i item. Na taj način su se definirale tranzicije „see-list-books“ i "see-book" koje postaju collection i item [17]. Na isti način su definirane tranzicije resursa komentara i polica. Tranzicije „edit-comment“, „edit-book“ i „edit-shelf“ postaju samo edit [17] i definiraju se podaci koji se šalju između klijenta i poslužitelja. Tako se za ažuriranje police šalju „identifier“ i „name“. Tranzicija „filtering“ postaje „search“.

Za sve tranzicije se nije uspjela naći zadovoljavajuća zamjena u IANA-i jer su tranzicije kao „add-book“, „delete-shelf“ specifične samo za ovaj servis koji se gradi. Tu se nazire problem u aplikacijskoj semantici jer programer koji će koristiti ovaj servis ne zna točno kakvu promjenu na poslužiteljskoj strani radi tranzicija „add-book“ (dodavanje knjige u policu) koja je unsafe i „non-idempotent“. Tako je i sa ostalim tranzicijama za koje se nije uspjelo pronaći javna imena iz navedenih repozitorija.

BOOK LIST

BOOK ITEM

identifier, name, author, genre, isbn,

publisher, datePublished, bookEdition,

numberOfPages, inLanguage, url,

description

COMMENT ITEM

identifier,

comment,

dateCreated,

dateModified

SHELF LIST

CREATE-BOOK

(unsafe

Non-idempotent)

COLLECTION (safe)

CREATE-COMMENT (unsafe

Non-idempotent)

{identifier}

READ-COMMENTS (safe)

{identifier}

DELETE-COMMENT

(unsafe

idempotent)

{identifier}

ITEM (safe)

{identifier}

SHELF ITEM

identifier, name

EDIT

(unsafe

idempotent)

{identifier, url,

description}

SEE-BOOKS

(safe

idempotent)

{identifier}

ITEM(safe)

{identifier}

COLLECTION(safe)CREATE-SHELF

(unsafe

Non-idempotent)

{name}

SEARCH

{genre}or{datePublished}or{ author}

safe

DELETE-BOOK

(unsafe

idempotent)

{identifier}

EDIT

(unsafe

idempotent)

{identifier, name}ADD-BOOK

(unsafe

Non-idempotent)

{identifier}

DELETE-SHELF

(unsafe

idempotent)

{id}

EDIT

(unsafe

idempotent)

{identifier, comment}

COMMENT LIST

ITEM

(safe)

{identifier}

READ-BOOK

(safe)

COLLECTION

(safe)

COLLECTION

(safe)

COLLECTION

(safe)

Slika 5: State-Machine: Book tracker - Javna imena

CASE29 33

6.4 Odabir tipa hipermedije

Tipovi medija (media types) služe za prijenos

informacije [3]. Nakon što se definirala semantika protokola potrebno je odabrati tip hipermedije koja će predstavljati reprezentaciju i tranzicije u komunikaciji između klijenta i poslužitelja. Na temelju javnih naziva tranzicija se odabire hipermedijski tip. JSON

‡‡‡ nije

format hipermedije jer on definira koncepte kao što su brojevi, polja, stringovi i objekti a koncepte poveznica ili njihovih veza (link relations) ne podržava [17]. Da bi se postigla HATEOAS razina potrebno je odabrati hipermedijski tip. Hipermedijski tipovi podataka se mogu podijeliti na uzorke kolekcija (collection pattern) kao što su Collection+JSON, AtomPub

§§§, OData

**** i na

generičke tipove (Generic Standards) - HTML††††

, Hyperermedia Application Language (HAL) ili Siren [17], te mnogi drugi. Poveznice među resursima su jedan od osnovnih zahtjeva RESTful sustava. Poveznica se sastoji od URI-a koji pokazuje gdje se nalazi povezani resurs i veze (link relations) između dva resursa [5].

URI-i su se definirali kroz model resursa, a imena veza u dijagramu stanja (imena tranzicija). Definiranjem javnih imena se pojedinim poveznicama definiralo semantičko značenje.

Uzorci kolekcija obuhvaćaju dodavanje i uklanjanje artikla u i iz kolekcije, modificiranje jednog elementa u kolekciji i postavljanje upita na podskup elemenata [5]. Građeni servis se može identificirati sa uzorcima kolekcija jer postoje kolekcije knjiga, komentara i polica.

‡‡‡

JavaScript Object Notation §§§

https://bitworking.org/projects/atom/rfc5023.html ****

http://www.odata.org/ ††††

Koristeći HTML dokument gubi se semantika HTTP

protokola. HTML dokumenti dozvoljavaju samo GET i POST

metodu [16].

Također se može modificirati, dodavati, brisati jedan element kao što je knjiga, komentar i polica. Na slici 6 je moguće vidjeti primjer dijela odgovora u Collection+JSON tipu medija.

Atribut „items“ prikazuje pojedine elemente kolekcije [17]. U ovom primjeru postoji samo jedan definirani element u kolekciji. U atributu „queries“ su objekti opisa vrste upita koji se može izvršiti nad kolekcijom [5]. Objekt „template“ sadrži sve elemente koji se koriste kod unosa ili ažuriranja resursa [5]. U polju objekata „links“ definiraju se poveznice na povezane resurse. Svaka poveznica mora imati definirane atribute „href“ i „rel“ dok su „prompt“, „name“ i „render“ opcionalne. Kroz svojstvo „rel“ se definira semantička vrijednost poveznicama. Poveznica u Collection+JSON tipu medija za knjigu pod id-em 1 bi bila definirana kao objekt {"href": localhost/books/1, "rel": item, "prompt": string, "name": string, "render": "image"} [17]. U ovoj poveznici vidljivo je korištenje tranzicije „item“ prema pojedinom resursu.

7. DISKUSIJA

Kako se u koraku definiranja javnih imena reprezentacija i tranzicija nisu uspjela naći imena koja će definirati neke od tranzicija kao što je dodavanje knjige u policu („add-book“), postoji potreba za izradom semantičkog profila koji će objašnjavati što koja tranzicija radi. Iz definiranog dijagrama stanja moguće je vidjeti da nije pronađeno niti jedno javno ime za nesigurne i ne idempotentne tranzicije. Takve tranzicije rade promjene na poslužiteljskoj strani i sigurno je da će developer klijenta potražiti u dokumentaciji što radi „add-book“ dok za tranzicije „create-book“, „create-comment“, „create-shelf“ može pretpostaviti ali će i one također morati biti definirane kroz dokumentaciju. Sve tranzicije i informacije u reprezentacijama koje nemaju

Slika 6: Dio Collection+JSON odgovora [17]

34 CASE29

definirano javno ime kroz IANA i schema.org repozitorij moraju biti dokumentirani. Semantički profil objašnjava tranzicije i može biti u oblicima machine-readable ili human-readable.

Klasificirani web servis NY timesa iz petog poglavlja ima human-readable dokumentaciju tj. klasičnu API

dokumentaciju u obliku web stranice u kojoj se definira svaki zahtjev i objašnjenje što se njime postiže. Na taj način se gubi semantika [17] odnosno ne pokriva se HATEOAS razina jer klijent ne dobiva cjelokupne informacije o upotrebi servisa kroz hipermedijski tip medija. Profilni jezici na kojima se može definirati machine-readable dokumentacija su ALPS

‡‡‡‡ i JSON-

LD§§§§

[17]. ALPS format vrši deskripciju u semantici aplikacije nad svim hipermedijskim tipovima, kao microformati u HTML-u [2]. Kako većina servisa ima svojstvene tranzicije ili semantičke deskriptore postoji potreba za izradom dokumentacije koja će ih objašnjavati.

Metodologijom se htio prikazati način izgradnje RESTful servisa i koje parametre je potrebno definirati za pokrivanje HATEOAS razine. Model resursa je potrebno izgraditi kada se gradi servis iz temelja tako da se dobije i model baze podataka. Također, potrebno je definirati model resursa jer se u njemu definiraju potrebni URI-i za dohvat resursa. U prikazanoj metodologiji nisu definirani statusni kodovi koji će biti vraćeni na zahtjev. Statusne kodove je potrebno implementirati generički za sve metode servisa i posebno za pojedinu metodu kako bi se u cijelosti podržalo ograničenje jedinstvenog sučelja. Kako definirati URI za upit kod pretrage knjiga, odnosno search tranzicija u dijagramu stanja, je također parametar koji je potrebno implementirati u metodama servisa.

Prikazanom metodologijom ne definira se sigurnost servisa. Kako definirati autentikaciju u servis i verzioniranje? Kako napraviti autorizaciju na određenu tranziciju koju korisnik ne smije napraviti ako nema dodijeljenu valjanu ulogu. Kako klijent razumijeva reprezentacije na temelju HTTP zaglavlja - „content negotiation“? Pripadna problematika koja se odnosi na ova pitanja nije podržana prikazanom metodologijom.

8. ZAKLJUČAK

Metodologijom izgradnje pokazan je postupak dizajna i izrade RESTful web servisa i dobivanje aplikacijske semantike građenog sustava. Modelom resursa definirani su URI-i u web servisu. Dijagramom stanja definirane su tranzicije i reprezentacije. Odabran je hipermedijski tip medija koji se koristiti za definiranje poveznica u web servisu. Pružanjem definiranih URI-a kroz HATEOAS otklanja se odgovornost klijenta za njihovim kreiranjem.

Definiranjem poveznica omogućuje se kretanje kroz različita aplikacijska stanja, ali klijent zbog nedostatka semantike ne zna koje novo stanje će postići određenom tranzicijom. Iz tog razloga postoji potreba za definiranjem generičkih imena tranzicija i reprezentacija iz IANA i schema.org repozitorija. Također, generičkim imenima olakšava se izrada dokumentacije jer nije potrebno definirati tranzicije sa javnim imenima kroz vlastitu dokumentaciju kada definicija postoji u repozitorijima.

‡‡‡‡

Application-Level Profile Semantics - http://alps.io/ §§§§

JSON for Linking Data - http://json-ld.org/

Dokumentacija se može definirati kao human-readable

ili uz pomoć profilnih jezika kao što je ALPS koji će definirati aplikacijsku semantiku web servisa. Korištenjem već definiranih hipermedijskih tipova po uzorku kolekcija izbjegava se izgradnja novog hipermedijskog tipa medija koji će prikazivati specifičnu domenu problema. Odabirom tipa medija moguće je definirati poveznice za kretanje kroz različita stanja aplikacije, ali preostaje problem definiranja semantike kako bi klijent mogao razumjeti posljedice svojih akcija.

CASE29 35

Literatura:

1 Amundsen, M., A Web API Design Methodology, 2014 https://www.infoq.com/articles/web-api-design-methodology (25.1.2017)

2 Amundsen, M., Richardson L., Aplication-Level Profile Semantics (ALPS), 2015, http://alps.io/spec/drafts/draft-01.html (9.2.2017)

3 Block, G., Cibrar, P., Howard, F., et. al., Designing Evolable Web APIs with ASP.NET, O'Reilly Media, 2014

4 Daigneau, R., Service Design Patterns: Fundamental Design Solutions for SOAP WSDL and RESTful Web Services, Addison Wesley, New Jersey, 2012

5 Dohmen, L., A Declarative Web Framework for the Server-side Extension of the Multi Model Database ArangoDB, Computer Science Master Thesis, 2014

6 Fakhroutdinov, F., UML Protocol State Machine Diagrams, 2009-2016, http://www.uml-diagrams.org/protocol-state-machine-diagrams.html (19.1.2017)

7 Fielding, R, Architectural Styles and the Design of Network-based Software Architectures, Doktorska Disertacija, University of California, Berkley, 2000, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (10.1.2017)

]Fielding, R, et. al., Hypertext Transfer Protocol – HTTP/1.1, 1999, http://www.ietf.org/rfc/rfc2616.txt, 51-71(10.1.2017)

8 Fielding, R , REST APIs must be hypertext-driven, 2008, http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven (12.1.2017)

9 Fowler, M., Richardson Maturity Model: Steps toward the glory of REST, 2010, http://martinfowler.com/articles/richardsonMaturityModel.html (10.1.2017)

10 Gera, S, RESTful Services Part 1: HTTP in a Nuthsell, 2016a, https://medium.freecodecamp.com/restful-services-part-i-http-in-a-nutshell-aab3bfedd131 (13.1.2017)

11 Gera, S, RESTful Services Part 2: Constraints and Goals, 2016b, https://medium.freecodecamp.com/restful-services-part-ii-constraints-and-goals-530b8f6298b9 (10.1.2017)

12 Gera, S, RESTful Services Part 3: HATEOAS and The Richardson Maturity Model, 2016c, https://medium.freecodecamp.com/restful-services-part-iii-hateoas-and-the-richardson-maturity-model-48d4e4c79b8d (10.1.2017)

13 Pautasso, C., Wilde, E., REST: Advanced Research Topics and Practical Applications, Springer, New York, 2014., 125-143

14 Pautasso, C., Wilde, E., REST: From Research to practice, Springer, New York 2011. , 93-116

15 Porres, I., Rauf, I., Modeling Behavioral RESTful Web Service Interfaces in UML, Abo Akademi University, Dept. of Information Technologies,Turku, Finland, 2011.

16 Richardson, L., Amundsen M., Ruby, S., RESTful WEB APIs, O'Reilly Media, 2013.

17 Richardson, L., Act Three: The Maturity Heuristic, 2009, https://www.crummy.com/writing/speaking/2008-QCon/act3.html (2.2.2017)

18 Sookocheff, K., On choosing a hypermedia type for your API – HAL, JSON-LD, Collection+JSON, Siren, oh My!, https://sookocheff.com/post/api/on-choosing-a-hypermedia-format/ (8.2.2017)

19 Weber, J., Parastatidis S., Robinson I., REST in Practice (Hypermedia and Systems Architecture), O'Reilly Media, 2010.

Informacije o autorima:

Alen Šljivar, bacc. inf.

Veleučilište u Rijeci

asljivar@veleri.hr, alensljivar44@gmail.com

dr.sc. Marin Kaluža, viši predavač

Veleučilište u Rijeci

mkaluza@veleri.hr

36 CASE29

CASE29 37

WEB ARHITEKTURE KOJE MIJENJAJU 'SVIJET'

Vedran Zdešić

SAŽETAK:

Predavanje ima cilj osvijestiti promjene koje su se događale zadnjih godina, a tiču se primjene novih arhitektura i frameworka unutar web aplikacija. Glavni fokus je pokazati ključne trenutke kod kojih su se prekretnice događale, te koje su dobrobiti donijele. Ključne riječi: Web arhitekture, asinkrono programiranje, Messaging Services, zero-downtime deployment, UI state management.

ABSTRACT:

This lecture aims to raise awareness of the changes that have happened last few years, regarding usage of new architectures and frameworks within the web applications. The main focus is to point to the key moments and milestones that transpired, and to show how we benefitted from all that. Keywords: Web architectures, asynchronous programming, Messaging Services, zero-downtime deployment, UI state management.

1. UVOD

Promjene u web svijetu vrlo su dinamične, pogotovo zadnjih godina. U globalnoj trci za boljim web softverskim proizvodima svaki detalj je važan. Svaki korak procesa razvoja i održavanja web aplikacija se konstantno preispituje i mijenja kako bi dobili kvalitetan proizvod koji je moguće trenutno isporučiti. Neke od ključnih faza i/ili momenata ovog procesa, na koje ću se ovdje osvrnuti, su:

Razvoj Povećanje količine podataka Komunikacija među aplikacijama Testiranje i automatizacija CI (Continuous Integration) / Deployment

Sve navedeno mora biti brže, bolje i jače, dok pritom složenost sustava raste. Pogledajmo koje promjene su se događale ili se događaju kako bi se to ostvarilo.

2. ARHITEKTURA 'LOŠE' APLIKACIJE

Krenimo od arhitekture web aplikacije koja je mogla biti razmatrana kao vrlo dobra, prema tadašnjim standardima, prije samo par godina. Pretpostaviti ćemo slijedeću arhitekturu:

UI sloj - MVC pattern - ASP.NET MVC 5 (ili niža verzija) - jQuery, jQuery UI, AJAX za asinkroni pristup - Aplikacija je bazično sinkrona

Poslovna logika - Standardna implementacija poslovnih objekata u

C# jeziku

Baza i ORM - MS SQL Server - Entity Framework 6 (ili niža verzija)

Za početak ću pojednostaviti, navodeći samo ova tri sloja, bez primjerice API servisnog sloja. U ovakvoj arhitekturi pretpostavlja se da korisnik prilikom upisa URL-a u svom pregledniku, šalje zahtjev na server gdje ga prihvaća Controller. Controller dohvaća i obrađuje podatke i šalje ih View-u, preko modela.

Kako bi se mogli kritički osvrnuti na ovu arhitekturu, spomenimo u slijedećim točkama, njene mane u odnosu na komponente procesa razvoja i održavanja, koje smo naveli kao ključne u uvodu, te navedimo momente u kojima nam je ova arhitektura zadavala najviše problema.

2.1 Razvoj

Razvoj u dobro strukturiranoj radnoj okolini MVC projekata je vrlo ugodan u početku. Problemi se proporcionalno povećavaju kako aplikacija raste. Tada je sve teže pratiti potencijalne veze između Controllera i View-ova, teško je pratiti što se poziva, i od kuda, te biti svjestan svih međuovisnosti. Situaciju "prije" i "poslije" samo djelomično može dočarati Slika 1. U praksi je situacija puno gora.

Za pisanje klijentskog koda, ili asinkronih poziva, jQuery je dobar odabir, ali s vremenom situacija prerasta u nepregledan kod ('spaghetti code') koji je teško debuggirati i održavati. U to vrijeme nemamo dostupne alate za 'compajliranje' jQuery ili JavaScript koda, tako da sve greške otkrivamo u run-time-u.

2.2 Povećanje količine podataka

Kada se baza naše 'loše' aplikacije poveća do razmjera koje nismo niti očekivali u početku razvoja, tada smo prisiljeni reagirati, jer rad za korisnika postaje spor, čak i na brzom hardveru. Neke od opcija ubrzavanja aplikacije uključuju primjenu raznih tehnika aplikacijskog cache-iranja podataka. Kada niti to nije dovoljno,

38 CASE29

uvodimo dodatni sloj aplikacije – NoSQL bazu podataka. NoSQL baza, bez sheme, u koju možemo pohraniti polu-strukturirane ili nestrukturirane podatke, skalabilnija je te nudi puno brži pristup podatcima od relacijske baze. Da bi aplikacija koristila podatke iz NoSQL baze, moramo ju prethodno napuniti/sinkronizirati. U našoj firmi smo za sinkronizaciju koristili vlastiti modul koji pokreće sinkronizacijske job-ove prema definiranim pravilima. Ovaj korak unapređenja arhitekture bio bi isti i za aplikaciju koju ćemo kasnije opisati kao aplikacija sa 'dobrom' arhitekturom.

2.3 Komunikacija među aplikacijama (internim i vanjskim)

Kako bi se aplikacija otvorila prema drugim aplikacijama i sustavima, standardna praksa je kreiranje dodatnog API sloja. U slučaju ove arhitekture, dodatni API sloj znači više posla u razvoju i održavanju. U vremenu ASP.NET MVC 5 i ranijih verzija postojala je jasna razlika između Controllera i ApiControllera time podrazumijevajući njihovu razliku i u smislu funkcionalnosti. Ovaj detalj ćemo kasnije razraditi kako bi pokazali kako je stapanje ovih komponenata u jednu i njihovo drugačije korištenje pojednostavilo razvoj i održavanje ovog sloja.

Jedan od momenata koji mogu biti značajni u ovom trenutku je, ne samo komunikacija aplikacije sa drugim, vanjskim aplikacijama i servisima, nego i slučaj kada imamo više svojih vlastitih aplikacija koje koriste iste resurse, bazu i sl. U kvantnom skoku koji ćemo prikazati

sa 'loše' na 'dobru' arhitekturu ćemo prikazati i rješavanje ovog problema.

2.4 Testiranje i automatizacija

Pogledajmo sada, dalje, što smo sve morali napraviti da bi naša ASP.NET MVC aplikacija bila testabilna. Prisjetimo se da direktno pozivanje Controllerovih akcija iz Unit Testova nije bilo moguće, jer Unit Test nije mogao aplikaciji prenijeti Http i Database Context koji se kreiraju u radu aplikacije na Web Serveru ili IIS Expressu.

Sjetimo se što je bilo potrebno napraviti da bi to omogućili na primjeru Database Contexta. Morali smo uz primjenu Repository Patterna (da ne širimo dalje sa Unit of Work Patternom), te biblioteka poput Ninject, 'otvoriti' Controller i prenijeti njegovom konstruktoru trenutni Database Context s kojim će raditi. Repository Pattern predviđa da postoji IRepository interface koji nasljeđuju i implementiraju svi repositoriji (klase/objekti koji rukuju sa podacima skrivajući pritom detalje pristupa bazi). Postojanje interfaca je bio uvjet da testni framework zna kreirati i 'podvaliti' lažne podatke tijekom Unit testa. Na tom principu su radili neki Mocking Frameworks. Prilično dodatnog posla. Prisjetimo se kako je to izgledalo uz pomoć slike 2.

Što se tiče automatizacije, imali smo sljedeću situaciju. Za pisanje UI testova, koristili smo alate poput primjerice Selenium Web Drivera. Budući da je aplikacija bazično sinkrona, svaki korak napisanog testa, treba čekati završetak prethodnog koraka. S

Slika 1.

Slika 2.

CASE29 39

druge strane, za testiranje asinkronog dijela aplikacije (AJAX pozivi, i sl.) bilo je potrebno u kodu testova dodatno implementirati čekanje na asinkrone elemente. Ukupno gledano, gubilo se dosta vremena na izvršavanje testova, što se dalje rješavalo paralelnim izvršavanjem testova.

Testovi koje je naporno pisati i izvršavaju su se sporo, pišu se sve manje tijekom vremena i preskače se njihovo izvršavanje kod Builda ili Commita. Posljedica svega je da testovi jednostavno postanu N-ti prioritet u projektu i vremenom se zanemaruju. To će u konačnici otežati održanje kvalitete našeg softverskog proizvoda.

2.5 CI / Deployment

Glavni cilj dobre CI strategije je omogućiti da sve što razvijemo ili popravimo u aplikaciji, korisnici dobiju na korištenje na najbrži i najbezbolniji način kako za njih, tako i za nas. Idealno, aplikacija ne smije prestati raditi tijekom tog procesa, čiji je važan dio deployment, ali nije jedini. Cijeli proces uključuje također i pravilno održavanje repozitorija koda, automatizaciju Builda, uključujući izvršavanje automatiziranih UI i Unit testova i slično. Ipak, u nastavku ćemo se usmjeriti uglavnom na deployment, jer arhitektura aplikacije može imati velik utjecaj na našu sposobnost kvalitetnog deploymenta web aplikacije.

Ako je aplikacija namijenjena svjetskom tržištu, onda je jasno da ju korisnik može koristiti bilo kada i od bilo kuda. U tom slučaju ne postoji trenutak kada deployment može obaviti bez narušavanja rada korisnika (jer uključuje restart aplikacije). Također, danas sve više velikih poslovnih korisnika jednostavno ne želi prekidati rad u aplikaciji zbog deploymenta. Kompanije imaju poslovnice u različiitim vremenskim zonama, i uvijek netko radi. Nedjelja popodne je već ponedjeljak ujutro u nekoj drugoj vremenskoj zoni, što znači da će netko morati prekinuti rad ako tada napravite deployment. Iako korisnika u načelu ne zanima kojom tehnologijom i u kojoj arhitekturi je kreirana vaša aplikacija, indirektno, bit ćete izloženi zahtjevima koje će korisnik tražiti samo zato što će te iste funkcionalnosti biti dostupne kod vaše konkurencije.

Postoji i interni moment vezan na deployment. Ako nemate zero-downtime deployment, te ako aplikaciju deployate u cijelosti, vezani ste za Release ciklus unutar kojeg morate odraditi kompletno Regression testiranje. U mojoj kompaniji je ovaj moment igrao važnu ulogu u stvaranju zadovoljnih djelatnika, u određenoj mjeri developera, ali najviše testera koji su uglavnom željeli napredovati i u tehničkim znanjima. Zbog striktnog Release ciklusa, testeri aplikacija su provodili puno vremena u manualnom testiranju (50% vremena). Manualno testiranje se provodilo na cijeloj aplikaciji prije svakog mjesečnog deploymenta (Regression Testing). Testeri su ponavljali radnje u sustavu koji detaljno poznaju, ponovo i ponovo. Kada radite nešto što vam nije zanimljivo, postajete manje produktivni s vremenom. Uglavnom, testeri su želljeli povećati vrijeme rada namijenjeno automatizaciji, jer im je taj dio bio zanimljiviji. Sveukupni osjećaj je bio da treba nešto poduzeti kako bi se oslobodio prostor za automatizaciju, dok bi se manualno testiranje odrađivalo paralelno. Tijekom pisanja automatiziranih testova, testeri su potpuno usmjereni na detalje vezane na strukturu aplikacije i njenog rada i tako bolje otkrivaju bugove. Mogu reći da smo potvrdili teoriju, koja kaže da se bugovi otkrivaju najviše tijekom procesa pisanja automatizacijskih testova, a ne tijekom njihovog izvršavanja kasnije. Također, broj automatiziranih

testova je rastao brže, a testeri su bili zadovoljniji razvijajući se i u tehničkim znanjima. I dalje smo za manualna testiranja dužeg trajanja koristili testere koji nisu pokazivali sklonost tehničkim znanjima. Ovaj skok bio je moguć samo uz promjenu arhitekture aplikacije koja će biti opisana kasnije kao 'dobra' arhitektura.

Ovdje treba naglasiti da je zero-downtime deployment moguće postići raznim hardverskim ili infrastrukturnim zahvatima, kao primjerice izmjenom aktivnih i neaktivnih nodova cluster servera, međutim u ovom radu ćemo se baviti problemima iz perspektive arhitekture aplikacija.

Vratimo se sada na našu 'lošu' aplikaciju. Kako bi omogućili zero-downtime deployment naše ASP.NET MVC aplikacije, u softverskom smislu, morali smo učiniti praktički čudo. Budući da serverski kod mora biti kompajliran i deployan na server u binarnom obliku, svaka takva akcija zahtjeva restart aplikacije. Tek nakon restarta novi assembliji (sklopovi) su učitani. Jedna od mogućnosti, da spriječimo down-time, je da svoju aplikaciju podjelite u Areas (područja). Svaka Area predstavlja modul aplikacije, unutar koje se nalaze objekti tog područja (primjerice, područja mogu biti, blagajna, skladište, knjigovodstvo, …). Pritom moramo omogućiti korištenjem Reflectiona, MEF-a, ili sličnih tehnologija dinamičko učitavanje assemblija. Ovaj proces je iznimno kompliciran, jer dolazite u situaciju kada sve sadržaje jednog Area želite spremiti u DLL koji tada sadrži i datoteke koje nisu binarne (javascript, css, …) pa ih tijekom korištenja morate 'raspakirati'. Postizanje zero-downtime deploymenta na ovaj način teško će vratiti uloženo, i ne bi ga preporučio.

3. ARHITEKTURA 'DOBRE' APLIKACIJE

Skok sa 'loše' na 'dobru' arhitekturu nije se dogodio odjednom niti u mojoj firmi, niti globalno. U praksi, razvojni timovi Microsofta, Googla i Facebooka paralelno su razvijali i unapređivali svoje frameworke, dok se paralelno razvijao JavaScript/ECMAScript i vezane tehnologije, te je ovaj skok nastao tijekom zadnjih nekoliko godina. Zanimljivo je bilo vidjeti suradnju između Microsofta i Googla na nekim temama, što bi prije bilo iznenađujuće. Krenimo od slijedeće arhitekture:

UI sloj - Angular 2 (sa TypeScript-om), Flux, Redux - UI Web Components - Aplikacija je bazično asinkrona

Poslovna logika - Standardna implementacija poslovnih objekata -

JavaScript/ECMAScript/TypeScript. JavaScript DTO (Data Transfer Objects).

API sloj - REST API, ASP.NET Core - Messaging Services, Rabbit MQ - Microservices arhitektura - Serversko renderiranje (DOM se renderira/

strukturira na serveru)

Baza i ORM - MS SQL Server - Entity Framework Core

Prednosti ove arhitekture u odnosu na 'lošu' bili bi slični da smo naveli Angular 1 umjesto Angular 2. Razlog tome je što se uz Angular 1 također može koristiti Redux komponenta i Flux arhitektura. Međutim, koncepti Angulara 2 u odnosu na 1 su napredniji kada gledamo sam framework, pa smo zato jednostavno preskočili Angular 1 u ovim razmatranjima.

40 CASE29

Pojasnimo sada što donosi ova arhitektura u odnosu na 'lošu' pregledom istih tema.

3.1 Razvoj

Ako ste došli iz Microsoft svijeta, i ako ste do sada radili uglavnom u Microsoft alatima i radnim okolinama, onda prijelaz na ovu arhitekturu može biti težak. Početna krivulja učenja nije brza ni laka. Ipak, svaki uloženi trud se isplati! Nadalje ćemo pretpostaviti da smo tijekom ovog kvantnog skoka, nekako primili paket znanja koji je potreban da kreiramo ovu novu arhitekturu. Osobno smatram, da svaki programer treba imati u svom dnevnom rasporedu vrijeme za samo-edukaciju koja će mu omogućiti praćenje stalno promijenjivog svijeta web razvoja, tako da je spreman na promjene poput ove.

Tijekom razvoja aplikacije ove vrste, moramo se riješiti sinkronog načina razmišljanja kojeg vučemo od prije te prihvatiti da su moderne aplikacije prvenstveno asinkrone, u samoj svojoj naravi. Naša asinkrona aplikacija mogla bi se kompletno napraviti u Angularu 2 sve do API sloja, samo uz primjenu web komponenti. Komponente osiguravaju dobru modularnost aplikacije. Ugrađene funkcionalnosti Angulara 2 omogućuju prilično jednostavno i skladno povezivanje podataka (data binding) sa formama i gridovima na UI sloju. Sve to zajedno, uz podršku novih asinkronih tehnika na bazi Promisa i Observables, omogućuju prilično jednostavan razvoj asinkrone aplikacije.

Stvar se ipak vremenom komplicira, kao i kod MVC aplikacija. Pretpostavimo da imamo neku email aplikaciju, koja ima pregled direktorija, pregled emailova i područje za notifikacije, sve istovremeno vidljive u aplikaciji. Što se događa kada stigne novi email ili vi pošaljete novi? U našoj asinkronoj aplikaciji, gdje se sve odvija neovisno, i sva ova tri područja/komponente dohvaćaju i prikazuju svoje podatke neovisno, vi se nalazite u poziciji kada postaje teško debuggirati sva ta istovremena/asinkrona događanja. Ipak, primjećujemo da naša asinkrona aplikacija ima – STANJE! Izgled aplikacije ovisi o stanju u kojem se nalazi. Pod stanjem mislim na skup koji čine podaci, zajedno sa ponašanjem komponenti na UI sloju. Dakle, stanje ne određuju samo podaci, nego i način na koji su prikazani. Primjerice, video na Facebook stranici kada je jednom dohvaćen i prikazan, može imati određena različita stanja na UI-u, pa tako video može biti u modu Play, Paused, Stopped. Stanje kao informaciju, najčešće nećemo spremati u bazu. Ako u svakom trenutku možemo jednoznačno odrediti i rukovati stanjem aplikacije, dovesti ćemo red u ovaj asinkroni svijet!

Upravo zbog toga, dolazi nam u pomoć Flux arhitektura i/ili Redux komponenta. Uz njihovu pomoć omogućiti ćemo komponentama aplikacije izvještavanje svih onih koji su pretplaćeni (subscribed) na određeni događaj, emitiranjem informacija o njihovoj promjeni. Komponenta koju zovemo Dispatcher tada obavještava sve preplaćene objekte o akciji koja se dogodila i to radi na principu FIFO (First-In-First-Out). Ova arhitektura nam omogućava da potpuno asinkronu aplikaciju učinimo malo više 'sinkronom'. Na ovaj način je olakšano debuggiranje i razvoj aplikacije, jer ju je lakše

slijedno pojmiti. Slijedeća slika pokazuje tijek događaja u takvoj arhitekturi:

Recimo da postoje kriteriji kojima određujete da li trebate Redux i Flux ili možete ostati samo na Angularu. Ti kriteriji su slijedeći:

Imamo podatke koje koristimo na više mjesta u aplikaciji istovremeno

Imamo više nezavisnih sudionika koji mogu promijeniti iste podatke. Primjerice, promjena se može dogoditi na serveru ili ih korisnik može promijeniti

S ovom arhitekturom možete smjestiti cijelu poslovnu aplikaciju u SPA (Single Page Application) na ugodan način.

Također, vidimo da je uz Angular 2 spomenut i TypeScript. Ovaj moment je vrijedno naglasiti. Dakle, za razliku od prethodne arhitekture, kada nismo imali mogućnost 'kompajlirati' JavaScript/jQuery kod, sada, pojavom TypeScripta, razvoj i debuggiranje se ubrzava, jer već tijekom pisanja koda otkrivamo greške koje smo prije otkrivali u run-time-u.

Kao zadnje ovdje, spomenimo da ćemo brzinu aplikacije dovesti na novi nivo uz pomoć tehnika serverskog renderiranja, koje cijeli DOM strukturiraju još na serveru.

3.2 Povećanje količine podataka

Već smo spomenuli da kada dohvat iz baze postane spor, i u ovoj arhitekturi, kao i u prethodnoj, možemo uvesti novi sloj sa NoSQL bazom. Taj dio smo pojasnili ranije. Pretpostavimo da smo to napravili.

Što radimo kada količina podataka i dalje raste, te imamo problema čak i sa ovakvim načinom rada? Što je slijedeći korak koji možemo poduzeti?

Daljnje ubrzanje u radu sa podacima možemo dobiti jedino ako ih još više približimo UI sloju. U tom slučaju, podatke spremamo u tzv. Store objekte na samom klijentu. Moramo pritom pripaziti da dovedemo samo potrebne podatke, s kojima korisnik radi, kako ne bi opteretili klijentsko računalo. Standardne tehnike koje ovdje koristimo poznate su nam od prije, a uključuju parcijalno dohvaćanje podataka, kao primjerice kod paginga ili scrollinga. Jednom dohvaćeni podaci ostaju na raspolaganju, dok se novi dohvaćaju tijekom slijedećih poziva prema API sloju.

3.3 Komunikacija među aplikacijama (internim i vanjskim)

Pretpostavimo sada čest slučaj kada u našoj kompaniji vremenom raste broj proizvoda. Budući pokrivamo određeno poslovno područje i radimo aplikacije koje koriste iste skupove podataka, nalazimo se u situaciji da nam sinkronizacija cijelog tog okruženja postaje najvažniji problem. Kada bi naše aplikacije kontaktirale direktno glavnu SQL Server bazu prilikom dohvaćanja podataka, onda to ne bi bio problem, ali kako bi povećali brzinu rada sa podacima, uveli smo dva dodatna sloja; NoSQL bazu na dodatnom serveru, te Store objekte na klijentu. Kada jedna od aplikacija napravi promjenu na dijelu podataka, tada treba nekako obavijestiti i ostale

Slika 3.

CASE29 41

aplikacije o promjeni. Nakon određene razine kompleksnosti, jedino rješenje je uvođenje dodatnog Messaging sloja koji će se brinuti da svi procesi i sinkronizacije budu odrađene prema zamišljenim scenarijima, te da korisnici rade sa validnim podacima u svakom trenutku.

Prijedlog konkretne implementacije ovog sloja može biti uz primjenu RabbitMQ middlewarea.

Slijedeća dobra vijest, koja unapređuje ovu arhitekturu, vezana je na ASP.NET Core framework. Sam framework kreiran je poštujući sve moderne trendove vezane za asinkrono programiranje. Jednu specifičnost ASP.NET Corea želim posebno naglasiti, a to je da za razliku od prijašnjih verzija ASP.NET-a sada ne razlikujemo više Controller i ApiController. Oni su spojeni u jedan, i bilo da radite API sloj ili Controllere za svoju ASP.NET aplikaciju, u oba slučaja vaša će komponenta naslijediti klasu Controller. To je odlična karakteristika, koja olakšava kreiranje API sloja, jer mnoge funkcionalnosti bi u suprotnom morali duplirati. Sada to nije slučaj, samo treba jasno definirati i razlikovati API funkcije od drugih.

3.4 Testiranje i automatizacija

Pogledajmo sada koje sve dobrobiti dolaze na polju testiranja i automatizacije, samo od toga što imamo relativno 'tanak' UI sloj, koji se naslanja direktno na API sloj.

Prvo, performance testing je nevjerojatno lak. Alatima poput SOAP UI ili Runscope možemo direktno napasti API-je, testirati njihovo ispravno funkcioniranje te usput dobiti vrijeme izvršavanja pojedinog API poziva. Ako nas ti rezultati zadovoljavaju, vrlo je velika vjerojatnost da nećemo imati nikakvih performance problema na UI sloju, jer vrijeme učitavanja određene 'rute' unutar aplikacije je određeno najdužim paralelnim izvršavanjem asinkronih poziva prema API sloju. Ovo je odlična vijest.

Druga odlična vijest je - nisu potrebni niti Unit Testovi. Pogledajte primjerice kod na slici 4. Forma je povezana sa komponentom koja direktno komunicira sa API servisima, dohvaćanjem podataka, te kasnije slanjem cijele forme (form.value). Standardne radnje poput data bindinga i klijentske validacije dio su samog frameworka.

Ako većina koda izgleda ovako, nema se što testirati Unit testovima. Unit testove možemo pisati samo na mjestima na kojima je situacija složenija nego ovdje.

Treba ovdje naglasiti da je Angular sam po sebi kreiran sa namjerom da bude testabilan, ali u okviru ove arhitekture, taj dio nije ključan. U načinu razmišljanja koji nas vodi u našem slučaju, želimo profitirati na drugačiji način. Želimo iskoristiti činjenicu da se programeri koji su do sada pisali Unit testove, mogu posvetiti pisanju UI, ili kako ih Angular tim voli zvati end-to-end testova. Na ovaj način imamo veliku moć i snagu usmjerenu na automatizaciju, testeri dobivaju veliku podršku programera tijekom svog rada. Testovi se pišu puno intenzivnije nego prije, testovi su kvalitetno napisani, koriste se tijekom Builda ili Commita. Ova sprega naglašava i osigurava usku vezu developmenta i testiranja što je jako dobro za ukupnu kvalitetu našeg softverskog proizvoda. I konačno, testovi su puno brži nego testovi sinkrone aplikacije. To dodatno doprinosi njihovom učestalijem korištenju.

3.5 CI / Deployment

U svrhu postizanja cilja koji smo si zadali još kod analize 'loše' arhitekture, a to je zero-downtime deployment, iskoristiti ćemo do sada spomenute komponente ove arhitekture, uz dodatnu primjenu mikro servisne arhitekture. Mikro servisima želimo omogućiti djelomični deployment aplikacije, čime ćemo se također riješiti striktnog Release i Regression ciklusa.

Slika 5.

S tehničke strane gledano, potrebno je API sloj parcijalizirati do nivoa koji nas zadovoljava, te time kreirati manje neovisne servise. Uz podršku RabbitMQ-a, potrebno je osigurati persistent sloj koji će sačuvati poruke tijekom kratkog trenutka samo parcijalnog deploymenta. Moguće je i duplirati endpointe pojedinih servisa te izložiti API Gateway prema vanjskim aplikacijama. API Gateway, uz korištenje RabittMQ Messaging servisa, može prihvaćati poruke i prema

Slika 4.

42 CASE29

potrebi preusmjeravati na aktivne enpointe/servise, tako da niti jedan zahtjev ne bude odbačen u kritičnom trenutku parcijalnog deploymenta naše aplikacije. Slijedeća slika prikazuje takvu arhitekturu.

4. DRUGE ZANIMLJIVE ARHITEKTURE

Između dvije navedene arhitekture, postoji bezbroj hibridnih arhitektura, koje koriste ponešto od obje. Također, postoje i drugi smjerovi kojima možete krenuti u izradi web aplikacije, pa navedimo par zanimljivih arhitektura.

4.1 jQuery iznad API sloja

Ovo je dobar primjer kombiniranja komponenata obje naše arhitekture. Može biti korisna za srednje velike poslovne aplikacije:

UI sloj - jQuery, jQuery UI, jqGrid - Aplikacija je bazično asinkrona

API sloj - REST API - ASP.NET Core

Baza i ORM - MS SQL Server - Entity Framework Core

Kod ove arhitekture, koriste se prednosti gotovih jQuery UI komponenti, i što je još zanimljivije jqGrid komponente koja nudi ugrađene mehanizme pregledavanja i editiranja podataka (inline editing, form editing). Uz pomoć tih komponenti i funkcionalnosti možemo prilično ubrzati razvoj.

4.2 Full Stack JavaScript

Vaša cijela aplikacija može biti pisana korištenjem JavaScript/ECMAScript i povezanih tehnologija. Na taj način možete potpuno upogoniti znanje JavaScript/ECMAScript developera koji su vam možda trenutno na raspolaganju.

UI sloj - Angular 2 (ili možda React) - Aplikacija je bazično asinkrona

API / serverski sloj - REST API - NodeJS, ExpressJS, serversko renderiranje

Baza i ORM - MongoDB - Mongoose

Problem je što ova arhitektura nije dobra za širok spektar poslovnih aplikacija, upravo zbog njenog asinkronog karaktera u cijelom rasponu od servera do klijenta. Samo debuggiranje i razvoj mogu biti vrlo

naporni. Pomoćni alati za debuggiranje NodeJS aplikacija su još uvijek nerazvijeni. Iako, situacija se mijenja iz dana u dan.

5. ARHITEKTURE BUDUĆNOSTI

Postoji puno potencijalnih smjerova kojima dalje može krenuti web development. Kao i do sada u ovom izlaganju, neću ulaziti u svu širinu toga, nego se usmjeriti na ono što se meni čini zanimljivo i vrijedno praćenja. Zato ću spomenuti samo jednu tehnologiju koja, čini se, ima potencijala mijenjati 'svijet' – WebAssembly (wasm). Ovom tehnologijom web aplikacije se vraćaju binarnoj formi, podržavajući kompajliranje iz primjerice C ili C++ koda. Iako u eksperimentalnoj fazi, podržavaju ju svi novi preglednici, a sve velike kompanije imaju oko na toj temi. Najveća prednost ovakvih aplikacija u odnosu na dosadašnje je povećana brzina (do 70%). Toliko poboljšanje u samo ovoj komponenti može utjecati na cijeli niz drugih. Sama tehnologija ne pokušava izgurati JavaScript, nego ga želi unaprijediti i učiniti bržim. Pokušavaju se izbjeći sve zamke koje su štetile tehnologijama poput Flasha.

Moguće je da poslovne aplikacije neće time profitirati, nego samo grafički zahtjevne web aplikacije. Bili smo svjedoci raznih kretanja i promjena u web tehnologijama, gdje se mijenjalo težište aplikacija u rasponu od servera do klijenta, deployali smo kod u rasponu od tekstualnih datoteka do kompajliranog koda, imali više ili manje strukturirane frameworke i alate. Taj proces nije savršen, uvijek nešto dobijemo, a nešto izgubimo, dok u cjelini, nadamo se, napredujemo. Vidjeti ćemo što nosi slijedeći val. Biti će sigurno zanimljivo.

6. ZAKLJUČAK

Pregledom ovih specijalnih slučajeva web arhitektura, bio mi je cilj pokazati što se dogodilo u web razvoju zadnjih godina, ali ne samo u tehnološkom i tehničkom smislu, nego pokazati na koji način su te promjene utjecale na efikasnost timova, kvalitetu proizvoda, ubrzanje procesa razvoja i sl.

Stavovi iznijeti ovdje posljedica su osobnog iskustva. Samim time ne drže stranu niti jednoj tehnologiji ili kompaniji. Zbog toga se nadam da će čitatelju prije svega dati smjer i fokus koji će ubrzati učenje i odluke u ranim fazama upoznavanja sa navedenim temama.

Želja mi je da ovaj rad bude doprinos uvođenja reda u kaosu svih dostupnih radnih okolina, alata i biblioteka trenutno dostupnih za razvoj web aplikacija. Zadovoljan sam ako sam čitatelju pomogao u tom smjeru i skratio vrijeme učenja i donošenja odluka.

Literatura

1 Web:

https://angular.io/

https://www.asp.net/

https://nodejs.org/en/

https://www.elastic.co/

http://microservices.io/

http://nosql-database.org/

https://www.rabbitmq.com/features.html

http://www.fullstackjs.com/book/index.html

http://webassembly.org/

CASE29 43

Podaci o autoru:

Vedran Zdešić

ProTest Solutions d.o.o.

e-mail: vedran.zdesic@protestsolutions.net

Vedran Zdešić, mag. ing. el., MCT višegodišnji je predavač, autor, razvojni inženjer i softver arhitekt, specijaliziran za Microsoft .NET tehnologije u tvrtki ProTest Solutions d.o.o. Sudjelovao je u pripremi udžbenika za Visoku školu za računarstvo. Certificiran je kao MCPD (Professional Developer), MCSD (Solution Developer) i MCT (Trainer). Bio je predavač na konferencijama poput Microsoft WinDays i CASE. Kroz niz projekata tijekom opsežnog radnog staža sudjelovao je u razvoju kompleksnih aplikacija, distribuiranih aplikacija i sustava, te softverskih produkata, usput primjenjujući široki spektar Microsoft-ovih tehnologija. Trenutno, polje posebnog interesa uključuje razvoj aplikacija na Microsoft Azure platformi, te mobilni razvoj na Xamarin platformi.

Vedran Zdešić is experienced lecturer, author, developer and software architect, specialized for Microsoft .NET technologies, employed by the ProTest Solutions d.o.o. He was involved in the preparation of textbooks for University College for Applied Computer Engineering. He is certified as MCPD (Professional Developer), MCSD (Solution Developer) and MCT (Trainer). He was lecturer on conferences like Microsoft WinDays and CASE. Over the years, he applied wide range of Microsoft technologies for developing complex and distributed applications, systems and products. Current fields of interests are Microsoft Azure and mobile development with Xamarin.

44 CASE29

CASE29 45

GO PROGRAMSKI JEZIK - OO PROGRAMIRANJE BEZ KLASA I NASLJEĐIVANJA

GO PROGRAMMING LANGUAGE – OO PROGRAMMING WITHOUT CLASSES AND INHERITANCE

Damir Vuk

SAŽETAK:

U ovome radu se govori o programskom jeziku Go, njegovim glavnim karakteristikama, odnosno prednostima i nedostacima kao alata za razvoj modernih aplikacija. Go spada u relativno mlade programske jezike opće namjene. On je razvijen za potrebe razvoja modernih aplikacija za 21. stoljeće. Go je utemeljen na idejama konkurentnog programiranja te prenosivosti izvornog koda bez izmjena na različite vrste procesora i operacijskih sustava. Go karakterizira iznimna brzina kompajliranja i izvođenja izvršnog koda, ali isto tako i jednostavnost koncepata jezika.

Za razliku od mnogih popularnih skripnih jezika, kao i jezika zasnovanih na virtualnim strojevima, Go je pravi kompajlerski jezik koji generira izvršni binarni kod čija brzina izvođenja je bliska brzini izvođenja C/C++ koda. Go sadrži cijeli eko sustav alata, te omogućuje skalabilni razvoj aplikacija uključujući i one vrlo velike. Pritom je vrijeme kompilacije izuzetno kratko čak i za veoma velike programe.

Go ima radikalno drugačiji pristup objektnoj orijentaciji. On nema koncepte klasa i nasljeđivanja. Umjesto toga, on ima koncepte kompozicije, ugradnje i interfejsa. Go je zamišljen kao bolja Java odnosno kao bolji C/C++. Go se razvija kao projekt otvorenog koda, pokrenut od strane malog Google-ovog tima, a nadopunjava se doprinosima mnogih programera iz zajednice otvorenog koda.

ABSTRACT:

This paper deals with Go programming language, his main characteristics, advantages and disadvantages. Go is a new language created for development of modern applications for 21st century, based on concurrency, multi platforms, speed and simplicity. Unlike popular scripting languages, Go is designed to compile into binary executable files with execution speed nearly as fast as C/C++ language. Go includes complete eco system of tools for scale efficiently so that it can be used to build very big applications. Go compile even a large program in a few seconds on a single computer.

Go takes a radically different approach to object-oriented programming. In Go there is no concept of classes and inheritance. Instead of that, Go supports composition, embedding and interfaces. Go is conceived as better Java, and also better C/C++. Go was conceived as a systems-level language. Now it can be used as a general purpose programming language. Go is an open source project developed by a Google team and many contributors from constantly growing open source community.

1. UVOD

Krajolik programskih jezika se stalno mijenja. Svako malo vremena, pojavljuju se novi jezici. Neki se od strane programerske zajednice dočekuju s velikim oduševljenjem, neki prolaze relativno nezapaženo, neki bivaju zaboravljeni, neki se desetljećima dobro drže u pojedinim nišama primjene, dok neki predstavljaju graničnike u povijesti programiranja. No, bez obzira na tip i namjenu jezika odnosno bez obzira na njegovu koncepciju i arhitekturu, svaki novi programski jezik doživljava kritike i pohvale, svaki ima svoje kritičare i zagovornike.

Svaki je jezik u svom konceptu i arhitekturi zamišljen za određeni aplikativni i računalni kontekst. Aplikativni kontekst se odnosi na to u kolikoj je mjeri jezik pogodan za izradu aplikacija: da li je namijenjen za neke specifične /ograničene primjene ili je pogodan za aplikacije bio kojeg tipa. Računalni kontekst se odnosi mogućnost razvoja i primjene programskih rješenja u odgovarajućoj računalnoj okolini: koji tip hardvera se zahtijeva, koji tip sistemskog softvera, te koji tip računalne infrastrukture. Idealan jezik bi bio onaj koji nije ograničen niti u pogledu aplikativnog, niti u pogledu

računalnog konteksta. Neki su u tome usko fokusirani, a neki nastoje biti široki. Na primjer, C jezik ima izrazito širok fokus kako u pogledu računalnog , tako i u pogledu aplikativnog konteksta. S druge strane, PHP jezik je jezik s vrlo uskim fokusom na web-aplikacije podržane odgovarajućom poslužiteljskom odnosno klijentskom arhitekturom. Treći primjer je Java, koja nastoji biti široka u obje komponente, ali je ipak u računalnom smislu ograničena budući da zahtjeva java virtualni stroj (JVM) za svaku instalaciju.

Pored karakteristike konteksta namjene, važne su i druge karakteristike kao što su lakoća savladavanja, vrsta licenciranja, lakoća upotrebe, dostupnost alata za razvoj i primjenu, te efikasnost razvijenih aplikacija (brzina izvođenja, potrebni resursi i pouzdanost/stabilnost u radu).

Potrebu za novim jezicima treba sagledavati ne samo kao potragu da se izbjegnu navedena ograničenja, nego i zbog stalne promjene informatičke tehnologije, koja ta ograničenja odnosno karakteristike postojećih jezika stavlja u novi tehnološki kontekst, pri čemu u kontekstu nove tehnologije, neke dobre karakteristike postaju beskorisne, a pojavljuju se i novi nedostaci. Uzmimo kao primjer mnoge programske jezike koji su u doba

46 CASE29

DOS operativnog sustava bili široko prihvaćeni kao vrlo efikasni, ali su nakon pojave Windows operativnog sustava vrlo brzo nestali.

Neki jezici po svom konceptu, pretendiraju da budu jezici opće namjene, dok se neki drugi fokusiraju na specifične niše primjene. Programski jezici koji u aplikativnom smislu pretendiraju da budu jezici opće namjene, nastoje se prilagoditi promjenama tehnologije, ali nakon nekog vremena u pravilu, ili postaju presloženi za upotrebu ili neefikasni u primjeni.

2. GO PROGRAMSKI JEZIK

Go je jezik opće namjene razvijen sa sistemskim programiranjem na umu. Go se bazira na sustavu jakog tipiziranja (engl. strong typing), na automatskom upravljanju memorijom (engl. garbage collection), kao i na eksplicitnoj podršci za konkurentno programiranje [3]. Go nije sasvim nov programski jezik. Službeno je nastao 2009 godine kao projekt otvorenog koda iza koga stoji Google. Ka takav, Go je besplatan za bilo koga i podliježe BSD licenci. Danas možemo reći da je ušao u svoju zrelu fazu. To znači da je razvijena dovoljno velika kolekcija koda u okviru standardne biblioteke, uz stalno rastući broj dodatnih biblioteka razvijenih od strane mnogih kontributora iz open-source zajednice. Nadalje, Go je sve više prihvaćen od strane programera, kao nova opcija za razvoj praktično svih vrsta aplikacija, na širokom spektru kompjutorskih platformi, što uključuje gotovo sve danas aktivne operativne sustave i tipove procesora. U Google-u uzimaju Go ozbiljno i to u strateškom smislu [w4].

Prema TIOBE indeksu koji predstavlja mjeru promjene popularnosti programskog jezika, Go je dva puta imao najveći pozitivan porast popularnosti, 2009. I 2016. godine. Iako prema istom indeksu, u veljači 2017. godine Go nema najveći indeks pozitivne promjene (+2,1%), njegov indeks promjene popularnosti je i dalje u izrazitom porastu (+1,81%). Zanimljivo je da su sva tri najpopularnija programska jezika: Java, C, C++, dugoročno u stalnom padu popularnosti; Java(-4,47%), C (-7,15%), C++ (-1,48%) [w8 ].

Go je upravo prije nekoliko dana izdan pod verzijom 1.8 [w6]. Najznačajnija poboljšanja se odnose na povećanje performansi i veću portabilnost. Potrebno je napomenuti da se prilikom izdavanja novih podverzija u okviru Go 1 verzije, poštuje obećanje da će svaka nova podverzija omogućiti nesmetano kompiliranje kao i izvođenje starog koda kao što je bilo kod prethodnih verzija, to znači bez ikakvih izmjena.

3. IZVORIŠTA I KONCEPTI

Trojica Googlovih programera s bogatim iskustvom: Robert Griesemer, Rob Pike i Ken Thompson, 2007. godine su započeli u okviru internog projekta, koncipirati novi jezik koji je u konačnoj verziji dobio ime Go. Kasnije je taj tim pojačan s nekoliko eksperata iz Google-a, a danas u njemu sudjeluje mnogo programera izvan Google-a na rqavnopravnoj osnovi. Osnovna ideja je u smom začetku bila da se osmisli jedan bolji programski jezik, bolji od svih raspoloživih jezika. Treba napomenuti da su Google-ovi softverski inženjeri koji su radili na projektu, a osobito trojica navedenih, bili dugogodišnji iskusni eksperti u razvoju u programskim jezicima C i C++.

Oni su u svom prethodnom radu, bili suočeni s nizom problema u razvoju velikih i skalabilnih aplikacija. U

jeziku C++, a slična situacije i s Javom, uobičajeno je da se dodaju nove osobine kako bi se jezik s vremenom poboljšao. Međutim, dodavanje novih elementa već ionako kompleksnom jeziku, komplicira njegovu primjenu, pogotovo kod ekstremno velikih i skalabilnih aplikacija. To također programerima početnicima ekstremno komplicira učenje i savladavanje jezika. Ako samo referentni priručnik za C++ ili Javu ima gotovo tisuću stranica teksta, onda to nikako nije doprinos produktivnosti programera koji ih počinju koristiti.

Umjesto toga, oni su krenuli razmišljati na drugačiji način, rukovodeći se sloganom „manje je više“. Njihova osnovna ideja je bila da se osmisli jezik koji će iz postojećih jezika uzeti najbolje, rukovodeći se pritom principom minimalizma. Kod principa minimalizma dvije su stvari najvažnije. Prvo, ako je potrebna neka funkcionalnost u jeziku, onda to mora biti napravljeno na samo jedan efikasan način. Drugo, programski jezik mora omogućiti jednostavniji i produktivniji način razvoja aplikacija. Ako se neki dio u procesu razvoja može automatizirati, onda to treba ugraditi u jezik ili alte jezika, a ne ostaviti programeru da se brine oko toga.

Polazeći od toga da jezici kao što su C, C++, Java i drugi, ne zadovoljavaju princip minimalizma, oni također ne odgovaraju potrebama suvremene informatičke tehnologije. Konačno, to su jezici koji su nastali u vremenu bitno drugačijeg kompjutorskog krajolika u odnosu na današnji. Nadalje, iako su u proteklom vremenu nastali mnogi skriptni odnosno dinamički jezici, koji su nastojali pokriti određene aplikativne niše, već dugo vremena nije razvijen pravi sistemski jezik koji bi parirao C jeziku, koji bi bio prilagođen kako današnjim, tako i nadolazećim tehnologijama.

Programerima je prije pojave jezika Go na raspolaganju bio izbor između tri mogućnosti. Upotreba C/C++ jezika i alata koji omogućuju dobivanje učinkovitog koda, ali uz dugotrajan razvoj i proširenje. Druga je mogućnost upotreba jezika zasnovanih na JVM ili CLR, kao što je Java i .NET jezici. Njihova je mana potreba za postojanjem virtualnih strojeva (JVM/CLR), uz nešto lošije performanse i probleme razvoja i skalabilnosti. Treća mogućnost je upotreba jednog od dinamičkih jezika (npr. Python). Dinamički jezici omogućuju relativno brz razvoj, ali uz smanjenu učinkovitost izvođenja i ograničenu portabilnost.

Osim toga, bilo koja od te tri mogućnosti ima dodatne mane kao što su: nedovoljna pouzdanost koda (eng. safety), nedovoljna prenosivost izvršnog koda, loša ili nikakva podrška u izradi konkurentnog koda (konkurentno/paralelno izvođenje koda) na višeprocesorskim/jezgrenim sustavima ili u masivnom mrežnom okruženju kao što je npr. cloud computing. Razumljivost i čitljivost napisanog koda općenito nije prihvatljiva. Prema nekim tvrdnjama, u razvoju softvera se troši više vremena na proučavanje napisanog koda nego na stvaranje novoga.

Zbog svega toga, poučeni vlastitim iskustvom u razvoju aplikacija s jedne strane, te višegodišnjom uključenošću u razvoj nekih od ključnih računalnih tehnologija, tvorci jezika Go su zacrtali kao njegove glavne karakteristike: efikasnost, brzinu i pouzdanost, te lakoću programiranja, kao i lakoću i efikasnost konkurentnog programiranja.

Go nije nastao na bazi jednog jezika. Ipak, tri su značajne grupe jezika koje su najviše utjecale na koncept jezika Go. Iako on ima osnovnu sintaksu sličnu jeziku C, od njega se značajno razlikuje. Go je imperativni, proceduralni jezik jednako kao i C, međutim

CASE29 47

Go predstavlja otklon od C++, jer ne podržava koncept klase i sve ostalo što uz to ide. Jednako kao i C, Go je kompajlerski jezik. Izvršni kod se dobiva kompajliranjem izvornog koda. Pritom je prenosivost koda ovisna o postojanju kompajlera za ciljanu platformu, a ne ovisi o izvornom kodu tj., isti izvorni kod je prenosiv bez izmjena. Za razliku od C/C++ jezika, proces kompajliranja odnosno dobivanja izvršnog koda je ekstremno brz, praktično trenutan, tako da je usporediv s dinamičkim jezicima, što C/C++ nije.

Drugi utjecaj dolazi od skupine jezika nastalih pod utjecajem jezika ALGOL60 kao što su Pascal Modula-2, i Oberon/2. Odatle je Go preuzeo koncept programskih paketa (eng. package), kao i način deklaracije metoda.

Treći izvor utjecaja dolazi iz teorijskog pristupa, odnosno formalnog opisnog jezika CSP koji je Hoare objavio 1978. Odatle dolazi teorijska podloga koja opisuje temeljne kocepte konkurentnog izvođenja programa. Na toj osnovi je Rob Pike razvio prvo jezik Squeak, a zatim funkcionalni jezik Newsqueak, te kasnije jezik Alef razvijen za operativni sustav Plan9. Iz tog izvora Go je naslijedio koncept gorutina i kanala koji omogućuju konkurentno izvođenje koda uz jednostavno programiranje.

Neke ideje su izvorna specifičnost Go koncepta, kao što dinamičke matrice i mape s direktnim pristupom. Nadalje, kako bi se osigurao efikasan razvoj softvera, Go inherentno uključuje niz go-alata, a ne samo kompajlere. U vezi objektnog programiranja, Go ima potpuno drugačiji, značajno pojednostavljen pristup, koji kao što smo naveli, ne uključuje klase.

4. KARAKTERISTIKE GO JEZIKA

Go je jedinstven programski jezik opće namjene s nizom izvanrednih osobina. Neki programski jezici posjeduju neke od tih osobina, ali snaga Go jezika je u sinergiji svih tih osobina. Go je:

Imperativni, proceduralan jezik zasnovan na jednostavnoj, minimalističkoj sintaksi, dobroj čitljivosti i razumljivosti izvornog koda,

Jednostavan za učenje i korištenje, Baziran na sustavu jakog tipiziranja (engl. strong

typing), Statički tipiziran (eng. statically typed) s

mogućnošću dinamičkih tipova, Jezik s automatskim upravljanjem memorijom (eng.

garbage collection management), Jezik koji je memorijski siguran (eng. memory-safe),

sa sigurnim tipovima (eng. type-safe), Kompajlerski jezik s izvanrednom brzinom

kompajliranja i brzinom izvršnog koda koja je usporediva s brzinom C/C++ koda,

Zasnovan na modelu programskih paketa (eng. package model) s klauzulom import za eksplicitne zavisnosti koda (eng. explicit dependencies),

Omogućuje među-platformsko kompajliranje (eng. cross compilation),

Jezik s ugrađenom konkurencijom rutina s jednostavnim sustavom sinkronizacije,

Objektno zasnovan, na način da koristi strukture, metode izvan struktura kao funcije, te koncept sučelja (eng. interface), ali ne i klase,

Jezik koji izuzetke rješava na specifičan način koristeći panic/recover koncepte,

Sadrži konzistentnu standardnu knjižnicu, također omogućuje uključivanje C/C++ izvornog koda,

U potpunosti podržava UTF-8 kodiranje,

Posjeduje niz dobro osmišljenih alata, koji zajedno s kompajlerima čine jedinstvenu cjelinu,

Besplatan jezik otvorenog koda.

Pred ovoga, postoje i kritički pogledi na Go jezik. Najjača kritika dolazi iz „objektno orijentiranog tabora“ zbog toga što Go odbacuje klasični pristup konceptu objektne orijentacije kakav je prisutan u mnogim OO-jezicima, osobito u C++, ali isto tako i u Javi i ostalima. Konstruktori jezika Go su upravo izostavljanje koncepta klase, podtipova i nasljeđivanja povezanog s klasama, smatrali doprinosom jednostavnosti, efikasnosti i pouzdanosti Go-a.

5. SUSTAV TIPOVA

Budući da je Go zasnovan na sustavu jakog tipiziranja (eng. strongly typed), to znači da svaka varijabla kojoj je pridružen tip, ne može taj tip promijeniti u neki drugi. Go posjeduje tri vrste tipova:

elementarni tipovi, strukturirani tipovi i tipovi interfejsa/sučelja (interface-types).

Elementarni tipovi su ugrađeni tipovi koji slijede minimalistički koncept. Oni uključuju: tekstualne nizove (stringove), numeričke tipove (ima ih više) te logičke tipove (Boolean).

Strig-tipovi podržavaju UTF-8 kodnu shemu, što znači da za svaki znak troše jedan ili više bajtova memorije.

Numerički tipovi uključuju cjelobrojne s predznakom i bez predznak, zatim tipove s pomičnim zarezom (decimalne), i treće kompleksne brojeve.

Cjelobrojni bez predznaka su: uint8, uint16, uint32, uint64.

Cjelobrojni s predznakom (pozitivni, 0 i negativni): int8, int16, int32, int64.

Broj iza oznake uint/int označava veličinu potrebne memorije odnosno ograničava vrijednosti koje mogu sadržavati.

Decimalni tipovi odnosno tipovi sa pomičnim zarezom su: float32 i float64, prema definiciji IEEE-754 32/64. Oni omogućuju preciznost na 7 odnosno 14 znamenki.

Kompleksni tip ima dvije varijante koji omogućuje zapis kompleksnih brojeva s realnom i imaginarnom komponentom koja je decimalna: complex32 i complex64.

Napomenimo da su svi ovi tipovi implementacijski neovisni o platformi, što nije uvijek slučaj kod ostalih programskih jezika. U tome je Go specifičan, jer omogućuje još dva implementacijski ovisna cjelobrojna tipa int i uint. Njihova veličina zavisi od implementacijske platforme tj., da li je ona 32 ili 64 bitna, te će oni u zavisnosti od toga odgovarati int32/int64 odnosno uint32/uint64 tipovima.

Logički tip ima oznaku: bool; te može primiti jednu od dvije vrijednosti, true/false.

Navedeni tipovi su elementarni, ali u jeziku Go postoje još tri složena ugrađena tipa. To su array, slice i map. Array tip označava jedno ili višedimenzionalnu matricu koja sadrži vrijednosti nekog drugog tipa. Array tip ima fiksni broj elemenata dodijeljen prilikom deklaracije varijable. Slice tip je sličan matrici, ali za razliku od nje, on može pomoću pridruženih metoda mijenjati broj elemenata koje sadrži.

Map tip predstavlja složeni tip koji sadrži tabelu parova: ključ/vrijednost, i omogućuje direktan pristup do

48 CASE29

elementa putem ključa. Ovaj tip je sličan konceptu hash tabele u nekim drugim jezicima.

Strukturirani tipovi nisu ugrađeni, oni se definiraju klauzulom: struct. Sastoje se od elementa drugih elementarnih ili drugih tipova. Tipovi sučelja ili interface-tipovi u Go-u se koriste za objektno programiranje „na Go-način“.

6. KORISNIČKI TIPOVI

Pored navedenih ugrađenih tipova, Go dozvoljava definiciju korisničkiki definiranih tipova (custom types). Oni se definiraju komandom type. Opći oblik komande type je slijedeći:

type nazivKorisničkogTipa specifikacijaTipa

Primjeri definicije jednostavnih korisničkih tipova:

type rBroj uint

type iznos float32

type ime string

type daNe bool

7. STRUKTURNI TIPOVI

Specifikacija tipova koji se sastoje od više komponenti, pri čemu sve komponente mogu biti različitih tipova, definira se tako da specifikacija počinje klauzulom struct:

type imeIprezime struct {

ime, prezime string

godište uint16

}

Strukturni tipovi su agregatnih tipovi. Oni agregiraju svoje komponente u jedan viši tip –agregat. Elementi strukturnog tipa se nazivaju polja. Agregatne vrijednosti ne mogu sadržavati same sebe. To znači polje nemože biti istog tipa kao i struktura, međutim polje može imati pointer tip strukture. Na primjer:

type osoba struct {

ime, prezime string

godište uint16

otac, majka *osoba

}

Strukturni tip može imati anonimno polje koje se naziva anonymous field. Anonimno polje se definira kao ugrađeni tip:

type osoba struct {

ime, prezime string

godište uint16

otac, majka *osoba

}

type radnik struct {

osoba

kvalifikacija string

}

var r1 radnik

Ovdje je u tip radnik ugrađen tip osoba. Takvo polje se zove anonimno polje. Zapravo, varijabla deklarirana kao tip radnik, sadrži šest polja.

Pogledajmo još jedan slučaj ugradnje anonimnog tipa:

// anonymus type

package main

import "fmt"

func main() {

var r1 radnik

var o1 osoba

r1.osoba.ime = "Marko"

r1.prezime = "Marić"

r1.godište = 1990

r1.kvalifikacija = "programer"

o1.ime = "Ivo"

o1.prezime = "Ivić"

fmt.Println(r1)

fmt.Println(o1)

}

type osoba struct {

ime, prezime string

godište uint16

}

type radnik struct {

osoba

kvalifikacija string

}

rezultat programa će biti slijedeći ispis:

{{Marko Marić 1990} programer}

{Ivo Ivić 0}

8. STRUKTURA GO PROGRAMA

Svaki Go izvorni program se se sastoji od jednog ili nekoliko paketa (package). Paket ili programski modul se sastoji od nekoliko obaveznih dijelova. Program započinje tekstom komentara. Komentar započinje s dvije kose crte (//). Nakon toga slijedi ključna riječ package, koja označava naziv programa odnosno paketa.

Slijedeća je ključna riječ je import, koja označava koji su eksterni moduli/paketi potrebni u programu. Nakon toga slijede funkcije koje započinju ključnom riječju: func a u nastavku potpisom funkcije (function signature). Potpis označava koje tipove će funkcija uzimati za ulazne, a koje za izlazne parametre. Tijelo funkcije započinje odmah nakon potpisa otvaranjem vitičaste zagrade, a završava njenim zatvaranjem u tekućem ili nekom od slijedećih redova na završetku tijela funkcije.

Program mora imati jednu ili više funkcija, ali jedna od njih mora imati naziv main, ona predstavlja početak procedure programa.

//Ovaj modul je primjer Go porograma

package main

import (

"fmt"

)

func main() {

var pozdrav string = "Hello world"

fmt.Println(pozdrav)

}

U programu se mogu još nalaziti deklaracije varijabli, konstanti i tipova. Njihova vidljivost, kao i vidljivost ostalih objekata (funkcija, metoda,...) je ili lokana ili globalna (public). Sintaksa vidljivosti je jednostavna. Prvo slovo određuje vidljivost: veliko slovo znači globalnu vidljivost, a sve ostalo lokalnu (vidljivost unutar paketa). Tip ostalih slova u imenu nema utjecaja na vidljivost. Na gornjem primjeru programa funkcija Println iz paketa fmt je globalno vidljiva, dok je

varijabla pozdrav vidljiva smo lokalno u okviru paketa.

Varijable se deklariraju eksplicitno putem ključne riječi var te navođenjem imena i tipa varijable. Opcinalno, prilikom deklaracije, varijabli može biti pridružena

CASE29 49

inicijalna vrijednost. Varijabla se može deklarirati i implicitno pomoću operatora := . U tom slučaju imenu varijable se pridružuje tip i vrijednost izraza na desnoj strani. U gornjem primjeru smo varijablu pozdrav mogli deklarirati uz pridruživanje inicijalne vrijednosti na slijedeći način:

pozdrav := "Hello world"

U ovom primjeru, varijabli pozdrav će biti pridružen tip

string, budući da je to tip koji odgovara pridruženoj

vrijednosti varijable. Pridružena vrijednost kod implicitne deklaracije može biti i funkcija odnosno metoda.

Osim varijabli, mogu se deklarirati inicijalizirati konstante. Konstante imaju nepromjenjivu vrijednost tj., onu koja im je dodijeljena prilikom inicijalizacije. Primjer deklaracije i inicijalizacije konstante:

const pozdrav string = " Hello world

"

Matrice se mogu deklarirati kao jednodimenzionalne ili kao više dimenzijske. Primjeri:

var a [5]int

var b [7]string

var c [5][3]int

KONTROLNE STRUKTURE PROGRAMA

Kontrolne strukture u jeziku Go su svedene na minimum. Postoje tri osnovne strukture koje imaju različite oblike. To su : if/else, for i swich.

Struktura if/elese je uobičajena struktura poznata iz mnogih drugih jezika:

if num := 19; num < 0 {

fmt.Println(num, " je negativno")

} else if num < 10 {

fmt.Println(num, " ima jednu

znamenku")

} else {

fmt.Println(num, " ima više

znamenaka")

}

U ovom primjeru imamo unutar if strukture implicitnu deklaraciju i inicijalizaciju varijable num. To je jedna od specifičnost u Go-u: varijabla implicitno deklarirana unutar kontrolne strukture nije vidljiva izvan te strukture. Ovo vrijedi i za druge kontrolne strukture, a isto tako i za funkcije.

Struktura for u Go-u ima višestruku ulogu. Općenito,

ona predstavlja programsku petlju, a ima tri oblika. Prvi oblik sadrži inicijalnu definiciju varijable petlje, uvjet do kada će se petlja izvršavat, te način promjene vrijednosti varijable petlje:

for j := 7; j <= 9; j++ {

fmt.Println(j)

}

Moguće je da u zaglavlju for strukture bude samo naveden uvjet:

i := 1

for i <= 3 {

fmt.Println(i)

i = i + 1

}

Slijedeći oblik za for je oblik beskonačne petlje koja može bit prekinuta pomoću ključne riječi break ili nastavljena pomoću continue:

for {

fmt.Println(i)

break

}

Gore navedena petlja će se izvesti samo jednom, jer će njeno beskonačno izvođenje već nakon prvog koraka biti prekinuto klauzulom break.

Dok se if struktura odnosi na odluku, programska struktura switch se odnosi na slučajeve višestrukog izbora:

i := 2

fmt.Print("Rezultat je ")

switch i {

case 1:

fmt.Println("1")

case 2:

fmt.Println("2")

case 3:

fmt.Println("3")

default:

fmt.Println("nedefinirano")

}

9. FUNKCIJE

Funkcije u jeziku Go čine temeljni programski blok. Svaki se Go program sastoji od niza funkcija. Među njima mora uvijek postojati jedna funkcija pod nazivom: main(). Ovdje vrijedi poznata izjava „funkcije u Go-u su građani prvog reda“. Iako Go nije pravi funkcionalni jezik, on ima mnoge osobine funkcionalnih jezika.

U Go-u mogu biti tri vrste funkcija:

Standardne funkcije, Anonimne funkcije, Metode.

10. STANDARDNE FUNKCIJE

Standardne ili normalne funkcije predstavljaju imenovani dio programskog koda koji ima:

ime , listu ulaznih parametara, listu izlaznih parametara, tijelo funkcije.

Funkcija započinje glavom funkcije a završava tijelom funkcije koje je omeđeno vitičastim zagradama. Glava standardne funkcije započinje klauzulom func, nakon

čega slijedi ime funkcije, lista ulaznih, te lista izlaznih parametara. Liste parametara su omeđene okruglim zagradama (). Lista parametara može biti prazna, a ako nije prazna sastoji se od niza parametara razdvojenih zarezom s pridruženim tipom. Broj, raspored i tipovi ulaznih i izlaznih parametara čini tzv. signaturu ili potpis funkcije. Važna osobina Go-a je mogućnost da funkcija ima više od jednog izlaznog parametra. Primjer funkcije koja uzima dva cjelobrojna parametra, a vraća listu parametara tipa: cjelobrojni, string, cjelobrojni, stiring:

package main

import "fmt"

func main() {

fmt.Print(zbroj(1, 2))

}

func zbroj(a, b int) (int, string,

int, string, int) {

return a, "+", b, " = ", a + b

}

50 CASE29

Ispis rezultata će biti:

1 + 2 = 3

Ovaj dio koda je mogao dati isti ispis, a biti napisan i ovako:

package main

import "fmt"

func main() {

x,y,z := zbroj(1,2)

fmt.Print(x," + ",y," = ",z)

}

func zbroj(a, b int) (int, int, int)

{

return a, b, a + b

}

Ovdje je interesantno uočiti kako je jednim operatorom pridruživanja moguće pridružiti vrijednosti i tipove niza varijabli: x,y,z := zbroj(1,2)

11. POINTERI

Funkcije uzimaju parametre kao vrijednosti (by value).To znači preuzete varijable će dobiti lokalnu kopiju za potrebe funkcije. Želimo li da se eventualne promjene koje izaziva funkcija, odražavaju na parmetar, moramo umjesto naziva parametarske varijable staviti njegovu pointer vrijednost, odnosno njegovu adresu. Međutim, to nije dovoljno. Takav parametar trebamo definirati kao pointer tip, a kod poziva funkcije treba proslijediti ne vrijednost parametra nego njegovu adresu.

U Go-u za svaki tip T, bilo ugrađeni bilo korisnički definirani, uvijek postoji odgovarajući pointer tip *T. Na primjer, ako je varijabla tipa int, onda njoj odgovara pointer tipa int. Pointer je referenca (adresa) na određenu varijablu, dok je pointer tip, tip varijable koja može sadržavati adresu te varijable. Pointer tip se razlikuje od običnog tipa po tome što mu u imenu prethodi operator z „*“

Ako u funkciji umjesto parametra prema vrijednosti želimo prenijeti parametar prema referenci , to ćemo učiniti tako da parametar definiramo kao pointer tip, a kod poziva funkcije umjesto vrijednosti varijable koja treba supstituirati parametar predat ćemo njenu adresu upotrebom operatora & neposredno prije naziva varijable. Pogledajmo kako to izgleda na primjeru:

// pointeri i funkcije

package main

import "fmt"

func main() {

var a int = 1

var b int = 2

fmt.Println(a, b, zbroj(&a, &b))

fmt.Println(a, b, zbroj(&a, &b))

fmt.Println(a, b, zbroj(&a, &b))

fmt.Println(a, b, zbroj(&a, &b))

fmt.Println(a, b, zbroj(&a, &b))

}

func zbroj(a, b *int) int {

x := *a + *b

y := a

*b = *y

*a = x

return x

}

U ovom programu će vrijednosti varijable a i b biti promijenjene prilikom svakog poziva funkcije zbroj. Rezultat će biti slijedeći ispis:

1 2 3

3 1 4

4 3 7

7 4 11

11 7 18

Pointeri su dobro poznati u jeziku C, međutim u Go-u za razliku od C-a, ne postoji nikakva aritmetika pointera. Pointeri su u Go-u različiti tipovi od tipa int. Na taj način se izbjegava nesigurnost do koje može doći zbog operacija na pointerima, za što u C-u postoji mogućnost.

Osim reference, pointeri imaju još jednu važnu ulogu u Go-u: u runtime-alokaciji memorije za varijable koje nisu deklarirane prilikom kompajliranja. Go posjeduje ugrađenu funkciju new() koja omogućuje alokaciju potrebne memorije za određeni tip varijable. Ona vraća pointer na tako alociranu varijablu, i to u toku rada programa.

12. ANONIMNE FUNKCIJE

Standardne funkcije imaju ime odnosno identifikator, dok ga anonimne nemaju. Odatle im proizlazi naziv. Susreću se drugi nazivi kao zatvarači (closures), funkcijski funkcijski literali ili lambda funkcije.

Anonimne funkcije su bezimene funkcije koje se mogu pridružiti običnim varijablama. Na primjer:

// anonimna funkcija pridružena

varijabli zbroj

package main

import "fmt"

func main() {

zbroj := func(a, b int) int {

return a + b }

fmt.Println(zbroj(1, 2))

fmt.Println(zbroj(zbroj(1, 2), 4))

}

Funkcije u Go-u je moguće shvatiti kao vrijednosti, ali kao tipove. Na primjer, slijedeće dvije funkcije su istog tipa:

func zbroj(a, b *int) int{

return a + b }

func razlika(x, y *int) int{

return a - b }

međutim, funkcije zbroj (1,2) i razlika(1,2) daju različite vrijednosti.

Funkcije u Go-u mogu također vraćati funkcije.

13. METODE

Metoda (method) u Go-u su posebne vrste funkcija. Metoda je funkcija koja djeluje nad varijablom određenog tipa. Takva varijabla se onda označava kao prijemnik metode (receiver). Svaki tip osim pointer tipa i interface tipa, može biti prijemnik određenih metoda. Zanimljivo da u Go-u čak i jednostavni ugrađeni tipovi poput int, string, bool, itd., mogu imati metode. Metode u Go-u se definiraju neovisno o definiciji tipa. Svaki tip može imati više metoda, ali sve metode jednog tipa moraju imati različito ime. U Go-u metode ne poznaju klasični „method overloading“ nad istim tipom

CASE29 51

prijemnika, osim ako se radi o različitom tipu prijemnika, kada je dozvoljena egzistencija više metoda s istim imenom.

Opći oblik deklaracije metoda je slijedeći:

func (p tip_p) imeMetode(lup) (lip) {

/* tijelo metode*/ }

pri čemu je:

p – varijabla prijemnik

tip_p – tip prijemnika

lup - lista ulaznih parametara

lip - lista izlaznih parametara

Metode istog imena, a različtih prijemnika, su različite metode. Metodama su dostupna polja prijemnika npr., kod strukturnih tipova. Zanimljivo je da su u Go-u metodi primjenjivi i na nestrukturne tipove.

14. INTERFEJSI

Interfejsi u Go-u su konstrukti koji predstvljaju definiciju skupa metoda. Interfejsi su abstraktni tj., oni ne sadrže implementaciju metoda, nego samo njihovu definiciju. Koncept interfejsa omgućuje ograničeni pogled odnosno pristup tipu preko skupa metoda koje interfejs sadrži. Interfejs omogućuje sakrivanje implementacijskih detalja. Interfejs specificira ponašanje nekog objekta kroz skup pridruženih metoda sadržanih i interfejsu.

Pojam interfejs uključuje dvije stvari:

skup metoda, tip (interfejs tip).

Primjer definicije i implementacije interfejsa biće nad varijablama r1, o1 i p1 :

// metode i interfejsi

package main

import "fmt"

func main() {

var b biće // interface tip

var r1 radnik

var o1 osoba

var p1 pas

r1.osoba.ime = "Marko"

r1.prezime = "Marić"

r1.godište = 1990

r1.kvalifikacija = "programer"

o1.ime = "Ivo"

o1.prezime = "Ivić"

p1.ime = "Rex"

p1.god = 2

fmt.Println(r1, r1.zovese())

fmt.Println(o1, o1.zovese())

fmt.Println(p1, p1.zovese())

b = r1

fmt.Println("Zove se: ",

b.zovese())

b = o1

fmt.Println("Zove se: ",

b.zovese())

b = p1

fmt.Println("Zove se: ",

b.zovese())

}

type osoba struct {

ime, prezime string

godište uint16

}

type radnik struct {

osoba

kvalifikacija string

}

type pas struct {

ime string

rasa string

god uint

}

type biće interface {

zovese() string

}

func (rm radnik) zovese() string {

return rm.ime + " " + rm.prezime

}

func (os osoba) zovese() string {

return os.ime + " " + os.prezime

}

func (pa pas) zovese() string {

return "pas " + pa.ime

}

rezultat je ispis:

{{Marko Marić 1990} programer} Marko

Marić

{Ivo Ivić 0} Ivo Ivić

{Rex 2} pas Rex

Zove se: Marko Marić

Zove se: Ivo Ivić

Zove se: pas Rex

Uočimo da su varijable r1, o1 i p1 svaka različitog tipa, ali zadovoljavaju (implementiraju) isti interfejs, koji sadrži samo jednu metodu: zovese().

Interfejsi su implementirani implicitno, jer se implementiraju implementacijom njihovih metoda. To je vrlo važno svojstvo interfejsa u Go-u, jer razdvaja definiciju od implementacije.

Prazni interfejs tip

Prazni interfejs (empty interfaces), je oblik interfejsa koji ne sadrži niti jednu metodu. Na primjer:

type svaki interface{}

Prazni interface u Go-u implementira svaka varijabla bez obzira na tip. Zbog toga prazni interfejs može nositi bilo kojeg tipa. Korisnost praznih interfejsa dolazi do izražaja kod funkcija koje mogu primiti parametre bilo kojeg tipa.

15. OO PROGRAMIRANJE I GO

Go nije klasični objektno orijentiran jezik budući da ne podržava koncepte klasa, podtipova i nasljeđivanja na način kako je to koncipirano u npr., C++ jeziku. Unatoč toga, Go se može smatrati objektno orijentiranim ili barem objektno zasnovanim jezikom. Objektne koncepte on postiže kroz vrlo sofisticiran sustav tipova (type system) s jedne strane, te koncept metoda i interfejsa.

Interfejsi su zasigurno najuzbudljiviji dio Go jezika. Interfejsi osiguravaju određen oblik polimorfizma. Interfejsi se mogu definirati za kod koji nije poznat (iznutra).Fleksibilnost interfejsa se ogleda i u tome što se oni potpadaju u univerzalni koncept tipova.

Kompozicija, ugradnja osnovni su koncepti OO pristupa u Go-u. Potpomognuti interfejsima daju snažne

52 CASE29

mehanizme za proizvodnju koda koji stabilan, pouzdan i dobrih performansi.

16. KONKURENTNO IZVRŠAVANJE

Go omogućuje jednostavan način programiranja konkurentnog izvršavanja koda pomoću koncepta gorutina (goroutines). Konkurentno izvršavanje koda je osobito bitno danas kad postoje višeprocesorske platforme. Njegov će značaj bit još veći u budućnosti. Za razliku od mainstream jezika, Go omogućuje efikasno konkurentno programiranje.

Potrebno je razlikovati pojam paralelnog od pojma konkurentskog procesiranja. Komkurencija je moguća i na jednoprocesorskim platformama. U tom slučaju svaka gorutina traži/čeka slobodno vrijeme procesora dok su druge rutine u stanju I/O operacijama, odnosno u stanju blokiranja. Gorutine su funkcije čije izvršavanje je specificirano naredbom go:

go mojaRutina(…)

Go ne traži složeno upravljanje gorutinama koje bi zavisilo od programera. Dodatni mehanizmi sinhronizacije su osigurani putem kanala (channels). Kanali mogu primati i slati vrijednosti pomoću ugrađenih operatora. Oni osiguravaju sinkronizaciju među gorutinama bez potrebe za uvjetnim varijablama i za eksplicitnim mehanizmima zaključavanja.

17. ZAKLJUČAK

U ovom članku smo opisali i komentirali samo neke od osobina odnosno elemenata Go jezika. Unatoč toga, nadamo se da to dovoljno ilustrativno ili barem intrigantno prikazuje izuzetne osobine ovoga jezika. Navedena literatura je sigurno dobar izvor za daljnje proučavanje. Pritom svakako treba početi od izvorne web-stranice: https//:www.golang.org.

Je li Go programski jezik za razvoj aplikacija u 21.stoljeću? Je li Go novi bolji sistemski programski

jezik, ili čak bolji jezik opće namjene? Odgovori na ta pitanja zavise od više faktora. Nije dovoljno da je programski jezik dovoljno dobar ili bolji od drugih. Jedan od tih faktora je i brzina i širina prihvaćanja od strane programera. Taj momentum je značajan iz više razloga. To utječe na popularnost, a popularnost ubrzava prihvaćanje. Veća prihvaćenost podstiče daljnji razvoj jezika i i dodatnih alata, literature.

Go je nesumnjivo dobar, moderan jezik s dobrim zaleđem u Google-u, ali i u konceptu otvorenog koda. Izuzetno je važno to da je lako započeti učitii. Dovoljan je dan ili nekoliko sati da se shvate njegovi koncepti. Dovoljan je tjedan ili mjesec da se mogu pisati svrsishodni programi. Dovoljna je godina dana da se postane ekspert. Da li je ovo preoptimistično? Čini se da neki stvarni primjeri govore tome u prilog.

Drugo pitanje je da li je Go samo „prva lasta“ u pojavi novoga trenda novih kompajlerskih jezika za novo doba. Ozbiljni konkurenti kucaju na vrata profesionalnog programerskog svijeta. Rust je jedan od njih, a nije jedini [w11]. Znači li to postupni pad popularnosti dinamičkih jezika? Indikativna je možda činjenica da je Google nedavno razvio transkompajler i runtime za Python-ov izvorni kod [w9, w10]. Nadalje, GopherJs je kmpajler koji Go izvorni kod prevodi u JavaScript kod [w12].

Treći faktor je spremnost iskusnih eksperata koji koriste neke od „mainstream“ programskih jezika da prijeđu na Go. Ne radi se samo problemu napuštanja akumuliranog iskustva, nego i o spremnosti da se prihvate novi modeli, a na puste stari. To je obično veliki (psihološki) problem.

Iako se može nekome učiniti da neopravdano odstupa od objektne orijentacije zasnovane na klasama, treba imati na umu da je Go jednostavan i minimalistički jezik s pragmatičkim rješenjima i povećanom pouzdanošću, prilagođen suvremenoj tehnologiji mikroservisa, cloud-computinga, mrežnih aplikacija i konkurentnog izvođenja.

Literatura

1 Balbaert, I. (2012). The way to Go: A thorough introduction to the Go programming language. IUniverse.

2 Curtis, M. (2015). Level Up Your Web Apps With Go. SitePoint.

3 Kozyra, N. (2014). Mastering Concurrency in Go. Packt Publishing Ltd.

4 Kozyra, N. (2015). Mastering Go Web Services. Packt Publishing Ltd.

5 Summerfield, M. (2012). Programming in Go: creating applications for the 21st century. Pearson Education.

Web izvori:

(Svi navedeni izvori su dohvaćeni 17.02.2017.)

w1. https://golang.org/

w2. https://golang.org/(doc/effective_go.html

w3. https://play.golang.org/

w4. http://www.tiobe.com/tiobe-index/

w5. https://www.goin5minutes.com/

w6. https://talks.golang.org/2017/state-of-go.slide#1

w7. https://talks.golang.org/2012/waza.slide#1 (Concurrency is not Parallelism)

w8. http://www.businessinsider.com/google-go-update-from-jason-burberel-2015-6

w9. https://github.com/google/grumpy

w10. http://www.theinquirer.net/inquirer/news/3001961/google-open-sources-python-on-go-transcompiler-grumpy

CASE29 53

w11. https://www.rust-lang.org/en-US/

w12. https://gopherjs.github.io/

w13. https://jan.newmarch.name/go/

Podaci o autoru:

Mr. sc. Damir Vuk

Visoka škola Virovitica

e-mail: damir.vuk@vsmti.hr

Mr. sc. Damir Vuk, je magistar informacijskih znanosti. Stalno je zaposlen u Visokoj školi Virovitica u zvanju višeg predavača od 2008. godine. Prije toga je više od trideset godina stjecao iskustvo u razvoju i održavanju informacijskih sustava u nekoliko različitih grana gospodarstva. Više od trinaest godina je bio izvršni direktor za informacijski sustav u društvu Bilokalnik d.d.. Praktično iskustvo u gospodarstvu započeo je davne 1977. godine uvođenjem obrade podataka pomoću mini-kompjutora, u poduzeću Tvin. Samostalno je osmislio i razvio nekoliko složenijih softverskih projekata.

Područja osobitog interesa su mu: baze i modeli podataka, informacijski sustavi, algoritmi i programiranje.

54 CASE29

CASE29 55

PARALELNO PROGRAMIRANJE U JAVI

PARALLEL PROGRAMMING IN JAVA

Zlatko Sirotić

SAŽETAK:

Tema je usporedba rada Java 5/6 Executora, Java 7 ForkJoin frameworka i Java 8 (paralelnog) Streama, na jednom jednostavnom primjeru.

Prvo se daje kratak prikaz mikroprocesora i Java konkurentnog programiranja. Zatim se prikazuju programski kod ta tri rješenja, i rezultat izvođenja sa različitim parametrima (broj Java dretvi i zadataka).

ABSTRACT:

The theme is the comparison between Java 5/6 Executor, Java 7 ForkJoin framework and Java 8 (parallel) Stream, on a single simple example.

Firstly we will see a short preview of the microprocessor and Java concurrent programming. Then we will look at source codes for the three solutions, and the results of the execution with different parameters (number of Java threads and tasks).

1. UVOD

Mooreov zakon za sada još uvijek vrijedi (neki mu proriču brzi kraj, drugi tvrde da će se zbog novih tehnoloških rješenja on još dugo održati). Naravno, umjesto (značajnijeg) povećanja radnog takta procesora, zadnjih 10-ak (i više) godina umjesto toga se povećava broj CPU-a na jednom mikroprocesorskom čipu, tj. broj jezgri. Zbog toga je konkuretno i paralelno programiranje prestalo biti važno samo za one softverske inženjere koji se bave npr. izradom operacijskih sustava, sustava za upravljanje bazama podataka i sl., već je postalo važno i za "obične" sofverske programere.

Što se tiče pojmova "konkurentno programiranje" i "paralelno programiranje", postoje različita mišljenja o odnosu između njih. Nekada se (uglavnom) definiralo da je paralelno programiranje podskup konkurentnog programiranja, pri čemu je paralelno programiranje bilo ono kod kojeg se programi zaista izvršavaju paralelno, tj. izvode se na dva ili više procesora. Budući da danas praktički svaki mikroprocesorski čip ima barem dvije jezgre, često se konkurentno programiranje definira kao ono kod kojeg se različiti programi "nadmeću" za dobijanje računalnih resursa, a paralelno programiranje kao ono kod kojeg se dijelovi istog programa paralelno izvršavaju, kako bi se ukupan program mogao izvesti što brže.

U ovom radu se prikazuju primjeri paralelnog programiranja (u Javi) koji su u skladu s ovom drugom definicijom, tj. u primjerima se program dijeli na dijelove koji se paralelno izvršavaju, kako bi se ukupan program mogao izvesti što brže, koristeći raspoložive jezgre računalnog sustava.

2. PODRŠKA HARDVERA (MIKROPROCESORA) I OPERACIJSKOG SUSTAVA PARALELNOM PROGRAMIRANJU

Dizajneri mikroprocesora oduvijek su se trudili da ubrzaju njihov rad, i to ne samo povećanjem brzine (što nažalost dovodi do povećane potrošnje struje i jačeg zagrijavanja), nego i na druge načine. Uz uvođenje priručne memorije u mikroprocesorske čipove, dizajneri su od 1985. nalazili i druge tehnike za rješavanje jaza između brzine registara i brzine glavne memorije, kako bi u konačnici povećali brzinu izvođenja programa. Jedan od načina koji znatno pridonosi povećanju performansi je paralelizam na razini instrukcija, ILP (Instruction-Level Parallelism).

Kasnije su se dosjetili su se da bi ILP mogli koristiti i na drugi način. Umjesto da se paralelno obrađuju (u različitim fazama) samo instrukcije istog programa, mogu se paralelno obrađivati instrukcije različitih programa, tj. instrukcije različitih procesorskih dretvi. Treba naglasiti da procesorske dretve (ili hardverske dretve) mogu izvršavati i dretve i procese operacijskog

sustava. Takvo obrađivanje instrukcija naziva se hardverski multithreading. Postoji temporal

multithreading, kod kojeg se u jednom taktu obrađuje (maksimalno) jedna instrukcija samo jedne dretve, i simultaneous multithreading (Intel koristi ime Hyper-Threading Technology), kod kojeg se u jednom taktu mogu istovremeno obrađivati instrukcije više dretvi.

Konačno, došli su do toga da u jedan mikroprocesorski čip ugrade dvije ili više procesorskih jezgri (jezgra je,

za razliku od hardverskih dretvi, potpuno zaseban procesor). U računalo se onda može ugrađivati i nekoliko višejezgrenih procesora, pa se dobije arhitektura npr. kao na slici 1. Na njoj je prikazan sustav s dva dvojezgrena mikroprocesorska čipa, a svaka

56 CASE29

jezgra ima dvije procesorske dretve (T1 i T2). Dretve jedne jezgre dijele priručne memorije L1i i L1d. Jezgre dijele priručne memorije L2 i L3. Dva procesora nemaju zajedničku priručnu memoriju, te pristupaju glavnoj memoriji na uobičajen način.

Na razini operacijskog sustava postoje procesi (koji

predstavljaju program u izvođenju), koji se mogu izvršavati kvazi-paralelno (ako postoji samo jedna procesorska jezgra, i to bez hardverskog multithreadinga) ili paralelno. No ako je dobro da se procesi mogu izvršavati paralelno, onda to može biti dobro i za manje dijelove programa nego što su procesi, tj. dobro je da se paralelno (ili kvazi-paralelno) mogu izvršavati dijelovi istog programa. Dijelovi programa koji se mogu izvršavati paralelno zovu se dretve ili niti (threads) operacijskog sustava. Dretve jednog

procesa dijele adresni prostor tog procesa, tj. jedna dretva vidi podatke druge dretve. Zapravo, dretve dijele globalnu memoriju (programski kod i globalne podatke) i gomilu (heap), ali imaju vlastiti stog (stack) i kontekst dretve, kako prikazuje slika 2.:

Slika 2: Najvažniji elementi dretvi operacijskog sustava (prikazane su tri dretve koje pripadaju istom procesu);

Izvor: [7]

Zamjena konteksta dretvi u pravilu se izvodi nekoliko puta brže od zamjene konteksta procesa. Zbog toga svi

današnji moderni operacijski sustavi nisu samo višeprocesni, nego i višedretveni.

Nažalost, kod višejezgrenih procesora (i višeprocesorskih sustava općenito) rast performansi sustava rijetko raste proporcionalno sa povećanjem broja jezgri, već je rast općenito manji. Za razliku od toga, povećanje radnog takta kod jednojezgrenih i jednoprocesorskih sustava u pravilu je povećavalo performanse skoro linearno. Zapravo, u nekim slučajevima se proporcionalno povećanje performansi može postići i kod višejezgrenih / višeprocesorskih sustava, npr. onda kada takvi sustavi služe za podršku baza podataka i aplikacijskih servera, gdje su pojedini procesi (ili dretve) međusobno nezavisni.

No, kada pokušamo paralelizirati (razbiti u dretve) jedan program, najčešće ne dobijemo linearno povećanje. Razlog za to objašnjava Amdahlov zakon

[7]. Ako je u nekom programu proporcija onih dijelova programa koji se mogu paralelno izvršavati jednaka p (što znači da je proporcija dijelova koji se ne mogu paralelno izvršavati jednaka 1 – p), onda se povećanjem broja procesora (procesorskih jezgri) može dobiti ovo povećanje:

Npr. ako imamo 10 procesora i ako je moguće paralelizirati 90% programa, onda je maksimalno povećanje brzine 5,26 puta, što je skoro dva puta manje od broja procesora. Ako je moguće paralelizirati 99% programa, onda je povećanje 9,17 puta.

3. KONKURENTNO PROGRAMIRANJE U JAVI VERZIJE 1 - 4

Svaki Java program ima barem jednu dretvu, onu koja izvršava metodu main(). Kada želimo napraviti svoju dretvu, imamo u Javi dva načina; jedan način je da napravimo klasu koja nasljeđuje klasu Thread i da nadjačamo (override) metodu run(), kao što prikazuje

sljedeći primjer [7], u kojem se kreiraju dvije klase, Worker1 i Worker2:

Slika 1: Sustav s dva dvojezgrena mikroprocesorska čipa (svaka jezgra podržava dvije hardverske dretve); Izvor: [3]

CASE29 57

class Worker1 extends Thread {

public void run() {

// implement doTask1() here

}

}

class Worker2 extends Thread {

public void run() {

// implement doTask2() here

}

}

Da bi se kreirale dretva, potrebno je kreirati objekt (instancu) klase (u ovom slučaju klase Worker1 i/ili Worker2) i pozvati metodu start() nad tim objektom. Time će se automatski kreirati dretva i pozvati metoda run() u njoj. U nastavku se prikazuje implementacija

metode compute() (iz neke treće klase čiji ostali detalji nisu prikazani), koja kreira dvije dretve, tako da dva posla (tasks) mogu biti izvedena paralelno (ako postoje dva slobodna procesora koja ih izvode):

void compute() {

Worker1 worker1 = new Thread();

Worker2 worker2 = new Thread();

worker1.start();

worker2.start();

}

Sada klase Worker1 i Worker2 proširimo sa sljedećim atributom i metodom:

private int result;

public void getResult() {

return result;

}

Pretpostavimo da dretve snimaju rezultat izračuna u tu varijablu, a metodom getResult() ih možemo čitati. Sada želimo dobiti rezultat oba izračuna u metodi compute():

return worker1.getResult() +

worker2.getResult();

Očito, moramo čekati da obje dretve završe prije nego dobijemo taj rezultat. To se postiže naredbom join()

koja, kad se poziva nad dretvom-izvršiteljem, uzrokuje da dretva-pozivatelj čeka dok dretva-izvršitelj ne završi. U ovom slučaju programski kod dretve-pozivatelja izgleda ovako:

int compute() {

worker1.start();

worker2.start();

worker1.join();

worker2.join();

return worker1.getResult() +

worker2.getResult();

}

Naravno, u ovom slučaju nije važno da li prvo pozivamo join() nad worker1 ili worker2.

Kako je prije navedeno, postoji i drugi način za kreiranje dretvi u Javi. Prethodno prikazani način (kreiranje klase koja nasljeđuje klasu Thread), iako izgleda logičan, manje se koristi jer je manje fleksibilan. Problem je u tome što u Javi (za sada) postoji samo jednostruko nasljeđivanje klasa. Bez višestrukog nasljeđivanja klasa, ako naša klasa "potroši" jednostruko nasljeđivanje za klasu Thread, ne može naslijediti od neke druge klase. Zbog toga se češće koristi drugi način kreiranja dretve. Prvo se napiše "pomoćna" klasa

koja nasljeđuje sučelje (interface) Runnable, pri čemu

mora implementirati metodu run(). Onda se objekt te "pomoćne" klase šalje konstruktoru koji kreira objekt klase Thread (tj. dretvu) u kodu naše "glavne" klase.

Do sada prikazani rad sa dretvama u Javi izgleda prilično jednostavno. No, problemi nastaju kada se dvije dretve (ili više njih) upliću jedna drugoj u posao, npr. tako da modificiraju isti objekt. To može stvoriti netočne rezultate i naziva se race condition, npr. u ovom slučaju [7]:

class Counter {

private volatile int value = 0;

public int getValue() {

return value;

}

public void setValue(int someValue)

{

value = someValue;

}

public void increment() {

value++; -- napomena: niti sama

naredba value++ nije atomarna

}

}

Pretpostavimo da neka metoda u nekoj drugoj klasi kreira objekt klase Counter i sadrži sljedeći kod:

x.setValue(0);

x.increment();

int i = x.getValue();

Pitanje je: koju vrijednost ima varijabla i na kraju ovih naredbi? Ako je riječ o jednodretvenom programu, onda je vrijednost 1. No u konkurentnom radu brojač može biti modificiran od drugih dretvi, tako da rezultat ovisi o ispreplitanju naredbi ove dretve sa naredbama neke druge dretve. Npr. ako druga dretva konkurentno izvodi naredbu x.setValue(2); varijabla i na kraju

navedenih naredbi prve dretve može imati vrijednost 1, 2 ili 3, tj. rezultat ovisi o slučajnom redoslijedu izvođenja naredbi dvije dretve (zapravo, dodatni problem je i u tome što sama naredba value++ nije atomarna, već se u stvarnosti razlaže na tri interne naredbe: temp = value; temp = temp + 1; value = temp). Naravno, to nije ono što se želi. Taj se problem rješava pomoću sinkronizacije koja se zove međusobno isključivanje (mutual exclusion), za što Java ima jednostavno rješenje još od verzije Java 1. Svaki objekt u Javi ima lokot (lock; nasljeđuje se automatski od superklase Object), kojega istovremeno može držati (zaključati) samo jedna dretva.

Objekt koji će služiti kao lokot može se kreirati npr. ovako:

Object lock = new Object();

Dretva koja će tražiti lokot (tj. zaključati lokot) to radi pomoću naredbe synchronized, koja označava

početak tzv. synchronized bloka (inače synchronized i volatile su jedine Java ključne riječi vezane za

konkurentnost; ostalo su metode klase Object ili metode klasa specijaliziranih za konkurentnost):

synchronized(lock) {

// critical section

}

Kada dretva dođe do početka tog bloka, pokuša zaključati lokot objekta koji je naveden kao argument

58 CASE29

naredbe synchronized. Ako je lokot zaključan od neke druge dretve, polazna dretva čeka dok on ne postane otključan. Nakon toga ga polazna dretva drži zaključanim sve do kraja tog bloka. Problem iz prethodnog primjera mogli bismo riješiti pomoću synchronized npr. ovako (u prvoj, odnosno drugoj dretvi; naravno, moramo biti sigurni da varijable lock u oba koda referenciraju isti objekt):

// prva dretva

synchronized(lock) {

x.setValue(0);

x.increment();

int i = x.getValue();

}

// druga dretva

synchronized(lock) {

x.setValue(2);

}

Osim bloka, i cijela metoda (funkcija / procedura) može imati synchronized na početku:

synchronized type method(args) {

// body

}

što je, zapravo, isto kao i ovo:

type method(args) {

synchronized(this) {

// body

}

}

Prethodno je slično konceptu monitora, ali dizajneri Jave su napravili određena odstupanja od tog koncepta. Svaki objekt u Javi ima unutarnji (intrinsic) lokot i unutarnju kondiciju (condition). Ako je metoda deklarirana pomoću ključne riječi synchronized, ona djeluje kao monitor. Međutim, Java objekt se razlikuje od monitora [6] u tri važne stvari, kompromitirajući time sigurnost dretve (thread safety) :

atributi ne moraju biti privatni; metode ne moraju biti sinkronizirane; unutarnji lokot je pristupačan klijentima.

Zbog toga je jedan od inventora monitora, Per Brinch Hansen, 1999. godine izjavio [1]: "Zaprepašćuje me da je ovaj nesigurni Java paralelizam shvaćen tako ozbiljno od programske zajednice, četvrt stoljeća nakon invencije monitora i programskog jezika Concurrent Pascal."

Kao što vrijedi za monitor, tako vrijedi i za Java klase - zaštita pristupa djeljivim varijablama nije jedini razlog zašto dretve moraju biti međusobno sinkronizirane. Često puta treba odgoditi izvođenje metode (ili dijela metode) u nekoj dretvi, dok se ne zadovolji određeni uvjet (a taj uvjet nije samo otključavanje određenog lokota). To se zove sinkronizacija na temelju uvjeta

(condition synchronization), koja se u Javi implementira pomoću naredbi wait / notifyAll / notify, koje se pozivaju nad sinkroniziranim objektima.

Slika 3. prikazuje promjenu stanja Java dretvi (napomenimo da zbivanja koja implicitno sadrže naredbe notify() / notifyAll() nisu prikazana potpuno detaljno). Java dretva prelazi u stanje Waiting ne samo nakon naredbe wait() i join(), već i kod čekanja na objekte klase Lock i Condition iz java.util.concurrent librarya, uvedenog u Java 5 verziji.

Slika 3: Dijagram promjene stanja Java dretvi; Izvor: [6]

4. KONKURENTNO PROGRAMIRANJE U JAVI VERZIJE 5, 6, 7, 8 (KRATAK PREGLED)

Konkurentnost u Javi od verzije 1 do verzije 4 praktički se nije mijenjala, osim što su se rješavali bugovi i sl. Suštinu "alata" za konkurentno programiranje činili su: klasa Object, tj. njen unutarnji (intrinsic) lokot (atribut te klase) i njene metode wait(...) / notify / notifyAll, Java ključne riječi synchronized i volatile, klasa Thread i sučelje Runnable.

U Javi verzije 5, koja se pojavila 2004. godine, uvedeno je dosta novina na drugim područjima (npr. generičke klase, bolje kolekcije i dr.), ali i na području konkurentnog programiranja. JSR 166, koji se odnosi na konkurentnost, temeljen je uglavnom na paketu edu.oswego.cs.dl.util.concurrent, kojega je napravio Doug Lea. Kroz novi paket java.util.concurrent uvedene su sljedeće nove mogućnosti:

Executors (thread pools, scheduling); Futures; Concurrent Collections; Locks (ReentrantLock, ReadWriteLock...); Conditions; Synchronizers (Semaphores, Barriers...); Atomic variables; System enhancements.

U Java verziji 6, koja se pojavila godinu i pol nakon verzije 5, nije se pojavilo ništa revolucionarno, ali su se na području konkurentnog programiranja (kao i na drugim područjima) "iznutra" poboljšale biblioteke, bilo da su se riješili bugovi ili poboljšale performanse. U Java verziji 7, koja je izašla 2011. godine, u području konkurentnog programiranja novost je Fork/Join framework. U Java verziji 8, koja je izašla u ljeto 2014. godine, u području konkurentnog programiranja novost je Stream API, koji je podržan lambda izrazima i default metodama (koje su i same po sebi jako značajne).

U ovoj točki prikazat će se (ukratko) samo jedna mogućnosti uvedena u Javi 5 (sa poboljšanjima u Javi 6), i to ReentrantLock (u sljedećoj točki prikazat će se

Java 5 executori). Do Java 5 verzije, jedini mehanizmi za koordinaciju pristupa djeljivim podacima bili su synchronized (koji koristi unutarnji lokot) i volatile. Java 5 donijela je i ReentrantLock, što je (klasa za)

CASE29 59

eksplicitan lokot. Kako navode autori u [4], on nije zamjena za implicitan, unutarnji lokot, već alternativa koju je bolje koristiti u nekim (ali ne svim) slučajevima. Klasa ReentrantLock implementira sučelje Lock, koje ima ove metode:

public interface Lock {

void lock();

void lockInterruptibly() throws

InterruptedException;

boolean tryLock();

boolean tryLock(long timeout,

TimeUnit unit)throws

InterruptedException;

void unlock();

Condition newCondition();

}

Zaključavanja pomoću objekata klase ReentrantLock ima istu semantiku kao i synchronized, ali ima i dodatne mogućnosti. Najčešći oblik korištenja je sljedeći [4]:

Lock lock = new ReentrantLock();

...

lock.lock();

try {

// update object state

// catch exceptions and restore

invariants if necessary

} finally {

lock.unlock();

}

Za razliku od implicitnog zaključavanja i otključavanja kod synchronized, ovdje se zaključavanje i otključavanje mora raditi eksplicitno, a vrlo je važno da se otključavanje stavi u finally blok, inače lokot može ostati stalno zaključan. Moglo bi se reći da je to korak nazad u odnosu na synchronized, jer je sad moguće (dodatno) pogriješiti. No, mogućnost da se zaključavanje i otključavanje lokota napravi u različitim dijelovima koda ponekad je nužna (iako je takav kod manje čitljiv), a sa synchronized se to nije moglo izvesti. Preporuča se korištenje dosadašnje synchronized varijante ako nam ne treba ova mogućnost ili dodatne mogućnosti klase ReentrantLock.

5. PARALELNO PROGRAMIRANJE POMOĆU EXECUTORA (JAVA 5 I DALJE)

U Javi 5 su kroz paket java.util.concurrent uvedeni executori (tj. sučelja Executor, ExecutorService,

Callable, Future, klase Executors, ThreadPoolExecutor, FutureTask i dr.). Executori, za razliku od direktnog rada s klasom Thread, pomažu da se programeri koncentriraju na kreiranje zadataka koji će se poslati executoru na izvršavanje, a optimizaciju izvršavanja rade executori, koji koriste thread pool. Executorima se

daje zadatak koji je instanca klase (najčešće anonimne) koja implementira sučelje Runnable ili Callable.

Pretpostavimo da imamo ovakav zadatak: naći koliko ima prim (prostih) brojeva među prvih N (npr. 10 000 000) prirodnih brojeva (N zadajemo). Naravno, cilj nam je izvršiti zadatak u što kraćem vremenu. Zbog toga želimo zadatak riješiti kroz paralelno programiranje, tako da maksimalno koristimo procesorske resurse.

Glavno pitanje je: kako podijeliti zadatak na podzadatke? Povezano pitanje je: koliko Java dretvi

kreirati? Možda onoliko koliko ima podzadataka? To

najčešće ne bi bilo dobro! Za (približno) određivanje broja Java dretvi može se koristiti jednostavna formula:

broj_Java_dretvi = broj_HW_dretvi / (1 – koeficijent_blokiranja)

Koeficijent blokiranja (blocking coefficient) je broj između 0 i 1 i nije ga lako odrediti. Računski intenzivni problemi imaju koeficijent koji se približava nuli, pa je tada preporučeni broj Java dretvi jednak ili nešto malo veći od broja HW dretvi.

No, sada treba odrediti kako podijeliti problem, tj. koliko ćemo imati podzadataka. Svaki podzadatak radit će konkurentno, pa ih svakako treba biti barem onoliko koliko ima Java dretvi. U općenitom slučaju može se primijeniti relativno jednostavna tehnika: broj podzadataka treba biti dovoljno velik da se iskoriste postojeće Java dretve, tj. ne smije se desiti da neke Java dretve ostanu dugo neiskorištene.

Dakle, broj podzadataka svakako mora biti veći od broja Java dretvi. Naravno, nije lako odrediti (a ponekad niti moguće) koliki točno treba biti taj broj – najčešće treba eksperimentirati. Uglavnom se pokazuje da se kod početnog povećanja broja podzadataka dobije značajno povećanje performansi, a s daljnjim povećanjem, povećanje performansi je sve manje (performanse se mogu i smanjiti).

Slijedi Java program, koji se sastoji od klase PrimesExecutor, koji ima ove ulazne parametre: - number: gornja granica do koje se traže prim brojevi;

- poolSize: broj Java dretvi; - numberOfParts: broj podzadataka.

import java.util.List;

import java.util.ArrayList;

import

java.util.concurrent.ExecutorService;

import

java.util.concurrent.Executors;

import java.util.concurrent.Callable;

import java.util.concurrent.Future;

import java.util.concurrent.TimeUnit;

public class PrimesExecutor {

public static void main(final

String[] args) {

if (args.length != 3) {

System.out.println("Usage:

number poolSize numberOfParts");

return;

}

final long number =

Long.parseLong(args[0]);

final int poolSize =

Integer.parseInt(args[1]);

long numberOfParts =

Long.parseLong(args[2]);

// svaki podzadatak radi barem 10

brojeva

if (numberOfParts > number)

numberOfParts = number / 10;

final long numberOfPrimes;

final long startTime =

System.nanoTime();

60 CASE29

if (number <= 1)

numberOfPrimes = 0;

else {

PrimesExecutor task = new

PrimesExecutor();

numberOfPrimes =

task.countPrimes(number, poolSize,

numberOfParts);

}

final long endTime =

System.nanoTime();

System.out.printf

("Number of primes under %d is

%d\n", number, numberOfPrimes);

System.out.println

("Time (seconds) taken is " +

(endTime - startTime) / 1.0e9);

}

private long countPrimes

(final long number, final int

poolSize, final long numberOfParts)

{

long count = 0;

try {

final List<Callable<Long>>

partitions = new ArrayList<>();

// zaokruživanje na više

final long chunksPerPartition =

(number + numberOfParts - 1)

/ numberOfParts;

for(long i = 0; i <

numberOfParts; i++) {

final long lower = i *

chunksPerPartition + 1;

long upperTemp = (i + 1) *

chunksPerPartition;

// zadnji podzadatak može

imati manje brojeva

if (upperTemp > number)

upperTemp = number;

// lokalna varijabla

referencirana iz inner class mora

biti final

// zato smo koristili

upperTemp

final long upper = upperTemp;

partitions.add(new

Callable<Long>() {

public Long call() {

return

countPrimesInRange(lower, upper);

}

});

}

final ExecutorService

executorPool =

Executors.newFixedThreadPool(poolSize

);

final List<Future<Long>>

resultFromParts =

executorPool.invokeAll(partitions,

10000, TimeUnit.SECONDS);

executorPool.shutdown();

for(final Future<Long> result :

resultFromParts) {

count += result.get();

}

} catch(Exception ex) { throw new

RuntimeException(ex); }

return count;

}

private static long

countPrimesInRange(long lower, long

upper) {

long total = 0;

// Provjeravaju se i parni

brojevi, zbog usporedbe sa Streams

rješenjem

for(long i = lower; i <= upper;

i++) {

if (isPrime(i)) total++;

}

// 1 nije prim, ali 2 je prim (a

za 2 isPrime daje false),

// pa je ukupan broj točan.

return total;

}

private static boolean

isPrime(final long number) {

if (number % 2 == 0) return

false;

for(long i = 3; i * i <= number;

i = i + 2) {

if (number % i == 0) return

false;

}

return true;

}

}

6. PARALELNO PROGRAMIRANJE POMOĆU FORK JOIN FRAMEWORKA (JAVA 7 I DALJE)

Stara rimska poslovica glasi: "Divide et impera" ("Podijeli pa vladaj" ili "Zavadi pa vladaj", engl. "Divide and Conquer").

CASE29 61

Implementaciju ExecutorService sučelja u slučajuForkJoin frameworka radi klasa ForkJoinPool.

Tipično se ForkJoinPool instanci šalje samo jedan zadatak (task), a onda ForkJoinPool instanca i zadatak zajedno primjenjuju tehniku Divide and Conquer. Broj Java dretvi u poolu se može zadati eksplicitno ili implicitno:

broj Java dretvi se zadaje eksplicitno (u ovom slučaju 8):

ForkJoinPool fjPool = new ForkJoinPool(8); ili implicitno, jer framework koristi metodu

Runtime.availableProcessors() (na računalu sa 8 HW dretvi, bit će 8 Java dretvi): ForkJoinPool fjPool = new ForkJoinPool();

Zadatak (task) treba biti instanca podklase apstraktne klase ForkJoinTask, preciznije podklasa apstraktne

podklase klase ForkJoinTask, a najčešće su to RecursiveTask (u primjeru) ili RecursiveAction. ForkJoinTask ima puno metoda, ali najvažnije su: compute(), fork(), join().

Slijedi pseudo kod za compute():

if (podzadatakJeDovoljnoMali()) {

rijesiPodzadatak();

} else {

MojForkJoinTask lijevaPolovica =

...

MojForkJoinTask desnaPolovica = ...

lijevaPolovica.fork(); -- stavi u

queue

desnaPolovica.compute();--

radi(rekurzivno)

lijevaPolovica.join(); -- čekaj

završetak

}

Za razliku od većine ExecutorService implementacija, kod ForkJoin frameworka svaka Java dretva u ForkJoinPool-u ima svoj red (queue) podzadataka na

kojima radi. Metoda fork() stavlja ForkJoinTask u red tekuće Java dretve. Inicijalno je zauzeta samo jedna Java dretva - kada joj pošaljemo (cijeli) zadatak. Dretva tada počinje dijeliti zadatak u dva podzadatka, pa prvi podzadatak (lijevi) stavi u red, a drugi podzadatak (desni) pokuša izvršiti (i tako rekurzivno), kao što pokazuje slika 4.

Ključna značajka ForkJoin frameworka je Work Stealing (krađa posla). Java dretve kradu posao

(podzadatak) drugoj Java dretvi iz njenog reda podzadataka, i stavljaju ga u svoj red (nešto što većina nas ne bi nikad napravila ).

Vrlo je važan redoslijed stavljanja podzadataka u red. Podzadaci koji se prvi stavljaju u red trebaju predstavljati veći dio posla. Npr. na početku imamo jedan zadatak, koji pokriva 100% posla. Njega dijelimo

Slika 5: ForkJoin – krađa podzadataka od strane drugih Java dretvi; Izvor: [9]

Slika 4: ForkJoin - podjela zadatka na podzadatke; Izvor: [9]

62 CASE29

u dva podzadatka, svaki po (otprilike) 50% posla. Prvi stavljamo u red, a drugi obrađujemo, pri čemu drugi opet dijelimo u polovice, itd. One Java dretve koje nemaju posla (tj. njihov red je prazan), kradu posao drugim Java dretvama, i to tako da uzmu posao (podzadatak) koji je najstariji u redu, a to je istovremeno i najveći posao iz reda druge Java dretve. Slika 5. pokazuje ta događanja, s 4 Java dretve.

Dijeljenje na podzadatke se, za razliku od primjera sa običnim executorima, radi implicitno – ne zadaje se broj podzadataka, već se određuje kada je podzadatak dovoljno mali. Nažalost, ne postoji opća

metoda kojom se ispravno određuje veličina tog malog podzadatka – to se radi eksperimentalno. Podzadatak na kojem se poziva metoda join() može tada biti već gotov, jer ga je možda ukrala druga Java dretva, i već napravila. Ili može biti ukraden, ali ga druga dretva upravo radi, pa tada treba čekati da završi. Treći je slučaj da podzadatak nije ukraden i tada ga radi tekuća dretva.

Poziv join() metode u compute() metodi treba biti jedna od zadnjih radnji, iza poziva fork() metode i rekurzivnog poziva compute() metode. Budući da je to jako važno, postoji i metoda invokeAll(a2, a1); koja može zamijeniti niz naredbi a1.fork(); a2.compute(); a1.join();

Slijedi Java program, koji se sastoji od klase PrimesForkJoin, koji ima ove ulazne parametre: - number: gornja granica do koje se traže prim brojevi; - poolSize: broj Java dretvi; - threshold: broj koji definira kada je podzadatak dovoljni mali (pa se više ne dijeli na dva nova).

import

java.util.concurrent.ForkJoinPool;

import

java.util.concurrent.RecursiveTask;

import java.util.concurrent.TimeUnit;

import

java.util.concurrent.ExecutionExcepti

on;

public class PrimesForkJoin extends

RecursiveTask<Long> {

private static int threshold;

private long start;

private long end;

private PrimesForkJoin(final long

theStart, final long theEnd) {

start = theStart;

end = theEnd;

}

public static void main(final

String[] args) {

if (args.length < 1 ||

args.length > 3) {

System.out.println

("Usage: number poolSize

threshold OR number poolSize OR

number");

return;

}

final long number =

Long.parseLong(args[0]);

final long numberOfPrimes;

final long startTime =

System.nanoTime();

if (number <= 1)

numberOfPrimes = 0;

else {

PrimesForkJoin task = new

PrimesForkJoin(1, number);

ForkJoinPool fjPool;

if (args.length == 2 ||

args.length == 3) {

fjPool = new

ForkJoinPool(Integer.parseInt(args[1]

));

} else {

fjPool = new ForkJoinPool();

}

if (args.length == 3) {

threshold =

Integer.parseInt(args[2]);

} else {

threshold = 100;

}

numberOfPrimes =

fjPool.invoke(task);

}

final long endTime =

System.nanoTime();

System.out.printf

("Number of primes under %d is

%d\n", number, numberOfPrimes);

System.out.println

("Time (seconds) taken is " +

(endTime - startTime) / 1.0e9);

}

protected Long compute() {

if (end - start <= threshold) {

return

countPrimesInRange(start, end);

} else {

long halfWay = ((end - start) /

2) + start;

PrimesForkJoin t1 = new

PrimesForkJoin(start, halfWay);

PrimesForkJoin t2 = new

PrimesForkJoin(halfWay + 1, end);

t1.fork();

long count2 = t2.compute();

long count1 = t1.join();

return count1 + count2;

}

}

private static long

countPrimesInRange ... kao prije ...

private static boolean isPrime ...

kao prije ...

}

CASE29 63

7. PARALELNO PROGRAMIRANJE POMOĆU PARALELNIH STREAMSA (JAVA 8)

Na temelju onoga što čitamo i čujemo, mogli bismo zaključiti da je najvažnija nova mogućnost u Javi 8 lambda izraz (ili kraće, lambda). Inače, lambda izraz je

(u Javi) naziv za metodu bez imena. U pravilu je ta metoda funkcija, a ne procedura. Zato možemo reći i da lambda izraz je anonimna funkcija,

koja se može javiti kao parametar (ili povratna vrijednost) druge funkcije (koja je, onda, funkcija višeg reda). U Javi 8 pojavile su se i tzv. default metode u

Java sučeljima (interfaces). One, zapravo, predstavljaju uvođenje višestrukog nasljeđivanja implementacije u

Javu. Međutim, lambda izrazi i default metode su, na neki način, posljedica uvođenja treće važne mogućnosti u Javi 8, a to je Stream API, koji nadograđuju dosadašnje Java kolekcije.

Lambda izrazi (ili lambda funkcije), imaju teoretsko porijeklo u lambda računu (lambda calculus), kojega je sredinom 30-ih godina prošlog stoljeća kreirao Alonzo Church. Poznata je Church-Turingova hipoteza (inače, Alen Turing je kod Alonza Churcha radio

doktorat), koja se ne može matematički dokazati, već se smatra intuitivno prihvatljivom. Ona (pojednostavljeno, te u današnjoj terminologiji) kaže da sve što se efektivno može izračunati, može se izračunati pomoću lambda računa ili Turingovog stroja. 50-ih godina se

formalno dokazalo da postoje i neki drugi sustavi koji su njima ekvivalentni: Gödelove rekurzivne funkcije, Postov sustav, Markovljevi algoritmi i dr. Bez obzira na teoretsku ekvivalentnost, Turingovi strojevi su po svom ponašanju bliži imperativnoj programskoj paradigmi, dok je lambda račun teoretska osnova za funkcijske programske jezike, od kojih je najstariji Lisp (nastao 1959.).

Java 8 lambda (izrazi) temelje se na tzv. funkcijskim sučeljima (functional interface), koji su postojali od

početka. Funkcijska sučelja su ona sučelja koja imaju točno jednu (jednu i samo jednu) apstraktnu funkciju. No, od Jave 8 funkcijska sučelja mogu imati i statičke metode i default metode (koje nisu postojale prije Jave 8). Npr. kad Java kompajler naiđe na ovakvu naredbu (lambda izraz je desno od znaka jednakosti; ovo je samo jedna od brojnih varijanti pisanja lambda izraza):

StringToIntMapper mapper = (String str) -> str.length();

kompajler provjerava da li postoji odgovarajuće sučelje StringToIntMapper, koje ima samo jednu apstraktnu funkciju. Pretpostavimo da postoji takvo sučelje:

// anotacija @FunctionalInterface

uvedena je u Javi 8

@FunctionalInterface interface

StringToIntMapper {

int map(String str);

}

Kompajler tada napravi nešto što ima jednak efekt kao sljedeća anonimna klasa:

StringToIntMapper mapper =

new StringToIntMapper() {

@Override

public int map(String str) {

return str.length();

}

};

Kako je već rečeno, default metode su u Javi 8 trebale prvenstveno zbog uvođenja Stream API-a. Kod uvođenja Streamsa, bilo je potrebno nadograđivati brojna postojeća Java sučelja, tj. dodavati im nove metode. Međutim, kad dodajemo nove metode u sučelje, moramo mijenjati sve klase koje ga (direktno ili indirektno) nasljeđuju, što može značiti izmjenu milijuna redaka programskog koda. Default metode su riješile taj problem. Sučelje sada može imati i implementaciju metode, a ne samo deklaraciju.

Pojava masivno višejezgrenih procesora traži bolji i lakši način izrade paralelnih programa od dosadašnjih načina. Jedan (dobar) način je da se koristi funkcijsko programiranje, a naročito paralelne kolekcije. Java nema paralelne kolekcije (ima samo paralelni niz, uveden u Javi 8), ali su zato uvedeni Streamsi, kako bi se postojeće kolekcije "zaogrnule" u (paralelne) Streamse i mogle (indirektno) paralelizirati. Za razliku od dosadašnjih kolekcija, koje sadrže sve svoje elemente u memoriji, Streamse možemo shvatiti kao "vremenske kolekcije", čiji se elementi (kojih teoretski može biti i beskonačan broj) stvaraju po potrebi. Način rada Java Streamsa prikazuje slika 6.

Usporedba rada s kolekcijama na klasičan način (korištenjem for petlje), pomoću lambda izraza bez Streamsa, i pomoću paralelnih Streamsa:

// 1. "klasična" obrada "klasične"

kolekcije - for petlja

private static void

checkBalance(List<Account> accList) {

for (Account a : accList)

if (a.balance() < a.threshold)

a.alert();

}

// 2. primjena lambda izraza za

obradu "klasične" kolekcije

private static void

checkBalance(List<Account> accList) {

accList.forEach(

(Account a) -> { if (a.balance() <

a.threshold) a.alert(); }

);

}

// 3. primjena Streamsa za

paralelizaciju "klasične" kolekcije

Slika 6: Način rada Java Streamsa; dretvi; Izvor: [8]

64 CASE29

private static void

checkBalance(List<Account> accList) {

accList.parallelStream().forEach(

(Account a) -> { if (a.balance() <

a.threshold) a.alert(); }

);

}

Paralelne verzije Streamsa interno se temelje na ForkJoin frameworku.

Slijedi Java program, koji se sastoji od klase PrimesStream, koji ima ove ulazne parametre: - number: gornja granica do koje se traže prim brojevi;

- isParallel: unese se 0 za serijsko izvršavanje, 1 za

paralelno izvršavanje. import java.util.stream.*;

import

java.util.concurrent.TimeUnit;

public class PrimesStream {

public static void main(final

String[] args) {

if (args.length != 2) {

System.out.println("Usage:

number 1/0 (parallel/not

parallel)");

return;

}

final long number =

Long.parseLong(args[0]);

final boolean isParallel =

(Integer.parseInt(args[1]) ==

1) ? true : false;

final long numberOfPrimes;

final long startTime =

System.nanoTime();

if (number <= 1)

numberOfPrimes = 0;

else

numberOfPrimes =

countPrimes(number, isParallel);

final long endTime =

System.nanoTime();

System.out.printf

("Number of primes under %d

is %d\n", number, numberOfPrimes);

System.out.println

("Time (seconds) taken is " +

(endTime - startTime) / 1.0e9);

}

protected static long countPrimes

(final long number, final

boolean isParallel)

{

long count;

if (isParallel)

count =

LongStream.rangeClosed(1L, number)

.parallel()

.filter(n -

> isPrime(n)) // lambda expression

.count();

else

count =

LongStream.rangeClosed(1L, number)

.filter(PrimesStream::isPrime) //

method reference

.count();

// 1 nije prim, ali 2 je prim

(a za 2 isPrime daje false),

// pa je ukupan broj točan.

return (count);

}

private static boolean isPrime

... kao prije ...

}

Slijede rezultati usporedbe rješenja pomoću Java 5/6 Executora, Java 7 ForkJoina i Java 8 paralelnog Streamsa na računalu s mikroprocesorkim čipom i7-4702MQ na 2.2 GHz (korištena Java 1.8.0_111):

PrimesExecutor 10000000 1 1000

Time (seconds) taken is 8.69

PrimesExecutor 10000000 2 1000

Time (seconds) taken is 4.57

PrimesExecutor 10000000 4 1000

Time (seconds) taken is 2.51

PrimesExecutor 10000000 8 1000

Time (seconds) taken is 1.76

PrimesExecutor 10000000 16 1000

Time (seconds) taken is 1.72

PrimesForkJoin 10000000 1 100

Time (seconds) taken is 8.89

PrimesForkJoin 10000000 2 100

Time (seconds) taken is 4.64

PrimesForkJoin 10000000 4 100

Time (seconds) taken is 2.59

PrimesForkJoin 10000000 8 100

Time (seconds) taken is 1.85

PrimesForkJoin 10000000 16 100

Time (seconds) taken is 1.79

PrimesStream 10000000 0

Time (seconds) taken is 8.92

PrimesStream 10000000 1

Time (seconds) taken is 1.92

... Number of primes under 10000000

is 664579

8. ZAKLJUČAK

Pisati konkurentne / paralelne programe nije lako, ali to je nužno u današnje vrijeme višejezgrenih mikroprocesorskih čipova. Srećom, razvijaju se i hardverske tehnike (npr. hardverska transakcijska memorija, HTM, koja za sada nije uzela velikog maha u običnom programerskom svijetu, vjerojatno i zbog bugova koje je Intel imao u implementaciji HTM-a u 4. generaciji svojih mikroprocesorskih čipova i7) i softverske tehnike koje olakšavaju konkurentno / paralelno programiranje.

To vrijedi i za Java okolinu, naročito od Jave 5 dalje. U radu je prikazan isti primjer paralelnog programa (gdje

CASE29 65

se program podijeli u dijelove koji se mogu izvršavati paralelno), riješen na tri različita načina: pomoću Java 5 Executora, Java 7 ForkJoin "frameworka" i Java 8 (paralelnih) Streamsa. Možda se neće svi složiti da je rješenje pomoću Java 7 ForkJoin frameworka

jednostavnije / razumljivije (iako je kraće) nego rješenje pomoću Java 5 Executora, ali vjerojatno će se (gotovo) svi složiti da je rješenje pomoću Java 8 (paralelnih) Streamsa najkraće i najrazumljivije. Vidjet ćemo što će nam tu donijeti Java 9.

Literatura:

1 Brinch Hansen, P. (1998): Java insecure Parallelism, Syracuse University, http://brinch-hansen.net/papers/1999b.pdf (veljača 2017.)

2 Boyarsky, J., Selikoff, S. (2015): OCP: Oracle Certified Professional Java SE 8 Programmer II Study Guide: Exam 1Z0-809, Sybex

3 Drepper U. (2007): What Every Programmer Should Know About Memory (white paper), Red Hat Inc., http://www.akkadia.org/drepper/cpumemory.pdf (veljačaj 2017.)

4 Göetz B. i ostali (2006): Java Concurrency in Practice, Addison-Wesley

5 Herlihy, M., Shavit, N. (2008): The Art of Multiprocessor Programming, Elsevier / Morgan Kaufmann Publishers

6 Horstmann, C.S., Cornell, G. (2008): Core Java: Volume 1 - Fundamentals (8.izdanje), Prentice Hall / Sun Microsystems

7 Meyer, B., Nanz S. (2010): Concepts of Concurrent Computation (materijali sa kolegija), ETH Zuerich - Chair of Software Engineering, http://se.inf.ethz.ch/old/teaching/2010-S/0268/index.html#lectures_slides (veljača 2017.)

8 Sharan, K (2014): Beginning Java 8 Language Features - Lambda Expressions, Inner Classes, Threads, I/O, Collections and Streams, Apress

9 Sierra K., Bates B. (2015): OCA/OCP Java SE 7 Programmer I & II Study Guide, McGraw-Hill Education

10 Subramaniam, V. (2011): Programming Concurrency on the JVM – Mastering Synchronization, STM, and Actors, The Pragmatic Bookshelf, Texas / Raleigh

Podaci o autoru:

Zlatko Sirotić, univ.spec.inf.

ISTRA TECH d.o.o., Pula

e-mail: zlatko.sirotic@istratech.hr

Autor radi više od 30 godina na informatičkim poslovima, uglavnom u poduzeću ISTRA TECH d.o.o., Pula (ISTRA TECH je novo ime poduzeća Istra informatički inženjering, osnovanog prije 27 godina).

Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi više od 20 godina.

Objavljivao je stručne radove na kongresima / konferencijama CASE, KOM, HrOUG, JavaCro, "Hotelska kuća", u časopisima "Mreža", "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješenja objavljivana su na web stranicama firmi Oracle i Quest (danas dio firme Dell).

Na Odjelu za informatičko-komunikacijske tehnologije Sveučilišta Juraj Dobrila u Puli sudjeluje (od početka osnivanja odjela) kao vanjski suradnik na kolegijima Baze podataka 2 i Informatički praktikum 1.

66 CASE29

CASE29 67

KRIPTOGRAFIJA U ORACLE BAZI PODATAKA

CRYPTOGRAPHY IN THE ORACLE DATABASE

Zlatko Sirotić

SAŽETAK:

U radu se prvo prikazuju osnove kriptografije. Prikazuje se razlika između simetričnih kriptosustava (koji koriste isti ključ u procesu kriptiranja i procesu dekriptiranja) i asimetričnih kriptosustava (kriptosustava s javnim ključem). Nešto detaljnije se prikazuje asimetrični kriptosustav RSA. Zatim se prikazuje upotreba kriptografije u Oracle bazi. U prilogu se prikazuje matematička osnova kriptosustava RSA.

ABSTRACT:

The paper presents the basics of cryptography. Furthermore, it shows the difference between the symmetric cryptosystem (which uses the same key in the encryption and decryption process) and asymmetric cryptosystem (cryptosystem with public key). The asymmetric cryptosystem RSA is explained in more details, as it is the use of cryptography in the Oracle database.The appendix shows the mathematical basis of the RSA cryptosystem.

1. UVOD

Sve do kraja 60-tih godina prošlog stoljeća, kriptografija se uglavnom koristila u vojne i diplomatske svrhe. Tada je došlo do širokog razvoja međunarodnih financijskih transakcija, pa se pojavila potreba za kriptosustavima koje će moći koristiti korisnici širom svijeta. Zato su uvedeni međunarodni standardi u kriptografiji. Prvo su uvedeni simetrični kriptosustavi, koji koriste isti ključ i u procesu kriptiranja i u procesu dekriptiranja, što znači da je ključ poznat i pošiljatelju i primatelju poruke (i samo njima). Kasnije su razvijeni asimetrični kriptosustavi (ili kriptosustavi s javnim ključem).

U radu se prvo prikazuju sigurnosne osobine poruka (informacija). Zatim se ukratko prikazuju simetrični i asimetrični kriptosustavi. Iako Oracle baza podataka za sada izravno ne koristi asimetrične kriptosustave, u nastavku se nešto detaljnije prikazuje najčešće korišteni asimetrični kriptosustav RSA. U prilogu se daju i neki matematički pojmovi vezani za RSA kriptosustav, te prezentacijska realizacija RSA kriptosusava u Oracle Forms alatu.

U nastavku se prikazuje korištenje kriptografije u Oracle bazi. Kao kod svih baza, tako i kod Oracle baze postoje dvije glavne vrste kriptiranja podataka – kriptiranje podataka koji su u tranzitu (data in transit) i kriptiranje podataka koji stoje (data at rest), a kod potonjih se uglavnom radi o podacima baze podataka koji se nalaze na diskovima. Kriptiranje podataka koji stoje radi se u Oracle bazi isključivo pomoću simetrične kriptografije, a moguće je primjenjivati "ručnu" metodu, tj. programiranje pomoću paketa DBMS_CRYPTO, ili dvije metode koje čine tzv. transparentnu enkripciju podataka (Transparent Data Encription, DTE): TDE Column Encryption i TDE Tablespace Encryption.

2. SIGURNOSNE OSOBINE PORUKA (INFORMACIJA)

Sigurnost računalnih komunikacija ovisi o sljedećim sigurnosnim osobinama poruka (informacija) ili, drugačije rečeno, o sljedećim zahtjevima nad porukama (informacijama):

povjerljivost (tajnost, privatnost, engl.

confidentiality): poruku (informaciju) koju osoba A šalje osobi B ne može pročitati nitko treći;

integritet (besprijekornost, netaknutost, engl.

integrity): osoba B je sigurna da poruka (informacija) koju je poslala osoba A nije promijenjena (od neke treće osobe);

raspoloživost (engl. availability): poruke

(informacije) moraju uvijek biti na raspolaganju ovlaštenim osobama, unatoč mogućim nepogodama / nesrećama ili zlonamjernim napadima;

autentičnost (vjerodostojnost, engl. authenticity):

osoba B zna da je samo osoba A mogla poslati poruku koju je ona (osoba B) primila;

neporecivost (nepobitnost, ne-nepriznavanje, engl.

non-repudiation): osoba A ne može zanijekati da je poslala poruku koju je osoba B primila (ako ju zaista poslala).

Može se napomenuti sljedeće:

prva tri zahtjeva (povjerljivost, integritet, raspoloživost) se često smatraju osnovnim zahtjevima;

raspoloživost se ne može povećati pomoću kriptografije, čak se ponekad može i smanjiti (kriptiranje i dekriptiranje poruka traje neko vrijeme);

često se navodi i šesti zahtjev, autorizacija (engl.

authorization): autentificirani korisnik može pristupati samo sadržajima koji su mu dopušteni, i to na način koji mu je dopušten; autorizacijom se dodatno osiguravaju povjerljivost i/ili integritet; autorizacija se ne rješava (direktno) pomoću kriptografije;

68 CASE29

zahtjev autentičnosti i neporecivosti (poruke) izgledaju slično, pa se može činiti da su ekvivalentni; no, autentičnost ne implicira neporecivost, jer bi npr. osoba B mogla sama sebi poslati poruku kriptiranu simetričnim ključem i tvrditi da je poruku poslala osoba A (koja jedina, uz osobu B, zna taj ključ); no, ako se primjenjuje asimetrični kriptosustav, onda osoba B ne može sama sebi poslati kriptiranu poruku u ime osobe A (jer samo osoba A ima tajni ključ) i može se sigurno tvrditi da je to poruka od osobe A; s druge strane, neporecivost ne implicira autentičnost, jer se osoba C može lažno predstaviti kao da je osoba A i koristiti svoj javni i privatni ključ (C može znati javni ključ osobe A, ali ne može znati tajni ključ osobe A).

Drži se da je zahtjev neporecivosti (poruke) jedini zahtjev koji se ne može elegantno riješiti pomoću simetričnih kriptosustava. No, asimetrični kriptosustavi puno su pogodniji i za rješavanje zahtjeva integriteta i autentičnosti. S druge strane, zahtjev povjerljivosti (naročito kod velikih poruka) najčešće se rješava pomoću simetričnih kriptosustava, koji su puno brži i traže ključeve manjih veličina (za istu razinu sigurnosti) u odnosu na asimetrične kriptosustave. Kod zahtjeva povjerljivosti, asimetrični kriptosustavi se najčešće koriste samo za razmjenu simetričnog ključa (kojim će se kriptirati poruka i osigurati njena povjerljivost).

3. SIMETRIČNI I ASIMETRIČNI KRIPTOSUSTAVI

Do kraja 60-tih godina prošlog stoljeća glavna primjena kriptografije bila je u vojne i diplomatske svrhe, pa su pojedine države (ili čak organizacije) imale svoje specifične kriptosustave. No, tada je došlo do širokog razvoja međunarodnih financijskih transakcija, pa se pojavila potreba za kriptosustavima koje će moći koristiti korisnici širom svijeta, tj. pojavila se potreba uvođenja (međunarodnih) standarda u kriptografiji.

Na temelju programa i javnog natječaja za zaštitu računalnih i komunikacijskih podataka koji je 1972./73. inicirao američki National Bureau of Standard (NBS), 1976. je prihvaćen kao standard kriptosustav koji je dobio ime Data Encryption Standard (DES), a koristi 56-bitne ključeve. Taj je standard bio u širokoj upotrebi sve do kraja 20. stoljeća (iako se koristi i danas), ali je već početkom 90-tih godina postalo jasno da je samo pitanje vremena kad će DES postati nesiguran, što se prvi put javno pokazalo 1998. godine. Zato je 1997. godine National Institute of Standards and Technology (NIST), organizacija koja je naslijedila NBS, raspisala natječaj za kriptosustav koji će naslijediti DES. Kao privremeni standard određen je prošireni DES standard imena 3DES (trostruki DES), koji koristi 168-bitne ključeve. Nasljednik DES-a izabran je 2000. godine i dobio je ime Advanced Encryption Standard (AES), a koristi 128, 192, ili 256-bitne ključeve.

Navedeni kriptosustavi su simetrični kriptosustavi, tj.

koriste isti ključ i u procesu kriptiranja (enkripcije, šifriranja) i u procesu dekriptiranja (dekripcije, dešifriranja), što znači da je ključ poznat i pošiljatelju i primatelju poruke (i samo njima). No, taj simetrični ključ ima manu da se mora (na siguran način) razmijeniti među sudionicima u komunikaciji, što nije veliki problem kod zatvorenih sustava s malim brojem sudionika u komunikaciji, ali je problem kod današnjih otvorenih sustava s nepoznatim i velikim brojem sudionika. Zato su razvijeni asimetrični kriptosustavi (ili kriptosustavi s javnim ključem). Glavna ideja je da se konstruiraju

kriptosustavi kod kojih je na temelju poznavanja funkcije kriptiranja praktički nemoguće izračunati funkciju dekriptiranja. Svaki sudionik u komuniciranju ima svoj javni ključ, koji može biti poznat svima, i svoj tajni ključ, koji je poznat samo njemu. Kriptiranje se radi javnim ključem primatelja, a dekriptiranje tajnim ključem primatelja (kod digitalnog potpisa je drugačije!), tako da samo primatelj može pročitati poruku. Asimetrični kriptosustavi nisu zamjena za simetrične, već jedni druge nadopunjuju, čime se dobivaju hibridni kriptosustavi.

Može se dati ovakva usporedba između simetričnih kriptosustava (SK) i asimetričnih kriptosustava (AK):

sigurnost: kod AK, samo privatni ključ mora biti

tajan, a javni ključ se može slobodno distribuirati; kod SK, zajednički (simetrični) ključ mora biti poznat dvjema (ili više) sudionicima u komunikaciji; nije dokazano da su AK sigurni, ali isto vrijedi i za SK, osim u slučaju kada se simetrični ključ upotrebljava samo jedanput;

dugotrajnost ključa: kod AK, isti par ključeva se

može koristiti dugo vremena, a kod SK je poželjno mijenjati ključ kod svake sesije;

upravljanje ključevima (engl. key management): ako je n broj sudionika u međusobnoj komunikaciji, SK traži ukupno n * (n – 1) / 2 ključeva, pri čemu svaki sudionik mora kod sebe pamtiti (n – 1) ključ; kod AK, treba ukupno n javnih ključeva, koji se mogu slobodno pohraniti na nekom pristupačnom mjestu (bazi javnih ključeva), a svaki sudionik mora pamtiti samo svoj tajni ključ (u pravilu pamti i svoj javni ključ, da ne mora za njega pristupati bazi);

razmjena ključeva: kod AK se ne moraju

razmjenjivati ključevi između sudionika; razmjena ključeva kod SK je obavezna; budući da je to opasno, upravo se AK koristi za sigurnu razmjenu simetričnog ključa, čime se onda omogućava SK (zajedno je to hibridni kriptosustav);

efikasnost: AK su značajno sporiji od SK; npr. RSA

kriptosustav je oko 1000 puta sporiji od DES kriptosustava;

veličina ključeva: ključevi za AK su značajno veći

od ključeva za SK (za istu razinu sigurnosti); npr. privatni ključ u RSA mora imati barem 1024 bita, dok je kod većine SK 128 bitova dovoljno.

U nastavku su dati neki vrlo važni pojmovi kod primjene asimetričnih kriptosustava (primjenjuju se samostalno, ili zajedno sa simetričnim kriptosustavima).

Sažetak (hash, digest): za razliku od funkcije

kriptiranja, koja je matematički gledano injektivna funkcija, tj. funkcija koja dva različita X-a preslikava u dva različita Y-a, funkcija sažetka može preslikavati više X-eva u isti Y, što znači da nema inverznu funkciju. Koristi se kao pomoćno sredstvo, npr. kod spremanja hash-a lozinki (umjesto samih lozinki) u bazu podataka, kod digitalnog potpisa i dr.

Digitalna omotnica: njome se postiže povjerljivost poruke. Za to bi se mogli koristiti i samo simetrični

ključevi. No, budući da je razmjena nekriptiranih simetričnih ključeva opasna, pošiljatelj kreira novi simetrični ključ (samo za tu sesiju), pomoću tog ključa kriptira izvornu poruku, a onda simetrični ključ kriptira pomoću javnog ključa primatelja, te onda šalje oboje - poruku kriptiranu simetričnim ključem i kriptirani simetrični ključ. Primatelj prvo dekriptira kriptirani simetrični ključ (svojim tajnim ključem, što znači da samo on to može napraviti), a onda tako dobivenim

CASE29 69

simetričnim ključem dekriptira izvornu poruku. Navedeno je prikazano na slici 1.

Digitalni potpis: njime se postiže integritet i neporecivost poruke. Pošiljatelj uz izvornu

(nekriptiranu) poruku šalje i izvornu poruku kriptiranu pomoću svog tajnog ključa (suprotno od uobičajene sheme asimetričnog kriptiranja, npr. one kod digitalne omotnice!). Primatelj pomoću javnog ključa pošiljatelja dekriptira poruku i uspoređuje ju s izvornom. Budući da samo pošiljatelj zna svoj privatni ključ, osiguran je integritet i neporecivost poruke. Zapravo, u praksi se najčešće ne kriptira izvorna poruka, već sažetak (hash) izvorne poruke, a razlozi su (barem) sljedeći: sažetak je kraći od izvorne poruke, pa se brže kriptira/dekriptira (važno je, jer su asimetrični kriptosustavi spori), ukupna poruka je kraća, izvorna poruka se može isto kriptirati (što onda čini digitalni pečat). U ovoj varijanti primatelj uspoređuje dobiveni sažetak s onim koji sam izračunava, kako je prikazano na slici 2.

Digitalni pečat: njime se postiže povjerljivost, integritet i neporecivost poruke. Digitalni pečat je

kombinacija digitalne omotnice i digitalnog potpisa, tj. digitalni pečat je digitalno potpisana digitalna omotnica.

Digitalni certifikat: njime se postiže autentičnost poruke. Digitalni certifikat je (specijalna) poruka koja je

(najčešće) digitalno potpisana od certifikacijskog centra (engl. Certification Authority, CA), kome se po definiciji vjeruje. Ta (specijalna) poruka sadrži barem par podataka - identifikator i javni ključ pošiljatelja. U praksi certifikat obično sadrži i podatak o roku valjanosti, primijenjenim algoritmima za sažimanje i kriptiranje kod potpisivanja, i dr. Pomoću digitalnog certifikata primatelj može provjeriti da li je dobiveni (od nekog pošiljatelja) javni ključ jednak onome koji piše u digitalnom certifikatu, tj. da li je pošiljatelj autentičan (onaj kojim se predstavlja).

Slika 1. Digitalna omotnica; Izvor [8]

Slika 2. Digitalni potpis; Izvor [8]

70 CASE29

4. OPIS RSA KRIPTOSUSTAVA

Diffie-Hellmanov postupak za razmjenu tajnog ključa

Iako je RSA prvi kriptosustav s javnim ključem (objavljen 1977. godine), začetnicima kriptografije javnog ključa smatraju se Diffie i Hellman, koji su 1976. godine objavili postupak (protokol) za razmjenu tajnog (simetričnog) ključa. Njihov postupak, iako služi za sigurnu razmjenu simetričnog ključa (tj. kod njihovog postupka se ne radi o javnim i tajnim ključevima, odnosno asimetričnom kriptosustavu), dao je ključnu ideju za realizaciju kriptosustava s javnim ključem – ideju da se konstruiraju kriptosustavi kod kojih bi iz poznavanja funkcije kodiranja bilo praktički nemoguće (u nekom razumnom vremenu) izračunati funkciju dekodiranja. Tada bi funkcija kodiranja mogla biti javna.

Diffie-Hellman postupak za razmjenu ključeva zasnovan je na činjenici da je u nekim grupama potenciranje puno jednostavnije od logaritmiranja (problem diskretnog logaritma).

Kriptosustavi s javnim ključem i RSA kriptosustav

U kriptosustavu s javnim ključem svaki korisnik ima dva

ključa: javni EK i tajni DK (slova E i D označavaju

glavnu namjenu tih ključeva: Enkripcija i Dekripcija). Ako Ana želi poslati Branku poruku P, onda je ona

kodira pomoću Brankovog javnog ključa EBK i pošalje

Branku šifrat C:

),( EBKPEC .

Branko dekodira šifrat koristeći svoj tajni ključ DBK :

),( DBKCDP tj.

)),,(( DBEB KKPEDP .

Napomena: u engleskoj literaturi uobičajena imena za glavne sudionike u komunikaciju su Alice i Bob (kod nas Ana i Branko), a ti su likovi uvedeni upravo u prvom radu o RSA kriptosustavu.

RSA je prvi i najpoznatiji kriptosustav s javnim ključem, objavljen 1977. godine, a nazvan je po svojim tvorcima Ronaldu Rivestu, Adi Shamiru i Leonardu Adlemanu.

Njegova sigurnost je zasnovana prvenstveno na teškoći faktorizacije velikih prirodnih brojeva. No, otvoreno je pitanje je li razbijanje RSA kriptosustava, tj. određivanje

x iz poznavanja nxe mod ekvivalentno faktorizaciji od

n.

Postupak izgradnje RSA kriptosustava

1. Odaberu se dva tajna velika prosta broja p i q,

svaki veličine barem 512 bitova (a preporučljivo je i 1024).

2. Izračunava se umnožak n = p q.

3. Izračunava se umnožak (n) = (p – 1) (q – 1).

4. Odabere se broj e < (n) i relativno prost u

odnosu na (n),

tj. takav da je nzd (e, (n)) = 1.

5. Izračunava se broj d < (n) tako da bude:

e d 1 (mod (n)),

što se može napisati i kao:

e d k (n) + 1 (može se primijetiti da zato što su broj e i

umnožak e d relativno prosti u odnosu na (n),

automatski je i broj d relativno prost u odnosu

na (n)).

6. Brojevi e i n se obznanjuju i čine javni ključ.

7. Brojevi p, q, d su tajni, pri čemu je d tajni ključ (zajedno sa n, koji je javno poznat).

Kriptiranje se obavlja funkcijom kriptiranja:

,mod),(),( nPKPRSAKPEC e

EE

a dekriptiranje funkcijom dekriptiranja:

nPnnP

nCKCRSAKCDP

edde

d

DD

modmod)mod(

mod),(),( 1

.

U nastavku se pokazuje da je taj postupak korektan, tj. da je:

)(mod nPPed .

Zapravo, mora se primijetiti da je navedeni postupak korektan samo ako je veličina poruke P manja od n. Ako

je poruka P n (što je u pravilu često), onda se izvorna

poruka P razbija na poruke rPPP ,...,, 21 od kojih je

svaka manja od n, te se svaka zasebno kriptira i dekriptira.

Provjera korektnosti RSA kriptosustava

Treba pokazati da je:

)(modnPPed .

Budući da je:

e d k (n) + 1 = k (p – 1) (q – 1) + 1,

može se za one P koji nisu kongruentni s 0 (mod p), što znači da nisu višekratnici od p, koristiti mali Fermatov teorem (prikazan u prilogu) i dobiti:

)(mod)1(

)(

1) -(qk

1) - (p 1 1) -(q 1) - (pk 1) - (qk

pPP

PPPP ed

.

To je, također, trivijalno ispunjeno i kada je P višekratnik od p, jer je tada:

)(mod0 pP ,

pa općenito vrijedi:

)(mod pPPed.

Analogno vrijedi i za q, pa se iz (posebnog slučaja) kineskog teorema o ostatcima (prilog) dobiva:

)(mod

)(mod)(mod

nPP

qPPpPP

ed

eded

.

Neke praktične napomene vezane za RSA kriptosustav

Važna praktična pitanja su:

1. Kako dobiti dva velika prosta broja p i q? 2. Kako odabrati javni ključ e? 3. Kako izračunati tajni ključ d?

Odgovori mogu biti sljedeći:

1. Budući da je teškoća faktorizacije velikih prirodnih brojeva osnova za sigurnost RSA kriptosustava, ne možemo faktorizacijom naći dokazivo proste brojeve p i q. Zato se nalaze vjerojatno prosti brojevi, npr.

pomoću heurističkog ispitivanja po Miller-Rabinu

CASE29 71

(prikazano u prilozima A i B). Zbog sigurnosti je preporučljivo da p i q ne budu preblizu jedan drugome, da p - 1 i q - 1 imaju barem jedan veliki prosti faktor, ali ne zajednički, jer je poželjno da p - 1 i q - 1 nemaju velikih zajedničkih faktora.

2. Za javni ključ e nekad se preporučivalo uzeti broj 3, ali se pokazalo da nije dobro imati jako mali broj e, pa se danas preporučuje staviti

655371216 e , što je broj koji je i pogodan

za računanje. No, može ga se i generirati nekim (pseudo)slučajnim postupkom.

3. Tajni ključ d može se izračunati na temelju proširenog Euklidovog algoritma (prilog).

Neke druge metode za zasnivanje kriptosustava s javnim ključem

RSA kriptosustav spada u asimetrične kriptosustave čija je sigurnost zasnovana prvenstveno na teškoći faktorizacije velikih prirodnih brojeva. Drži se da je teškoća faktorizacije velikih prirodnih brojeva ekivalentna teškoći nalaženja "klasičnog" diskretnog logaritma, tako da su kriptosustavi koji primjenjuju jednu

ili drugu metodu u načelu isto sigurni (kod istih veličina ključeva). Primjer poznatog kriptosustava koji koristi metodu "klasičnog" diskretnog logaritma je kriptosustav ElGamal, nazvan po svom autoru (Taher ElGamal).

No, asimetrični kriptosustavi koji rade na temelju teškoće nalaženja diskretnog logaritma u grupi eliptičkih krivulja nad konačnim poljem K za istu sigurnost traže značajno manje ključeve. Takvi se kriptosustavi zovu kriptosustavi temeljeni na eliptičkim krivuljama (Elliptic Curve Cryptosystem, ECC). Procjenjuje se da su danas (oko 2010. godine) ekvivalentno sigurni RSA ključevi duljine 1369 bita i ECC ključevi duljine 146 bita (ECC su skoro 10 puta manji), a da će 2040. godine (zbog procijenjenog povećanja snage klasičnih, ne-kvantnih računala) ekvivalentno sigurni RSA i ECC ključevi biti duljine 3214 i 191 bita (ECC su skoro 17 puta manji). To je osobito važno kod onih primjena kod kojih je prostor za pohranu ključeva ograničen (npr. kod pametnih kartica). Treba napomenuti da su u Java 7 uvedene funkcije za kriptiranje pomoću eliptičkih krivulja.

5. KRIPTIRANJE PODATAKA U TRANZITU

Kriptiranje podataka koji su u tranzitu nije vezano samo za baze podataka i takvo se kriptiranje uglavnom koristilo i prije kriptiranja podataka koji stoje u bazi. Kada je riječ o Oracle bazi, postoje rješenja kriptiranja podataka u tranzitu koja su vezana uz Oracle bazu, ali postoje i rješenja nezavisna od Oracle baze. No, obje varijante kriptiranja podataka u tranzitu imaju isti cilj, zaštiti tri vrste paketa (podataka baze) koji se prenose mrežom:

1. paketi koji služe za inicijaciju sesije između klijenta i servera baze podataka;

2. paketi koje klijent šalje bazi, uključujući SQL naredbe;

3. paketi koje baza, kao odgovore, šalje klijentu.

Jasno je zašto se želi zaštiti 3.vrstu paketa, jer su to podaci, a i 2.vrstu paketa, SQL naredbe, jer se i u njima mogu nalaziti neki tajni podaci (npr. broj kreditne kartice u SQL upitu i sl.).

No, važno je zaštiti i 1.vrstu paketa (podaci za inicijaciju sesije), bez obzira što Oracle baza uvijek tokom logon procesa prenosi lozinku u kriptiranom obliku (bez obzira da li je promet mrežom kriptiran ili nije). Ako promet mrežom nije kriptiran, tokom postupka

identifikacije/autentikacije na Oracle bazu može se pojaviti jedna potencijalna ranjivost.

Postupak identifikacije/autentikacije (kod Oracle baze) pojednostavljeno ide tako da klijent prvo pošalje bazi korisničko ime. Baza na temelju korisničkog imena potraži u sistemskim tablicama hash vrijednost lozinke za tog korisnika (lozinka se nikada ne sprema u Oracle bazu, pa ni kriptirana). Baza generira slučajni ključ za novu sesiju, taj ključ kriptira pomoću hash vrijednosti lozinke (koristeći AES algoritam) i šalje klijentu tako kriptirani ključ sesije. Klijent dekriptira primljeni serverski ključ sesije, koristeći hash vrijednost lozinke koju je korisnik unio. Zatim klijent generira vlastiti (klijentski) ključ sesije, te uz pomoć oba ključa sesije (serverskog i klijentskog) kriptira lozinku (koristeći AES), te ju šalje serveru, zajedno s kriptiranim klijentskim ključem sesije (kojega isto kriptira pomoću hash vrijednost lozinke, koristeći AES). Server sada može dekriptirati klijentski ključ sesije, te uz pomoć njega i svog ključa sesije dekriptirati primljenu lozinku, izračunati njen hash i na kraju ga usporediti sa hash vrijednošću koja je spremljena u bazi. Ranjivost navedenog postupka sastoji se u tome da napadač koji na neki način sazna hash vrijednost lozinke iz baze može, osluškujući mrežu, dekriptirati serverski i klijentski ključ sesije, te onda dekriptirati i lozinku. Ako je promet mrežom kriptiran, te ranjivosti nema. Naravno, može se primijetiti da postoji značajna ranjivost baze ako netko nepozvan može saznati hash vrijednost lozinki iz baze.

Sam proces kriptiranja podataka u tranzitu može se raditi pomoću dva Oracle rješenja, koja se dobivaju samo uz opciju Advanced Security Options (ASO). Jedno je rješenje tzv. Network Data Encryption (NDE), a drugo se zasniva na Secure Socket Layer (SSL).

Preporuča se korištenje NDE rješenja, jer je jednostavnije od SSL varijante.

Osim ta dva Oracle rješenja, moguće je koristiti i nezavisna softverska ili hardverska rješenja, npr. različite varijante tuneliranja (jedna od njih je Secure Shell - SSH), Internet Security Protocol (IPSec), ili

hardverske akceleratore (koji, za razliku od softverskih rješenja, ne opterećuju procesore klijenta/servera), npr. mrežne kartice koje podržavaju enkripciju/dekripciju.

6. KRIPTIRANJE PODATAKA NA DISKOVIMA

Kriptiranje podataka koji nisu u tranzitu, a najčešće je riječ o podacima na diskovima, postalo je predmet velike pažnje zadnjih 10-tak godina. Naime, bez obzira na sve druge načine osiguravanja podataka u bazi, vidjelo se da su jako opasni oni slučajevi u kojima se ukradu podaci na diskovima, pa onda napadači imaju dovoljno vremena i mogućnosti da pristupe osjetljivim podacima i kada nemaju direktan pristup kroz bazu podataka. Podaci iz baze podataka mogu, ako nisu kriptirani, biti relativno lako dostupni i van sustava za upravljanje bazom podataka, npr. može se i sa običnim uređivačem teksta dobiti uvid u podatke, S druge strane, nije dovoljno da budu zaštićeni samo podaci koji se direktno nalaze u bazi podataka, već i podaci koji su nastali npr. backup-om tih podataka.

Poduzeća (ali i druge organizacije) danas pristupaju kriptiranju podataka na diskovima najčešće iz tri razloga (ili kombinacije tih razloga):

da bi spriječili lošu reputaciju koju dobiju nakon što se otkrije da su napadači otuđili osjetljive podatke;

72 CASE29

da izbjegnu ili smanje financijske troškove koje imaju zbog odšteta koje su dužne nadoknaditi oštećenim stranama;

da budu u skladu s različitim regulatornim propisima o zaštiti podataka, naročito zaštiti privatnih podataka.

Kriptiranju podataka na diskovima može se pristupiti na tri različita načina:

"ručno" kriptiranje se radi kroz aplikaciju/aplikacije, programiranjem; dobra strana takvog načina kriptiranja je da je vrlo fleksibilno – programiranjem se može postići manje-više sve što se želi; loše strane su brojne; kriptiranje kroz aplikaciju ne može se izvesti na brzinu, jer su aplikacije kompleksne i treba puno toga u njima mijenjati; kriptiranje uvijek pogoršava performanse, a kriptiranje vlastitim programiranjem najčešće je najsporije; kod kriptiranja vlastitim programiranjem često se zaboravi neko područje (neka aplikacija), pa onda napadač može iskoristiti tu slabost i kroz nju dobiti nekriptirane podatke; na kraju, najveća mana kriptiranja vlastitim programiranjem je da se ne može na adekvatan način zaštiti ključeve za kriptiranje;

"automatsko" kriptiranje kroz sustav za upravljanje bazom podataka; bolje je od prethodne varijante; SUBP sustavi danas imaju dosta napredne mogućnosti "transparentnog" kriptiranja, kod kojega aplikacija niti "ne zna" da su podaci kriptirani; no, za razliku od programiranja kroz aplikaciju, "transparentno" kriptiranje ne pomaže kod sakrivanja podataka od onih koji imaju pristup bazi;

"automatsko" kriptiranje na razini diskovnog sustava; u ovom slučaju ne kriptiraju se samo podaci u bazi, već svi (željeni) podaci na diskovima, bili u bazi podataka ili ne; ovaj način kriptiranja podataka možda je najtransparentniji (za aplikaciju) i najjednostavniji; u nastavku se ovaj način kriptiranja ne prikazuje, već se prikazuju samo prva dva načina kriptiranja, koja su vezana za bazu podataka.

Kod kriptiranja podataka u bazi podataka, bilo programiranjem ili "automatski" kroz SUBP, postoje različite varijante korištenja ključeva za kriptiranje (napomena: u načelu se uvijek radi o simetričnom kriptiranju):

postoji jedan ključ za kriptiranje podataka u cijeloj bazi podataka;

postoji jedan ključ za svaku tablicu baze podataka (ili neki drugi dio baze podataka, npr. tablespace baze podataka);

postoji jedan ključ za svaki stupac koji se kriptira; postoji jedan ključ za svaki redak koji se kriptira; različite kombinacije prethodnog.

Također, vrlo je važno (ako ne i najvažnije) pitanje – gdje se sprema ključ (ključevi):

u bazu podataka; u datoteke izvan baze podataka (na serveru baze

podataka, aplikacijskom serveru ili klijentu): u programski kod aplikacije; iako ovo rješenje

izgleda primamljivo, ono je najlošije, jer postoje različiti načini dekodiranja (disasembliranja) programa i dolaska do ključa koji je sakriven u programu.

7. KRIPTIRANJE PODATAKA POMOĆU PAKETA DBMS_CRYPTO

Kako je već prije navedeno, "ručno" kriptiranje (kroz aplikaciju, programiranjem) podataka u bazi vrlo je zahtjevno i u načelu se ne preporučuje. Traži puno vremena za izvedbu, ima najlošije performanse, omogućuje ostavljanje "rupa" u kriptiranju, a najveći je problem kod njega – kako upravljati ključevima za kriptiranje. Bez obzira na te mane, u Oracle bazi nekada se mora koristiti "ručno" kriptiranje, a najvažnija dva slučaja jesu:

na raspolaganju je samo Standard edicija baze, koja nema mogućnosti za "transparentno" kriptiranje (koje je dodatna opcija u Enterprise ediciji);

želi se kriptirati (neke) podatke i korisnicima baze - "transparentno" kriptiranje ne može sakriti podatke korisnicima baze.

Za "ručno" kriptiranje koristi se paket (na bazi) DBMS_CRYPTO.

DBMS_CRYPTO ima sljedeće mogućnosti:

podržava kriptografske algoritme: DES, 3DES, 3DES_2KEY, AES, RC4; ako nema nekog posebnog razloga, preporučljivo je koristiti algoritam AES, koji omogućava kriptiranje sa 128, 192 ili 256-bitnim ključevima;

kriptografski hash algoritmi: MD5, SHA-1, MD4; MAC algoritmi (algoritmi za autentikaciju poruka)

HMAC_MD5, HMAC_SH1; kriptografski generatori pseudoslučajnih brojeva u

formatu RAW, NUMBER, BINARY_INTEGER; kriptiranje blokova podataka: kriptiranje

ulančavanjem blokova (Cipher Block Chaining, CBC) gdje se prethodni kriptirani blok zbraja (XOR) sa novim blokom prije kriptiranja, dvije varijante koje su slične prethodnom - CFB (Cipher Feedback Chaining) i OFB (Output Feedback Chaining), te varijanta koju bi trebalo izbjegavati – ECB (Electronic Notebook), jer kod nje isti ulaz uvijek daje isti izlaz, pa se na temelju statističke analize teksta može pokušati dekriptirati poruka;

ispunjavanje (padding) podataka nulama ili pomoću metode PBCS5 (preporučljivo).

U nastavku slijedi prikaz korištenja paketa DBMS_CRYPTO, koji uključuje i usporedbu performansi bez / sa kriptiranjem. Prvo se radi pomoćni paket:

create or replace package

encryption_wrapper as

function encrypt (p_string in

varchar2, p_key in varchar2)

return raw;

function decrypt (p_raw in raw,

p_key in varchar2)

return varchar2;

end;

create or replace package body

encryption_wrapper as

g_encrypt_typ constant

PLS_INTEGER default

DBMS_CRYPTO.ENCRYPT_AES256

+ DBMS_CRYPTO.CHAIN_CBC

+ DBMS_CRYPTO.PAD_PKCS5;

function padkey (p_key in

varchar2)

return raw is

begin

CASE29 73

return

utl_raw.cast_to_raw(rpad(p_key,32));

end;

function encrypt (p_string in

varchar2, p_key in varchar2)

return raw

is

begin

return

dbms_crypto.encrypt

(src =>

UTL_I18N.STRING_TO_RAW (p_string,

'AL32UTF8'),

typ => g_encrypt_typ,

key => padkey (p_key));

end;

function decrypt (p_raw in raw,

p_key in varchar2)

return varchar2

is

begin

return utl_i18n.raw_to_char (

dbms_crypto.decrypt

(src => p_raw,

typ => g_encrypt_typ,

key => padkey (p_key)),

'AL32UTF8');

end;

end;

Prethodni paket koristi se za kriptiranje tablice T (koristi se i pomoćna tablica STAGE, iz koje se puni pomoćna tablica T):

create table stage as

select object_name from

all_objects;

create table t (

last_name varchar2(30),

encrypted_name raw(32)); -- ovaj

će se stupac kriptirati

Ovo je primjer punjenja tablice T iz tablice STAGE bez kriptiranja, metodom redak po redak, koja je najsporija:

declare

l_start number :=

dbms_utility.get_cpu_time;

begin

for x in (select object_name from

stage) loop

insert into t (last_name)

values ( x.object_name );

end loop;

dbms_output.put_line

((dbms_utility.get_cpu_time -

l_start) || ' hsecs' );

end;

431 hsecs (= 4,31 sekundi rada CPU-

a).

Slijedi primjer punjenja

tablice T iz tablice STAGE sa

kriptiranjem:

truncate table t;

declare

l_start number :=

dbms_utility.get_cpu_time;

begin

for x in (select object_name from

stage) loop

insert into t (encrypted_name)

values (

encryption_wrapper.encrypt

(x.object_name, 'Secret

Key Secret Key Secret Key'));

end loop;

dbms_output.put_line

((dbms_utility.get_cpu_time -

l_start) || ' hsecs' );

end;

2502 hsecs

Vidi se da je INSERT sa kriptiranjem oko 6 puta sporiji od INSERT-a bez kriptiranja. Daleko veće razlike, na štetu kriptiranja, dobile bi se kada bi se unos podataka radio masovnom (bulk) metodom, tj. više redaka odjednom. Slično kao INSERT ponašaju se i UPDATE i SELECT naredbe. Jedino DELETE ne ovisi o (ne)kriptiranju.

8. PROBLEMATIKA KLJUČEVA I ORACLE WALLET

Kako je već prije navedeno, jedan od najvećih problema kod kriptiranja podataka u bazi je – gdje spremiti ključ(eve) za kriptiranje. Ključ se može staviti npr. u programe, ali (kako je već navedeno) znalcima je relativno lako doći do ključeva skrivenih u programu. Moguće ih je staviti u bazu podataka, no onda onaj koji ukrade bazu podataka, ukrade i ključeve. Moguće ih je staviti u datoteke izvan baze podataka. No onda te datoteke moraju biti kriptirane, a slijedi pitanje gdje držati ključ za kriptiranje tih datoteka, itd. Također, treba napomenuti da je rješenje po kojemu prije pristupa podacima korisnik (na neki način) predaje ključeve, vrlo nepraktično, osim ako se koristi hardverski modul za sigurnost (Hardware Security Module, HSM).

Osim pitanja gdje spremiti ključ(eve), postavljaju se i neka druga praktična pitanja. Poznato je da ključeve za kriptiranje treba svako toliko mijenjati. No, ako imamo backup(e) podataka koji su kriptirani starim ključem(ključevima), onda imamo potrebu čuvanja tog starog ključa(ključeva).

Uglavnom, vidi se da problem upravljanja ključevima za kriptiranje nije jednostavno riješiti. Oracle u Enterprise ediciji, sa ASO opcijom (od verzije 11.2.0.4 to se može koristiti i u Standard ediciji), nudi jedno rješenje koje naziva Oracle Wallet (novčanik). Wallet je datoteka izvan baze (zapravo, može biti više datoteka, tj. više walleta) koja sadrži ključeve za kriptiranje (i dekriptiranje, jer je riječ o simetričnim algoritmima), a sadržaj te datoteke je kriptiran lozinkom. Lozinka se zadaje prilikom kreiranja walleta, ali se može naknadno

74 CASE29

mijenjati. Prije nego se otvori baza podataka (iako može i kasnije), administrator baze podataka (ili netko drugi koji zna lozinku) otvori wallet, a onda baza podataka može koristiti ključeve koji su pohranjeni u wallet-u za kriptiranje/dekriptiranje podataka u bazi. Moguće je koristiti i tzv. auto-login wallet, koji se sam pokrene kod startanja baze. Iako može izgledati kako takav auto-login način rada nema smisla, on ima smisla u onim slučajevima kada netko može ukrasti podatke ali ne i server, jer auto-login način rada funkcionira samo na istovjetnom serveru na kojem je instaliran. Postoji i treći način korištenja walleta, koji je zapravo i najsigurniji, a to je da se wallet nalazi na posebnom HSM modulu. HSM modul, osim sigurnosti, može povećati i performanse, jer on može preuzeti na sebe kriptiranje/dekriptiranje podataka i time odteretititi bazu podataka.

No, najčešći način korištenja Oracle Walleta je pomoću lozinke, što se u nastavku ukratko prikazuje. Kao prvo, u Oracle SQLNET.ORA parametarskoj datoteci mora biti zapisano gdje se wallet nalazi, npr.:

ENCRYPTION_WALLET_LOCATION=

(SOURCE=(METHOD=FILE)(METHOD_DATA=

(DIRECTORY=/home/ora11gr2/network/a

dmin/)

))

Nakon toga se kreira wallet, sa:

ALTER SYSTEM SET ENCRYPTION KEY

IDENTIFIED BY

lozinka_za_wallet;

Kada se starta baza, nakon otvaranja baze mora se pokrenuti otvaranje walleta:

ALTER SYSTEM SET ENCRYPTION WALLET

OPEN

IDENTIFIED BY

lozinka_za_wallet;

Ako se želi privremeno zatvoriti wallet, to se može napraviti sa:

ALTER SYSTEM SET ENCRYPTION

WALLET CLOSE

IDENTIFIED BY

lozinka_za_wallet;

9. KRIPTIRANJE PODATAKA POMOĆU TDE COLUMN ENCRYPTION

Kao i Oracle Wallet, i Transparent Data Encryption (TDE) Column Security se može koristiti samo u Enterprise ediciji baze, pri čemu je potrebna i ASO opcija. TDE Column Security služi za zaštitu određenih stupaca tablica podataka na disku, u slučaju da netko neovlašteno dođe do tih podataka izvan baze, ali su ti stupci za korisnike baze uvijek transparentno dekriptirani. Treba napomenuti da stupci nisu kriptirani samo u tablicama, već i REDO, UNDO i TEMP pomoćnim strukturama podataka na disku (naravno, i u backup podacima).

Može se kreirati novi kriptirani stupac postojeće tablice, ili kriptirati postojeći stupac, ili kreirati potpuno nova tablica sa kriptiranim stupcem, što se prikazuje u nastavku:

CREATE TABLE t (

c1 varchar2(30),

c2 varchar2(30) ENCRYPT

);

Ako se unese redak u tu tablicu i sa SELECT pogleda sadržaj, činit će se kao da podaci nisu kriptirani – zato jer ih baza sama transparentno dekriptira:

INSERT INTO t VALUES

( '***ovo NIJE kriptirano***',

'***ovo JE kriptirano***');

SELECT * from t;

C1 C2

------------------------------ ------

------------------------

***ovo NIJE kriptirano*** ***ovo JE

kriptirano***

Ako se privremeno zatvori wallet i onda pokuša unijeti novi redak sa oba stupca, vidjet će se da se tada ne može unijeti kriptirani stupac, ali može se unijeti nekriptirani stupac i poslati NULL za kriptirani stupac (jer je kod definicije stupaca omogućena NULL vrijednost). Također, ako je wallet zatvoren ne može se dati SELECT nad kriptiranim stupcima, ali može nad nekriptiranim:

ALTER SYSTEM SET ENCRYPTION WALLET

CLOSE

IDENTIFIED BY lozinka_za_wallet;

INSERT INTO t VALUES

( '***ovo NIJE kriptirano***',

'***ovo JE kriptirano***');

*

ERROR at line 1:

ORA-28365: wallet is not open

INSERT INTO t VALUES

( '***ovo NIJE kriptirano***',

NULL);

SELECT c2 FROM t;

*

ERROR at line 1:

ORA-28365: wallet is not open

SELECT c1 FROM t;

C1

------------------------------

***ovo NIJE kriptirano***

***ovo NIJE kriptirano***

Kada se navodi ključna riječ ENCRYPT, postoje tri opcije:

USING 'algorithm': može se birati AES ili DES enkripcija; u pravilu nema smisla koristiti stari DES algoritam; default je 192-bitni AES (može se birati i 128 ili 256);

IDENTIFIED BY password: time se može specificirati određeni ključ za enkripciju stupca (i isto sprema u wallet), a inače se ključ sam generira, za svaki stupac posebno; specificirani ključ je potreban npr. onda kada kriptirane podatke treba seliti na drugu bazu pomoću eksterne tablice;

SALT ili NO SALT: default je SALT, tj. da baza sama doda određene slučajne (random) bajtove na početku kriptiranih podataka; time je enkripcija jača, jer istovjetni izvorni podaci nisu više istovjetni nakon kriptiranja, pa je kriptoanaliza otežana; korištenje NO SALT treba ograničiti samo za stupce koji se indeksiraju (indeksirani stupci moraju imati uvijek iste kriptirane podatke za iste izvorne podatke).

CASE29 75

TDE Column Security nije bez mana.

Jedna mana su smanjene perfomanse u odnosu na bazu bez kriptiranja. To smanjenje performansi je zavisno od toga što se radi. No, uvijek je brže od rješenja koje se može dobiti programiranjem pomoću paketa DBMS_CRYPTO. Jedan od razloga za gubljenje performansi je i taj što se podaci čuvaju u kriptiranom obliku i u memoriji, tj. u SGA strukturi baze (no, prednost toga je da netko tko bi mogao pristupiti tom dijelu memorije ne bi vidio smislene podatke).

Drugo, zbog potrebe da se kriptirani podaci zaokruže na višekratnik od 16 bajtova, a i zbog dodavanja SALT podataka, TDE Column Security kriptiranje troši i više prostora na disku (i u SGA dijelu memorije).

TDE Column Security ima i neka ograničenja:

ako kriptirani stupac ima indeks, taj indeks isto mora biti kriptiran (inače kriptiranje gubi smisao), ali onda kriptiranje ne može koristiti SALT opciju, jer indeksirani stupci moraju imati uvijek iste kriptirane podatke za iste izvorne podatke;

kriptirani indeksi se realno mogu koristiti samo za pretragu određene vrijednosti, ali ne i za pretragu raspona vrijednosti, jer kriptirani podaci više nemaju smisleni raspon;

kriptirani stupci se ne mogu koristiti za funkcijske indekse;

nad kriptiranim stupcima ne mogu se raditi vanjski ključevi.

Kako će se vidjeti u nastavku, TDE Tablespace Security nema gore navedene restrikcije, a i performanse su generalno puno bolje u odnosu na TDE Column Security.

10. KRIPTIRANJE PODATAKA POMOĆU TDE TABLESPACE ENCRYPTION

Kao i TDE Column Security, tako se i TDE Tablespace Security može koristiti samo u Enterprise ediciji baze, pri čemu je potrebna i ASO opcija. TDE Tablespace Security po prvi put je uveden u Oracle bazi 11.1. Kako samo ime kaže, ovdje se ne kriptira samo određeni stupac, već cijeli tablespace.

Za razliku od TDE Column Security, kod TDE Tablespace Security nije moguće kriptirati postojeću tablicu ili postojeći tablespace, već je potrebno kreirati novi kriptirani tablespace i onda u njega kopirati postojeće tablice koje želimo kriptirati. Kreiranje kriptiranog tablespace-a radi se sa:

CREATE TABLESPACE

kriptirani_tablespace

DATAFILE ...

ENCRYPTION DEFAULT STORAGE

(ENCRYPT);

Kao i kod TDE Column Security, i ovdje je moguće odabrati algoritam za enkripciju, a on može biti 3DES168, AES128, AES192 ili AES256. Default je AES128, a ne AES192 kao kod TDE Column Security, jer je ovdje količina podataka koja se kriptira/dekriptira puno veća - cijeli tablespace, a ne pojedini stupac/stupci.

Svaka tablica koja se kreira u kriptiranom tablespace-u bit će u cijelosti kriptirana. Kriptiranje se radi na razini bloka tablice, a ne retka ili stupca, pa nema potrebe za

zaokruživanjem podataka na višekratnik od 16 bajtova, jer je blok podataka sam po sebi višekratnik od 16 bajtova. Također, budući da je svaki blok podataka jedinstven, nije potreban SALT podatak. Rezultat je taj da TDE Tablespace Security ne zauzima dodatni prostor na disku. Dalje, TDE Tablespace Security kriptira podatke prije slanja podataka iz SGA na disk, odnosno dekriptira ih u obrnutom smjeru. To znači da su podaci u SGA u nekriptiranom obliku, što predstavlja potencijalnu ranjivost u slučaju da netko neovlašten može pristupiti SGA području (no, ta je ranjivost samo teoretska, jer takav vjerojatno lako može pristupiti i drugim dijelovima baze, pa i preuzeti DBA prava), ali je prednost u tome da se čitanje/upis u SGA radi brzo.

Za razliku od podataka u SGA, podaci u REDO, UNDO i TEMP pomoćnim strukturama na disku su kriptirani (isto kao i kod TDE Column Security). No, treba uzeti u obzir da nakon kopiranja nekriptirane tablice iz nekriptiranog tablespace-a u kriptirani tablespace, te brisanja nekriptirane tablice, nije sigurno da više nema nekriptiranih podataka (te tablice). Naime, ti podaci ostaju određeno vrijeme u REDO, UNDO i TEMP pomoćnim strukturama. Naravno, ostaju i u backup-iranim podacima.

11. ZAKLJUČAK

Kriptiranje podataka važno je zbog očuvanja privatnosti, integriteta i autentičnosti poruka (informacija), te zbog osiguranja neporecivosti slanja poruke.

Za kriptiranje se koriste simetrični i asimetrični kriptosustavi. Simetrični kriptosustavi su puno brži (oko 1000 puta), ali asimetrični kriptosustavi omogućavaju razmjenu ključeva među velikim brojem sudionika.

Važno je kriptirati podatke u tranzitu, ali i podatke koji se nalaze na medijima (najčešće diskovima). Podatke na medijima može se kriptirati nezavisno od baze podataka, ili ih se može kriptirati unutar baze podataka.

Oracle baza direktno omogućava simetrično kriptiranje. Kriptografske mogućnosti različitih edicija Oracle baze su sljedeće:

Standard edicija baze ima kriptiranje pomoću paketa DBMS_CRYPTO (programiranjem); njime se može postići sve, pa i sakrivanje podataka od (nekih) korisnika u bazi, ali uz lošije performanse i uz otvoreni problem spremanja ključeva za kriptiranje;

Enterprise edicija sa dodatnom opcijom Advanced Security ima transparentno kriptiranje podataka (TDE); TDE ne služi za sakrivanje podataka od legalnih korisnika baze, već samo za zaštitu podataka u slučaju krađe cijelog računala ili sustava za pohranu podataka; ASO opcija omogućava i dvije varijante kriptiranje podataka u tranzitu - jedno je rješenje tzv. Network Data Encryption (NDE), a drugo se zasniva na Secure Socket Layer (SSL).

Nažalost, značajna je razlika u cijeni između Standard edicije i Enterprise edicije sa dodatnom opcijom ASO. S druge strane, činjenica je da se vlastitim programiranjem u Standard ediciji vrlo teško može postići sigurnost ključa (ili više ključeva) koju ima skuplja varijanta. No, uvijek postoji i mogućnost korištenja transparentnog kriptiranja na razini diskovnog sustava.

Literatura:

1 Bača, M. (2004): Uvod u računalnu sigurnost, Narodne novine, Zagreb

76 CASE29

2 Ben-Natan, R. (2009): HOWTO Secure and Audit Oracle 10g and 11g, Auerbach Publications

3 Budin, L., Golub, M., Jakobović, D., Jelenković, L. (2010): Operacijski sustavi, Element, Zagreb

4 Dujella, A., Maretić, M. (2007): Kriptografija, Element, Zagreb

5 Knox, D. C. (2004): Effective Oracle Database 10g Security by Design, McGraw-Hill

6 Kyte, T. (2009): Expert Oracle Database Architecture, Apress

7 Mollin, R. A. (2007): An Introduction to Cryptography, Chapman & Hall/CRC (Taylor & Francis Group), Boca Raton

8 Žagar, M. (2008): Otvoreno računarstvo – Sigurnost (prezentacijski materijali), FER, Zagreb

9 Žubrinić, D. (2002): Diskretna matematika, Element, Zagreb

Oracle priručnici za bazu 12c Release 2 (2016.):

10 Advanced Security Administrator's Guide

11 Database Security Guide

12 Enterprise User Security Administrator's Guide

Podaci o autoru:

Zlatko Sirotić, univ.spec.inf.

ISTRA TECH d.o.o., Pula

e-mail: zlatko.sirotic@istratech.hr

Autor radi više od 30 godina na informatičkim poslovima, uglavnom u poduzeću ISTRA TECH d.o.o., Pula (ISTRA TECH je novo ime poduzeća Istra informatički inženjering, osnovanog prije 27 godina).

Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi više od 20 godina.

Objavljivao je stručne radove na kongresima / konferencijama CASE, KOM, HrOUG, JavaCro, "Hotelska kuća", u časopisima "Mreža", "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješenja objavljivana su na web stranicama firmi Oracle i Quest (danas dio firme Dell).

Na Odjelu za informatičko-komunikacijske tehnologije Sveučilišta Juraj Dobrila u Puli sudjeluje (od početka osnivanja odjela) kao vanjski suradnik na kolegijima Baze podataka 2 i Informatički praktikum 1.

PRILOG: Neki matematički pojmovi vezani za RSA kriptosustav

Djeljivost brojeva

Neka su a, d Z. Kaže se da d dijeli a ako je a različito od 0 i ako je d višekratnik od a. Tu činjenicu (da d dijeli a) može se izraziti i na ove načine:

da (d je djelitelj od a; ako d = 1 ili a, zove se trivijalni djelitelj, inače se zove faktor)

a = k d (a je višekratnik od d).

Relacija dijeli je refleksivna (aa, tj. svaki broj dijeli sebe samoga), antisimetrična (ako su a i b različiti i ab, ne može biti

da ba) i tranzitivna (ako ab i bc, onda ac).

Teorem dijeljenja

Neka su zadani a Z i b N. Onda postoje jedinstveni brojevi q Z i r 0, …, b -1 takvi da je:

a = q b + r (q je količnik ili kvocijent, r je ostatak ili reziduum).

Činjenica da je r ostatak dijeljenja a sa b može se napisati i ovako:

r = a mod b.

Najveći zajednički djelitelj, relativno prosti brojevi

Ako su a, b, d Z i vrijedi da i db tada je d zajednički djelitelj od a i b. Ako je barem jedan od brojeva a, b različit od nule, tada postoji njihov najveći zajednički djelitelj (najveća zajednička mjera). Da je d najveći zajednički djelitelj brojeva a i b, piše se ovako:

d = nzd (a, b) (druga varijanta: d = Nzm (a, b) ).

Ako je nzd (a, b) = 1, kaže se da su a i b relativno prosti.

Euklidov algoritam i prošireni Euklidov algoritam

Euklidov algoritam opisan je u Euklidovom djelu Elementi (4. stoljeće p.n.e.). Uobičajeno se koristi za brzo nalaženje najvećeg zajedničkog djelitelja d brojeva a i b.

No, Euklidov algoritam daje i opis efektivnog postupka kojim se može doći do brojeva x, y, c koji zadovoljavaju diofantsku jednadžbu oblika:

a x + b y = c (a i b su zadani, x, y, c se nalaze).

CASE29 77

Ta jednadžba ima rješenje (koje nije jednoznačno, već postoji beskonačno mnogo rješenja) ako i samo ako je minimalno rješenje za c jednako nzd (a, b). Tzv. prošireni Euklidov algoritam koristi se da se, uz nzd (a, b), nađu i brojevi x i y koji zadovoljavaju navedenu jednadžbu.

Prosti brojevi (prim-brojevi) i osnovni teorem aritmetike

Prosti brojevi su prirodni brojevi veći od 1 koji su djeljivi samo sa 1 i samim sobom, tj. nemaju faktore. Brojevi koji nisu prosti zovu se složeni brojevi (i imaju faktore).

Osnovni teorem aritmetike kaže da se svaki prirodni broj a > 2 može prikazati na jedinstven način kao umnožak potencija svojih prostih djelitelja, pri čemu su prosti djelitelji poredani po veličini (manji lijevo):

....21

21ke

k

eepppa

Ako je broj a složen, to se zove rastav ili faktorizacija broja a na proste faktore.

Prostih brojeva ima beskonačno mnogo (dokaz je dat u Euklidovim Elementima). Broj prostih brojeva koji su manji ili

jednaki broju x uobičajeno se označava sa (x). Vrijedi:

(x) x / ln x, kad x .

Iz toga proizlazi da je vjerojatnost P da neki slučajno izabrani veliki broj n bude prosti:

P (n je prosti broj) (n / ln n) / n = 1 / ln n.

Ekvivalentnost po modulu (kongruencija po modulu)

Kaže se da su brojevi a, b Z ekvivalenti po modulu m (ili kongruentni po modulu m, ili kongruentni modulo m) ako je njihova razlika djeljiva sa m, tj. ako vrijedi:

m(a – b) (ili a – b = k m).

Tada se piše:

a b (mod m) (čita se: a je ekvivalentan (kongruentan) b po modulu m).

Može se pokazati da su tada (i samo tada) ostatci dijeljenja a sa m, odnosno b sa m jednaki:

a b (mod m) a mod m = b mod m.

Relacija kongruencija po modulu m je refleksivna, simetrična i tranzitivna.

Eulerova (phi) funkcija

Funkcija : N N koja prirodnom broju n pridružuje broj prirodnih brojeva koji su < n i relativno prosti sa n zove se

Eulerova funkcija. Definira se da je (1) = 1.

Ako je n složeni broj, koji ima rastav na proste faktore ,,...,, 21 kppp može se pokazati da je:

./11.../11/11)( 21 kpppnn

Posebno za slučaj kada je n umnožak dva prosta broja p i q (n = p q), vrijedi:

(n) = n (1 – 1/ p) (1 – 1/ q) = p q (1 – 1/ p) (1 – 1/ q) = (p – 1) (q – 1).

Posebno za slučaj kada je n prosti broj p, vrijedi

(p) = p – 1.

Eulerova kongruencija (teorem)

Ako su a i n relativno prosti prirodni brojevi, onda je:

.mod1)( na n

Mali Fermatov teorem

Za poseban slučaj Eulerove kongruencije kada je n prosti broj p, pa je (p) = p – 1, vrijedi:

pa p mod11 (za svaki a N koji nije višekratnik od p).

Drugi oblik Fermatova teorema vrijedi i ako je a višekratnik od p:

paa p mod (za svaki a N).

Pseudoprosti brojevi

Mali Fermatov teorem može poslužiti (i) kada se treba generirati slučajni veliki broj za koji se sa velikom vjerojatnošću može tvrditi da je prosti broj (ako je generirani broj mali, lako se može dokazati da li je prosti, postupkom rastava na proste faktore; no, rastav velikih brojeva na proste faktore je složen i na teškoći tog rastava se i zasniva RSA algoritam).

Generira se slučajni veliki neparni broj n i gleda se da li taj broj zadovoljava mali Fermatov teorem za neki slučajno odabrani broj a (koji može biti relativno mali), tj. gleda se da li vrijedi:

naan mod .

Ako gornje ne vrijedi, n sigurno nije prosti broj. Tada se može tražiti dalje, u okolini broja n (npr. tako da se n poveća za 2, jer nijedan paran broj osim 2 nije prosti).

78 CASE29

Ako gornje vrijedi, to ne znači da je n sigurno prosti broj! Naime, postoje i pseudoprosti brojevi, za koje isto vrijedi mali

Fermatov teorem za neke baze a. Može se pokazati da za svaku bazu a 2 postoji čak beskonačno mnogo pseudoprostih brojeva. Zbog toga se testiranje prostosti ne radi samo s jednom bazom a, nego se generira veći broj baza (što veći broj baza, to je veća vjerojatnost da je izabrani broj n prosti). Ako provjere sa svim bazama zadovoljavaju mali Fermatov teorem, velika je vjerojatnost da je broj n prosti. Nažalost, postoje i posebni pseudoprosti brojevi, zvani Charmichaelovi brojevi.

Charmichaelovi brojevi i heurističko ispitivanje po Miller-Rabinu

Charmichaelovi brojevi su brojevi koji su pseudoprosti u svakoj bazi a, tj. vrijedi:

CaaC mod za svaki a (C je ovdje oznaka za Charmichaelov broj),

odnosno vrijedi:

Ca 1-C mod1 za svaki a koji je relativno prost sa Charmichaelovim brojem.

Korseltov kriterij kaže da je n Carmichaelov ako i samo ako je n složen, kvadratno slobodan (što znači da je 1 najveći kvadrat koji dijeli n, odnosno eksponenti svih prostih faktora od n su jednaki 1) i za svaki prosti faktor p od n vrijedi da p – 1 dijeli n – 1. Može se pokazati da odavde neposredno slijedi da n mora biti produkt od barem tri različita prosta broja.

Zbog toga što postoje Carmichaelovi brojevi, testiranje prostosti sa različitim bazama a ne može biti dovoljno sigurno.

Naime, ako se slučajno naiđe na Carmichaelov broj (istina, vjerojatnost za to je mala, jer iako Carmichaelovih brojeva ima beskonačno mnogo, oni su puno rjeđi od prostih brojeva), onda će testiranje broja C (Carmichaelov broj) u svakoj bazi a pokazati da je zadovoljen Fermatov teorem.

Zbog toga se, osim testiranja na Fermatov teorem sa različitim bazama, radi još jedno testiranje. Gleda se da li za generirani broj n postoji x različit od +1 i –1 koji zadovoljava jednadžbu:

nx2 mod1 (x je različito od +1 i –1).

Ako postoji takav x, tada se kaže da je x netrivijalni drugi korijen od 1 mod n i tada je n sigurno složen broj. U suprotnom je n možda prosti broj (nije sigurno).

Heurističko ispitivanje po Miller-Rabinu zasniva se upravo na navedena dva testa, tj. generirani broj n je sigurno složen ako:

za neku odabranu bazu a (u više iteracija) nije zadovoljen Fermatov teorem

ili postoji netrivijalni drugi korijen od (1 mod n).

U suprotnom se sa velikom vjerojatnošću može tvrditi da je generirani broj n prosti.

Kineski teorem o ostatcima

Kineski teorem o ostacima (engl. Chinese Remainder Theorem - CRT) govori o rješenju sustava linearnih kongruencija. Ime mu se vezuje uz kineskog matematičara iz prvog stoljeća Sun Tzua.

Neka su rmmm ,...,, 21 u parovima relativno prosti prirodni brojevi, te neka su raaa ,...,, 21 cijeli brojevi. Tada sustav

kongruencija:

rr21 maxmaxmax mod...,,mod,mod 21

ima rješenja.

Ako je 0x jedno rješenje, onda su sva rješenja dana sa:

....mod 20 r1 mmmxx

Za poseban slučaj, kada su p i q prosti i kada su svi ia jednaki a, vrijedi:

x a (mod p) x a (mod q) x a (mod p q)

što se može koristiti u dokazu korektnosti RSA algoritma.

Conference Net@inovativno rješenje za

upravljanje organizacijom konferencija integrirano s društvenim mrežama i dostupno na uređajima upravljanim dodirom

www.conferenceatnet.com

CITUS d.o.o.Dragutina Golika 63, Zagreb

http://www.citus.hrcitus@citus.hr

eMotiondetection

Interactive Motion and gesture controlled

MicrosoftKinect PersonRecog