SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

ZAVRŠNI RAD br. 4465

Android aplikacija za razmjenu poruka temeljena na standardu JMS

Antonio Ivčec

Zagreb, lipanj 2016.

Sadržaj Uvod ....................................................................................................................................... 11. Standard JMS ................................................................................................................. 2

1.1. JMS ahitektura ....................................................................................................... 31.2. JMS modeli ............................................................................................................ 4

1.2.1. Model komunikacije porukama ..................................................................... 41.2.2. Model objavi-pretplati ................................................................................... 5

1.3. Programski model JMS .......................................................................................... 61.3.1. Administrativni objekti .................................................................................. 71.3.2. JMS veze ........................................................................................................ 71.3.3. JMS sjednice .................................................................................................. 81.3.4. JMS proizvođači ............................................................................................ 81.3.5. JMS potrošači................................................................................................. 81.3.6. JMS poruke .................................................................................................... 91.3.7. JMS iznimke ................................................................................................ 10

1.4. JMS 2.0 ................................................................................................................ 111.4.1. Pojednostavljeni API ................................................................................... 121.4.2. Nove mogućnosti ......................................................................................... 16

2. Apache ActiveMQ ....................................................................................................... 212.1. Grupe poruka ....................................................................................................... 212.2. Virtualna odredišta ............................................................................................... 222.3. Zamjenski znakovi za odredišta ........................................................................... 222.4. Kompozitna odredišta .......................................................................................... 23

3. O web priključnicama .................................................................................................. 243.1. Web priključnica Kaazing .................................................................................... 24

4. O razvijenoj aplikaciji .................................................................................................. 254.1. Tehničke značajke ................................................................................................ 254.2. Programske značajke ........................................................................................... 264.3. Dizajn aplikacije .................................................................................................. 294.4. Testiranje aplikacije ............................................................................................. 324.5. Buduće nadogradnje aplikacije ............................................................................ 33

Zaključak .............................................................................................................................. 34Literatura .............................................................................................................................. 35Sažetak ................................................................................................................................. 36Skraćenice ............................................................................................................................ 38Privitak A ............................................................................................................................. 39Privitak B ............................................................................................................................. 41

1

Uvod

Razmjena porukama danas je neizostavan aspekt ljudskog postojanja.

Kako se ljudska komunikacija razvijala i postajala sve modernijom i boljom, tako

se prirodno javila i potreba za ostvarenjem komunikacije između dijelova softvera

te različitih dijelova jedne aplikacije. Cilj ovog rada bio je proučiti i analizirati

standard JMS upravo takve namjene. JMS je već dugo industrijski standard za

komunikaciju labavo povezanih komponenti, bilo da je riječ o komunikaciji

porukama između dva krajnjih klijenata ili o komunikaciji putem modela objavi-

pretplati. U sklopu ovog rada također je bilo potrebno usporediti postojeće

pružatelje JMS usluge te pronaći jednoga koji omogućava potporu za uređaje koje

pokreće operacijski sustav Android. Korištenjem tog pružatelja JMS usluge trebalo

je izraditi i testirati jednu mobilnu aplikaciju koja demonstrira JMS komunikaciju

pomoću oba modela komunikacije koju on pruža.

U poglavlju 1 dan je pregled standarda JMS 1.1 te pregled kroz poboljšanja

koja je donio novi standard JMS 2.0. U poglavlju 2 opisan je pružatelj JMS usluge

Apache ActiveMQ koji je korišten za izradu aplikacije u ovom radu. U poglavlju 3

opisana je tehnologija web priključnica, te jedna takva priključnica Kaazing koja

omogućuje pokretanje izrađene aplikacije za Android uređaje. U poglavlju 4

opisana je cjelokupna programska potpora koja je ostvarena u sklopu ovog

završnog rada. U privitku su dodane upute za instalaciju i pokretanje ostvarene

programske potpore.

2

1. Standard JMS

Komunikacija porukama koju podrazumijevamo u okviru ovog rada (engl.

messaging) jest komunikacija između softverskih komponenata ili različitih

aplikacija. To je oblik slabo povezane komunikacije (engl. loosely coupled), pri

kojoj pošiljatelj i primatelj razmjenjuju poruke, a da ne moraju u isto vrijeme biti

dostupni. Štoviše, primatelj poruke ne mora znati ništa o pošiljatelju, a pošiljatelj

poruke ništa o primatelju. Pošiljatelj i primatelj samo koriste isto odredište (engl.

destination) poruke koja se prenosi, te koriste isti format poruke. Ovakav oblik

komunikacije se također razlikuje od elektroničke pošte (engl. e-Email), koja

predstavlja komunikaciju između više osoba ili komunikaciju između osobe i

aplikacije.

Standard JMS (engl. Java Message Service) uvodi aplikacijsko programsko

sučelje (engl. Application programming interface, skraćeno API) koje aplikacijama

omogućava stvaranje, slanje, primanje te čitanje poruka. JMS pripisuje sučelja

koja svaki određeni pružatelj JMS usluga implementira na svoj način, držeći se

propisanih ugovora sučelja. JMS omogućuje komunikaciju koja, osim što pruža

slabo povezanu razmjenu podataka, omogućava asinkron i pouzdan prijenos

poruka. Prema tome, klijent može primati poruke bez da ih eksplicitno traži i one

pristižu redom kojim su poslane. Također, svaka poruka koja je pristigla na

odredište uvijek će zainteresiranim klijentima biti isporučena upravo jednom.

Specifikacija JMS objavljena je prvi put u Kolovozu 2008., od strane tvrtke

Sun. Od tada, dobila je svoje nadogradnje 2002. verzijom JMS 1.1, te 2013.

verzijom JMS 2.0.

3

1.1. JMS ahitektura

Arhitektura JMS sustava sastoji se od sljedećih elemenata:

• Davatelj JMS usluge (engl. JMS provider)

- Sustav za komunikaciju koji implementira JMS sučelja te pruža

administrativne i kontrolne značajke koje omogućuju razmjenu poruka.

• JMS klijent (engl. JMS client)

- Programi ili softverske komponente pisane u programskom jeziku Java,

koje proizvode te konzumiraju JMS poruke.

- Primjer: programska potpora izvedena u sklopu ovog rada izgrađena je

koristeći klijentsku JMS biblioteku

• Poruke (engl. JMS messages)

- Objekti koji služe za prijenos informacija između JMS klijenata.

- Postoje različite vrste, ovisno o tipu podataka koji se prenosi. Tako postoje

tekstualne poruke, binarne poruke, poruke tokova podataka te poruke koje

prenose mape vrijednosti (sadrže parove ključ-vrijednost).

• Administrativni objekti (engl. Administrative objects)

- Objekti kreirani i unaprijed konfigurirani od strane administratora, dani na raspolaganje klijentima.

- Uključuju odredišta ( engl. destinations) i tvornice veza (engl. connection factories) te su opisani u nastavku ovog dokumenta.

4

1.2. JMS modeli Postoje dva modela komunikacije koje specificira standard JMS. To su

model komunikacije porukama (engl. point-to-point model, skraćeno PTP) te

model objavi-pretplati (engl. publish-subscribe model). Zadaća svakog davatelja

JMS usluge jest da implementira i omogući ova dva modela komunikacije.

1.2.1. Model komunikacije porukama

Model PTP, baziran je na konceptu redova poruka (engl. message queue),

pošiljatelja i primatelja poruka. Svaka poruka je adresirana na jedan specifični red,

a klijenti izvlače poruke iz reda koji čuva poruke adresirane na njih. Red čuva sve

pristigle poruke dok one nisu konzumirane ili dok poruke ne isteknu. Svaka poruka

može biti konzumirana upravo jednom i od strane upravo jednog klijenta. Sukladno

tome, ako više klijenata čeka poruke od strane istog reda, poruke će biti dostupne

iterativno jednom pa drugom klijentu, redom dospijeća. Pošiljatelj i primatelj

poruke nisu vremenski ovisni te ne moraju biti pokrenuti u isto vrijeme. Tako

primatelj poruke može dohvatiti poruku koja je poslana dok je on bio ugašen (pod

pretpostavkom da poruka u međuvremenu nije istekla).

Sl. 1. 1 Model PTP [1]

Ovakav model komunikacije koristi se kada poslana poruka mora biti

konzumirana od strane upravo jednog klijenta.

5

1.2.2. Model objavi-pretplati

U aplikaciji koja koristi objavi-pretplati model, klijenti se pretplaćuju i

adresiraju određene teme (engl. topics). Time komunikacija funkcionira kao neka

vrsta oglasne ploče. Pretplaćivanjem na temu, klijent prima sve poruke koje su na

tu temu adresirane. Pretplatnici (engl. subscribers) i izdavači (engl. publishers)

djeluju anonimno te se dinamički mogu pretplaćivati na teme. Svaka poruka

adresirana na temu biti će konzumirana od strane svih klijenata koji su pretplaćeni

na tu temu. Poruke ostaju u temi samo onoliko dugo koliko je potrebno da poruka

bude distribuirana svim pretplaćenim klijentima. U ovom modelu, pretplatnici i

izdavači su vremenski ovisni, pošto pretplatnik prima poruke samo nakon što se

registrirao kao pretplatnik, a tema ne sadrži povijest svih poruka koje su na nju

poslane. Isto tako, pretplatnik mora biti aktivan čitavo vrijeme koje želi primati

poruke.

Kako bi se doskočilo gore navedenoj prepreci, postoje takozvane izdržljive

pretplate (engl. durable subscriptions). Naime, takve pretplate omogućuju

arhiviranje poruka za klijenta koji je pretplatnik ali se iz bilo kojeg razloga ugasio.

Takva pretplata se nastavlja sve dok se pretplatnik sam eksplicitno ne odjavi od te

pretplate.

Sl. 1. 2 Model objavi/pretplati [1]

Ovakav model komunikacije koristi se kada poslana poruka može biti

procesirana od strane više klijenata.

Specifikacija JMS 1.1 omogućuje korištenje istog koda za izvođenje

komunikacije preko tema ili preko redova, čime se dobiva na fleksibilnosti i

6

višekratnoj iskoristivosti istog koda. Na programerima je da utvrde koji model više

odgovara potrebama njihove aplikacije te njega koriste. Konzumiranje samih

poruka također je neovisno o odabranom modelu i tu se programerima nudi

asinkroni te sinkroni pristup konzumiranja poruka. Kao sinkroni način čekanja

poruke postoji metoda za eksplicitni dohvat poruke s odredišta pri čemu se

pozivajuća dretva blokira dok poruka ne stigne. Alternativni način, koji se danas

češće koristi je pretplata instance slušatelja poruke (engl. message listener) koji

sadrži akciju koju treba izvesti pri primitku poruke. Na ovaj način nema radnog

čekanja i pristigla poruka će svojim dolaskom izazvati svoju obradu.

1.3. Programski model JMS U ovom poglavlju dan je kratki pregled kroz gradivne elemente koje

specificira JMS te od kojih se sastoji svaka aplikacija koja koristi JMS.

Sl. 1. 3 Programski model JMS [1]

7

1.3.1. Administrativni objekti

Kao administrativne objekte, imamo JMS odredišta (engl. JMS destinations)

i tvornice JMS veza (engl. JMS connection factories). To su elementi JMS-a koji

imaju vrlo različitu tehnološku implementaciju između različitih davatelja JMS

usluga.

1.3.1.1 Tvornice JMS veza

Tvornice JMS veza su objekti koje klijent koristi kako bi stvorio vezu s

određenim pružateljem JMS usluge. Tvornica veze enkapsulira skup

konfiguracijskih parametara koji su definirani od strane administratora. Svaka

tvornica JMS veze je ujedno i implementacija jednog od ponuđenih JMS sučelja te

namjene:

• ConnectionFactory

• QueueConnectionFactory

• TopicConnectionFactory

1.3.1.2 JMS odredišta

JMS odredišta su objekti koji služe kao izvori i ponori JMS poruka. U PTP

modelu, odredišta predstavljaju redove, a u Publish/subscribe modelu su to teme.

Jedna aplikacija može istovremeno koristiti i JMS redove i JMS teme. JMS

odredišta implementacije su sučelja Destination.

1.3.2. JMS veze

JMS veza (engl. JMS connection) predstavlja virtualnu vezu aplikacije s

pružateljem JMS usluge. Jedna veza zapravo predstavlja TCP/IP vezu između

klijenta i programa davatelja usluge. Jednom kada je veza ostvarena, ona se

koristi za stvaranje jedne ili više JMS sjednica. JMS veza se obavezno otvara

pozivom metode start i zatvara pozivom metode stop.

8

1.3.3. JMS sjednice

JMS sjednica (engl. JMS session), predstavlja jednodretveni kontekst čija je

namjena stvaranje i konzumiranje poruka. JMS sjednica služi i za stvaranje

proizvođača te potrošača poruka, JMS odredišta (redova i tema) te samih JMS

poruka. JMS sjednice implementiraju sučelje Session.

1.3.4. JMS proizvođači

JMS proizvođač (engl. JMS producer) je objekt koji je stvoren od strane

sjednice i koristi se za slanje poruka na JMS odredište. On je implementacija

sučelja MessageProducer. Pri stvaranju proizvođača, njemu se može navesti

destinacija za koju stvara poruke ili se može napraviti anonimni proizvođač pa u

trenutku slanja, predati i poruka te destinacija na koju se poruka treba poslati.

1.3.5. JMS potrošači

JMS potrošač (engl. JMS consumer) je objekt stvoren od strane sjednice,

koji služi za registriranje klijenta koji je zainteresiran za primanje poruka koje

pristižu na JMS odredište. JMS potrošač je implementacija sučelja

MessageConsumer. Nakon što je potrošač stvoren i otvoren, on postaje aktivan i

koristi se za dohvat pristiglih poruka. Potrošač se otvara pozivom funkcije start,

a zatvara pozivom funkcije stop.

Pristigle poruke mogu se dohvatiti sinkronim pozivom metode receive koja

blokira pozivajuću dretvu, ili asinkronom načinom. Asinkrona metoda

podrazumijeva izradu objekta koji sluša dolazeće poruke (engl. listener) i izvodi

svoju onMessage metodu za svaku pristiglu poruku. Metoda onMessage prima

poruku kao argument, pretvara je u tip poruke, ovisno o tome kakvu poruku

potrošač očekuje, te ju konzumira.

9

1.3.6. JMS poruke

JMS poruke (engl. JMS messages) su primarni objekti JMS komunikacije

koji su jednostavnog, ali izrazito fleksibilnog formata. JMS poruka sastoji se od

svojeg zaglavlja (engl. header), svojih svojstva (engl. properties) i svojeg tijela

(engl. body), od kojih je samo zaglavlje nužno za svaku poruku.

Zaglavlje poruke sadrži niz unaprijed definiranih polja koja klijenti i

pružatelji JMS usluga koriste za identifikaciju i usmjeravanje poruka. Neka polja su

postavljena od strane pružatelja usluge, a neka od strane klijenata. Svaka poruka

ima svoj jedinstveni identifikator koji je sadržan u polju identifikatora poruke (engl.

JMSMessageID field). Vrijednost polja odredište (engl. JMSDestination field)

prikazuje odredište poruke (temu ili red). Također tu su i polja za prioritet i vrijeme

isteka poruke. Određena polja se mogu postaviti od strane klijenta, a neka se

automatski popunjavaju pozivanjem send i publish metoda.

Također, poruka može sadržavati i polja stvorena od strane klijenata koja

nazivamo svojstvima. Tako se mogu izgraditi birači poruka (engl. message

selectors), kojima klijent može filtrirati poruke na osnovu njihovih svojstva.

JMS standard pripisuje 5 podvrsta tipa Message koji označavaju različit tip

poruke i sadrže različito tijelo poruke. Tipovi JMS poruka navedeni su u tablici 1.1.

Tip poruke Sadržaj tijela poruke

TextMessage Objekt tipa java.lang.String MapMessage Skup ime-vrijednost parova, imena su tipa String, a

vrijednosti primitivni tipovi programskog jezika Java. Poredak parova nije definiran

BytesMessage Sirovi tok bajtova čiji format nije interpretiran StreamMessage Tok primitivnih Javinih tipova, koji se popunjavaju i

čitaju sekvencijski ObjectMessage Objekt koji implementira sučelje Serializable

Tablica 1.1 Tipovi JMS poruka

10

1.3.7. JMS iznimke

JMS specificira posebne JMS iznimke (engl. JMS exceptions) koje pružaju

generički način rukovanja iznimkama nastalim tijekom rada JMS aplikacije.

Korijenska iznimka koja se koristi je JMSException. Ta iznimka sadrži niz

naslijeđenih iznimaka koje bolje opisuju specifičnu situaciju koja je dovela do

iznimke, neke od važnijih su:

• InvalidClientIDException

- Baca se kada klijent pokuša postaviti identifikator klijenta na vrijednost koju

JMS poslužitelj ne podržava.

• InvalidDestinationException

- Javlja se kada JMS odredište nije razumljivo JMS poslužitelju, ili odredište

više nije važeće.

• JMSSecurityException

- Javlja se kada JMS poslužitelj odbije poslano korisničko ime i lozinku

poslanu od strane klijenta.

• MessageFormatException

- Javlja se kada se pokuša iščitati polje poruke koje ona ne sadrži ili kada se

njezin sadržaj pokuša čitati kao sadržaj poruke drugačijeg tipa od njezinog.

• MessageNotReadableException

- Baca se kada klijent pokuša pročitati poruku koja omogućuje samo pisanje.

• MessageNotWriteableException

- Baca se kada klijent pokuša pisati u poruku koja omogućuje samo čitanje.

11

1.4. JMS 2.0 Standard JMS dobio je novu inačicu 2.0, u Svibnju 2013. godine. Nova

verzija održava sve programske elemente koji su postojali i u prijašnjim verzijama

JMS-a, no programski se model proširuje i modernizira kako bi bio u skladu s

promjenama koje su se dogodile s novim verzijama Jave. U skladu s time, sve

aplikacije koju su do sada koristile stari API, mogu ga nastaviti koristiti bez nekih

problema s portabilnosti izvornog koda. Ovo je izrazito važno ako se uzme u obzir

da je JMS jedan od najuspješnijih API-jeva po broju različitih implementacija koje

postoje. Osim usklađenosti sa starom verzijom, korištenje JMS 2.0 API-ja u novim

aplikacijama se bitno pojednostavljuje i smanjuje se broj linija koda koje programer

mora napisati kako bi napravio funkcionalnu aplikaciju koja koristi JMS. JMS

standard verzije 2.0 opisan je u detaljnije potpoglavljima koja slijede.

Sl. 1. 4 Novi programski model JMS 2.0 [3]

12

1.4.1. Pojednostavljeni API

Novi standard, još nazvan i pojednostavljeni API (engl. simplified API),

sadrži sve elemente starog, klasičnog API-ja (engl. classic API) te uvodi nova

sučelja. Tako nije potrebno raditi velike preinake u postojećim aplikacijama i

programerima ostaje na odabir da koriste nova sučelja ili već dobro poznate

elemente klasičnog sučelja. U tom smislu, klasični API nije zastario (engl.

deprecated), već se i dalje može koristiti. U novoj verziji uvedena su 3 sučelja,

koja proširuju funkcionalnost već postojećih. Novo sučelje JMSContext služi kao

spajanje starih sučelja Connection i Session u jedan zajednički objekt.

Zamjena za staro sučelje MessageProducer je sučelje JMSProducer. Ono

omogućava postavljanje parametara poruke korištenjem nizanja metoda (engl.

method chaining) čime se dobiva skraćeni i čitljiviji kod. Sučelje JMSConsumer

pojednostavljuje klasično sučelje MessageConsumer i koristi se na sličan način.

Umjesto bacanja iznimke JMSException, korištenje novog pristupa izaziva

bacanje nove iznimke JMSRuntimeException, izvedene iz iznimke

RuntimeException, koja je neprovjeravana iznimka te ne zahtijeva eksplicitno

rukovanje u kodu.

1.4.1.1 Slanje poruke U kôdu 1.1 prikazan je jedan tipičan primjer korištenja klasičnog API-ja,

prikazano je tijelo jedne metode koja šalje JMS poruku. Kao parametri metode

predani su jedna JMS destinacija red, imena queue, te tijelo same poruke u

tekstovnom obliku, text. Ti detalji nisu prikazani na kodu zbog sažetog prikaza. try { Connection connection = connectionFactory.createConnection(); try { Session session = connection.createSession( false, Session.AUTO_ACKNOWLEDGE);

MessageProducer messageProducer = session.createProducer(queue); TextMessage textMessage = session.createTextMessage(text); messageProducer.send(textMessage); } finally { connection.close(); } } catch (JMSException ex) { // rukovanje iznimkom }

Kôd 1.1 – Slanje poruke korištenjem JMS 1.1

13

Stvara se zasebna instanca veze i instanca sjednice. Zatim se stvara

proizvođač poruke na predanom redu stvorene sjednice. Stvara se jedna

tekstualna poruka i proizvođač šalje poruku. Nakon komunikacije, veza se

eksplicitno zatvara.

try (JMSContext context = connectionFactory.createContext();){

context.createProducer().send(queue, text)

} catch (JMSRuntimeException ex)

// rukovanje iznimkom

}

Kôd 1.2 – Slanje poruke korištenjem JMS 2.0

Kôd 1.2 prikazuje isti scenarij korištenjem novog API-ja. Umjesto da se

stvaraju instance veze i sjednice, stvara se samo JMS kontekst. Nakon toga se na

kontekstu u istoj liniji stvara proizvođač i šalje poruka predanom redu, odnosno

destinaciji. Umjesto eksplicitnog zatvaranja veze, kontekst se definira u posebnoj

verziji konstrukta try s resursima (engl. try with resources), koji je dostupan od

Jave verzije 7. Ovakvo korištenje konteksta je moguće jer klasa JMSContext

implementira sučelje Closeable koje mu omogućava automatsko brisanje pri

izlasku iz try bloka. Sučelja Connection i Session sada se također mogu

definirati na ovaj način. Isto tako, nigdje nije potrebno eksplicitno stvaranje

tekstualne poruke, već ju potrošač stvara implicitno, na osnovu predanog String

objekta text koji predstavlja tijelo poruke. Novi pristup također prikazuje korištenje

novi iznimke JMSRuntimeException.

14

1.4.1.2 Sinkrono primanje poruke Kôd 1.3 prikazuje tijelo metode koja na sinkroni način prima poruku i iz nje

izvlači tekst u varijablu body. String body=null;

try {

Connection connection = connectionFactory.createConnection();

try {

Session session = connection.createSession(

false, Session.AUTO_ACKNOWLEDGE);

MessageConsumer messageConsumer =

session.createConsumer(queue);

connection.start();

TextMessage textMessage =

(TextMessage)messageConsumer.receive();

body = textMessage.getText();

} finally {

connection.close();

}

} catch (JMSException ex) {

// rukovanje iznimkom

}

Kôd 1.3 – Sinkrono primanje poruke korištenjem JMS 1.1

Stvara se instanca veze, sjednice i potrošača. Prima se poruka

odgovarajućeg tipa i iz poruke se vadi tijelo u tekstualnom obliku.

String body=null; try (JMSContext context = connectionFactory.createContext();){ JMSConsumer consumer = session.createConsumer(queue); body = consumer.receiveBody(String.class); } catch (JMSRuntimeException ex) { // rukovanje iznimkom }

Kôd 1.4 – Sinkrono primanje poruke korištenjem JMS 2.0

U kôdu 1.4 radi se ista stvar opet korištenjem klase JMSContext za

spajanje na vezu. Ovdje nema eksplicitnog pretvaranja u tip poruke koja se

očekuje već se pozivom metode receiveBody direktno dobiva tijelo te poruke.

15

Kao parametar, ta metoda očekuje identifikator klase, koji označuje tip tijela

poruke koje se želi izvaditi.

1.4.1.3 Asinkrono primanje poruke

Ako se poruka želi dočekati asinkrono, tu postoji mogućnost dodavanja

slušača nad instancom potrošača poruke, MessageConsumer. Slušač poruke je

opisan sučeljem messageListener. Nakon registracije slušača poruke, vezu je

potrebno eksplicitno pokrenuti pozivom start, kako bi praćenje započelo. Takvo

korištenje prikazano je u kôdu 1.5.

MessageConsumer messageConsumer = session.createConsumer(queue);

messageConsumer.setMessageListener(messageListener);

connection.start();

Kôd 1.5 – Asinkrono primanje poruke korištenjem JMS 1.1

U pojednostavljenom API-ju, asinkrono primanje poruke se odvija na sličan

način. Pojednostavljenje je u tome što pozivanje metode start nad vezom više

nije potrebno, već čekanje poruka započinje sa stvaranjem same veze. Takvo

ponašanje je automatsko, no može se naknadno promijeniti. Kôdu 1.6 prikazuje

asinkrono primanje poruke korištenjem pojednostavljenog API-ja.

JMSConsumer consumer = context.createConsumer(queue);

consumer.setMessageListener(messageListener);

Kôd 1.6 – Asinkrono primanje poruke korištenjem JMS 2.0

16

1.4.2. Nove mogućnosti

1.4.2.1 Dijeljene pretplate

Jedan od najvažnijih noviteta koji je uveden u verziji JMS 2.0 jest uvođenje

takozvanih dijeljenih pretplata (engl. shared subscriptions). Dijeljene pretplate

namijenjene su za klijenta koji posao dohvaćanja novih poruka s teme dijeli na

nekoliko JMS potrošača. U tom smislu, drugi JMS potrošači se pokreću u

odvojenim dretvama ili pak u skroz odvojenim Javinim virtualnim strojevima (engl.

Java virtual machine). Recimo da posao koji potrošač radi nad dobivenom

porukom traje duže nego prosječno vrijeme između dolaska dviju poruka. U tom

slučaju nam nastaje usko grlo jer svaka sljedeća poruka sigurno čeka u redu zbog

procesiranja stare poruke. Ako pak napravimo više potrošača koji rade istu

obradu, oni će svi dobiti sve poruke i krenuti ih procesirati. Ideja je sljedeća:

umjesto da se svaki potrošač spaja na temu i dobiva svoju instancu iste poruke,

potrošači koriste zajedničku, dijeljenu pretplatu i svaka nova poruka šalje se samo

jednom od pretplaćenih potrošača, upravo onom koji ju je spreman obraditi. Do

sada se ovom problemu moglo doskočiti uporabom tehnologije Message-Driven Beam unutar platforme Java EE ili pak nekim rješenjima na razini pružatelja JMS

usluge. Recimo, implementacija pružatelja usluge HornetQ nudila je takozvane

divert objekte koji bi usmjeravali poruke iz JMS teme na JMS red kojeg su slušali

potrošači te bi preko njega ciklički primali pristigle poruke. JMS 2.0 donio je

rješenje ovog problema sa standardiziranjem dijeljene pretplate koja više nije

ekskluzivna samo za Java EE. Klasa JMSContext sadrži statičku metodu

createSharedConsumer koja stvara takvog pretplatnika na predanoj temi.

Dijeljene pretplate dostupne su u običnoj i u izdržljivoj verziji pretplate na temu.

Ukratko, pretplate na temu sada imaju 4 verzije:

• Nedijeljena regularna pretplata (engl. Unshared nondurable subscription)

- dostupna u verziji 1.1 i verziji 2.0

- stvara se pozivom metode createConsumer

- postavljanje identifikatora klijenta pretplate je opcionalno

17

• Nedijeljena izdržljiva pretplata (engl. Unshared durable subscription)

- dostupna u verzijama 1.1 i 2.0

- stvara se pozivom metode createDurableSubscriber ili

createDurableConsumer (samo u verziji 2.0)

- sadrži samo jednog potrošača

- postavljanje identifikatora klijenta je obavezno

- pretplata se identificira kombinacijom imena pretplate i klijentskog

identifikatora

• Dijeljena regularna pretplata (engl. Shared nondurable subscription)

- dostupna od verzije 2.0

- stvara se pozivom metode createSharedConsumer

- može sadržavati više pretplatnika

- za identifikaciju pretplate koristi se ime pretplate i identifikator klijenta koji

može i ne mora biti postavljen

• Dijeljena izdržljiva pretplata (engl. Shared durable subscription)

- dostupna od verzija 2.0

- stvara se pozivom metode createSharedDurableConsumer

- može sadržavati više pretplatnika

- za identifikaciju pretplate koristi se ime pretplate i identifikator klijenta koji

može i ne mora biti postavljen

18

1.4.2.2 Odgoda slanja poruke

JMS 2.0 također uvodi odgodu slanja poruke. Ukoliko se koristi klasični API,

odgoda se može postaviti na instancu sučelja MessageProducer metodom

setDeliveryDelay. Ako se koristi pojednostavljeni API, tada se odgoda

postavlja na instancu tipa JMSProducer. Varijanta metode u novom sučelju vraća

korišteni JMSProducer objekt čime se postiže elegantno nizanje metoda

navedeno u nastavku. Odgoda slanja poruke u obje varijante navodi se u

milisekundama. Postavljanje odgode slanja poruke prikazano je u kodu 1.7.

try(JMSContext context = connectionFactory.createContext()) {

context.createProducer()

.setDeliveryDelay(20000)

.send(queue, “Hello world”);

}

Kôd 1.7 – Postavljanje odgode slanja poruke

1.4.2.3 Svojstvo o dostavi poruke

Unutar JMS 1.1 poruke, već je postojalo svojstvo JMSXDeliveryCount,

koje daje informaciju koliko je puta jedna poruka bila poslana. Međutim, do sada

je postavljanje tog svojstva bilo potpuno opcionalno. Razlog zašto se neka poruka

uzastopno isponova šalje, jest ako je došlo do problema s prijenosom poruke prvi

put. Takav slučaj je obično problem na strani aplikacije, koja nije u stanju

procesirati poruku ili ju obrađuje na krivi način što izaziva iznimku. Verzija 2.0

pokušava riješiti ovaj problem, na način da postavljanje tog svojstva postaje

obavezno. Sada aplikacija koja konzumira poruku može detektirati da je poruka na

neki način “loša” ili uzrokuje probleme, te može na poseban način njome rukovati.

Recimo, poruka koje je nevaljana se može poslati u poseban red za takve poruke

kako bi administrator mogao ispitati uzrok problema.

19

1.4.2.4 Asinkrono slanje poruke

Uobičajeno, kada JMS klijent pošalje poruku, metoda send ne završava

svoj posao dok klijent ne dobije povratnu poruku od servera da je poruka sretno

stigla. Takav način slanja poruka smatramo sinkronim slanjem (engl. synchronous

send). JMS 2.0 uvodi mogućnost slanja poruke na asinkroni način (engl.

asynchronous send). Prilikom slanja poruke, ista se šalje serveru, a kontrola se

automatski vraća aplikaciji bez čekanja na odgovor sa servera. Na taj način,

aplikacija nije osuđena na radno čekanje, već tijekom čekanja na odgovor sa

servera može raditi nešto korisno. Davatelj JMS usluge obavješćuje aplikaciju o

uspješnosti poslane poruke pomoću metode onCompletion unutar instance

slušatelja CompletionListener. Dva su glavna razloga iz kojih bi netko želio

koristiti asinkroni način slanja poruke. Prvi je čisto izbjegavanje radnog čekanja,

asinkrono slanje omogućuje izvođenje nekih drugih operacija, većeg prioriteta za

vrijeme čekanja odgovora. Recimo ažuriranje grafičkog korisničkkog sučelja ili

obrada neke druge poruke. Drugi razlog je da korisnik može doći u situaciju da želi

poslati veliki broj poruka odjednom. Tada čekanje povratnih poruka može dodatno

usporiti rad cijele aplikacije i predstavljati usko grlo za izvođenje ostatka aplikacije.

try (JMSContext context = connectionFactory.createContext();){

CountDownLatch latch = new CountDownLatch(1);

MyCompletionListener myCompletionListener =

new MyCompletionListener(latch);

context.createProducer()

.setAsync(myCompletionListener)

.send(queue,"Hello world");

// u ovom trenu moze se izvesti

// neki korisni posao

latch.await();

if (myCompletionListener.getException()==null){

System.out.println("Stigao odgovor sa servera!");

} else {

throw myCompletionListener.getException();

}

}

Kôd 1.8 – Postavljanje odgode slanja poruke

20

Kôd 1.8 predstavlja jedan takav posao. Prije slanja poruke, proizvođač JMS

poruke dobiva instancu sučelja CompletionListener kroz metodu setAsync.

Za čekanje odgovora ovdje smo koristili instancu klase CountDownLatch (iz

paketa java.util.concurrent) , čija metoda await izaziva čekanje dok neka druga

dretva ne pozove njezinu metodu countDown. U kodu 1.9 u nastavku dan je cijeli

kod klase MyCompletionListener kako bi bili jasniji detalji njezine izvedbe.

class MyCompletionListener implements CompletionListener {

CountDownLatch latch;

Exception exception;

public MyCompletionListener(CountDownLatch latch) {

this.latch=latch;

}

@Override

public void onCompletion(Message message) {

latch.countDown();

}

@Override

public void onException(Message message, Exception exception) {

latch.countDown();

this.exception=exception;

}

public Exception getException(){

return exception;

}

}

Kôd 1.9 – Implementacija sučelja CompletionListener

Sučelje CompletionListener specificira dvije metode. Metodu

onCompletion i onException. U konkretnom primjeru, kada je poruka pristigla,

instanca sučelja CompletionListener dojavljuje instanci CountDownLatch da

može prestati čekati na nju.

21

2. Apache ActiveMQ

Apache ActiveMQ je posrednik poruka otvorenog koda, koji ima potpunu

implementaciju JMS klijenta te potporu za posrednika poruka. On pruža opcije za

velika poduzeća koja omogućuju komunikaciju s više od jednog klijenta i

poslužitelja u isto vrijeme. On podržava veliku količinu višeplatformskih klijenata i

protokola. Isto tako, on uključuje biblioteke u programskim jezicima Java, C, C++,

C#, Ruby, Perl, Python, PHP . Trenutno je najnovija verzija 5.13.3. U nastavku su

navedene neke od brojnih naprednih mogućnosti koje ActiveMQ nudi povrh same

JMS specifikacije, kako bi komunikaciju porukama učinio što boljom i lakšom za

korištenje.

2.1. Grupe poruka

Grupu poruka (engl. Message group) čine sve poruke koje imaju istu

vrijednost polja JMSXGroupID. ActiveMQ se brine za to da sve poruke u istoj

grupi poruka budu poslane upravo jednom JMS potrošaču (vlasniku grupe

poruka), dok god je on aktivan. Čim taj potrošač prestane s radom, drugi potrošač

će biti odabran. Grupa poruka se isto tako, može zatvoriti manualno. Ovakvo

korištenje poruka je poželjno ako se želi balansirati opterećenjem potrošača nekog

odredišta. Ono što možda nije očito na prvi pogled, jest činjenica da će sve poruke

koje dođu do potrošača i vlasnika grupe poruka, doći upravo redoslijedom kojim su

poslane. Dakle, ovaj način garantira poredak procesiranja poruka na istom

potrošaču.

22

2.2. Virtualna odredišta

Virtualna odredišta omogućuju stvaranje logičkih odredišta koja se vrlo lako

mapiraju u jedno ili više fizičkih odredišta. Ideja virtualnih odredišta jest da se

omogući funkcionalnost koju omogućuju izdržljivi potrošači, ali na način da se

izbjegnu neki problemi s balansiranjem opterećenja koje oni uvode. Naime, pri

gašenju jednog izdržljivog proizvođača, ne želimo da njegov posao ovisi o njemu

samom, već želimo da postoji mogućnost da netko nastavi raditi njegov posao.

Recimo da postoji logička tema VirtualTopic.Topic. Potrošač A se na nju

može pretplatiti kao na bilo koju drugu temu. Međutim, potrošači B i C se mogu

spojiti na red ConsumeQueue.VirtualTopic.Topic (gdje je ConsumeQueue

arbitrarno ime reda koje je zajedničko za potrošača A i B) , te preko njega

naizmjence primati poruke iz originalne teme. Na taj način red, odnosno tema, će

biti konzumirana i nakon prestanka rada jednog of potrošača (B ili C). U ovom

primjeru red ConsumeQueue će se automatski stvoriti.

2.3. Zamjenski znakovi za odredišta

Zamjenski znakovi za odredišta (engl. wildcards) koriste se kako bi se

odjednom spojilo na više odredišta. ActiveMQ uvodi posebne znakove ., * i > kako

bi se izbjeglo pisanje imena odredišta dugih imena, te omogućilo spajanje na više

odredišta istog tipa imena odjednom. Recimo da postoje red

imena “PRICE.STOCK.NASQAD.ORCL” i red imena “PRICE.STOCK.NYSE.IBM”,

ime reda PRICE.> odnosilo bi na oba ta reda, pošto oboje počinju prefiksom

“PRICE.”. Znak zvjezdica (*) koristi se za zamjenu bilo kojeg niza znakova u

imenu, a znak točka (.) kao odvajanje dijelova imena.

23

2.4. Kompozitna odredišta

Od verzije 1.1 ApacheMQ podržava kompozitna odredišta (engl. composite

destinations). Kompozitna odredišta predstavljaju odredišta koja, uz korištenje

oblikovnog obrasca kompozicije, zapravo predstavljaju skupinu JMS odredišta. Na

taj način, operacije nad jednim, vršnim odredištem, rezultiraju delegiranjem tih istih

operacija na sva odredišta koja su sadržana u tom jednom odredištu. Prikaz

takvog korištenja prikazan je u kôdu 2.1. U prvom primjeru red1 je kompozitno

odretište koje sadrži tri redova: prvi, drugi i treci. U drugom primjeru

prikazano je koristenje varijable red2 kao odredišta koje sadrži jednu temu i jedan

red. Ta varijabla koristi se kao delegat za red prvi, te temu jednaTema.

Queue red1 = new ActiveMQQueue(“prvi,drugi,treci");

Producer.send(red1, message);

Queue red2 = new ActiveMQQueue("prvi,topic://jednaTema)

Producer.send(red2, message);

Kôd 2.1 – Postavljanje odgode slanja poruke

24

3. O web priključnicama

Web priključnice (engl. WebSocket) označavaju protokol koji omogućuje

dvosmjerne kanale komunikacije preko jedne TCP veze. Protokol WebSocket

standardiziran je od strane IETF 2011. godine, a API koji on koristi od strane W3C.

Tehnologija WebSocket omogućava stvaranje interaktivne sjednice između klijenta

i poslužitelja. Koristeći njegov API, omogućeno je slanje poruka na poslužitelj te

primanje poruka pokrenutih događajima (engl. event-driven messaging), bez

prozivanja servera i eksplicitnog čekanja na odgovor.

Specifikacija protokola WebSocket uvodi kratice ws i wss kao dio URI sheme,

koje označavaju nekriptiranu i kriptiranu vezu priključnicom. Protokol WebSocket

podržan je u većini modernih web preglednika, uključujući Google Chrome,

Internet Explorer, Firefox, Safari te preglednik Opera.

3.1. Web priključnica Kaazing Jedna takva implementacija standarda WebSocket je i web priključnica

Kaazing. Kaazing rukuje svom komunikacijom preko web priključnice, pretvarajući

poruke iz poslužiteljskih servisa baziranih u različitim tehnologijama (RSS, XMPP,

JMS) u WebSocket događaje. Kaazing podržava više različitih klijenata, među

kojima su web klijenti HTML5 (uključivši i mobilne uređaje) najistaknutiji.

Web priključnica Kaazing ima svoju JMS inačicu koja proširuje mogućnosti

ostalih davatelja JMS usluge. Tako Kaazing omogućuje distribuciju JMS poruka

preko velikog broja JMS klijenata, puno većeg nego što bi to normalan posrednik

JMS poruka uspio sam. Također, on omogućava JMS komunikaciju klijenata preko

web-a, vatrozida i preko posredničkih poslužitelja (engl. proxy server). Isto tako,

Kaazing omogućava korištenje istog posrednika poruka klijentima na različitim

platformama. Upravo iz tog razloga je on i korišten u sklopu ovo završnog rada,

kako bi omogućio JMS komunikaciju preko Android uređaja. Da bi omogućio

izradu klijentskih aplikacija preko JMS standarda, Kaazing sadrži posebne

klijentske JMS biblioteke te namjene.

25

4. O razvijenoj aplikaciji

U praktičnom dijelu ovog rada je razvijena aplikacija koja koristi standard JMS

za komunikaciju porukama, izrađena za mobilne uređaje koji koriste operacijski

sustav Android. Aplikacija omogućuje čavrljanje (engl. chat) na dva načina, čime

je prikazano korištenje oba JMS modela. Prvi način omogućuje komunikaciju

modelom razmjene poruka (P2P) u kojoj korisnik stvara izvorni red na kojem čeka

pristigle poruke te se spaja na odredišni red na koji šalje poruke. Preduvjet za

ispravno funkcioniranje ovog modela je pretpostavka da krajnji korisnici znaju

jedan za drugoga, te unaprijed dogovore ime izvorišnog i odredišnog reda koji se

koriste. Drugi način predstavlja model objavi-pretplati, u kojem se klijenti spajaju

na zajedničku temu te anonimno razmjenjuju poruke.

4.1. Tehničke značajke Aplikacija je izvedena korištenjem, sada već standardiziranog okruženja za

izradu Android aplikacija, Android Studija verzije 2.1.1. Kao sustav za

automatizaciju izgradnje aplikacije, Android Studio koristi sustav Gradle (najnovija

verzija 2.13). Sustav Gradle jako olakšava izgradnju same aplikacije jer

omogućuje pokretanje i testiranje aplikacije, izgradnju .apk datoteke koja služi za

pokretanje aplikacije na uređajima te razrješava ovisnosti o bibliotekama koje se

koriste u kodu (engl. dependencies). Za minimalni Android API (engl. minimum

required SDK) odabran je API verzije 14 (Android 4.0 - IceCreamSandwich) kako

bi se omogućilo izvođenje aplikacije na što većem broju Android uređaja. Svi

uređaji s nižom verzijom API-je ne mogu instalirati ovu aplikaciju. Ciljana verzija

Android API-ja (engl. target SDK), koja je i korištena za testiranje aplikacije je

Android SDK verzije 23. Također, korištene su dodatne biblioteke

com.android.support:appcompat-v7 te com.android.support:design, kako bi se

omogućilo korištenje alatne trake (engl. ActionBar) te letećeg teksta (engl. floating

text) koje aplikaciji daju suvremeni izgled.

26

Za omogućavanje JMS komunikacije korištena je web priključnica Kaazing,

te posrednik JMS poruka Apache ActiveMQ. Apache ActiveMQ je također korišten

kao davatelj JMS usluge, a na klijentskoj strani su korištene biblioteke Geronimo

koje sadržavaju implementaciju sučelja JMS, potrebnih za izradu klijentskih

aplikacija. Također su korištene biblioteke koje nudi priključnica Kaazing, za

spajanje klijenata na samu web priključnicu.

4.2. Programske značajke

Aplikacija se sastoji od dva prozora (engl. Activity), Prvi je

MainMenuActivity koji prikazuje inicijalni prozor sa spajanjem na web priključak i

odabirom modela komunikacije, a drugi je prozor ChatActivity koji prikazuje same

poruke. Prozor MainMenuActivity sastoji se od svojeg Java koda u datoteci

MainMenuActivity.java i dokumenta koji opisuje grafičko korisničko sučelje,

activity_menu.xml. Samo korisničko sučelje izvedeno je uporabom menadžera

LinearLayout, koji vizualne elemente pozicionira vertikalno jednog ispod drugoga.

Imena svih grafičkih elemenata, poput gumba, inicijalnih teksta u poljima te

pomoćnih tekstova u ulaznim poljima nalaze se u datoteci values/strings.xml.

Takve informacije su odvojene od koda tako da se lako izmjenjuju izvana, bez

potrebe za ponovnim kompiliranjem cijele aplikacije. Isto tako, pošto informacije o

tekstovima grafičkih elemenata, nisu ugrađene u kod (engl. hardcoded text), vrlo je

lako dodavanje prijevoda istih tekstova na drugim jezicima i na taj način lokalizirati

cijelu aplikaciju. Posao spajanja na JMS vezu, nalazi se u klasi MainMenuActivity,

a posao spajanja na pretplatu, slanja i primanja poruka nalazi se u klasi

ChatActivity. Za prozor ChatActivity kao dokument sa kodom se koristi

ChatActivity.java, a njegovo grafičko sučelje opisano je u dokumentu

activity_chat.xml. Za iscrtavanje samih poruka korišteni su posebni .xml

documenti, pošto su poruke elementi koji se dinamički popunjavaju u prikazu

ListView prozora. Poslana i primljena poruka opisani su dokumentima

received_message.xml i sent_message.xml.

27

Sl. 1. 5 Isječak iz datoteke activity_menu.xml koji opisuje grafičko sučelje inicijalnog

prozora

Logika same aplikacije podijeljena je između klasa MainMenuActivity i

ChatActivity. MainMenuActivity sadrži samo funkcionalnosti za spajanje na vezu,

a ChatActivity sadrži funkcionalnosti registracije i prestanka registracije na

pretplatu te posao s dohvatom i slanjem poruka. Cijeli ChatActivity je ponovno

iskorišten, kako bi isti prozor omogućio komunikaciju putem teme i komunikaciju

putem reda.

Informaciju o tome kako cijeli ChatActivity mora izgledati prenosi MainMenuActivity

pri stvaranju instance klase ChatActivity. Naime, prenosi se jedna instance

novostvorene enumeracije ChatType, koja može biti POINT_TO_POINT ili

PUB_SUB. Kako bi ChatActivity znao razlikovati sučelje poruka koje su pristigle, od

poruka koje je korisnik poslao, koristi se još jedna doatna enumeracija

ChatMessageType. Elementi te enumeracije su SENT i RECEIVED.

28

Sl. 1. 6 Dokument message_outline_sent.xml koji opisuje izgled pojedine dolazne poruke

Kako poslovi koji imaju veze sa JMS vezom (spajanje na vezu,

pretplaćivanje, slanje poruka) ne bi zadržali glavnu dretvu, svi su pokretani

postavljanjem u red dodatnih dretvi klase DispatchThread. Ta klasa podtip je

klase HandlerThread iz paketa android.os. Za dinamičko popunjavanje liste koja

prikazuje pristigle i poslane poruke, korišten je podtip klase ArrayAdapter iz

paketa android.widget, koji nudi funkcionalnost dinamičkog izvora podataka za

listu na grafičkom sučelju.

29

4.3. Dizajn aplikacije Inicijalni prozor aplikacije sastoji se od polja u koji se upisuje lokacija web

priključnice, te tipke CONNECT putem koje se pokreće spajanje na priključnicu.

Prilikom uspješnog spajanja, omogućavaju se tipke POINT TO POINT koja vodi

na čavrljanje između dviju osoba (P2P) te tipke PUBLISH-SUBSCRIBE koja vodi

na grupno čavrljanje putem teme i modela objavi-pretplati. U svakom trenu,

korisnik može zaustaviti vezu sa web priključnicom, a ako ju eksplicitno ne zatraži i

ugasi aplikaciju, veza će se raskinuti sama. Inicijalni prozor prikazan je na slici 1.7.

Sl. 1. 7 Inicijalni prozor aplikacije (lijevo – prije spajanja na web priključak, desno – nakon

spajanja na web priključak)

30

Ako korisnik odluči čavrljati pritiskom na tipku POINT-TO-POINT, dočekat

će ga dijalog sa slike 1.8 (lijevo). U dijalogu, traži se ime reda koji se koristi za

primanje poruke (source queue), te ime reda koji se koristi za slanje poruke

(destination queue). Imena redova unutar JMS-a inače započinju prefiksom

/queue/, no ova aplikacija to sama nadodaje na odabrano ime, tako da se

redovima mogu pridijeliti simbolička imena, koja ovdje imaju interpretaciju

korisničkih imena. Ako zadani red već postoji, isti se koristi za komunikaciju, u

suprotnom se red zadanog imena stvara. Za takvo ponašanje zaslužan je korišteni

posrednik poruka Active ApacheMQ. Prikaz samog prozora za čavrljanje i jednog

toka razgovora dan je na slici 1.8 (desno). Korisnik u svakom trenu može izaći iz

razgovora pritiskom na tipku BACK, mobilnog uređaja.

Sl. 1. 8 Lijevo – upisivanje imena redova za spajanje na čavrljanje korištenjem P2P

modela, desno – P2P čavrljanje u tijeku

31

Pri izlazu iz prozora za čavrljanje, prekidaju se sve aktivne pretplate i

ponovno se ulazi u inicijalni prozor, koji omogućava uspostavljanje novog

razgovora.

Ukoliko se korisnik odluči za komunikaciju preko spajanja na temu, pritišće

tipku PUBLISH-SUBSCRIBE i dočekan je sa dijalogom na slici 1.9 (lijevo). U

dijalogu korisnik navodi ime teme na koju se želi spojiti. Ukoliko ta tema ne postoji,

davatelj JMS usluge Apache ActiveMQ će se pobrinuti za to da takva tema

nastane. Nakon upisivanja imena teme, korisnik dolazi na prozor za komunikaciju

prikazan na slici 1.9 (desno).

Sl. 1. 9 Lijevo – primjer spajanja na temu pod imenom fer-grupa,

desno – tijek izvođenja čavrljanja modelom objavi-pretplati

32

Na prozoru se pojavljuju poruke redom dolaska na temu. Pošto je korisnik

pretplaćen na sve poruke teme, a ujedno i sam šalje poruke na istu temu, njegove

iste poslane poruke mu dolaze kao odgovor od teme. U tome se vidi da je

komunikacija putem teme zapravo anonimna, pošto nijedan član pretplate na temu

ne zna tko su ostali članovi, te ne zna tko je poslao određenu poruku. Kao i u

prošlom modelu komunikacije, korisnik u svakom trenu može izaći iz razgovora

pritiskom na tipku BACK, čime prestaje njegova pretplata na temu.

4.4. Testiranje aplikacije Testiranje aplikacije izvedeno je na sljedećim uređajima:

• Samsung Galaxy S3 mini (Android 4.4.2)

• Samsung Galaxy S5 (Android 4.4.4)

• ZTE Blade L3 (Android 4.4.4)

Testiranje komunikacije preko Kaazing web priključnice ostvareno je

pomoću priključnice koju sam pokrenuo na svojem osobnom računalu na portu

8001. Također, Apache ActiveMQ poslužitelj pokretan je na istom računalu na

portu 8161. Uz testiranje konkretnim Anroid uređajima, tijekom razvoja aplikacije

korišten je Android emulator Genymotion za testiranje funkcionalnosti aplikacije, te

demo web aplikacija koja dolazi uz Kaazing i omogućuje čavrljanje preko

priključnice. Sve uočene pogreške su uklonjene kako bi aplikacija bila što

funkcionalnija i responzivnija.

33

4.5. Buduće nadogradnje aplikacije

Moguće dodatne nadogradnje aplikacije mogle bi uključivati pretraživanje

postojećih redova i tema na spojenoj web priključnici što bi olakšalo korištenje

aplikacije. Tako korisnik ne bi trebao eksplicitno pisati ime teme na koju se želi

pretplatiti već bi ju mogao odabrati iz liste već postojećih tema.

Komunikacija modelom objavi-pretplati mogla bi se dodatno proširiti na

način da se omogući da klijent istovremeno sluša više tema, te da odabire na koju

temu želi poslati poruku. Ovakva komunikacija, iako naizgled malo kaotična,

mogla bi funkcionirati ako bi se, uz pristiglu poruku na neki način ispisalo iz koje

teme poruka dolazi.

Također, moguće je napraviti klijentsko filtriranje poruka, na način da se

prikazuju samo poruke određenog tipa, koje interesiraju korisnika. To se može

postići korištenjem dodatnih polja koje klasa Message nudi i koje bi držale

informaciju o tipu ili sadržaju poruke.

Uz sve navedeno, ovu aplikaciju se može vrlo lako lokalizirati na više

jezika, tako da se dodaju dokumenti sa prijevodima svih grafičkih elemenata.

34

Zaključak

Zadatak ovog završnog rada bio je proučiti standard JMS te putem jednog

pružatelja JMS usluge ostvariti mobilnu aplikaciju koja omogućuje razmjenu

poruka stvarnom vremenu. Kratki pregled kroz JMS standard je dan u ovom radu,

a tražena programska podrška je uspješno realizirana. Izrađena aplikacija

upogonjuje koristi klijentski JMS API kako bi omogućila komunikaciju modelom

P2P te modelom objavi-pretplati. Iako izrađena aplikacija služi više kao demo,

stvarna softverska rješenja koriste JMS na isti način.

Rad na izradi ove aplikacije se na trenutke činio zahtjevan, pošto ne postoji

puno poslužitelja JMS usluge za uređaje na operacijskom sustavu Android, a oni

koji i postoje su uglavnom slabo dokumentirani te nisu popraćeni sa mnogo

konkretnih primjera. Unatoč tome, informacije ipak postoje za one koji ih dovoljno

dugo traže, a i samim programiranjem i testiranjem se jako puno toga nauči i svi

problemi se daju riješiti.

Ostvarena aplikacija bi mogla biti i nadograđena nekim dodatnim

mogućnostima koje bi učinile komunikaciju jednostavnijom te lokalizacijom čime bi

aplikacija bila dostupnija široj publici.

35

Literatura

[1] Oracle (2010), “Overview of the JMS API”,

https://docs.oracle.com/cd/E19798-01/821-1841/bncdr/index.html

[2] Nigel Deakin (2013), “What's new in JMS 2.0”,

http://www.oracle.com/technetwork/articles/java/jms20-1947669.html

[3] Oracle, “Understanding the simplified API programming model”,

https://docs.oracle.com/middleware/1221/wls/JMSPG/simplified_api.htm

[4] Apache ActiveMQ, features, http://activemq.apache.org/features.html

[5] Kaazing WebSocket Gateway, documentation, http://kaazing.com/doc/

[6] Wikipedia, “Websocket“, http://en.wikipedia.org/wiki/WebSocket

36

Sažetak

Android aplikacija za razmjenu poruka temeljena na standardu JMS

Standard JMS (engl. Java Message Service) je industrijski standard za

komunikaciju labavo povezanih softverskih komponenti koji pruža komunikaciju

preko dva modela. To su model komunikacije porukama između krajnjih klijenata

te model objavi-pretplati. API propisan od JMS-a omogućuje aplikacijama

stvaranje, slanje, primanje te čitanje JMS poruka. JMS verzije 2.0 pristigle 2013.,

zadržava sve funkcionalnosti i sučelja koja JMS originalno propisuje, no uvodi i

neke novitete koji olakšavaju i poboljšavaju postojeću JMS uslugu. Tako je novi

API puno sažetiji i jednostavniji za korištenje i usklađen sa novitetima koji su

pristigli u programski jezik Java.

U sklopu izrade ovog rada korišten je posrednik JMS poruka Apache

ActiveMQ, te web priključnica Kaazing kako bi se komunikacija mogla odviti

između više Android uređaja. Izrađena je jednostavna aplikacija za čavrljanje koja

omogućuje dva načina čavrljanja, čime su prikazane funkcionalnosti oba JMS

modela.

Ključne riječi: JMS, model komunikacije porukama, model objavi-pretplati,

Apache ActiveMQ, Kaazing, web priključnica, Android, komunikacija porukama

37

Sumary

An Android Application for Message Exchange

Based on JMS

JMS is the industry standard for loosely-coupled communication of software

components. The JMS API supports two models of communication: point-to-point

model and publish-subscribe model. JMS introduced its API that allows client

application to create, receive, send and read JMS messages. JMS 2.0 came out in

2013. and brought some novelties that simplify and enrich the already existing

JMS service. The new API is more concise, easier to use, and in compliance with

the novelties that came with recent Java versions.

Developed application uses Apache ActiveMQ as the message broker, and

Kaazing WebSocket Gateway, which enables communication between several

Android devices. The finished product is a simple Android chat application, which

showcases communication over point-to-point and publish-subscribe model.

Keywords: JMS, point-to-point model, publish-subscribe model, Apache

ActiveMQ, Kaazing, WebSocket, Android, chat

38

Skraćenice

JMS Java Message Service standard za labavo povezanu komunikaciju softverskih komponenti API Application Programming interface aplikacijsko programsko sučelje IETF Interner Engineering Task Force tvrtka koja razvija i promiče Internet standarde IP Internet Protocol Internetski protokol TCP Transmission Control Protocol transmisijski kontrolni protokol XML Extensible Markup Language proširivi jezik za označavanje RSS Rich Site Summary format za jednostavnu i brzu distribuciju web sadržaja XMPP Extensible Messaging and Presence proširivi protokol za trenutno Protocol poručivanje i evidenciju prisutnosti

39

Privitak A

Instalacija web priključnice Kaazing i posrednika poruka Apache ActiveMQ U ovom privitku opisano je postavljanje web priključnice Kaazing na svoje

lokalno računalo. Dane su upute za pokretanje alata preko bash ljuske, no

pokretanje preko Windowsa i komandne linije su vrlo slične.

Za Windows računala potrebno je preuzeti .zip datoteku sa

http://kaazing.com/download/#ce-kwg, a za Linux ili Mac preuzeti .tar.gz datoteku.

Nakon toga, preuzetu datoteku potrebno je odpakirati u neki mapu, koji ćemo

odsada zvati GATEWAY_HOME. Unutar mape GATEWAY_HOME/brokers nalazi

se mapa apache-activemq-5.10.0 koja sadrži implementaciju posrednika poruka

Apache ActiveMQ. Tu mapu treba kopirati i staviti je negdje gdje se može lako

dohvatiti.

Prije pokretanja i korištenja Android aplikacije, potrebno je pokrenuti

ActiveMQ i Kaazing. Da bi pokrenuli ActiveMQ posrednika poruka preko bash

ljuske, potrebno se pozicionirati u datoteku apache-activemq-5.10./bin te upisati:

./activemq start. Ukoliko je sve u redu, posrednik poruka počinje sa svojim radom i

može mu se pristupiti preko adrese http://localhost:8161/., gdje se nalaze

informacije o trenutno pokrenutim redovima poruka i temama.

Kako bi pokrenuli Kaazing web priključnicu, potrebno je otvoriti

GATEWAY_HOME/conf/gateway-config.xml te pronaći dio:

<service> <name>JMS Service</name> <description>JMS Service</description> <accept>ws://${gateway.hostname}:${gateway.extras.port}/jms</accept> <accept>ws://local-ip-address:${gateway.extras.port}/jms</accept>

40

Na mjestu ”local-ip-address” potrebno je staviti javnu IP adresu računala na koje

se postavlja WebSocktet. Nakon toga, može se pokrenuti Kaazing WebSocket

pozicioniranjem u GATEWAY_HOME/bin te pokretanjem naredbe ./gateway.start

kojom se pokreće WebSocket u trenutnoj bash ljusci.

Ako je sve u redu, Kaazing WebSocket je pokrenut i može mu se pristupiti putem

adrese http://localhost:8001/. Na ovoj adresi nalaze se detalji trenutne veze te

postoji nekoliko demo programa koji opisuju funkcionalnost Kaazing web

priključnice.

U ovom trenu moguće je pokrenuti Android aplikaciju. U trenutku kada se želi

ugasiti JMS komunkacija potrebno je ugasiti pokrenutu Kaazing aplikaciju( ctrl + c)

te ugasiti posrednika poruka ActiveMQ pozicioniranjem u apache-activemq-5.10./bin te pokretanjem naredbe ./activemq stop.

41

Privitak B

Instalacija Android aplikacije Kako bi se uspješno instalirala Android aplikacija potrebno je pratiti sljedeće

korake:

1. U glavnom izborniku uređaja treba odabrati stavku opcije->sigurnost

(engl. settings -> security) te omogućiti instaliranje aplikacije sa

nepoznatih izvora(engl. unknown sources).

2. Potrebno je priključiti uređaj USB kablom na računalo i uključiti USB

skladištenje (engl. USB storage) za kopiranje dadoteka sa računala

na SD karticu uređaja.

3. Unutar Android Studio projekta treba pronaći datoteku

app/build/outputs/apk/app-debug.apk te ju kopirati u proizvoljni

direktorij na uređaju.

4. Sigurno odspojiti Android uređaj sa računala.

5. Pronaći .apk datoteku na mobilnomu uređaju te ju instalirati.

Pod uvjetom da su pokrenuti Kaazing WebSocket i Apache ActiveMQ,

aplikacija se sada može pokrenuti. Prije spajanja na JMS vezu, potrebno je još u

polje Location upisati javnu IP adresu računala na kojem se nalazi WebSocket,

tako da lokacija primjerice izgleda ovako: ws://192.168.5.14:8001/jms.

Ako je sve do sada urađeno ispravno, omogućena je komunikacija između

klijenata na vezi.