Wildfly Swarm

Wildfly Swarm [2] je produkt zelo razˇsirjenega aplikacijskega streˇznika Wil-dfly (predhodno poznan pod imenom Jboss). Na trg je priˇsel maja 2015 in je razmeroma mlado in (ˇse) nerazˇsirjeno ogrodje. Swarm je dejansko razgra-jen aplikacijski streˇznik Wildfly, iz katerega izberemo potrebne podsisteme in jih vkljuˇcimo v naˇs Swarm projekt. S tem se izognemo troˇsenju virov na nepotrebnih podsistemih.

Swarm podpira standardno Javo EE, kar pomeni, da lahko uporabimo celotno moˇc java EE v naˇsi mikrostoritvi in smo tako dobili java EE alter-nativo Spring Boot ogrodju. Poleg tega nam omogoˇca uporabo preverjenih Wildfly nadzornih in upraviteljskih podsistemov, ki pripomorejo k veˇcji pro-duktivnosti razvijalcev. Prav tako Swarm omogoˇca hiter prehod iz aplikacije za aplikacijski streˇznik Wildfly v samozagonski JAR oziroma mikrostortev.

Wildfly podsistemi se v Swarmu imenujejo frakcije.

Podpira veliko standardnih java EE knjiˇznic, katerim so vsakodnevno do-dane nove, med drugim Weld za injiciranje odvisnosti, Undertow kot servlet, standarden JAX-RS za REST in druge. Ko se bo podpora Swarma ˇse doda-tno izboljˇsala, lahko priˇcakujemo moˇcno orodje za kreiranje java EE mikro-storitev z vsemi lastnostmi standardnih aplikacij na aplikacijskih streˇznikih.

4.1.4 KumuluzEE

KumuluzEE [3] je rezultat sodelovanja med diplomantom in profesorjem Fa-kultete za raˇcunalniˇstvi in informatiko v Ljubljani tekom ˇstudijskega leta 2014/2015. Tako kot Wildfly Swarm je tudi KumuluzEE namenjen standar-dni Javi EE, kmalu po izidu prve verzije je prejel nagrado “2015 java Duke’s Choice Award Winnder” [18] (za primerjavo, nekateri izmed prejˇsnjih dobi-tnikov nagrade so Hadoop, ogrodje za porazdeljene sisteme in Jenkins, orodje za sprotno integracijo).

Trenutno KumuluzEE aplikacije teˇcejo na Jetty servletu, ki je bil izbran zaradi zmogljivosti in velikosti, naˇcrtovana je tudi podpora preostalih

popu-larnih servletov. V podpori preostalih knjiˇznic in ogrodij zaostaja za Swar-mom, trenutno podpira Servlet 3.1 (Jetty), WebSocket 1.1 (Jetty), JSP 2.3 (Jetty Apache Jasper), EL 3.0 (RI UEL), CDI 1.2 (RI Weld), JPA 2.1 (RI EclipseLink), JAX-RS 2.0 (RI Jersey), JSF 2.2 (RI Mojarra), Bean Valida-tion 1.1, (RI Hibernate validator), JSON-P 1.0 (RI JSONP). Na prvi po-gled izpo-gleda veliko, vendar pri Swarmu, Spring Bootu in Dropwizardu nismo naˇstevali vseh podprtih knjiˇznic in ogrodij, zaradi velikega ˇstevila le teh.

KumuluzEE je trenutno eden izmed redkih konkurentov Swarmu, ki so dosegli primerno stopnjo zrelosti. Prednost pred Swarmom je ravno neod-visnost, saj Swarm spada pod Wildfly in ga tako naredi bolj primernega za aplikacije, ki teˇcejo na Wildfly aplikacijskih streˇznikih ali za razvijalce, ki imajo izkuˇsnje z Wildflyom. Vstopni prag za KumuluzEE je tako le znanje razvoja java EE aplikacij, prav tako stremi k minimiziranju potrebne konfi-guracije in cilja na oblaˇcno gostovanje. Uporaba v produkciji je (trenutno) odsvetovana.

4.2 Odkrivanje storitev

Kakor smo omenili, je ena glavnih prednosti mikrostoritev moˇznost skali-ranja. Ob poveˇcanem prometu zaˇzenemo veˇc instanc posamezne storitve med katere se porazdelijo zahtevki. Vendar v primeru sinhrone komunika-cije, samo zagon nove instance ni dovolj; poznati moramo tudi IP naslov in vrata te storitve, da ji lahko poˇsljemo zahtevek, saj so naslovi dodeljeni di-namiˇcno ob kreiranju novih instanc in jih ne moremo zapeˇci v konfiguracijske datoteke. Pri tem nam lahko pomaga metoda odkrivanja storitev, ki shrani potrebne informacije (IP naslov, vrata, poverilnice za preverjanje pristnosti, protokole in ostale podatke) instanc vseh mikrostoritev v registru storitev (angl. service registry) [49] in jih po potrebi posreduje mikrostoritvam.

Register storitev je pravzaprav ˇse ena izmed storitev v naˇsem sistemu.

Zaradi svoje naloge je njeno delovanje kljuˇcno za delovanje sistema. V pri-meru nedelovanja ostale storitve ne morejo komunicirati med seboj, razen ˇce

si naslove drugih storitev zaˇcasno shranjujejo v predpomnilnik. Vendar tudi te naslovi sˇcasoma postanejo zastareli. Odkrivanje storitev lahko poteka na klientu (angl. client-side discovery pattern [47]) ali na streˇzniku (angl.

server-side discovery pattern [47]).

Pri odkrivanju storitev na strani klienta le ta najprej kontaktira register storitev, ki mu poda informacije o instancah posamezne mikrostoritve, ki so trenutno na voljo. Klient nato na podlagi prejetih informacij in lastnih po-treb izbere, katero instanco bo kontaktiral - izenaˇcevanje obremenitve tako poteka na strani klienta in se lahko prilagodi zahtevam aplikacije. Primer lahko vidimo na sliki 4.1. Pri tem naˇcinu odkrivanja storitev imamo samo en kritiˇcni del, register storitev, za katerega moramo zagotavljati dostopnost.

Slabost odkrivanja storitev na strani klienta je tesnejˇsa sklopljenost z regi-strom storitev; v vsaki tehnologiji moramo posebej implementirati logiko za komunikacijo z registrom storitev in tudi za izenaˇcevanje obremenitev.

Drugi omenjeni pristop, odkrivanje storitev na strani streˇznika, postavi izenaˇcevalca obremenitve med klienta in register storitev (slika 4.2). Klient poˇsilja zahtevke izenaˇcevalcu obremenitev, ki nato od registra storitev pri-dobi informacije o instancah mikrostoritve in se odloˇci, kateri bo posredoval zahtevek. Klient tako ni sklopljen z registrom storitev, saj komunicira le z izenaˇcevalcem obremenitve. Glavna slabost tega pristopa je nova kompo-nenta (izenaˇcevalec obremenitve), za katero moramo zagotavljati dostopnost.

Poleg tega imamo veˇc klicev v omreˇzju kot v primeru odkrivanja na strani klienta.

Ko se nova instanca mikrostoritve zaˇzene, se lahko registrira v storitev za odkrivanje storitev na dva naˇcina. V prvem naˇcinu mikrostoritev sama skrbi za obveˇsˇcanje registra storitev o svojem delovanju (samoregistracija, angl. self registration [47]). Ob zagonu se mora registrirati in podati svoj naslov. V primeru, da se mikrostoritev ugasne, pred tem obvesti register storitev in ta jo odstrani iz svojega repozitorija naslovov. Tekom delovanja se mora mikrostoritev redno javljati registru storitev, v nasprotnem primeru jo po doloˇcenem ˇcasu neaktivnosti odstrani iz svojega repozitorija. Redno

Slika 4.1: Primer odkrivanja storitev na strani klienta.

javljanje lahko vsebuje podrobnejˇse opise stanja (zaganjanje, dosegljiv, pre-obremenjen, zaustavitev in drugi). Glavna pomanjkljivost samoregistracije je sklopljenost mikrostoritve z registrom storitev, saj mora mikrostoritev po-znati njegov naslov. Poleg tega moramo implementirati logiko za komuni-kacijo z registrom storitev v vsaki tehnologiji posebej (npr. ˇce imamo eno mikrostoritev v Javi in eno v Cju). Menjava orodja za odkrivanje storitev pomeni tudi spremembe v kodi vsake mikrostoritve.

V drugem naˇcinu odkrivanja storitev se mikrostoritev neposredno ne za-veda orodja za odkrivanje storitev. Nalogo registracije in sledenja storitvam prevzame tretje orodje, registrar storitev (angl. service registrar) [47]. Regi-strar sledi spremembam s pregledovanjem okolja, v katerem teˇcejo instance

Slika 4.2: Primer odkrivanja storitev na streˇzniˇski strani.

mikrostoritev, ali prejemanjem dogodkov, ki jih sproˇzijo nove instance ob zagonu. Ob spremembi posodobi register storitev; registrira nove storitve ali odstrani nedelujoˇce. Kakor pri odkrivanju storitev na strani streˇznika je tudi tu glavna prednost ohlapna sklopljenost mikrostoritve in registra storitev, medtem ko se ponovno sooˇcimo s problemom vzdrˇzevanje dodatne kritiˇcne komponente v naˇsem sistemu.

Kakor smo omenili na zaˇcetku, je odkrivanje storitev predvsem potrebno v primeru sinhrone komunikacije, saj so instancam mikrostoritev dodeljeni dinamiˇcni IP naslovi oziroma vrata in ne moremo vnaprej vedeti, na katerih naslovih se bo nahajala doloˇcena storitev. V nasprotnem primeru pri asin-hroni komunikaciji komuniciramo samo s sporoˇcilno vrsto, ki redko, ˇce sploh kdaj, spremeni svoj naslov. Zato lahko uporabimo konfiguracijske datoteke, v katere zapiˇsemo potrebne podatke za komunikacijo s sporoˇcilno vrsto in se izognemo potrebi po odkrivanju storitev.

V nadaljevanju si bomo pogledali najbolj priljubljena orodja za

odkri-vanje storitev na trgu in jih primerjali med seboj. Ugotovili bomo, da ni enotnega in najboljˇsega orodja, ki bi reˇsil vse izzive, vendar se moramo pri-lagajati glede na lastnosti in potrebe aplikacije, ki jo razvijamo. Eno izmed meril za primerjavo je CAP teorem (slika 4.3) [36], ki zatrjuje, da je v po-razdeljenem sistemu nemogoˇce soˇcasno zagotoviti konsistentnost podatkov (angl. consistency), dostopnost (angl. availability) in odpornost na delitve omreˇzja (angl. partition tolerance). Veˇcinoma porazdeljen sistem zagotavlja dve izmed teh lastnosti, odvisno od potreb. V nadaljevanju se bomo spo-znali z dvema CP in enim AP registrom storitev, med katerimi bomo kasneje izbirali.

Slika 4.3: Slika CAP teorema, ki trdi, da v distribuiranem sistemu ni moˇc zagotoviti dostopnost, konsistentnost in odpornost na izpade hkrati.