SVEUILITE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

DIPLOMSKI RAD br. 2859

Sustav za distribuirano slanje i primanje

SMS i MMS poruka
Jakov Semenski

Zagreb, srpanj 2007.

Mentor rada: prof. dr. sc. Igor S. Pandi

Zahvaljujem mentoru prof. dr. sc. Igoru Pandiu

na svesrdnoj pomoi u izradi ovog rada

Ime i prezime:

Jakov Semenski

Naslov rada:

Sustav za distribuirano slanje i primanje SMS i MMS poruka

Saetak:

U okviru diplomskog rada napravljen je sustav za slanje i

primanje SMS, MMS,WAP Push i binarnih poruka razliitim
kanalima izmeu raunalnog sustava i mobilnog ureaja
korisnika, uz mogunost administriranja i kontrole pristupa
korisnika, te mjerenja i ograniavanja broja poslanih poruka.
Izraen je SDK (engl. Software Development Kit) klijenta za
slanje i prijem mobilnih poruka u jezicima Java i C# koji
implementiraju sve funkcije klijentske strane, te slui za
implementaciju konkretnih klijentskih aplikacija.
U radu je prikazano funkcioniranje Platforme za isporuku
usluga (Service Delivery Platform) i Parlay X suelja. Opisan
je rad Web-servisa i odgovarajuih protokola i detaljno je
razraen nain konfiguriranja i implementiranja web servisa za
slanje i primanje svih tipova poruka. Takoer su razraene
tehnologije JSP (Java server pages) i Servlet za generiranje
dinamikog sadraja na posluiteljima, te je objanjen koncept
konfiguriranja i proirenja sustava novim funkcijama i
kanalima za slanje i primanje poruka.

Sadraj
Skraenice .................................................................................................................................. 7
Popis stranih izraza..................................................................................................................... 8
Uvod ........................................................................................................................................... 9
1.

2.

3.

4.

Osnovni koncept ............................................................................................................... 11

1.1.

Arhitektura sustava ................................................................................................... 13

1.2.

Komunikacija ........................................................................................................... 14

1.2.1.

Komunikacija SMS/MMS Gatewaya s operaterom tel. usluga........................ 14

1.2.2.

Komunikacija raunalnih korisnika sa SMS/MMS Gatewayom .................. 16

1.3.

Sustav za administriranje ......................................................................................... 17

1.4.

Izvedba sustava ........................................................................................................ 17

Platforma za isporuku usluga ........................................................................................... 19

2.1.

Arhitektura i funkcionalni elementi ......................................................................... 20

2.2.

Komunikacija s platformom ..................................................................................... 21

Parlay ................................................................................................................................ 22
3.1.

Parlay tehnologija ..................................................................................................... 22

3.2.

Parlay APIs ............................................................................................................... 23

3.3.

Parlay implementacije .............................................................................................. 23

3.4.

PARLAY X .............................................................................................................. 23

3.4.1.

Postupak slanja SMS-a ..................................................................................... 25

3.4.2.

Postupak primanja SMS-a ................................................................................ 26

3.4.3.

Postupak slanja MMS-a ................................................................................... 27

WEB SERVISI ................................................................................................................. 28

4.1.

Sloj protokola Web servisa ...................................................................................... 29

4.1.1.

SOAP- Simple Object Access Protocol ........................................................... 30

4.1.2.

SOAP poruka.................................................................................................... 31

4.2.

5.

WSDL....................................................................................................................... 32

4.2.1.

Prijenosni oblik funkcionalnosti....................................................................... 33

4.2.2.

Opisni oblik funkcionalnosti ............................................................................ 34

Dinamike web stranice ................................................................................................... 35

5.1.

Servlets i Java server pages ...................................................................................... 35

5.1.1.

6.

Servlet............................................................................................................... 35

5.2.

Java Server Pages (JSP) tehnologija ........................................................................ 39

5.3.

MVC arhitektura ...................................................................................................... 41

5.3.1.

Male i srednje aplikacije .................................................................................. 41

5.3.2.

Velike aplikacije ............................................................................................... 41

Primjeri aplikacija ............................................................................................................ 43

6.1.

Implementacija ......................................................................................................... 43

6.1.1.
6.2.

Baza podataka .......................................................................................................... 44

6.2.1.
6.3.

Tehnologije....................................................................................................... 43

Podaci o tablicama ........................................................................................... 44

Aplikacija za slanje i primanje poruka ..................................................................... 46

6.3.1.

Arhitektura ....................................................................................................... 46

6.3.2.

Organizacija koda ............................................................................................. 47

6.3.3.

Aplikacijska logika ........................................................................................... 48

6.3.4.

Model ............................................................................................................... 55

6.3.5.

Pristup Vipnet-ovoj infrastrukturi .................................................................... 58

6.3.6.

Slanje i primanje poruka .................................................................................. 60

6.3.7.

Primanje poruka ............................................................................................... 62

6.4.

Aplikacija za administriranje ................................................................................... 65

6.4.1.

Arhitektura ....................................................................................................... 65

6.4.2.

Organizacija koda i implementacija ................................................................. 67

6.4.3.

Prezentacijski sloj ............................................................................................. 68

6.4.4.

Aplikacijska logika ........................................................................................... 75

6.4.5.

Model ............................................................................................................... 79

6.5.

Korisnike aplikacije ................................................................................................ 80

6.5.1.

SDK u jezicima Java ........................................................................................ 81

6.5.2.

SDK u jezicima C# ........................................................................................... 83

6.6.

Web servis klijenta za primanje poruka ................................................................... 84

Zakljuak .................................................................................................................................. 85
Literatura .................................................................................................................................. 86

Skraenice
CORBA Common Object Request Broker Architecture
DCE

Distributed Computing Environment

DTD

Document Type Definitions

HINA

Hrvatska Izvjetajna novinska agencija

J2EE

Java 2 Enterprise Edition

JDBC

Java Database Connectivity

JSP

Java Server Pages

JVM

Java Virtual Machine

MMS

Multimedia Messaging Service

MVC

Model View Controller

PHP

Hypertext Preprocessor

RMI

Remote Method Invocation

RPC

Remote Procedure Call

SDK

Software Development Kit

SDP

Service Delivery Platform

SMS

Short Message Service

SMTP

Simple Mail Transfer Protocol

SOAP

Simple Object Access Protocol

SQL

Standard Query Language

UDDI

Universal Description, Discovery and Integration

UML

Unified Modelling Language

WAP

Wireless Application Protocol

WSDL

Web Services Definition Language

XML

Extensible Markup Language

Popis stranih izraza

envelope

omotnica

form

forme

header

zaglavlje

fault

greka

gateway

pristupnik (mrei s razliitim protokolom)

provide

omoguiti

session

sesija

Uvod
Komunikacijske tehnologije danas u velikoj mjeri odreuju nain ivota i uzrokuju mnoge
drutvene promjene. U uvjetima globalnog trita tehnoloke inovacije su gotovo istovremeno
prisutne u svim dijelovima svijeta. Deregulacijom telekomunikacijskog trita otvorena je
mogunost za privatno poduzetnitvo i pravo trino natjecanje u podruju komunikacija, a to
je omoguilo pojavu novih operatera, usluga i tehnologija.
Mobilna telefonija oduzima korisnike fiksnoj telefoniji, pa iako je prijenos glasa i dalje
najisplativija usluga, vodei operateri ulau velika sredstva u izgradnju mrenih platformi
koje podravaju daljnji razvoj i proirenje dananjih mrea novim hardverskim i softverskim
elementima. Ti elementi omoguuju jednostavno kreiranje novih usluga te koritenje
otvorenih standardnih tehnologija, poput web usluga, uz smanjenje trokova poslovanja.

Openito o mobilnim uslugama

Mobilna tehnologija u znatnoj mjeri utjee na svakodnevni ivot velikog broja ljudi. U
Hrvatskoj je vie od 3,5 milijuna korisnika mobilnih telefona, a sve je vie i operatera koje
nude usluge mobilne telefonije. Konkurencija meu operaterima potie razvoj usluga koje
korisnicima stoje na raspolaganju.
Mobilne usluge su idealan kanal putem kojeg se korisnicima moe ponuditi jedinstven pristup
raznim informacijama i podacima, ali i mogunost da i sami razvijaju usluge. Razvojni ciklusi
novih usluga su sve krai, a razlike u uslugama namijenjenim poslovnim ili malim
korisnicima su sve manje.
Mobilni pristup elektronikoj poti, sinkronizacija s PC raunalima, WiFi moduli, koritenje
internetskih preglednika postali su standardni zahtjevi mobilnih korisnika, stoga operateri sve
vie surauju s velikim hardverskim i softverskim tvrtkama i nude nove naine za koritenje
dodatnih usluga.

Spajanje Interneta i beinih komunikacijskih mrea dovelo je do revolucionarnih inovacija

na tritu. Mobilni telefon, nekada samo sredstvo glasovne komunikacije, danas sve vie
postaje sredstvo osobne komunikacije, sredstvo pristupa informacijama i sredstvo plaanja.
Koritenje SMS i MMS poruka vrlo je popularan nain komunikacije izmeu korisnika
mobilnih ureaja. Veina (ako ne i svi) danas upotrebljavani mobilni telefoni podravaju
takav nain komunikacije.
Ono to je trenutano glavni nedostatak mobilnoga Interneta je dostupnost bogatog sadraja
kao to su glazba, slike u boji, fotografije i video. Svi ovi tipovi sadraja, ve dostupni
prilikom pristupa Internetu preko osobnog raunala, nedostaju prilikom mobilnoga pristupa
Internetu. Uvoenjem usluge multimedijskih poruka (engl. Multimedia Messaging, skraeno
MMS) oekivanja krajnjih korisnika napokon e biti ispunjena. Ta usluga tekstualnim
sadrajima dodaje audio i video sadraje. MMS je sljedei korak u evoluciji usluga
zasnovanih na komunikaciji porukama i smatra se kljunom uslugom u mreama druge
generacije te u mreama s poboljanom podatkovnom komunikacijom.

10

1. Osnovni koncept
Cilj ovog rada je napraviti SMS/MMS Gateway sustav za eksperimentalno slanje i primanje
SMS, MMS, WAP Push i binarnih poruka razliitim kanalima izmeu raunalnog sustava i
mobilnog ureaja korisnika, uz mogunost administriranja i kontrole pristupa korisnika te
mjerenja i ograniavanja broja poslanih poruka.
Ovaj projekt je osmiljen kako bi osim slanja standardnih poruka korisnicima omoguio
definiranje vlastitih poruka, proirenja postojeih i stvaranje novih usluga. Korisnicima daje
potpunu slobodu kod naina pristupa infrastrukturi za slanje i primanje poruka te odabiru
tehnologije za realizaciju pristupa SMS/MMS Gatewayu.
Prednosti ovakvog sustava: korisniku se, osim postojeih formata za slanje poruka, nudi
mogunost definiranja vlastitih poruka kao i stvaranje novih usluga korisnicima mobilnih
ureaja.
Slika 1.1 prikazuje radnu shemu SMS/MMS Gatewaya, odnosno razmjenu poruka korisnika
raunalnog sustava s korisnicima mobilnih ureaja.

R
n
je
m
az
a
ka
ru
po

Sl 1.1 Koncept razmjene poruka preko SMS/MMS Gatewaya

11

Korisnici raunalnog sustava alju SMS/MMS poruke Gatewayu kroz odreene kanale
koristei vlastite ili ve postojee aplikacije (web preglednik, e-mail ) uz njima pripadajue
protokole (HTTP, SOAP, IMAP, itd.). Gateway provjerava korisnike podatke i ukoliko
korisnik ima prava za slanje, poruka se prosljeuje drugim kanalima prema operateru
telekomunikacijskih usluga (Web servis, gsm modem, itd.). Svaki kanal prema operateru ima
svoj pretplatniki broj tako da poruka poslana od vie korisnika kroz isti kanal prema
operateru ima jednak izlazni broj.

Sl 1.2 Slanje poruka preko razliitih kanala mobilnim ureajima

Na slian nain provodi se i primanje poruka. Korisnici mobilnih ureaja alju poruku na
jedan od pretplatnikih brojeva kanala SMS/MMS Gateway. Gateway provodi filtriranje
poruka prema broju s kojeg je poslana i prema sadraju poruke.

Korisnik 1

Tekst: AAA
Od: 09133333

Tekst: AAA

Primanje poruka

Korisnik 2

Tekst: CCC
Od: 09155555

...

Slanje poruka

SMS/MMS Gateway
BROJ
09133333

09144444

TEKST
CCC

Korisnik N

Tekst: BBB
Od: 09144444

KORISNIK

KORISNIK
2

Broj: 09133333

Tekst: BBB

Broj: 09144444

Tekst: CCC

Broj: 09155555

Sl 1.3 Primanje i filtriranje poruka razliitih korisnika mobilnih ureaja

12

Popis filtera sadran je u tablici filtera koja se aurira pri unosu svakog korisnika. Nakon
filtriranja, poruka se prosljeuje korisniku po kanalu (web servis, e-mail, itd.) koji je takoer
posebno definiran za svakog korisnika

1.1. Arhitektura sustava

Sustav ine elementi hardverskih sklopova i odgovarajue softverske podrke koji zajedno
omoguavaju razmjenu poruka izmeu raunalnog sustava i mobilnog ureaja korisnika.
Interaktivni sustav podrazumijeva dvosmjernu razmjenu informacija, to u sluaju SMS/MMS
Gatewaya s korisnicima raunalnog sustava i korisnicima GSM mree, znai da postoji
dvosmjerna komunikacija izmeu korisnikova mobilnog ureaja i raunalnog sustava
koristei se pritom uslugama mobilne telefonije.
Sljedea slika prikazuje globalni pregled rada SMS/MMS Gatewaya.
SMS/MMS Gateway
Baza
podataka

Operater
telekomunikacijskih
usluga

Korisnik
HTTP posluitelj
slanje poruka

Kanal za
prijem poruka

Logika za slanje poruka

Kanal za
slanje poruka

slanje poruka

Kanal za
prijem poruka

primanje poruka

Logika za primanje poruka

primanje poruka

Kanal za
slanje poruka

Logika za administriranje

Web
preglednik
Administrator

Sl 1.4 Arhitektura SMS/MMS Gatewaya

Sustav je podijeljen je u 3 kategorije te su za svaku definirane sljedee funkcije:

13

Logika za slanje poruka s raunalnog sustava na mobilni ureaj:

podrava slanje SMS, MMS, WAP Push i binarnih poruka razliitim kanalima

podrava dodavanje novih kanala za slanje i primanje poruka

podrava sigurnu dostavu poruka

Logika za prijem poruka s mobilnog ureaja na raunalni sustava korisnika:

podrava vie kanala za prijem poruka s mobilnog ureaja

podrava registraciju vie klijenata za prijem poruka preko razliitih kanala

podrava filtriranje odnosno prosljeivanje poruke klijentu prema ulaznom kanalu,

poiljaocu i sadraju poruke

omoguuje modularno dodavanje vie naina za komunikaciju izmeu Gatewaya i

klijenta

Alat za konfiguraciju sustava:

omoguuje konfiguriranje sustava preko web suelja: izlaznih i ulaznih kanala i ostalih
parametara sustava

omoguuje definiranje korisnika sustava (za autorizaciju klijenata) te njihovih prava

(slanje poruka, registriranje klijenta za prijem, profil klijenta prijem samo kroz
odreene kanale)

omoguuje nadzor rada sustava preko web suelja u realnom vremenu (registrirani
klijenti za slanje i prijem poruka, obavljene transakcije)

vodi evidenciju o poslanim i primljenim porukama, ukljuujui i vrijeme zahtjeva te

vrijeme izvrenja zahtjeva (za slanje ili za prijem)

prosljeivanje greaka administratoru u obliku tekstualnog zapisa (log datoteke)

1.2. Komunikacija
1.2.1.

Komunikacija SMS/MMS Gatewaya s operaterom tel. usluga

Zavod za telekomunikacije dobio je pristup SMS/MMS infrastrukturi tvrtke VIPnet, odnosno

platformi za isporuku usluga preko jednog posluitelja.

14

Kako bi se to vie olakao razvoj usluga, Vipnet je komunikaciju zasnovano na web

servisima, ime je jednostavnost suelja prema osnovnim mrenim uslugama i elementima
osigurana. Web servisi su osobito znaajni u otvaranju apstraktnog suelja prema osnovnim
mrenim uslugama i elementima, te je cijela komunikacija zasnovana je na Parlay X
standardu (http://www.parlay.org).
Na ovaj nain omoguen je pristup Vipnet-ovoj infrastrukturi putem standardiziranog suelja
bez poznavanja sloenih protokola za komunikaciju. Osigurana je mogunost da se jednom
razvijene usluge ponude i na tritima izvan Hrvatske meu operaterima koji koriste Parlay X
specifikaciju suelja za komunikaciju.
Osim web servisa, u suradnji sa HINA-om, Zavod za telekomunikacije trebao je dobiti na
koritenje GSM modem kao drugi kanal za slanje poruka. Kako modem jo nije isporuen,
komunikacija sa GSM modemom nije implementirana, ali postoji podrka za dodavanje novih
kanala.

Slanje poruka
Slanje poruka vri se pozivom web servisa na strani VIPneta.
Vipnet je FER-u omoguio pristup sljedeim uslugama
SMS

Slanje
mogue slati jednu poruku na vie korisnika odjednom
Slanje s notifikacijom
ukoliko se poruka alje kroz ovo suelje, korisnik smije slati poruku jednom
korisniku pri emu VIPnet alje dojavu o isporuci poruke
Binarne poruke

MMS

Slanje
mogue slati na vie korisnika odjednom
mogue dodati neogranien broj priloga razliitog formata

WAP Push

Slanje
mogue slati prema vie korisnika

15

Primajne poruka
Primanje poruka se takoer izvodi putem web servisa, no u ovom sluaju VIPnet poziva web
servis na strani SMS/MMS Gatewaya. Zbog toga je implementiran web servis na HTTP
posluitelju koji slua dolazee poruke SMS-a, MMS-a i statusa poslane poruke od strane
VIPnet Gatewaya. Usluga primanja MMS trenutno nije dostupna, ali je implementirana.

1.2.2.

Komunikacija raunalnih korisnika sa SMS/MMS

Gatewayom

Slanje poruka korisnicima

Slanje poruka korisnicima vri se na 2 naina, putem web servisa ili putem e-maila. Za
primanje poruka preko web servisa korisnici na svojoj strani moraju imat http posluitelj sa
postavljenim web servisom koji e prihvaati poruke. Kako implementacija i konfiguriranje
sustava nije jednostavna, korisnicima je omogueno primanje SMS poruka i informacija o
statusu poruka putem e-maila.

Primanje poruka od korisnika

Da bi omoguili korisnicima koritenje svih usluga VIPnet-a, na slian nain implementirano
je i primanje poruka, to se realizira pozivom web servisa na strani SMS/MMS Gatewaya.
Uz definiranje svih komunikacijskih kanala, prikaz cjelokupne arhitekture SMS/MMS
Gatewaya izgleda ovako:

16

SMS/MMS Gateway
Baza
podataka

Operater
telekomunikacijskih
usluga

Korisnik
HTTP posluitelj
Logika za slanje poruka
slanje poruka
slanje poruka

Web servis

Web servis

GSM modem

slanje i primanje
poruka

Logika za primanje poruka

Web servis

slanje poruka

Preglednik
elektronike
pote

primanje poruka E-mailom

Web servis

primanje poruka

Logika za administriranje

Web
preglednik
Administrator

Sl 1.5 Proirena arhitektura SMS/MMS Gatewaya

1.3. Sustav za administriranje

Svaki novi sustav mora sadravati suelje prema administratoru kako bi se mogle izvravati
sve potrebne promjene. Pristup administratora izveden je preko web suelja, odnosno web
aplikacije koja implementira sve gore navedene funkcije, izmeu ostalog, podrava
pojednostavljeno pretraivanje transakcija i samih korisnika.

1.4. Izvedba sustava

SMS/MMS Gateway je u potpunosti razraen na tehnologijama otvorenog koda (engl. Open
source technology) u Javi odnosno koritenjem J2EE standarda. Izveden je u troslojnoj
(MVC) arhitekturi, ime se omoguava vea skalabilnost, fleksibilnost i prilagodljivost
sustava te omoguuje proirenja i nadogradnje bez strukturnih promjena u jezgri aplikacije.

17

SMS sustav ine elementi hardverskih sklopova i odgovarajue softverske podrke koji
zajedno omoguavaju razmjenu poruka izmeu raunalnog sustava i mobilnog ureaja
korisnika.

18

2. Platforma za isporuku usluga

Platforma za isporuku usluga (engl. Service Delivery Platform, skraeno SDP), oblikuje,
upravlja, odrava i isporuuje komunikacijske usluge.
Jedinstvena platforma

za isporuku usluga treba omoguiti fiksnim i mobilnim

telekomunikacijskim operaterima da u svoju ponudu to jednostavnije i bre uvode nove,

inovativne podatkovne i glasovne usluge. Ona predstavlja kompletno okruenje za brzi razvoj,
uvoenje u rad, izvoenje, upravljanje i naplatu modernih telekomunikacijskih usluga.
Ujedinjuje razliite mogunosti mree, usluga i razliite izvore sadraja, a kroz standardno i
pojednostavljeno suelje te resurse stavlja na raspolaganje programerima. SDP omoguuje
vanjskim partnerima ili drugim operaterima da koriste interne resurse mree u vlasnitvu
odreenog pruatelja usluga.
Funkcije platforme za isporuku usluga:

SDP predstavlja okruenje za brzi razvoj, uvoenje u rad, izvoenje, upravljanje i

naplatu modernih telekomunikacijskih usluga.

SDP podrava implementaciju glasovnih i podatkovnih usluga neovisno o tipu mree

ili ureaja na kojima se te usluge izvode.

SDP ujedinjuje razliite mrene funkcionalnosti i izvore sadraja i stavlja ih na

raspolaganje razvojnim inenjerima putem standardnog i pojednostavljenog
programskog suelja.

SDP vanjskim partnerima ili drugim pruateljima komunikacijskih usluga daje

mogunost koritenja internih mrenih resursa koji su u vlasnitvu odreenog
operatera.

SDP je dio IT infrastrukture odreenog operatera, a ne dio njihove osnove

telekomunikacijske mree.

SDP slui kao integracijski sloj izmeu resursa mree, vanjskih javnih usluga,
vanjskih partnera, razliitih ureaja te na posljetku krajnjih korisnika.

19

2.1. Arhitektura i funkcionalni elementi

Jo uvijek ne postoji industrijski prihvaena, referenta arhitektura SDP rjeenja. SDP je
zapravo niz povezanih softverskih komponenti, esto od razliitih proizvoaa, koji zajedno
ine integralno rjeenje za upravljanje i stvaranje usluga.
Slika 1 prikazuje osnovne elemente jedinstvenog rjeenja za isporuku usluga.

Sl 2.1 Osnovni elementi SDP rjeenja

Elementi koji zajedno ine jedno cjelovito rjeenje za isporuku usluga su:
Platforma za izvoenje usluga (engl. Service Execution Platform) je telekomunikacijski
aplikacijski posluitelj. To je raunalna platforma na kojoj se izvode same usluge tj.
aplikacije. Ova komponenta je najee bazirana na J2EEi ili .NET tehnologiji (raunalno
okruenje unutar kojeg se u realnom vremenu izvodi niz odvojenih .NET ili EJB procesa
koji meusobno komuniciraju putem web usluga).
Sloj za povezivanje s mreom (engl. Network Abstraction Layer) je integracijski sloj koji
prua pristup do osnovnih mrenih usluga (upravljanje pozivima, naplata, autorizacija
korisnika, SMS, MMS, lokacijske usluge). Glavni zadatak ovog sloja je maskirati

20

kompleksni interni sustav same mree i otvoriti njenu funkcionalnost pomou

standardnih protokola (najee web usluga) i programskih suelja.
Platforma za isporuku sadraja (engl. Content Delivery Platform). Slui za integraciju
dodatnih sadraja u mreu operatera. Takove sadraje vrlo esto nude vanjske partnerske
tvrtke (eng. content provider) i odnose se npr. na isporuku televizijskog programa preko
mobilnog ureaja.
Sloj za objavljivanje i dostavljanje usluga (engl. Service Exposure Layer) na razne naine
koriste mreni operatori. Osnovno pitanje je kako otvoriti programsko suelje prema
mrenim resursima. Implementacija ovog sloja SDP arhitekture omoguava vanjskim
partnerima koritenje mrenih usluga u njihovim aplikacijama, bez potrebe za
specifinim telekomunikacijskim znanjima. Postizanjem vieg nivoa apstrakcije ovog
suelja, jednostavnije je koritenje, ali je manji broj opcija na raspolaganju programeru.
Time se smanjuje i mogunost pogreke ali se istovremeno ograniava krajnji rezultat
novih usluga. Potrebno je pronai pravi balans izmeu jednostavnosti suelja i
mogunosti koje su na raspolaganju za kreiranje specifinih usluga.
Na taj nain je takoer mogue proiriti poslovne aplikacije s telekomunikacijskim
komponentama npr. CRM sustavi s informacijama o lokaciji korisnika u realnom vremenu,
SMS upozorenja za kalendare ili elektroniku potu i dr.
Otvaranjem ovakvih mogunosti krajnjim korisnicima i programerima koji e pomou njih
razvijati

aplikacije,

zapravo

se

pojavljuje

itava

nova

industrija

koja

koristi

telekomunikacijske resurse kako bi stvorili usluge s dodatnom vrijednou.

2.2. Komunikacija s platformom

Upravo na mogunostima i nainu funkcioniranja SDP-a razvile su se nove usluge koje je i
Vipnet ponudio svojim korisnicima. Kroz web servise za otvaranje apstraktnog suelja prema
osnovnim mrenim uslugama i elementima i komunikaciju zasnovanu na Parlay X standardu,
Vipnet je omoguio korisnicima pristup svojoj infrastrukturi putem standardiziranog suelja
bez poznavanja sloenih protokola za komunikaciju, a time i potencijalno irenje poslovanja
na druga trita koja koriste Parlay X standard.

21

3. Parlay
1998 godine je osnovana organizacija Parlay Group, iji je osnovni cilj standardizacija
programskih suelja telekomunikacijskih mrea. Do sada su proizveli itav niz preporuka za
standardizaciju programskih suelja (engl. API) koja omoguuju vanjskim partnerima
koritenje usluga telekomunikacijske infrastrukture.
Najznaajnija Parlay suelja ukljuuju kontrolu poziva, konferencije, interakciju sa
korisnikom (audio i tekstualna komunikacija) i naplaivanje. Suelja su specificirana u
CORBA Interface definition language i WSDL-u. Koritenje CORBA programskog jezika
omoguuje komunikaciju na daljinu izmeu aplikacije na korisnikoj strani i Parlay
Gatewaya. Najvea uloga suelja jest da bude neovisan o tehnologiji koju koriste
telekomunikacijske mree(e.g. CDMA vs GSM vs landline SS7).
2003. godine Parlay Group je definirala skup programskih suelja - nazvan Parlay X. To je
najire prihvaen standard potpuno baziran na tehnologiji web usluga. Suelje je
pojednostavljeno, namijenjeno veem broju korisnika.
Parlay grupa usko surauje sa ETSI i 3GPP, a unutar 3GPP-a Parlay je dio Open Services
Architecture, pa se esto koristi izraz Parlay/OSA

3.1. Parlay tehnologija

Uloga Parlay/OSA jest da omogui (engl. provide) suelje neovisno o mrenoj tehnologiji i
programskom jeziku za kreiranje novog web servisa. Kao rezultat Parlay/OSA API (engl. API
Application Program Interface) su specificirani u UML-u (engl. Unified Modelling Language,
skraeno UML), tako da postoje razliite realizacije ili mapiranja za pojedina programska
okruenja:

CORBA/IDL

Java

WSDL

Parlay Framework

22

Vano je za operatora telekomunikacijske mree da zna kako koritenje bilo kojeg Parlay
suelja ne moe utjecati na sigurnost i integritet mree. Uloga Parlay/OSA Framework jest da
omogui mrei nain za verifikaciju aplikacija koje koriste Parlay/OSA API. Framework
jednako tako dozvoljava aplikacijama da otkriju mogunosti mree i omoguuje upravljake
funkcije u sluajevima pojave greaka i preoptereenosti.

3.2. Parlay APIs

Parlay servis APIs prikazuje se kao aplikacija koja izvrava telefonski poziv, odreuje
lokaciju osobe (terminala) ili naplauje skidanje melodija.

3.3. Parlay implementacije

Parlay/OSA specifikacije definiraju API, a ne govore kako suelje treba biti implementirano.
Tipina implementacija Parlay/OSA dodaje novi mreni element Parlay/OSA Gateway koji se
implementira u Framework. Gateway moe implementirati pojedinani servis API-a ili moe
interaktivno djelovati sa ostalim elementima mree kao to su sklopovi za omoguavanje
individualnih servisa (npr. kontrola poziva ili lokacije). Neki isporuitelji tretiraju
Parlay/OSA izlaz kao samostalan element mree (Ericsson NRG), a drugi ga ukljuuju kao
funkciju u IN Service Control Point (Telcordia OSP).

3.4. PARLAY X
Parlay Group je definirala skup programskih suelja baziranih na web uslugama, nazvan
Parlay X. Web usluge su prvenstveno razvijene kao B2B84 integracijski mehanizam, dok je
CORBA zamiljena kao rjeenje za povezivanje aplikacija unutar tvrtke. Web usluge se
baziraju na HTTP protokolu i tako jednostavno prolaze kroz korporativne vatrozide, a
podrava ih i veina velikih proizvoaa softvera. Izuzetno prikladno za razvoj jednostavnijih
web aplikacija koje putem web usluga koriste telekomunikacijske resurse. Uslijed velikog
porasta popularnosti web usluga na Internetu, i sam Parlay X je dobio na vanosti. Mogue ga
je zamisliti kao jednostavan prikaz osnovnih komunikacijskih funkcionalnosti u obliku web
usluga kao to su slanje i primanje SMS-a i MMS-a, lociranje korisnika, poziv prema treoj
osobi (third party call, naplaivanje, notifikacija poziva, itd.). Ove web usluge su zamiljene
kao organizirane skupine metoda koje predstavljaju razliite grupe telekomunikacijskih

23

funkcionalnosti. Namijenjene su u prvom redu vanjskim razvojnim inenjerima od kojih se ne

oekuje posebno telekomunikacijsko znanje.
Svaki Parlay X web servis treba apstrahirati (izvui, izolirati) od niza telekomunikacijskih
mogunosti izloenih od Parlay API-a. Shematski prikaz nivoa apstrakcije i relacije ParlayParlay X moe se prikazati grafiki

Parlay X
Applications
Parlay
Applications
Increasing
abstraction

Parlay X APIs
Parlay X Web Services

Parlay APIs
Parlay Gateway
Network Protocols
(e.g. SIP, INAP etc)

Network Elements

Sl 3.1 Parlay programska suelja

Slika 3.1 prikazuje odnose izmeu Parlay X suelja i Parlay programskog suelja (API).
Aplikacijom se smatra bilo koji softver koji putem Parlay X web usluga komunicira s Parlay
platformom. Aplikacija moe biti Java program, .NET komponenta, PHP program ili obina
XML skripta. Te aplikacije mogu biti pisane u bilo kojem programskom jeziku i izvoene na
bilo kojoj raunalnoj platformi sve dok potuju definiranu sintaksu web usluga i pravilno
interpretiraju rezultate izvoenja ovih web usluga. Skupina web usluga nazvana Parlay X je
samo pojednostavljeni prikaz nieg Parlay programskog suelja direktno integriranog s
mreom.

24

Parlay X skupina web usluga ima sljedee zajednike karakteristike:

Svaka usluga je nastala iz skupa povezanih telekomunikacijskih funkcionalnosti, a

pri njihovoj fizikoj implementaciji vea se panja posvetila jednostavnosti
koritenja nego potencijalnim funkcionalnostima.

Interakcija izmeu aplikacija koje koriste Parlay X web usluge i posluitelja kojim je
implementirana Parlay platforma, vri se putem izmjene standardnih XML podataka
tj. SOAP poruka.

WSDL jezik je izabran za iniciranje i opis Parlay X web servisa.

Parlay X web usluge koriste jednostavnu aplikativnu semantiku pa se razvojni

inenjeri mogu u potpunosti fokusirati na stvaranje novih vrijednosti kroz svoje
aplikacije.

Parlay X web usluge su potpuno neovisne o mrenoj opremi ili vrsti

telekomunikacijske mree. Ta odlika im omoguava da aplikacije pisane za Parlay
suelja budu iskoristive i u mreama sljedee generacije.

Ove web usluge su samo programska suelja i kao takve ne pruaju funkcionalnosti
za autorizaciju, autentifikaciju ili naplatu koritenja mrenih resursa. Koritenjem
ve prethodno navedenih mehanizama u arhitekturi usmjerenoj uslugama, nove
aplikacije preko Parlay suelja mogu pristupati specijaliziranim IT sustavima u mrei
operatera gdje te funkcije i prirodno pripadaju: sustav naplate, sustav za kontrolu
pristupa, aktivaciju usluga i ostali sustavi za potporu poslovanju.

3.4.1.

Postupak slanja SMS-a

Slika 3.2 prikazuje jedan primjer koritenja SMS web servisa za slanje SMS poruke iz
aplikacije za pretplatnika na uslugu o vremenskoj prognozi. Aplikacija poziva web servis da
preuzme informacije o vremenu te ih proslijedi pretplatniku (1, 2) i koristi Parlay X suelje za
koritenje SMS web servis metoda za slanje SMS-a (3). Nakon pozivanja, SMS web servis
poziva Parlay X API metodu (4) koristei Parlay/OSA SCS-SMS suelje. Dalje operator
proslijeuje poruku pretplatniku (5, 6).

25

Weather
Info
Info meteo
Web
Service
Web Service

SMS Web
SMS-X
Service
component

Parlay X I/F

SCS-SMS
SCS-SMS
4
Parlay API

1
3
..
getMeteoInfo()
..
Retrieve
user Profile
.
2

Parlay Gateway

5
You have
a new SMS
Weather info

SMS-C
SMS-C

Mobile network

SendSms (
Weather info
..,,,)

User
profile

Sl 3.2 Postupak slanja SMS-a

3.4.2.

Postupak primanja SMS-a

Slika 3.3 prikazuje postupak primanja SMS-a koritenjem SMS web servisa. Aplikacija prima
poziv Parlay X web servisa za prihvaanje SMS-a poslanog od pretplatnika (1, 2). SMS
poruka sadri e-mail adresu osobe koju pretplatnik eli nazvati. Aplikacija poziva Parlay
suelje (3) prema Third Party Call web servisu zbog realizacije traenog zahtjeva (4).
4

Third Party
Call
3PC-X
Web Service
component
SMS
Web
SMS-X
Service
component

Parlay X I/F
3

Mobile network

Parlay X I/F

SOAP

SOAP

Call
mary@company.com

..
2
notifySmsReception()
{..
Retrieve
user number
.
2
User
profile

makeACall(..,,,)

Sl 3.3 Postupak primanja SMS-a

26

3.4.3.

Postupak slanja MMS-a

Slika 3.4 prikazuje postupak koritenja sendMessage i getMessageDeliveryStatus metoda za

slanje podataka pretplatniku i provjere statusa poruke. Aplikacija poziva web servis za
dohvaanje podataka (1, 2) i slanje sendMessage metodom (3) koristei Parlay X suelje
Multimedia Message web servisa. Nakon toga operator prosljeuje MMS poruku pretplatniku
koristei mobilnu mreu (5, 6).

Stock
StockQuote
Quote
Web
WebService
Service

Multimedia
Message
MMSCWeb
-X
Service
component

Parlay X I/F

4
MMS-C
MMSC
MM7 VASP
Interface

1
3

User
profile

..
content1 =get StockQuote ()
..
Retrieve
user Profile
.
messageId= sendMessage( content )
.
status= getMessageDeliveryStatus
(messageId)
if status=Message_Waiting
.
fi

content2 =get StockQuote ()

messageId= sendMessage ( content2 )

Mobile network
6

Sl 3.4 Slanje MMS poruke

27

4. WEB SERVISI
Web usluge postaju sve znaajnije pri stvaranju apstraktnog suelja izmeu mrenih resursa i
vanjskih partnera. Temelje se na iroko prihvaenim industrijskim standardima poput HTTP-a
i XML-a. Prilikom objavljivanja mrenih resursa vanjskim partnerima, tehnologija web
usluga se ponovno namee kao logian izbor je se takva komunikacija odvija upravo putem
Interneta i standardnog HTTP-a.
Web servisi su aplikacije (komponente ili moduli) koje egzistiraju u distribuiranim
okruenjima poput Interneta ili privatnih LAN-ova, objavljuju se na jedinstvenoj lokaciji i
nude kao odreene usluge. Kako bi usluga bila kompletna nudi se i potpuna specifikacija
suelja, poslovnih zahtjeva, kvaliteta servisa, pravnih i financijskih uvjeta koritenja. Resursi
se adresiraju primjenom URL-a koji vraa informaciju korisniku koji je eli koristiti
Njihovo funkcioniranje temelji se na request-response paradigmi gdje request i response
mogu biti dio jedne operacije (synchronous model) ili se mogu pojaviti odvojeno
(asynchronuous model). Komunikacijski model se temelji na postojanju tzv. service providera
i service requestora koji komuniciraju koritenjem SOAP protokola tj. XML preko HTTP-a.

Sl 4.1 Komunikacija SOAP protokolom

28

Web servis usluge opis suelja nude dovoljno detaljno kako bi se mogla izgraditi korisnika
aplikacija koja bi ih koristila. Navedeni opis ponuen je u obliku XML dokumenta koji je
pisan u WSDL jeziku.

Sl 4.2 Komunikacija web servisa

Prednosti web servisa u odnosu na klasine web aplikacije su:

fleksibilnost - mogu ih koristiti najrazliitiji programi i ureaji:

drugi web servisi

same web aplikacije
GUI programi
mobilni telefoni
pocketPC

tedljivost - rastereenje mree i resursa

jednostavnost - laki za razvoj, testiranje i odravanje

4.1. Sloj protokola Web servisa

Sloj protokola se stalno razvija i koristi da definira, otkriva i implementira web servise.
Osnova ovih protokola lei u sljedea etiri nivoa:
ServiceTransport - nivo odgovoran za prijenos poruka izmeu aplikacija i u njega su

trenutno ukljueni HTTP, SMTP i FTP, te novi protokoli kao to je BEEP (engl. Blocks
Extensible Exchange Protocol, skraeno BEEP)
XMLMessaging - nivo odgovoran za razumijevanje poruka za razmjenjivanje koje se

implementiraju

XML

formatu

trenutno

se

koristi

XML-RPC

(engl.

XMLRemoteProcedureCall, skraeno XML-RPC) i SOAP

Service Description - definira javno suelje za odreeni Web servis i trenutno se opisuje kroz

WSDL (engl. WebService Description Language, skraeno WSDL)

29

Service Discovery - centraliziranje servisa u zajedniki i jedinstven registar koji osigurava

jednostavno objavljivanje i pronalaenje servisa, a to se postie pomou UDDI-a (engl.

Universal Description, Discovery and Integration, skraeno UDDI)

4.1.1.

SOAP- Simple Object Access Protocol

SOAP je komunikacijski protokol namijenjen za razmjenu strukturiranih podataka u

necentraliziranom, distribuiranom okruenju. Koristi se XML-om za prijenos strukturiranih
poruka, koje je mogue razmjenjivati neovisno o prijenosnom protokolu. SOAP protokol
definira kako te poruke trebaju izgledati i kako ih prenijeti. SOAP ne definira sadraj i
redoslijed razmjene poruka jer to ovisi o Web servisu koji koristi. SOAP protokol omoguuje
komunikaciju izmeu aplikacija na razliitim operacijskim sustavima, na razliitih
platformama i pisanih u razliitim programskim jezicima.
SOAP protokol moe biti vezan uz protokole nie razine poput SMTP (engl. Simple Mail
Transport Protocol) ili TCP/IP (engl. Transmission Control Protocol / Internet Protocol)

protokola, iako se najee koristi vezan uz HTTP (engl. Hypertext Transfer Protocol)
protokol. HTTP protokol je podran na veini platformi i kao takav osnovni je aplikacijski
protokol globalne mree. Veina kompanija posjeduje raunalnu mrenu infrastrukturu koja
podrava HTTP protokol, kao i strunjake koji poznaju HTTP protokol.
HTTP povezivanje se koristi jer podrava tekstualnu komunikaciju porukama (GET,
POST) to pridonosi jednostavnosti koritenja SOAP poruka te omoguava slobodnu
komunikaciju koritenjem porta 80 tako da se mogu izbjei problemi propusnosti vezani za
vatrozidove. Komunikacija se takoer odvija putem HTTP POST poruka, samo to se klijent i
server trebaju dogovoriti kako prikazati podatke koje funkcija prima i vraa
Najvanija znaajka SOAP protokola je jednostavna implementacija protokola na nizu
sklopovskih i programskih platformi. SOAP protokol je sastavni dio sustava zasnovanog na
web servisima. Arhitekture sustava zasnovanih na uslugama poput DCE (engl. Distributed
Computing Environment) arhitekture ili CORBA (engl. Common Object Request Broker
Architecture) arhitekture koriste mnogo zamrenije komunikacijske protokole. Najvei

nedostatak navedenih protokola je malen broj implementacija te nedostatak strunjaka koji ih

poznaju. Iako SOAP protokol ne nudi sve mogunosti koje mogu komunikacijski protokoli
DCE ili CORBA arhitekture ponuditi, on je dovoljno jednostavan i proiriv da bi postao izbor
IT (engl. Internet Technology, skraeno IT) industrije.

30

4.1.2.

SOAP poruka

SOAP poruka je XML dokument zadanog formata moe prenositi parametre koje treba
predati programskom bloku na obradu ili rezultate obrade podataka.
Ovaj oblik primjene SOAP specifikacije naziva se SOAP RPC (engl. SOAP Remote
Procedure Call). Uz SOAP RPC, SOAP specifikacija previa upotrebu SOAP poruka za

prijenos dokumenata.
SOAP poruka mora zadovoljavati nekoliko pravila:

SOAP poruka mora biti ispravno formatirani XML dokument i koristiti SOAP
omotnicu i SOAP XML prostor imena;

SOAP poruka ne smije sadravati DTD referencu niti posebne naredbe za

procesiranje XML dokumenta

SOAP poruka sastoji se od nekoliko elemenata:

Omotnica- (engl. Envelope)

Obavezna jer identificira XML dokument kao SOAP poruku. Omotnica koristi
xmlns:soap podruje imena (engl. namespace) i uvijek mora imati vrijednost
http://www.w3.org/2001/12/soap-envelope koja definira omotnicu kao SOAP
omotnicu.
Definira okosnicu za odreivanje onoga to se nalazi u poruci, tko je treba
koristiti i kako.
Zaglavlje (engl. header)

Neobavezno - nosi odgovarajue informacije zaglavlja. U zaglavlju se nalaze

informacije o primjeni poruke, identifikatoru prijenosa te podaci o poiljatelju i
primatelju poruke. Format i sadraj podataka ovisi o vrsti SOAP poruke. Ako
se ovaj element koristi unutar SOAP poruke, mora biti neposredno podreen
Envelope elementu.
Tijelo (engl. body)

Obavezno - poruke s podacima o pozivu i odgovoru te porukama o greci koje

su se dogodile tijekom obrade poruka.
Porukama o grekama (engl. fault).
Ovaj dio smjeten je unutar tijela poruke (Body elementa) i nije obavezan. Ako
se tijekom komunikacije dogodila nekakva greka, informacije o nastalim
grekama biljee se unutar Fault elementa. Kodovi greaka propisani su
preporukom SOAP protokola.

31

Sl 4.3 Prikaz strukture SOAP poruke

4.2. WSDL
WSDL (engl. Web Services Definition Language, skraeno WSDL) je opisni jezik pomou
kojega se opisuju suelja web servisa. Opis suelja servisa je XML dokument pisan po
pravilima WSDL jezika, a ukljuuje informacije o skupini prihvatljivih SOAP poruka i o
njihovom prijenosu. Budui da su WSDL dokumenti zasnovani na XML-u, oni su pogodni za
itanje, pisanje ili mijenjanje koritenjem aplikacija koje imaju mogunost obrade XML
dokumenata.
Opis oblika poruka propisan je XML Schema dokumentom, kojim se propisuje ustrojstvo,
sadraj i smisao drugih XML dokumenta, a kojeg su razvili Microsoft i IBM u svrhu
definiranja XML poruka, operacija, te mapiranja prema koritenim komunikacijskim
protokolima. Operacije i poruke su definirane apstraktno tako da omoguuju koritenje
razliitih formata poruke i mrenih protokola.
WSDL dokument definira:
oblik poruka,
web servise u terminima krajnjih toaka (endpoints) koje komuniciraju XML

porukama,
protokol kojim se mora komunicirati sa uslugom,

32

 suelje usluge,
dovoljan je za stvaranje korisnikog programa potroaa usluge.

WSDL se sastoji se od sljedeih XML elemenata:

Definitions

- korijenski (engl. root) element

Types

- slui za definiranje tipova podataka koje usluga koristi

Message

- apstraktna definicija podataka koja slui za komunikaciju korisnika i

davatelja usluge

Operation

- apstraktna definicija operacija koje usluga podrava

Port type

- skup operacija koje podrava jedna ili vie pristupnih toaka Web

usluge
Binding

- konkretan protokol i tip podataka za odreeni port type element

Port

- predstavlja jednu mrenu toku koja se sastoji od mrene adrese i

binding elementa na koji se referira

Service

4.2.1.

- kolekcija port elemenata

Prijenosni oblik funkcionalnosti

Web servisi komuniciraju porukama koje se grade u skladu sa SOAP protokolom. Poruka je
spremna za slanje kada je u obliku SOAP omotnice. SOAP omotnica je oblik poruke koji
putuje raunalnom mreom i sastoji se od SOAP zaglavlja (engl. SOAP header) i tijela SOAP
poruke (engl. SOAP body). Zaglavlje nije nuan dio SOAP omotnice dok je tijelo SOAP
poruke nuan dio SOAP omotnice jer sadri SOAP poruku u XML obliku.
Oblik zapisa podataka koji koristi SOAP protokol je XML jezik. Mehanizam kojim se
kodiraju podaci proiriv je i mogue ga je navesti u svakoj SOAP poruci. Ako se gradi SOAP
poruka za prijenos poziva udaljene funkcije ili za prijenos rezultata izvoenja udaljene
funkcije (engl. Remote Procedure Call SOAP) tada tijelo poruke sadri ulazne parametre
funkcije ili izlazne vrijednosti poziva funkcije. Za kodiranje podataka u ovom obliku SOAP
poruke koristi se jednostavno XML kodiranje. Ako se gradi poruka za prijenos XML

33

dokumenta (engl. Document Style SOAP) tada se podaci zapisuju u skladu sa odreenim XML
Schema dokumentom.
SOAP protokol neovisan je o prijenosnom protokolu nie razine, ali postoje veze SOAP
protokola i veine prijenosnih protokola nie razine poput HTTP, SMTP, POP3, IMAP, JMS i
dugih protokola.
Proirenja SOAP protokola mogu se ostvariti preko SOAP zaglavlja. SOAP zaglavlje moe
sadravati informacije vezane uz siguran prijenos podataka, dodatke o cjelovitosti slijeda
operacija, oznake sljednica ili informacije o upravljanju prijenosom poruka.

4.2.2.

Opisni oblik funkcionalnosti

Opisni oblik funkcionalnosti koristi WSDL dokumente za opis suelja XML Web usluge.
WSDL opis usluge mora sadrati tri dijela: apstraktni dio (to), nain povezivanja sa uslugom
(kako) i nain izvedbe usluge (gdje). Dijelovi opisa mogu biti podijeljeni u vie dokumenata
kako bi se poveale mogunosti ponovnog koritenja dijelova opisa.
Apstraktni dio WSDL dokumenta opisuje tip usluge. Vie pruatelja usluga moe nuditi jedan
tip usluge. U ovom dijelu definirano je logiko suelje XML web usluge. Logiko suelje
XML web usluge opisuje niz operacija koje usluga nudi. Za svaku operaciju definirane su
ulazne i/ili izlazne SOAP poruke koje se izmjenjuju, oblik svake SOAP poruke i tip podataka
koji se koristi za svaki element u SOAP poruci.
Dio WSDL dokumenta koji opisuje nain povezivanja sa uslugom definira oblik veze
logikog suelja sa skupom prijenosnih protokola. Oblik veze odreuje hoe li poruka biti
graena u obliku poziva udaljene funkcije ili u obliku za prijenos XML dokumenta. Oblikom
veze logikog suelja i skupa prijenosnih protokola odreen je nain kodiranja poruke, izbor
XML Schema dokumenta za konstrukciju SOAP omotnice, sadraj zaglavlja SOAP omotnice
i prijenosni protokol koji se koristi.
Dio WSDL dokumenta koji opisuje nain izvedbe usluge odreuje skup prikljunica usluge
preko kojih se usluga moe koristiti. Svaka prikljunica moe koristiti poseban nain
povezivanja sa uslugom. Proizvoai mogu na ovaj nain ponuditi vie razliitih naina
koritenja jedne usluge.

34

5. Dinamike web stranice

Kako se web poeo koristiti za usluge isporuke, tako su i pruatelji usluga (engl. service
provider) prepoznali potrebu za dinamikim sadrajima. Isprva su skripte CGI (engl. Common
Gateway Interface) bile glavna tehnologija za generiranje dinamikog sadraja na

posluiteljima. Iako je iroko koritena, tehnologija CGI skripata ima mnogo nedostataka,
ukljuujui i ovisnost o platformi i nedostatak skalabilnosti. Kako bi se rijeili ti nedostaci,
kreirana je tehnologija Java servleta i JSP (engl. Java Server Pages) kao prenosiv nain
pruanja dinamikih sadraja orijentiranih prema korisniku. Tehnologija servleta predstavlja
posluiteljsku stranu tehnologije koja je postala standard za razvoj komercijalnih web
aplikacija, a jednostavna je za uenje i razvijanje novih aplikacija. Efikasnim programiranjem,
servleti i JSP odjeljuju prezentaciju i kontrolu nad podacima, takav model programiranja zove
se MVC arhitektura (engl. Model View Controller, skraeno MVC).

5.1. Servlets i Java server pages

5.1.1.

Servlet

Servleti su Java programi, odnosno Java klase koje proiruju funkcionalnost servera i web
aplikacija. Ponaaju se kao posrednik izmeu zahtjeva koji dolazi od strane Web
pretraivaa ili drugog HTTP klijenta i baza podataka ili drugih aplikacija na HTTP serveru.

C
JD B

SM
T

...
Sl 5.1 Uloga posrednika

35

Servlet se izvrava na web-serveru na zahtjev klijenta - web-preglednika.

Uloga servleta je sljedea:
proitati podatke koje alje web preglednik u svom zahtjevu;
izvriti procesiranje koje se od njega oekuje i formirati rezultat;
poslati rezultat klijentu (najee u obliku HTML dokumenta).

Program klijenta koji eli pristupiti web serveru moe biti napisan u bilo kojem programskom
jeziku, najee je to web preglednik, pristupa preko programskog modela zahtjev-odgovor
(engl. request-response). Web server prosljeuje zahtjev servletu koji procesira zahtjev,
dinamiki formira odgovor koristei informacije iz klijentovog zahtjeva zajedno s podacima
prikupljenim iz drugih izvora (drugi servleti, dijeljeni objekti, baze podataka ) i preko web
servera alje odgovor natrag klijentu.
Prednosti u odnosu na CGI:

brzina
kljuna prednost Java Servlet tehnologije je brzina,
za razliku od CGI programa, servleti se jednom uitavaju u memoriju i izvode
iz memorije nakon poetnog uitavanja,
serveti se stvaraju kao niti (engl. thread), i po prirodi su vienitni.
neovisnost o platformi (portabilnost)
Java servleti se mogu pokretati na bilo kojem web serveru koji podrava
servlete
Proirivost
imaju sve prednosti Jave i mogu se proiriti iz postojeih klasa
sigurnost
upravljanje memorijom
rukovanje iznimkama
servleti nasljeuju svojstva i sigurnost koje omoguuju web servisi

Struktura servleta
Svaki HTTP servlet proiruje apstraktnu klasu HttpServlet iz paketa javax.servlet.http. Ako
servlet nije namijenjen radu s HTTP protokolom (to je mogue) onda se kreira proirivanjem
apstraktne klase GenericServlet iz paketa javax.servlet.
Klasa HttpServlet proiruje GenericServlet koja pak implementira suelje Servlet.

Suelje Servlet ima sljedee metode:

36

init

poziva se pri prvom pokretanju servleta,

service

poziva se na svaki zahtjev klijenta,

destroy

poziva se kada se servlet uklanja iz memorije servera.

Klasa HttpServlet prerauje metodu service iz suelja Servlet tako da moe razlikovati
razliite tipove zahtjeva web preglednika. Najei su GET i POST. Za njihovo tretiranje
HttpServlet klasa definira metode doGet i doPost koje poziva service metoda. Ona odreuje

tip zahtjeva i poziva ove dvije metode (odnosno druge, za druge tipove zahtjeva).

doGet

poziva se kod GET zahtjeva

doPost

poziva se kod POST zahtjeva

Druge metode klase HttpServlet su: doDelete, doHead, doOptions, doPut i doTrace.
Metode doGet i doPost dobivaju objekte koji implementiraju suelja HttpServletRequest i
HttpServletResponse koja omoguavaju interakciju izmeu klijenta i servera.

Suelja HttpServletRequest i HttpServletResponse:

HttpServletRequest

omoguava servletu da doe do podataka koji su poslani u

zahtjevu klijenta.

HttpServletResponse omoguava servletu da preda rezultate klijentu (obino

formiranu web stranicu).

Primjer jednog servleta koji generira odgovor Hello world moemo vidjeti u nastavku:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class HelloServlet extends HttpServlet {

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {

37

response.setContentType("text/html");
PrintWriter out = response.getWriter();
String docType =
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +
"Transitional//EN\">\n";
out.println(docType +
"<HTML>\n" +
"<HEAD><TITLE>Hello</TITLE></HEAD>\n" +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H1>Hello World</H1>\n" +
"</BODY></HTML>");
}
}

Sl 5.2 Primjer Hello World servleta

ivotni ciklus Servleta

Spremnik (engl. container) u kojem se servlet nalazi kontrolira ivotni ciklus servleta. Kada je
upuen zahtjev serveru, spremnik izvodi sljedee korake.
1. Ako ne postoji instanca servera, web spremnik:

uitava klasu servlet,

kreira instancu klase servlet,

inicira instancu servleta, smjeta ju u memoriju i poziva init metodu.

38

2. Poziva service metodu, kojoj alje objekt zahtjeva i odgovora (request-response):

na svaki zahtjev klijenta service metoda uzima upit, vri obradu i vraa odgovor;
tokom ivotnog ciklusa servleta metoda service se poziva jednom po zahtjevu,
na svaki novi zahtjev web-server e kreirati novi thread u kojem e metoda
service biti izvrena,
ukoliko spremnik treba izbrisati servlet, on ga finalizira tako to pozove
destroy metodu servleta (kada je server u mirovanju neko vrijeme ili kada se
server gasi).

5.2. Java Server Pages (JSP) tehnologija

Java Server Pages (JSP) tehnologija je ekstenzija servlet tehnologije stvorena za specifinu
podrku pri pisanju HTML i XML stranica. Kombinira statiki HTML s dinamiki
generiranim sadrajima.
JSP je obina web-stranica koja u sebi ima dodatne tagove <% i %> izmeu kojih se nalazi
dinamiki generirani dio, odnosno kod pisan u Javi. Web server e svaku JSP stranicu pri
prvom dolasku na nju prevesti u servlet, stoga nema bitne razlike izmeu JSP i servelta.
Kada server iz JSP-a generira servlet, kreira _jspService metodu koja zamijenjuje doGet i
doPost metode.

Postoje tri tipa skript-elemenata koje nalazimo u JSP-u:

Izrazi (expressions) oblika <%= Java izraz %>

izraunava i ubacuje u izlaz servleta;

Skripleti oblika <% Javin kod %>

ubacuje u _jspService metodu (koju zove service metoda);

Deklaracije oblika <%! Deklaracija metode/varijable %>
ubacuje u tijelo servleta izvan svake metode.

Unutar izraza moemo dohvaati lokalne varijable _jspService metode, od kojih su

najvanije:

request

- referenca na HttpServletRequest objekt;

response

- referenca na HttpServletResponse objekt;

session

- referenca na HttpServletSession objekt vezan s klijentovim

zahtjevom;

39

out

- Writer za slanje odgovora klijentu;

application

- ServletContext, struktura podataka koju dijele svi servleti JSP u web

aplikaciji.

Primjert JSP-a:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>JSP Expressions</TITLE>
</HEAD>
<BODY BGCOLOR="#FDF5E6">
<H1>Current time: <%= new java.util.Date() %></H1>
</Body>
</HTML>

Sl 5.3 Primjer prikaza vremena u JSP-u

JSP se koristi kad ima malo dinamiki generiranih dijelova jer na taj nain izbjegavamo
ispisivanje kompleksnih HTML stranica putem naredbi za ispis servleta. Java kod je od
HTML koda odijeljen tagovima to omoguava mnogo lake oblikovanje stranica, a slinu
metodu koriste i ASP i PHP tehnologije. S druge strane, servleti su praktiniji kada je
programski dio koji generira stranicu kompleksan. U sloenim aplikacijama se stoga koristi
kombinacija servleta (koji vri obradu informacija) i JSP-a koji je zaduen za prezentaciju
rezultata.

40

JSP je slian JavaScript-u, s tom razlikom da se JavaScript kod izvrava na strani klijenta, dok
se JSP kod izvrava na serverskoj strani.

5.3. MVC arhitektura

MVC je najee koritena arhitektura za GUI-e u kojoj se suelje ili dio suelja rastavlja na
tri dijela, model koji sadrava podatkovne elemente, odgovara na upite o vlastitom stanju ili
mijenja stanje, pogled ( engl. view se odnosi na grafiki prikaz modela, a controller
interpretira ulaz sa mia ili tipkovnice i pretvara ih u naredbe koje se alju modelu i view-u.

5.3.1.

Male i srednje aplikacije

Veina postojeih aplikacija spada u kategoriju malih i srednjih. Razlog uporabe ovakve
arhitekture je jednostavnost pisanja i odravanja koda. U ovakvim aplikacijama su uobiajeni
mnogi sigurnosni problemi kao to su dinamiki upiti bazi podataka koji su konstruirani iz
nedovoljno provjerenog korisnikog ulaza, zatim loe rukovanje pogrekama i slabe
autorizacijske kontrole.

5.3.2.

Velike aplikacije

Velike aplikacije zahtijevaju drugaiju arhitekturu od one koja se koristi u malim i srednjim
aplikacijama. Izrada skalabilnih aplikacija neophodna je kada aplikacija koristi vei broj
vanjskih resursa i nudi vie razliitih funkcija korisniku. Skalabilna aplikacijska arhitektura je
esto podijeljena u slojeve, a koritenjem dizajnerskih smjernica za postizanje modularnosti
sadri vie ponovno iskoristivih dijelova. Podjela aplikacije na slojeve omoguuje distribuciju
aplikacije na razliite posluitelje, ime se unapreuje skalabilnost na raun sloenosti. Jedna
od najeih arhitektura za web aplikacije je model-pogled-upravlja (engl. Model-ViewController, skraeno MVC), koji implementira aplikacijsku arhitekturu programskog jezika
SmallTalk 80. MVC se nalazi u mnogim J2EE aplikacijama, a ASP.NET tehnologija moe se

smatrati djelominom implementacijom ovog pristupa.

Pogled (ili prezentacijski sloj) je prednji dio aplikacije koji slui za izradu prikaza i generira

HTML izlaz s malo ili bez aplikacijske logike. Kako su mnoge aplikacije internacionalizirane
i ne sadre lokalne znakove ili informacije o kulturi u prezentacijskom sloju, moraju se
pozivati funkcije upravljaa (aplikacijske logike) za dobivanje podataka o korisnikovom
41

jeziku, kulturi, mjernim jedinicama, itd. Sav korisniki ulaz se prosljeuje natrag upravljau u
aplikacijskoj logici.
Upravlja (ili aplikacijska logika) prihvaa korisnikov ulaz i provlai ga kroz razliite

procese koji pozivaju objekte aplikacijskog modela za dohvaanje, obradu ili pohranu
podataka. Da bi se izlazni podaci proslijedili u sigurnom obliku za pogled (prezentacijski
sloj), neophodno je da upravljai centralizirano provjeravaju ulazne podatke na posluiteljskoj
strani kako bi otkrili mogue sigurnosne probleme prije prosljeivanja podataka modelu.
Model omotava funkcionalnost u web aplikacijama. Osnovna karakteristika modela je

transparentnost prema pozivatelju i mogunost upravljanje poslovnim procesima na visokoj

razini. Uloga modela je provjeravanje da li podaci odgovaraju odreenim poslovnim
pravilima i rizicima jedinstvenim za koriteno spremite podataka. Suelje upravljaa i
modela treba osigurati tipitiranost podataka, ali i fleksibilnost kako bi se zadovoljile budue
potrebe. Pozivi modela prema spremitu podataka trebaju se izvoditi najsigurnijom metodom
koja ovisi o samom spremitu podataka (baza podataka, datoteka, web servis itd.).

odgovor

POGLED
(VIEW)

zahtjev

Odabir
prikaza

Upit o stanju

UPRAVLJA
(CONTROLLER)

Manipulacija
MODEL

APLIKACIJA
Sl 5.4 MVC arhitektura

42

6. Primjeri aplikacija
6.1. Implementacija
Implementacija SMS/MMS Gatewaya sastoji se od 2 aplikacije i baze podataka:
1. Aplikacija koja vri logiku za slanje i primanje poruka,
2. Web aplikacija za administriranje nad sustavom.
Rad aplikacija ne ovisi jedna o drugoj, te su zbog razliitih funkcionalnosti odvojene. Jedino
to ih povezuje je baza podataka (Slika 6.1) i konfiguracijska datoteka.

SMS/MMS Gateway
HTTP posluitelj

Baza podataka
itanje i
pisanje

Aplikacija za
slanje i primanje
poruka

Korisnici

itanje

Transakcije

itanje i
pisanje

itanje i
pisanje

itanje i
pisanje

itanje i
pisanje

Web aplikacija
za
administriranje

itanje

Filter (rijei)

Filter
(brojevi)

itanje

Sl 6.1 Komunikacija s bazom podataka

6.1.1.

Tehnologije

Obje aplikacije napisane su u Javi odnosno J2EE standardu i prate troslojnu (MVC)
arhitekturu. Izvode se na Apache Tomcat serveru koji koristi Apache Axis kao SOAP procesor
za podrku komunikacije s web servisima. Aplikacije komuniciraju s MySql bazom podataka
na kojoj se nalaze svi podaci potrebni za interakciju s korisnikom i administratorom sustava.

43

6.2. Baza podataka

Baza podataka je kljuna za razumijevanje rada aplikacija, a organizirana je u dvije glavne
cjeline:
prva cjelina se brine za rad s korisnicima aplikacije i njihovim filter
elementima,
druga cjelina se brine za arhiviranje transakcija.

6.2.1.

Podaci o tablicama

Tablice za rad s korisnicima i filter elementima:

Korisnici:

users - sadri sve osnovne podatke o korisnicima, podatke potrebne za pristup gatewayu,

njihovim pravima za slanje poruka i podatke za primanje poruka

osnovni podaci o korisniku

ime

prezime

podaci za slanje poruka

korisniko ime

lozinka

prava

broja za slanje svakog tipa poruke

podaci za primanje poruka

podaci o servisu

sadri servis na koji se alju poruke (soap ili e-mail)

sadri adresu servisa na koji se alju poruke

podaci o filtriranju poruka

tip filtriranja (po broju ili po rijei u poruci) koji se vri pri dolasku
poruke

broja primljenih poruka

44

Filteri:

numbers - tablica numbers sadri popis filter elemenata (brojeva telefona) svakog

korisnika koji je odabrao filtriranje po telefonskom broju. Svaki korisnik moe imati vie
od jednog broja kao filter element. Svaki tel. broj mora biti jedinstven
podaci

broj mobitelaidentifikacijska oznaka korisnika

(polje UserId u tablici users)

strings - tablica strings sadri popis filter elemenata (tekst) svakog korisnika koji je

odabrao filtriranje po tekstu unutar poruke. Svaki korisnik moe imati vie od jedne rijei
kao filter element. Svaka rije moe se pojaviti samo jednom
podaci

rije i identifikacijska oznaka korisnika

(polje UserId u tablici users)

Transakcije:

transaction - sadri popis transakcija svih poruka - vodi evidenciju o poslanim i

primljenim porukama, ukljuujui i vrijeme zahtjeva te vrijeme izvrenja zahtjeva (za
slanje i za prijem)
osnovni podaci o transakciji

podaci o poiljatelju i primatelju poruke

podaci o kanalu kojim je poruka poslana

podaci o vremenu slanja i primitka poruke

podaci o grekama

ukoliko je dolo do greke kod slanja ili primanja poruke, upisuje se opis
greke u transakciju

45

6.3. Aplikacija za slanje i primanje poruka

6.3.1.

Arhitektura

Arhitektura i slojevi sustava za slanje i primanje poruka prikazani su na slici . Aplikacija

slijedi osnove principe gradnje J2EE aplikacija. Iako je takva arhitektura najee troslojnog
oblika, kako se prezentacija vri na klijentovoj implementaciji programa za slanje SMS/MMS
oruka gatewayu, nema potrebe za prezentacijskim slojem.
APLIKACIJA
UPRAVLJA (CONTROLLER)
Web servis prema klijentu

Web servis prema operateru

Logika za obradu podataka

MODEL
Pristup podacima baze podataka

Slanje poruka klijentu

Slanje poruka operateru

Sl 6.2 Arhitektura aplikacije za slanje i primanje poruka

Kao to vidimo na slici, aplikacija se sastoji od dva sloja:

Upravlja (ili aplikacijska logika) kroz web servise prihvaa poruke, provlai kroz

razliite procese koji pozivaju objekte aplikacijskog modela kako bi dohvatili, obradili i
pohranili podatke. Funkcija upravljakog modela je prosljeivanje poruke u originalnom
obliku, dohvata i auriranje podataka korisnika i na kraju upisa podataka transakcije.

46

Model dohvaa, aurira i dodaje podatke u baze podataka i alje poruke (web servisu, e-

mail).

6.3.2.

Organizacija koda

Sustav za slanje i primanje poruka je dinamika web aplikacija, sastoji se od pet paketa u
kojima su klase rasporeene po funkcionalnosti. Radi bolje razumljivosti paketi su
rasporeeni u slojeve aplikacijske logike i model.
Paketi i klase rasporeene po slojevima
Aplikacijska logika:

hr.tel.fer.server - sadri klase koje vre svu logiku aplikacije za prosljeivanje poruka
MessageFwdMob.java - sadri logiku za prosljeivanje poruka operatoru
MessageFwdClient.java - sadri logiku za prosljeivanje poruka klijentu

hr.tel.fer.hr.notification - web servisi

MessageListenerClient.java - web servis koji slua nadolazee poruke klijenta,
sadri metode za dohvaanje svih tipova poruka
MessageListenerMob.java - web servis koji slua nadolazee poruke operatera
MyNotificationPortRetriever.java - web servis koji slua nadolazee poruke
operatera i poziva odgovarajuu metodu MessageListenerMob klase

Model:

hr.tel.fer.beans - sadri beanove (niz objekata koji predstavljaju replike entiteta iz baze
podataka) za dohvaanje, mijenjanje i dodavanje entiteta baze podataka

Transaction.java - manipulira transakcijama baze podataka

User.java - manipulira korisnicima baze podataka
Filter.java - dohvaa filtere korisnika baze podataka
DBConnection.java - sadri podatke i metode za uspjenu konekciju s bazom
Log.java - zapisuje greke u log file

hr.tel.fer.message.send - sadri klase za slanje poruka, odnosno klase za poziv web

servisa klijenta i operatera
AttachmentFer.java - sadri sve elemente priloga MMS poruke
BinaryMessage.java - sadri metode za kreiranje SMS poruke iz skupine
byteova
Gmail.java - slanje e-mail poruka preko pretinca na gmail-u
SendMessage.java - slanje svih tipova poruka na web servis operateru
SendMessageClient - slanje svih tipova poruka na web servis klijenta

47

hr.tel.fer.constants - sadri konstante

Constant.java - sadri sve konstante koje se inicijaliziraju pri pokretanju
aplikacija
MessageConstant.java - sadri konstante poruka

hr.tel.fer.constants - sadri konstante

Constant.java - sadri sve konstante koje se inicijaliziraju pri pokretanju
aplikacija
MessageConstant.java - sadri konstante poruka

hr.tel.fer.test - klasa koja sadri klase za testiranje (koristi se umjesto poziva web
servisa)

6.3.3.

Aplikacijska logika

Dijagram toka (slanje poruke)

Sl 6.3 Dijagram toka slanje poruka

48

Ulaz u aplikaciju
Svaka aplikacija mora imat definiran ulaz da bi mogla obraditi neki zahtjev. Ulaz u nau
aplikaciju je web servis klijenta i operatera.
Web servis za klijenta

Web servis za klijenta implementiran je u klasi MessageListenerClient.java. Klasa sadri

metode za dohvaanje SMS, MMS, WAP Push i binarnih SMS-ova. Osim poruka, dohvaaju
se i podaci potrebni za autorizaciju klijenta i tel. brojevi na koje se alje poruka.
Metode klase MessageListenerClient.java su:

smsReceived(String username, String password, String text, String[] recipient)

smsReceivedDelivery(String username, String password, String text, String recipient)

wapPushReceived(String username, String password, String subject, String url, String

recipient)

binaryReceived(String username, String password, AttachmentFer[] attachmentFer,

String[] recipient)

mmsReceived(String username, String password, String subject, AttachmentFer[]

attachmentFer, String[] recipient)

Jedina metoda koja ne prihvaa polje tel. brojeva (recipient) je smsReceivedDelivery, jer se
ovom metodom alju SMS poruke za koje se vraa potvrda o isporuci poruke, to nije mogue
ako se alje na vie korisnika odjednom.
Konfiguracija

Da bi korisnici imali pristup web servisu, klasa MessageListenerClient.java se moraju

registrirati na posluitelju. Apache Axis biblioteka je odgovorna za pokretanje tog servisa i
delegiranja SOAP poruka prema MessageListenerClient klasi na dolazak.
Zbog toga je potrebno konfigurirati web.xml i server-config.wsdd (potrebne za startanje
servisa zajedno sa posluiteljem) tako da se MessageListenerClient web servis pokree na
odreenoj URL adresi.

49

Nakon to je web servis konfiguriran, svaki klijent ima pristup opisu web servisa na temelju
koje moe generirati klijenta.
Web servis za operatera

Web servis operatera je definiran u klasi MessageListenerMob.java. Poruke koje se dohvaaju

su: SMS, MMS i Info o statusu poruke. Konfiguriranje i implementacija metoda i suelja
objanjena je u poglavlju Pristup VIPnet-ovoj infrastrukturi

Logika (klijent alje poruku)

Logika za prosljeivanje poruka od klijenta raunalnog sustava na mobilni ureaj korisnika
implementirana je u MessageFwdMob klasi hr.tel.fer.server paketa. Sve poruke koje dolaze na
web servis klijenta prosljeuju se ovoj klasi koja obrauje sve podatke, puni beanove za upis
u bazu podataka i za prosljeivanje poruke na web servis operatera.
Funkcije koje vri MessageFwdMob:

1. Provjera korisnikih podataka korisnika

a. Provjera usernama i passworda
b. Provjera prava slanja poruke
2. Slanje poruke
a. Kreiranje objekta poruke koje se alje
3. Upis transakcije
4. Vraanje rezultata klijentu
a. Ako je transakcija uspjeno provedena, korisniku se alje identifikacijski kod
poruke

Primjer koda:

Provejra korisnikih podataka

User user = new User();
user.selectUser(conn, "username", username);

50

if (user.getUser().equals(""))
return SmsConstant.NO_USER + ": " + username;// no such user
if (user.getPass().compareTo(password) != 0)
return SmsConstant.WRONG_PASS;// wrong password
if (user.getSms() == 0)
return SmsConstant.SERVICE_DENIED;// can't send sms
Slanje poruke:
Message sms = new SmsMessage(text);
SendMessage message = new SendMessage(sms, recipient,'s');
String msgId = message.send();
Upis transakcije
Transaction trans = new Transaction(SmsConstant.CLIENT_TO_MOBILE, null, new
Timestamp(System.currentTimeMillis()),

"SMS",

msgId,

null,

text,

username,

recipient, Status.MESSAGE_WAITING.toString(), null);

trans.insertTransaction(conn, username, "sent", recipient.length);
Vraanje rezultata klijentu
return msgId;

Sljedea slika prikazuje slijed poziva klasa kod slanja poruka:

51

Sl 6.4 Poziv klasa kod slanja poruka

Logika (klijent prima poruku)

Logika za prosljeivanje poruka s mobilnog ureaja na raunalni sustav korisnika vrlo je
slina logici slanja poruke. Implementirana je u MessageFwdClient klasi hr.tel.fer.server
paketa. Za razliku od prije, korisnik kojem e se poslati poruka pretrauje se u tablicama
filtera.

Pri

dolasku

poruke

web

servis

MessageListenerMob

prosljeuje

poruku

MessageFwdClient klasi.
Funkcije koje vri MessageFwdClient pri dolasku poruke:

1. Dohvaanje korisnika iz tablica filtera

a. Prvo pretrauje po broju
b. Ako nije pronaao korisnika po broju, pretrauje ga po tekstu SMS-a
2. Slanje poruke
a. Kreiranje objekta poruke koje se alje klijentu kanalom koji je on odredio
(poziv web servisa ili slanje e-mail-a)
3. Upis transakcije
Funkcije koje vri MessageFwdClient pri dolasku potvrde o isporuci:

1. Dohvaanje korisnika iz tablica transakcija po identifikacijskom broju poruke

52

2. Slanje poruke
a. Kreiranje objekta poruke koje se alje klijentu kanalom koji je on odredio
(poziv web servisa ili slanje mail-a)
3. Upis transakcije

Primjer koda pri dolasku poruke:

Pretraivanje userId-a iz tablice filtera (filter prima broj telefona i privih par znkova
teksta poruke)
String filterText = smsMessage.getText();
if (filterText.length() < Constant.numOfFilterCharacters) filterText = null;
else

filterText = filterText.substring(0, Constant.numOfFilterCharacters).toUpperCase();

Filter filter = new Filter(endUserAddress, filterText);

String userId;
userId = filter.selectFilter(conn);
Dohvaanje korisnikla po userId-u
User user = new User();
user.selectUser(conn, "userid", userId);
Slanje poruke korisniku (Soap ili e-mail)
//slanje poruke pozivom web servisa
if (user.getService().equalsIgnoreCase(SmsConstant.SOAP)) {
SendSmsClient sms = new SendSmsClient();
sms.sendSms(user.getUrl() ,endUserAddress,smsMessage.getText(),
SmsConstant.SOAP);
} else {
//slanje poruke mailom
String text=smsMessage.getText()+"\n\nPoslano: "+sentString+"\nUlazni kanal:
"+SmsConstant.SOAP;

53

new GMail(user.getEmail(), endUserAddress, text);

}
Upis transakcije
Transaction trans = new Transaction(action, received, sent, "SMS", null, null,
smsMessage.getText(), endUserAddress,
new String[] { user.getUser() }, status, error);
trans.insertTransaction(conn, user.getUser(), "received",1);

Primjer koda pri dolasku potvrde o isporuci

Kod prosljeivanja potvrde o isporuci, postupak je slian kao i kod primanja poruke, a
korisnik se pretrauje u tablicama transakcija pod identifikacijskom oznakom poruke (msgId)
koji je zapisan u transakcijama (trewn) kad je korisnik uspjeno poslao poruku.

Dohvaanje korisnika iz tablica transakcija po identifikacijskom broju poruke

Transaction trans = new Transaction();
trans.selectTransaction(conn, "messageId", messageId);
User user = new User();
if (trans.getFrom() != null) user.selectUser(conn, "username", trans.getFrom());

Slika 6.5 prikazuje poziv klasa prilikom primanje poruke operatera i prosljeivanja korisniku
raunalnog sustava.

54

Sl 6.5 Poziv klasa kod primanja poruka

6.3.4.

Model

Model ove aplikacije ima sljedee funkcije:

Dohvaanje, auriranje i dodavanje podataka u bazu

Slanje poruka putem web servisa klijentu i operateru

Slanje e-mail poruka klijentu

Komunikacija s bazom podataka

Za razmjenu podataka s bazom podataka brinu se beanovi: Filter.java, User.java i
Transaction.java. Sve tri klase na vrlo slian nain dohvaaju konekciju, kreiraju upit prema

bazi te pune svoje objekte podacima iz baze ili spremaju podatke objekata u bazu.
Za dohvaanje konekcije prema bazi brine se klasa DBConnection koja preko JDBC-a (engl.
Java Database Connectivity, skraeno JDBC) ili Data Pool-a (HTTP server kontrolira i

dodjeluje konekciju) priprema konekciju. Trenutno je implementirano dohvaanje konekcije

55

preko JDBC-a, zbog toga je za podizanje drivera odgovorna aplikacija, a ne server kao to je
obiaj kod Data Pool-a.
Pri prvom pristupu bazi podataka inicijalizira se objekt DBConnection koji unutar svoje init()
metode instancira drivere prema bazi.
DBConnection.java (podizanje drivera i dodjela konekcije)
public void init (){
Class.forName(driver);
}
public Connection getConn(){
return DriverManager.getConnection(url, username, password);
}
Primjer koda za spremanje podataka u bazu:
//dohvaanje konekcije
conn = dBconn.getConn();
pstmt = conn.prepareStatement(insertTransactionSQL);
//dodavanje elemenata unutar upita insertTransactionSQL
int i = 1;
pstmt.setString(i++, action);
pstmt.setTimestamp(i++, received);

// spremanje podataka
conn.setAutoCommit(false);
pstmt.execute();
// zatvaranje upita
pstmt.close();
// izvriti upit

56

conn.commit();
conn.setAutoCommit(true);
conn.close();

Slanje poruka putem web servisa

Poziv web servisa vri se putem Apache Axis SOAP procesora. Da bi poziv bio mogu,
potrebno je dodati odgovarajue jar biblioteke i poznavati opis web servisa (wsdl datoteka)
koji sadri opis svih parametara koji se alju i primaju web servisu.
Za slanje poruka klijentu brine se SendMessageClient klasa.
Service service = new Service();
Call call = null;
String ret = null;
call = (Call) service.createCall();
// definiranje url adrese i ime metode koja se poziva
call.setTargetEndpointAddress(new java.net.URL(endpointURL));
call.setOperationName(new QName("http://hr.tel.fer.server", "smsReceived"));
// dodavanje ulaznih i izlaznih parametara
call.addParameter("smsMessage", XMLType.XSD_STRING, ParameterMode.IN);
call.setReturnType(org.apache.axis.encoding.XMLType.XSD_STRING);
// poziv web servisa
call.invoke(new Object[] { smsMessage,endUserAddress,channel});

Slanje poruka operateru definirano je posebnim bibliotekama i objanjeno u poglavlju

Pristup VIPnetovoj infrastrukturi

Slanje e-maila
GMail klasa odgovorna je za slanje mail-a, koristi mail.jar biblioteku za pristup mail
sanduiu. Za potrebe testiranja otveren je sandui na gmailu.

57

6.3.5.

Pristup Vipnet-ovoj infrastrukturi

Vipnet Open interface usluga

Koncept otvaranja telekomunikacijske platforme prema vanjskim partnerima vidljiv je na
primjeru projekta Vipnet-a (Open Interface) koji omoguuje vanjskom partneru ugradnju
Vipnet usluge u vlastitu aplikaciju.
Kroz taj projekt je tvrtkama partnerima omogueno koritenja infrastrukture potrebne za
slanje i primanje SMS poruka, slanje MMS poruka, koritenje sustava za naplatu s
autorizacijom putem mPIN-a, plaanje trokova kreditnih kartica, pristup nekim bankovnim
raunima i Vipnetovom telefonskom raunu korisnika.
Prema postavljenim kriterijima u ovakav model suradnje s Vipnetom moe ui svaka tvrtka
koja ima dobru ideju za razvoj usluge, registrirana je u Republici Hrvatskoj i Vipnet-ov je
GSM korisnik. Po odobrenju zahtjeva otvara se pristup razvojnoj okolini na kojoj se vri
razvoj i testiranje usluge ili aplikacije. Ukoliko se cijeli proces uspjeno zavri, usluga prelazi
u komercijalnu fazu i mogue ju je ponuditi na tritu.
Pristup Vipnet-ovoj infrastrukturi mogu je putem TIS KIS-ove MGW(MGW Message
Getaway) biblioteke koja koristi ParlayX specifikaciju s ciljem da operatera opskrbi

standardnim protokolom za komunikaciju s aplikacijama. Tvrtka TIS KIS, koja posluje u

sklopu TIS grupacije, nudi softverska rjeenja bez kojih nije mogue slanje i primanje SMS i
MMS poruka. Tvrtka izrauje softverske proizvode pomou kojih operateri grade vlastite
usluge na podruju SMS-a i MMS-a. To su bazini softveri koji slue da bi se poruke uope
mogle distribuirati.

MGW bilblioteka
MGW je messaging platforma koja omoguuje brzo i jednostavno pokretanje i upravljanje
VAS uslugama, SMS, MMS, LBS i WAP Push-om, te ostalim binarnim formatima SMS-ova.
MGW omoguuje operateru da otvori svoju infrastrukturu nekoj treoj strani, omogui joj
pokretanje vlastitih VAS usluga, a da u isto vrijeme zadri potpunu kontrolu nad vlastitim
core sustavima. Pri tome je mogue odrediti cijene i ograniiti propusnost, te sastaviti

opsene statistike.
Vipnet je korisnicima stavio na raspolaganje 2 MGW klijentske API biblioteke:

Java API 1.2.1

58

NET API 1.1.2

PHP API se nalazi na TIS KIS-ovim stranicama (http://www.tiskis.com).

Konfiguracija pristupa
Za uspjean pristup Vipnetovoj infrastrukturi potrebno je konfigurirati vatrozid na serveru
FER-a tako da prihvaa HTTP konekcije sa porta 80 odaslane s Vipovog servera
(212.91.99.123). Isto tako, potrebno je konfigurirati Vipnet-ov server da prihvaa poruke
odaslane s FER-ovog servera (161.53.19.120) na portu 80.
Osim podeavanja vatrozida, Vipnetu prosljeujemo URL adresu web servisa na koji e nam
dolaziti

notifikacije

primljenih

poruka:

http://demo1.tel.fer.hr/MMStest

odnosno

http://161.53.19.120/MMStest
Parametri potrebni za spajanje:

URL - Url adresa na koju se alju poruke

ServiceAddress - adresa usluge na koju se spaja (razliita za svaki tip poruke)

SenderUsername - korisniko ime (isto za sve usluge)

SenderPassword - lozinka (ista za sve usluge)

Okruenje
Vipnet je objavio dvije verzije razvojnih okruenja za vanjske programere (engl. Software
Developement Kit). Jedno je bazirano na .NET tehnologiji, a drugo na Java standardima pa je

time razvojnim timovima stavljen na raspolaganje i odabir platforme na kojoj ele razvijati
svoje aplikacije ili usluge. Trei SDK koji je baziran na PHP-programskom jeziku moe se
skinuti sa TIS KIS- ovih stranica. Svi paketi su besplatni te zajedno sa njima dolaze veina
potrebnih biblioteke i programa.
Princip programiranja MGW biblioteke za slanje i primanje poruka je vrlo slian za oba
okruenja, dok se konfiguriranje posluitelja za primanje notifikacije dolazeih poruka
uvelike razlikuje, prvenstveno zato to se koriste razliiti posluitelji i servisi.

59

6.3.6.

Slanje i primanje poruka

MGW JAVA 1.2.1 API

Za uspjeno pisanje aplikacije za slanje poruka potrebno je zadovoljiti sljedee uvjete:

Operacijski sustav neovistan

Java SDK version 1.4.x or version 1.5.x (http://java.sun.com)

Apache Tomcat posluitelj

Apache Axis

Apache Tomcat server koristi se za Java Servlet i JavaServer Pages tehnologije

(http://www.apache.org/). Tomcat se moe koristiti kao mali samostalni web-server ili kao
posluitelj za servlete integriran u Apache HTTP server.
Apache axis je Jakarta implementacija SOAP protokola, ima podrku za WSDL, generira java
klasa za implementaciju web servisa.
Glavni servisi u MGW biblioteci su:

MessageManager - za slanje poruka (poziva web servis na strani operatera tel.

usluga)

MessageListener - za primanje i notifikaciju poruka (web servis koji slua dolazee

poruke)

LocationManager - za traenje lokacije terminala (poziva web servis na strani

operatera tel. usluga)

Slanje poruka
Za uspjeno pisanje aplikacije za slanje poruka potrebno je dodati odgovarajue biblioteke
odnosno .jar datoteke, napraviti java klasu i importirati potrebne pakete.
Najvanije klase koje je potrebno instancirati su:

SingleRouteCredentialsHandlerImpl - potrebna radi autorizacije sa gatewayom

(Vipnet infrastrukturom),

MessageManagerImpl - potrebna za slanje SMS ili MMS poruke, a ujedno i za

dohvaanje MMS privitaka i dohvaanja statusa poslane poruke.

Slino kao i za ostale servise u MGW Client biblioteci, svaka metoda sadri u sebi argument
routeId koji se koristi za razluivanje korisnikog imena i lozinke. Taj argument koristi

60

RouteCredentialsHandler suelje. Zbog toga je prije svega potrebno instancirati klasu

SingleRouteCredentialsHandlerImpl koja implementira RouteCredentialsHandler suelje, te

dodati korisniko ime i lozinku.

SingleRouteCredentialsHandlerImpl credentialsHandler = new
SingleRouteCredentialsHandlerImpl();
credentialsHandler.setUsername("userName");
credentialsHandler.setPassword("userPassword");

Ovisno o tome elimo li slati SMS ili MMS poruku, moramo instancirati odgovarajue
objekte:

SmsMessage message = new SmsMessage(text message);

za SMS je potrebno samo dodati tekst poruke tipa String

MmsMessage message = new MmsMessage(subject);

za MMS osim subjekta, moze se poslati i prilog

Prilog moe biti:

tekstualnog sadraja

Attachment tekstAttachment = new Attachment (Text,UTF-8);

Message.addAttachment(tekstAttachment);
polje byteova

byte [] bytes = getAttachmentAsByteArray(file path);

Attachment attachment = new Attachment(bytes, attachmentType, "myId", file path);
message.addAttachment(attachment);

Na kraju je potrebno instancirati klasu MessageManagerImpl koja implementira

MessageManager suelje. Prije poziva metode sendMessage, potrebno je unijeti URL adresu

na koju se alje poruka i instancu SingleRouteCredentialsHandlerImpl klase koja sadri

podatke za autentifikaciju.
MessageManager messageManager = new MessageManagerImpl();
messageManager.setSendMessagePortURL("sendMessagePortURL");
messageManager.setRouteCredentialsHandler(credentialsHandler);

Nakon toga slijedi pokretanje metode send message.

messageManager.sendMessage (String routeId, Message message, String serviceAddress,
String[] endUserAddresses, Priority, String charging);

61

Ova programska naredba u kodu aplikacije korespondira odgovarajuoj pojednostavljenoj

SOAP poruci (izostavljeni su namespace i encoding atributi):
<sendSMS>
<destAddressSet> Tel:01234567</destAddressSet>
<senderAddressSet>Tel:987654321</senderAddressSet>
<message>Hello World!</message>
</sendSMS>

HTTP zahtjev za slanje SOAP poruke prikazuje poziv sendMessage metode i slanje
parametara za autentifikaciju.
Hypertext Transfer Protocol:
POST /jboss-net/services/SendMessagePort HTTP/1.0\r\n
Request Method: POST
Request URI: /jboss-net/services/SendMessagePort
Request Version: HTTP/1.0
Content-Type: multipart/related; type="text/xml";
Accept: application/soap+xml, application/dime, multipart/related, text/*\r\n
Host: oi-test.Vipnet.hr\r\n
SOAPAction: "SendMessage#sendMessage"\r\n
Credentials: user name:password

Kao povratnu informaciju metoda sendMessage vraa messageId tako da je mogue metodom
getMessageDeliveryStatus provjeriti status poruke, ali pod uvjetom da je konfiguriran web

servis za notifikaciju poruka.

messageManager.getMessageDeliveryStatus(String routeId, String messageId)

6.3.7.

Primanje poruka

Za notifikaciju poruka koristimo MessageListener service. MessageListener se razlikuje od

ostalih servisa jer zahtjev ne putuje od servisa do gatewaya, nego obratno. On slua dolazee

62

poruke ili status poslane poruke od gatewaya, zbog toga je aplikacija odgovorna za
implementaciju servisa, a ne MGW biblioteka.
Klase koje su nam potrebne za konfiguriranje notifikacije poruka su:

MessageListener - implementacija ovog suelje slua dolazne poruke sa gatewaya

MmNotificationPortImpl - procesuira dolazne poruke sa gatewaya i pokree

odgovarajuu metodu registriranog MessageListenera

MmNotificationPortRetrieve - implementacija ovog suelja pri prvom zahtjevu

instancira i prosljeuje sve poruke MmNotificationPortImpl klasi

Inicijalna komponenta u MGW biblioteci je klasa MmNotificationPortImpl, a implementacija
suelja MessageListener-a mora biti registrirana kao njegov posjed. Pri dolasku poruke s
gatewaya pokree se odgovarajua metoda registriranog MessageListenera.
Zbog toga je potrebno kreirati vlastitu klasu (npr. MessageListenerImpl) koja implementira
metode MessageListener suelja.
Metode messageListener suelja su:

smsReceived(...)

listener.smsReceived(...) poziva se kod primanja SMS-a

mmsReceived(...)

listener.mmsReceived(...)poziva se kod primanja MMS-a

deliveryStatusReceived(...)

listener.deliveryStatusReceived(...)poziva se kod statusa poruke

Listener je potrebno registrirati u MmNotificationPortImpl klasi.

MessageListener listener= new MessageListenerImpl();
MmNotificationPortImpl.setMessageListener(listener);

MmNotificatonPortImpl zahtjeva neki HTTP entry point gdje e dolaziti notifikacije s

gatewaya. On dolazi u obliku Parlay X MmNotificationPort web servisa

Parlay X MmNotificationPort web servis

Apache Axis biblioteka je odgovorna za pokretanje tog servisa i delegiranja SOAP poruka

prema MmNotificationPortImpl klasi na dolazak.

63

Zbog toga je potrebno konfigurirati web.xml i server-config.wsdd (potrebne za startanje

servisa zajedno sa posluiteljem) tako da se MmNotificationPort web servis pokree na URL
adresi koju smo odredili u dogovoru s operaterom.
Svi HTTP zahtjevi dolaze u MmNotificationPort servis i zatim se proslijeuju prema
MmNotificationPortImpl klasi.

Taj most dolazi u obliku MmNotificationPortRetriever suelja. Zbog toga je potrebno u

web.xml datoteci registrirati implementaciju MmNotificationPortRetrieve suelja i na prvi

web servis zahtjev MmNotificationPortImpl e biti instanciran.

Ovako izgleda dio HTTP zahtjeva u kojem se moe vidjeti kako se poziva metoda
notifyMessageReception MmNotificationPortImpl klase te se na taj nain sve poruke

proslijeuju MessageListeneru.
Primjer implementacije MmNotificationPortRetrieve suelja i konfiguriranja listenera.
public class MyNotificationPortRetriever implements MmNotificationPortRetriever {
public MmNotificationPort getMmNotificationPort(ServletContext servletContext) {
SingleRouteCredentialsHandlerImpl credentialsHandler
= new SingleRouteCredentialsHandlerImpl();
credentialsHandler.setUsername("user");
credentialsHandler.setPassword("password");
MessageManagerImpl mm = new MessageManagerImpl();
mm.setRouteCredentialsHandler(credentialsHandler);
MessageListenerl ml = new MessageListenerImpl();
MmNotificationPortImpl mi = new MmNotificationPortImpl();
mi.setMessageListener(ml);
mi.setMessageManager(mm);
return (MmNotificationPort) mi;
}

Ovisno o tipu poruke koja se alje, aktivira se odreena metoda messageListenera:

64

Hypertext Transfer Protocol

POST /MMStest HTTP/1.0\r\n
Host: demo1.tel.fer.hr\r\n
SOAPAction: "MmNotification#notifyMessageReception"\r\n

Prikaz pojednostavljene SOAP poruke s gatewaya (izostavljeni su namespace i encoding

atributi):
<soapenv:Envelope>
<soapenv:Body>
<registrationIdentifier>400032BA</registrationIdentifier>
<message>Proba</message>
<value>tel:385912526084</value>
</soapenv:Body>
</soapenv:Envelope>

Kod dohvaanja MMS priloga potrebno je jo dodati MessageManager kao posjed

MmNotificationPortImpl klase.
MmNotificationPortImpl.setMessageManager(MessageManager);

6.4. Aplikacija za administriranje

6.4.1.

Arhitektura

Arhitektura web aplikacije za administraciju sustava kao i prethodna, slijedi osnove principe
gradnje J2EE aplikacija, odnosno tehnologiju Java Servleta i JSP-a kao prenosiv nain
pruanja dinamikih sadraja orijentiranih prema korisniku. Aplikacija odjeljuje prezentaciju i
kontrolu nad podacima to ini MVC arhitektura (engl. Model View Controller). Osim
serverskih skripti, aplikacija sadri i klijenske skripte JavaScript. Klase su rasporeene po
namjeni (spajanje na bazu, html prikaz podataka, klase koje vre logiku), to omoguuje
jednostavno dodavanje novih funkcija.

65

HTTP
odogovor

HTTP
zahtjev

APLIKACIJA ZA ADMINISTRIRANJE
POGLED (VIEW)

UPRAVLJA (CONTROLLER)
Logika za autentifikaciju

Generiranje HTML sadraja

Logika za obradu zahtjeva

Rad sa
korisnicima

Rad sa
transakcijama

MODEL
Pristup podacima baze podataka

Pristup podacima sessiona

Sl 6.6 Arhitektura aplikacije za administriranje

Kao to vidimo na slici, aplikacija se sastoji od tri sloja:

Pogled (ili prezentacijski sloj) je prednji dio aplikacije koji slui za izradu prikaza, a ima za

cilj generirati HTML izlaz s poneto aplikacijske logike. Poziva funkcije upravljaa
(aplikacijske logike) kako bi dobila podatke o korisnicima i transakcijama, izmijenila i dodala
podatke o korisnicima i njihovim filtrima. Osim toga prezentira konfiguracijske parametre
aplikacije za slanje i primanje poruka.
Upravlja (ili aplikacijska logika) prihvaa HTTP zahtjeve korisnika i provlai ga kroz

razliite procese koji pozivaju objekte aplikacijskog modela kako bi dohvatili, obradili ili
pohranili podatke. Centralizirano provjerava ulazne podatke kako bi otkrili mogue
sigurnosne probleme prije prosljeivanja podataka ostalim procesima i modelu, te osiguravaju
da je izlaz u sigurnom obliku za prosljeivanje pogledu.
Model dohvaa, aurira i dodaje podatke koji se prosljeuju prezentacijskom sloju kroz

aplikacijski sloj. Pozivi modela odvijaju se prema konfiguracijskoj datoteci, bazi podataka i
sesiji korisnika.

66

6.4.2.

Organizacija koda i implementacija

Web aplikacija za administraciju koristi tri razliite tehnologija za uspjenu izvedbu MVC
arhitekture. Prezentacijski sloj implementiran je tehnologijom JSP-a. Struktura svake stranice
prezentacijskog sloja je veim dijelom definirana HTML kodom unutar kojeg se dohvaaju
parametri objekata sloja modela. Aplikacijska logika implementirana je tehnologijom Java
Servleta, prihvaa i prosljeuje zahtjeve ostalim servletima i poziva objekte sloja modela (sloj

pristupa podacima). Sloj modela implementiran je klasinim Java klasama, odnosno

objektima koji imaju pristup bazi podataka, sesiji korisnika.
Paketi i klase rasporeene po slojevima:
Prezentacijski sloj:

Glavne stranice
Indeks.jsp - poetna stranca za autentifikaciju korinsika
Main.jsp - glavna stranica koja definira cjelokupni izgled svih ostalih stranica,
sadri glavni izbornik pored kojeg poziva ostale stranice na zahtjev korisnika

Sporedne stranice - pozivaju se unutar stranice Main.jsp

NewUser.jsp - prikazuje formu za unos podataka korisnika

selectTransaction.jsp - prikazuje podatke odabrane transakcije
selectUser.jsp - prikazuje podatke odabranog korisnika
ViewAllTransactions.jsp - omoguuje pregled i pretraivanje transakcija po
zadanom uvjetu
ViewAllUsers.jsp - omoguuje pregled i pretraivanje korisnika po zadanom
uvjetu
DeleteUser.jsp - prikazuje obavijest o uspjeno obrisanom korisniku
Home.jsp - prikazuje poetnu stranicu
Error.jsp - prikazuje poruku o pogreci

Skripta na klijentskoj strani

Script.js - java skripta koja provjerava podatke forme prije nego to se alju
aplikaciji

Izgled stranice
Master.css definiran je izgled parametara html elemenata koji se koriste na
svim stranicama

67

Aplikacijska logika:

hr.tel.fer.servlet - sadri servlete koje vre svu logiku aplikacije

Login.java - sadri logiku autentifikaciju korisnika, kreiranje sesije i
inicijalizaciju objekta pristupa bazi podataka
Main.java - sadri svu logiku za kontrolu sesije korisnika i prosljeivanje
zahtjeva drugim servletima i prezentacijskom sloju
Transaction.java - sadri logiku za pristup i pripremu podataka transakcija
prezentacijskom sloju
User.java - sadri logiku za pristup i pripremu podataka korisnika
prezentacijskom sloju

Model:

hr.tel.fer.servletbeans - sadri beanove (niz objekata koji predstavljaju replike entiteta iz

baze podataka) za dohvaanje, mijenjanje i dodavanje entiteta baze podataka

Transaction.java - manipulira transakcijama baze podataka

User.java - manipulira korisnicima baze podataka
SessionAtributes.java - manipulira podacima sesije korisnika
DBConnection.java - sadri podatke i metode za uspjenu konekciju s bazom
Log.java - zapisuje greske u log file

hr.tel.fer.constants - sadri konstante

Constant.java - sadri sve konstante koje se inicijaliziraju pri pokretanju
aplikacija
MessageConstant.java - sadri konstante poruka

6.4.3.

Prezentacijski sloj

Prezentacijski sloj ine 2 glavne stranice, to su Index.jsp i Main.jsp. Svaka od stranica poziva
svoj sebi pripadajui servlet aplikacijskog sloja koji vri logiku i vraa odgovor.

Poetna stranica
Poetna stranica je Index.jsp, predstavlja prvi ulaz u aplikaciju gdje se korisnik autentificira
svojim korisnikim imenom i lozinkom (Slika 6.7).

68

Sl 6.7 Poetna stranica indeks.jsp

Ova stranica sadri formu koja POST metodom alje parametre login servletu. Osim to alje
login i password korisnika, forma index.jsp-a sadri i hidden polje FROMJSP koje e se

pokazati nunim za navigaciju stranicom.

<FORM method="post" action="/AdminSms/servlet/Login">
<input type=hidden name=FROMJSP value="Login">

Nakon to Login servlet obradi zahtjev korisnika, ukoliko autentifikacija nije bila uspjena
korisniku se vraa ista stranica sa porukom o greci koja se dohvaa GET metodom unutar
index.jsp-a.
<% String status= request.getParameter("status");
if (status!=null) out.println("Status: "+status);%>

Sl 6.8 Stranica indeks.jsp kod neuspjene autorizacije

Glavna stranica
Ukoliko se korisnik uspjeno autentificirao, korisniku se vraa glavna stranica ili Main.jsp.
Ona definira cjelokupan izgled aplikacije i svih sporednih stranica. Sadri glavni izbornik
pored kojeg poziva ostale stranice na zahtjev korisnika (Slika 6.9).

69

Sl 6.9 Prikaz glavne stranice Main.jsp

Stranica se sastoji od forme (engl. form) unutar koje se nalazi tablica sa glavnim izbornikom
na lijevoj strani i sporednim stranicama na desnoj.
<form method="post" action="/AdminSms/servlet/Main" name="form">
<table class="one" width="1200px" height="700px" border="1" align="center">
<tr valign="top">
<td width="20%">
Glavni izbornik
</td>
</tr>
<tr valign="top">
<td width="80%">
Sporedne stranice
</td>
</tr>
</table>
</form>

70

Forma alje podatke POST metodom koja main servletu alje parametre potrebne za
navigaciju i obradu podataka
Navigacija

Za razliku od komercijalnih stranica gdje svaki gumb sadri link prema nekoj drugoj stranici,
ovdje svaki gumb predstavlja submit gumb forme koja post metodom alje hidden parametre
main servletu.
Hidden parametri koji se alju potrebni su main i ostalim servletima za obradu zahtjeva.

Njihove vrijednosti mijenjaju se klikom na gumb koji uz pomo Java skripte (engl.
JavaScript) postavlja njihove vrijednosti i na kraju submita formu.

Parametri koji se uvijek postavljaju su:

command - parametar koji main servlet odreuje kojem e servletu proslijediti zahtjev

action - parametar koji servletima odreuje koje e metode pozvati i odreuje koja se

sporedna stranica poziva unutar main.jsp-a

fromjsp - parametar koji oznauje s kojeg je servleta doao zahtjev, odreuje

servletima na koji nain e obraditi zahtjev, a prezentacijskom sloju na koji nain e

prezentirati odreene objekte
Primjer gumba glavnog izbornika koji postavlja command na vrijednost Main, action na
vrijednost NewUser i fromjsp na vrijednost Main:
<a href="#NoviKorisnik"
onClick="document.form.action.value='NewUser';
document.form.command.value='Main';
document.form.fromjsp.value='Main';
document.form.submit();
return false;">Unos korisnika</a>

Nakon to main servlet, odnosno aplikacijska logika obradi zahtjev, poziva se Main.jsp. koji
ita SessionAtributes parametar iz sessiona-a koji sadri parametre potrebne za prikaz
sadraja. Jedan od tih parametara je i action parametar koji main.jsp odreuje stranicu koja se
poziva unutar glavne tablice desno od izbornika.

71

itanje SessionAtributes objekta iz sessiona:

<jsp:useBean id="atrib" scope="session" class="hr.tel.fer.servletbeans.SessionAttributes">
</jsp:useBean>

Poziv sporedne stranice unutar glavne tablice

<td width="80%">
<%
String action = atrib.getAction();
if (action.equals("")) {
//ako action nije zadan poziva se stranica Home.jsp
action="Home.jsp";
}else{
action=action+".jsp";
}
%>
<jsp:include flush="true" page="<%=action %>"></jsp:include>
</td>

Sporedne stranice
Sporedne stranice pozivaju se unutar stranice Main.jsp. Svaka stranica ima definirane
elemente koje ine izgled stranice, za navigaciju i slanje parametara koriste formu Main.jsp-a.

Skripta na klijentskoj strani

Stranica NewUser.jsp koristi Java skriptu Script.js za validaciju podataka prije nego to se
poalju posluitelju. Pored toga, upozorava korisnika ukoliko nisu uneeni svi potrebni podaci
i pojednostavljuje upis filtera automatski dodavajuui novi red kod dodavanaja filtera.
Sljedea slika prikazuje upozorenje kod neispravno uneenog podatka.

72

Sl 6.10 Primjer prikaza upozorenja JavaScript-a

Script.js - Java skripta koja provjerava podatke forme prije nego to se alju aplikaciji

Pregled navigacije kroz stranice dan je na sljedeoj slici:

73

Sl 6.11 Navigacija kroz stranice izbornika

74

Sl 6.12 Navigacija kroz ostale stranice

6.4.4.

Aplikacijska logika

Autorizacija
Autorizacija je implementirana unutar Login servleta. Kada doe prvi zahtjev, poziva se init
metoda Login servleta unutar koje se inicijaliziraju konfiguracijski podaci. Jedan od podataka
je i administratorki username i password. Unutar doPost metode provjeravaju se uneeni
podaci, ukoliko podaci odgovaraju administratorskim, kreira se nova sesija i zahtjev se
prosljeuje main servletu.
if (user.equals(Constant.adminUser)){
if(pass.equals(Constant.adminPass)){
HttpSession session = req.getSession(true);
if (session.isNew() == false) {

75

session.invalidate();
session = req.getSession(true);
}

Prije prosljeivanja zahtjeva main servletu, sesiji se dodaje objekt SessionAtributes koji osim
parametara za prosljeivanje sadri i konekciju prema bazi podataka.
DBConnection conn=new DBConnection();
SessionAttributes atrib = new SessionAttributes();
atrib.setConn(conn);
session.setAttribute("atrib", atrib);
//prosljeivanje zahtjeva main servletu
redirect="/AdminSms/servlet/Main";

Glavna logika
Svi zahtjevi nakon autorizacije prosljeuju se main servletu koji vri glavnu logiku aplikacije.
Uloge main servleta su:
1. Provjerava da li postoji sesija korisnika
2. ita iz zahtjeva parametre command i action, potrebne radi daljnjeg prosljeivanja
zahtjeva
3. Ukljuuje (engl. include) zahtjev servletu naziva koji se nalazi unutar command
parametra
4. Prosljeuje (engl. forward) zahtjev Main.jsp koji ita parametar action za poziv
sporedne stranice

Primjer koda za svaki od funkcija main servleta.

String redirect="/AdminSms/index.jsp";
//provjera sesije korisnika
if (session==null) {
//ako sesija ne postoji proslijedi zahtjev na indeks.jsp

76

res.sendRedirect(redirect);
} else{
//itanje parametara iz zahtjeva
command=req.getParameter("command");
action=req.getParameter("action");
//ukljuije servlet
rd=getServletContext().getRequestDispatcher("/servlet/"+command);
rd.include(req, res);
//prosljeuje zahtjev Main.jsp-u
rd=getServletContext().getRequestDispatcher("/Main.jsp");
rd.forward(req, res);
}

Transaction i User servlet

Transaction i User servlet sadre svu logiku za interakciju sa slojem pristupa podacima kao i

pripremu podataka za prezentacijski sloj. Nakon to servlet primi zahtjev prosljeen od main
servleta, poziva metodu u ovisnosti o odabranoj akciji korisnika koja se ita iz action
parametra.
Primjer poziva metode User servleta u ovisnosti action parametra:
protected void doPost(HttpServletRequest req, HttpServletResponse res) throws
ServletException {
String action = req.getParameter("action");
if (action.equalsIgnoreCase("InsertUser")) {
insertUser(req, res);
} else if (action.equalsIgnoreCase("ViewAllUsers")) {
viewAllUsers(req, res);
} else if (action.equalsIgnoreCase("SelectUser")) {
selectUser(req, res);

77

} else if (action.equalsIgnoreCase("ChangeUser")) {
changeUser(req, res);
} else if (action.equalsIgnoreCase("DeleteUser")) {
deleteUser(req, res);
}

Funkcije koje svaka metoda vri mogu se naslutiti iz naziva metode. Na vrlo slian nain
funkcioniraju, itaju parametre iz zahtjeva i pune pozivaju metode beanova, odnosno sloja
pristupa podacima koji dohvaaju, mijenjaju ili dodaju vrijednosti u bazu podataka.
Popis funkcija servleta:
User.java

insertUser

viewAllUsers - po zadanom uvjetu dohvaa podatke vise korisnika iz baze i priprema

- ita podatke iz zahtjeva korisnika i unosi ih u bazu podataka

za prikaz

selectUser

- dohvaa podatke korisnika iz baze i priprema za prikaz

changeUser

- mijenja podatke postojeeg korisnika korisnika i unosi ih u bazu

podataka

deleteUser

- brie korisnika iz baze podataka

Transaction.java

viewAllTransactions - po zadanom uvjetu dohvaa podatke vise transakcija iz baze i

priprema za prikaz

selectTransaction

- dohvaa podatke transakcije iz baze i priprema za prikaz

Vrlo je lako zakljuiti da su JSP-ovi prezentacijskog sloja povezani s funkcijama User i

Transaction servleta (Tablica 6.1).

78

Tablica 6.1 Povezanost JSP-a sa funkcijama servleta

JSP

Servlet

Metoda

NewUser

User

insertUser

selectUser

User

selectUser

ViewAllUsers

User

viewAllUsers

selectTransaction

Transaction

selectTransaction

viewAllTransaction

Transaction

viewAllTransaction

DeleteUser

User

deleteUser

Home

Main

Index

Login

Main

Main

6.4.5.

Model

Model ove aplikacije ima sljedee funkcije:

Dohvaanje, auriranje i dodavanje podataka u bazu

Komunikacija s bazom podataka

Slino kao i u prethodnoj aplikaciji, za razmjenu podataka s bazom brinu se beonovi
User.java i Transaction.java (Objanjeno u poglavlju 6.3.4)

Prijenos podataka prezentacijskom sloju

Prijenos podataka iz aplikacijske logike prezentacijskom sloju vri se putem sesije korisnika,
odnosno session objekta. Osim podataka korisnika i transakcija, najee se alje objekt
SessionAtributtes koji sadri informacije za navigaciju i prikaz sadraja.

Primjer spremanja podataka korisnika iz baze podataka u polje stringova i dodavanje u objekt
sessiona (implementirano u User i Transaction servletu):

79

//dohvat korisnika iz baze podataka

String[][] users = user.selectRows(conn, searchCond, searchValue, cond,
sort, (pageNum - 1) * 10, 15);

//izracun broja stranica sprema se u instancu SessionAtributes objekta

atrib.setTotalPages(user.getRecordsCount() / 15);
atrib.setPageNum(pageNum);
atrib.setSort(sort);

//spremanje SessionAtributes objekta i polja stringova u session objekt

session.setAttribute("users", users);
session.setAttribute("atrib", atrib);

Primjer dohvata podatka iz sessiona unutar JSP-a:

//dohvat SessionAtributes objekta
<jsp:useBean id="atrib" scope="session"
class="hr.tel.fer.servletbeans.SessionAttributes"></jsp:useBean>

//dohvat polja stringova unbutar scripleta

<%
String [][] users=(String[][]) session.getAttribute("users");
%>

6.5. Korisnike aplikacije

Za koritenje aplikacije za slanje i primanje poruka potrebno je kreirati web servis klijenta.
Kako je jedna od prednosti web servisa neovisnost o programskom jeziku, korisnik moe
izabrati koritenje SDK (engl Software development kit) pri implementaciji klijenta. U sklopu

80

diplomskog rada implementirani su klijenti za slanje poruka koji koriste sve funkcije
SMS/MMS Gatewaya u jezicima Java i C#.
Za izradu klijenta potreban je opis web servisa koji korisnik moe nai na URL adresi (na
kraju URL adrese mora se dodati ?wsdl kako bi se dobila wsdl datoteka) web servisa
SMS/MMS Gatewaya.

6.5.1.

SDK u jezicima Java

Kreiranje web servis klijenta vrlo je jednostavno pomou programskog alata Eclipse 3.2 koji
ima podrku za kreiranje web servis klijenta iz opisa web servisa (wsdl. datoteka). Eclipse
kreira odgovarajue klase i beanove.
Primjer klasa koji se izgenerira:

WebSerClient.java

WebSerClientProxy.java

WebSerClientService.java

WebSerClientServiceLocator.java

WebSerClientSoapBindingStub.java

AttachmentFer.java

Koritenje aplikacije

Za poziv web servisa jednostavno se instancira Proxy objekt i pozove odgovarajua metoda,
odnosno poziv prema web servisu.
Primjer slanja SMS poruke:
WebSerClientProxy send = new WebSerClientProxy();
send.smsReceivedDelivery("user", "pass", "Proba", "38591111111");

Za slanje MMS-a potrebno je instancirati klasu AttachmentFer, ukoliko kao prilog koristimo
neku sliku, video itd., potrebno je prebaciti taj prilog u polje byteova.
Primjer funkcije koja iz datoteke kreira polje byteova:

81

private byte[] getAttachmentAsByteArray(String attachmentPath) throws

FileNotFoundException, IOException {
InputStream inStream = null;
ByteArrayOutputStream outStream = null;
try {
inStream = new FileInputStream(attachmentPath);
outStream = new ByteArrayOutputStream();
byte[] buffer = new byte[1024];
int readLength = 0;
while ((readLength = inStream.read(buffer, 0, 1024)) > -1) {
outStream.write(buffer, 0, readLength);
}
buffer = outStream.toByteArray();
outStream.close();
outStream = null;
inStream.close();
inStream = null;
System.out.println("Attachment size: " + buffer.length + " byte(s)");
return buffer;
} finally {
if (outStream != null)
outStream.close();
if (inStream != null)
inStream.close();
}
}

82

6.5.2.

SDK u jezicima C#

Koritenje aplikacije

Na jednak nain kreira se i web servis klijenta napisan u C#. Koritenjem alata Microsoft
Visual C# 2005 Express Edition, iz URL adrese web servisa.

Primjer poziva web servisa u C#:

webService.WebSerClientService send = new webService.WebSerClientService ();
status = send.smsReceivedDelivery(txtUsername.Text, txtPassword.Text, txtText.Text,
txtDest1.Text);

Za slanje MMS-a potrebno je prilog transformirati u polje byteova:

FileStream fs = File.OpenRead(txtPicture.Text);
byte[] content = new byte[fs.Length];
fs.Read(content, 0, (int)fs.Length);

U sklopu implementacije klijenta u C# napravljeno je i vizualno suelje koje korisnicima

olakava slanje poruka:

83

Sl 6.13 Suelje aplikacije za slanje poruka

Aplikaicija se pokree iz .exe datoteke, preduvjet za koritenje programa je instaliran .NET

Framework 2.0.

6.6. Web servis klijenta za primanje poruka

SMS/MMS Gateway poziva web servis klijenta kod prosljeivnja poruka preko Soap
protokola. Kao primjer implementiran je web servis klijenta u Javi na Tomcat posluitelju
koji prima poruke od SMS/MMS Gatewaya.
Web servis mora imati sljedee metode:
public

String

smsReceived(String

endpointURL,String

smsMessage,String

endUserAddress, String channel)

public

String

deliveryStatusReceived(String

endpointURL,String

from,String

status,String messageId, String channel)

Registrirati unutar konfiguracijske datoteke servera web servis i prijaviti URL adresu web
servisa administratoru SMS/MMS Gatewaya

84

Zakljuak
Razvoj mobilnih telekomunikacija, pojava novih tehnologija i konkurencija operatera pruaju
korisnicima sve raznovrsnije i zahtjevnije mogunosti. Dolazi do integracija i prilagodba
poslovnih informacijskih sustava takvim novim uslugama, te stvaranje novih partnerskih
odnosa u informatikom i telekomunikacijskom poslovanju.
Brzo i efikasno kreiranje novih usluga, upravljanje proizvodima i uslugama nakon njihovog
ukljuivanja u trite, te korisnika podrka za takve usluge su glavna podruja promjena u
poslovnoj praksi telekomunikacijskih tvrtki. Korisnik, njegovi zahtjevi i potrebe postaju
sredite poslovnog interesa operatera.
Vipnetov koncept otvaranja telekomunikacijske platforme prema vanjskim partnerima
omoguuje stvaranje vlastite aplikacije za slanje i primanje SMS i MMS poruka. Razvoje
takove aplikacije donosi nove sadraje u sklopu:

slanja i primanja SMS-a i MMS-a,

ukljuivanje 3D sadraja u poruku,

uvoenje virtualne i proirene stvarnosti,

pristup i kontrolu aplikacija.

Dodatne usluge obogauju ponudu i doprinose daljnjem razvoju novih aplikacija, to

omoguava bolji poloaj na tritu telekomunikacija.

85

Literatura
[1]

Marui, Sven: Unaprjeenje poslovanja telekomunikacijskih operatera primjenom

arhitekture usmjerene uslugama : magistarski rad [online]. Zagreb : Ekonomski
fakultet, 2006. Pristup:
http://oliver.efzg.hr/gnet/57Marusic.pdf#search=%22parlay%20marusic%22

[2]

Parlay X web services specification, Version 2.0;

http://www.parlay.org/en/specifications/; Parlay Group, 2004. g.

[3]

Service Delivery Platforms and Telecom web services; Moriana Group, srpanj, 2004

[4]

http://www.telekom.hr
http://www.t.ht.hr
http://www.parlay.org
http://www.morianagroup.com/
http://www.openmobilealliance.org/
http://www.3gpp.org/
http://www.vipnet.hr/
http://www.t-mobile.hr
http://www.tele.fi/
http://www.w3.org
http://www.corba.org/
http://www.ws-i.org/
http://www.optima-telekom.hr
http://www.vodatel.hr/
http://hr.wikipedia.org/

86