Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Damjan Kojc
UNIVERZALNI KOMUNIKACIJSKI ODJEMALEC S PODPORO ZA UPORABNIŠKI
ENUM
Diplomsko delo
Maribor, avgust 2011
I
Diplomsko delo univerzitetnega študijskega programa
UNIVERZALNI KOMUNIKACIJSKI ODJEMALEC S PODPORO ZA
UPORABNIŠKI ENUM
Študent: Damjan Kojc
Študijski program: UN ŠP - Elektrotehnika
Smer: Elektronika
Mentor: doc. dr. Iztok Kramberger
Somentor: doc. dr. Tomaž Rotovnik
Maribor, avgust 2011
II
III
ZAHVALA
Zahvaljujem se mentorju doc. dr. Iztoku
Krambergerju in so-mentorju doc. dr. Tomažu
Rotovniku za strokovno pomoč in vodenje pri
opravljanju diplomskega dela. Posebna zahvala
velja staršem, ki so mi omogočili študij in moji
mladi družini, ki me je neprestano spodbujala k
zaključku študija.
IV
UNIVERZALNI KOMUNIKACIJSKI ODJEMALEC S PODPORO ZA
UPORABNIŠKI ENUM
Ključne besede: uporabnik, mobilni odjemalec, poizvedba, ENUM protokol, domena, komunikacija, Java, Android
UDK:
004.42:004.777(043.2)
Povzetek
V diplomskem delu je predstavljeno, kako smo na podlagi raziskav obstoječih standardov
in podobnih pilotskih projektov (v tujini) s področja dostopa do različnih tipov
komunikacijskih kanalov preko ENUM protokola, zasnovali, razvili in nato vzpostavili
preprost model Uporabniškega ENUM sistema. Sistem smo razvili v programskem jeziku
Java EE in uporabili podatkovno bazo Oracle. Izdelali smo tudi prototip univerzalnega
komunikacijskega odjemalca za mobilni telefon z operacijskim sistemom Android.
Odjemalec zna na podlagi telefonske številke, ki je postala univerzalen ključ (globalno
dostopen vsem uporabnikovim potencialnim stikom), z ENUM DNS poizvedbo na
Uporabniški ENUM sistem pridobiti dodatne možne komunikacijske kanale do željenega
uporabnika in komunikacijo z njim tudi vzpostaviti.
V
UNIVERSAL COMMUNICATION CLIENT WITH USER ENUM
SUPPORT
Key words: user, mobile client, query, ENUM protocol, domain, communication, Java, Android
UDK:
004.42:004.777(043.2)
Abstract
This diploma work presents how we have designed, developed and set up a simple User
ENUM system on the basis of researches done on existing standards and similar pilot
projects abroad. It is developed in the Java EE programming language and with the use of
the Oracle database. We have developed a prototype of a universal communication client
for mobile phones with the Android operating system. The client is able to obtain
additional possible communication channels to a desired user and also establish
communication with the user on the basis of a telephone number, which has become a
universal key (globally available to all user's potential contacts) via the ENUM DNS query
to the User ENUM system.
VI
VSEBINA
1 UVOD ........................................................................................................................... 1
2 TEMELJI ENUM SISTEMA IN UPORABLJENA RAZVOJNA ORODJA ....... 4
2.1 KAJ JE ENUM ? ...................................................................................................... 5
2.1.1 ENUM protokol ................................................................................................. 7
2.1.2 Uporabniški ENUM ......................................................................................... 10
2.1.3 Infrastrukturni ENUM ..................................................................................... 12
2.2 JAVA ENTERPRISE EDITION (JAVA EE 5) .............................................................. 13
2.3 ECLIPSE (SOFTWARE DEVELOPMENT KIT) ............................................................ 16
2.4 OPERACIJSKI SISTEM ANDROID ............................................................................. 18
2.5 ANDROID PROGRAMSKI PAKET (SOFTWARE DEVELOPMENT KIT) ......................... 22
2.6 APLIKACIJSKI STREŽNIK (JBOSS AS 5) ................................................................. 25
2.7 SISTEM DOMENSKIH IMEN (DNS STREŽNIK BIND 9) ............................................ 27
2.8 APLIKACIJSKI PROGRAMSKI VMESNIK ZA DNS (DNSJAVA 2.0.8) .......................... 30
2.9 PODATKOVNA BAZA ORACLE 10G ........................................................................ 32
3 IMPLEMENTACIJA UPORABNIŠKEGA ENUM SISTEMA IN
UNIVERZALNEGA MOBILNEGA ODJEMALCA..................................................... 40
3.1 DELITEV SISTEMA PO SKLOPIH .............................................................................. 40
3.2 VZPOSTAVITEV RAZVOJNEGA OKOLJA ZA SISTEM UPORABNIŠKI ENUM .............. 42
3.3 PODATKOVNA BAZA UPORABNIŠKEGA ENUM SISTEMA ...................................... 46
3.4 PL/SQL SHRANJENE STREŽNIŠKE PROCEDURE ..................................................... 50
3.5 DOMENSKI STREŽNIK BIND ................................................................................. 52
3.6 ORODJE ZA DNS POIZVEDOVANJE V PROGRAMSKEM JEZIKU JAVA ....................... 54
3.7 SERVLET ZA DNS POIZVEDOVANJE IZ J2ME APLIKACIJ ....................................... 57
3.7.1 NAPTR zapisi v XML obliki (pravilo).............................................................. 59
3.8 UENUM - ENTERPRISE APLIKACIJA UPORABNIŠKEGA ENUM SISTEMA .............. 59
3.8.1 Spletni in EJB vsebnik ..................................................................................... 61
3.8.2 Konfiguracija trajnosti (JPA s ponudnikom Hibernate) ................................. 68
3.8.3 Konfiguracija modula za prijavo uporabnika v portal (angl. login module) .. 70
3.9 TELEDROID ENUM – UNIVERZALNI MOBILNI KOMUNIKACIJSKI ODJEMALEC ....... 75
VII
4 EKSPERIMENTALNI REZULTATI ..................................................................... 78
4.1 ENUM DNS POIZVEDBA ...................................................................................... 79
4.2 FUNKCIONALNOSTI PRI NEREGISTRIRANIH IN NEPRIJAVLJENIH UPORABNIKIH ....... 82
4.2.1 Preverjanje uporabnika pri registraciji mobilne številke................................ 84
4.2.2 Preverjanje uporabnika pri registraciji stacionarne številke.......................... 84
4.3 FUNKCIONALNOSTI PRI REGISTRIRANIH-PRIJAVLJENIH UPORABNIKIH ................... 85
4.3.1 Ažuriranje NAPTR zapisov .............................................................................. 85
4.3.2 Sprememba gesla in naslova elektronske pošte ............................................... 87
4.3.3 Zahteva za novo avtomatično generirano prijavno geslo ............................... 88
4.4 FUNKCIONALNOSTI PRI ADMINISTRATORJIH ......................................................... 89
4.4.1 Urejanje uporabnikov in registracij ................................................................ 89
4.4.2 Pregled dnevnih statistik in log datotek .......................................................... 91
4.5 ENUM POIZVEDBA NA MOBILNEM ODJEMALCU IN KOMUNIKACIJA ..................... 91
5 SKLEP ........................................................................................................................ 96
6 LITERATURA IN VIRI ........................................................................................... 98
7 PRILOGE ................................................................................................................. 100
7.1 SEZNAM SLIK ...................................................................................................... 100
7.2 SEZNAM PREGLEDNIC ......................................................................................... 102
7.3 NASLOV ŠTUDENTA ............................................................................................ 102
7.4 KRATEK ŽIVLJENJEPIS......................................................................................... 103
VIII
UPORABLJENI SIMBOLI IN KRATICE
A Address ADT Android Development Tools AJAX Asynchronous JavaScript and XML ANSI American National Standards Institute API Application Programming Interface AV Android Virtual Device BIND Berkeley Internet Name Domain BSD Berkeley Software Distribution CMP Container - Managed Persistence CPL Common Public License CRM Customer Relationship Management CSS Cascading Style Sheets DB Database DD Deployment Descriptor DDL Data Definiton Language DDMS Dalvik Debug Monitor Server DIG Domain Information Groper DML Data Manipulation Language DNS Domain Name System DNSSEC DNS Security Extensions EAR Enterprise ARchive EDNS0 Extended DNS EE Enterprise Edition EIS Enterprise Information System EJB Enterprise JavaBeans ENUM tElephone NUmber Mapping EPL Eclipse Public License ERP Enterprise Resource Planning FTS Full Table Scan GUI Graphical User Interface HTML Hyper Text Markup Language HTTP HyperText Transfer Protocol IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers IDE Integrated Development Environment IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6
IX
ISC Internet System Consortium ISO International Organization for Standardization JAAS Java Authentication and Authorization Service JAR Java ARchive JDBC Java DataBase Connectivity JDK Java Development Kit JDT Java Development Toolkit JMS Java Message Service JMX Java Management Extensions JNDI Java Naming and Directory Interface JPA Java Persistence API JRE Java Runtime Enviroment JSF JavaServer Faces JSP JavaServer Pages JTA Java Transaction API JVM Java Virtual Machine MMS Multimedia Messaging Service MX Mail eXchange NAPTR Naming Authority Pointer NP Number Portability NS Name Server OTI Object Technology International PID Process IDentifier PL/SQL Procedural Language/Structured Query Language POJO Plain Old Java Object RPM Red Hat Package Manager SCM Supply Chain Management SD Secure Digital SDK Software Development Kit SDL Software Development Laboratories SIP Session Initiation Protocol SMS Short Message Service SOA Start Of Authority SQL Structured Query Language SUPB Sistem za Upravljanje s Podatkovno Bazo TCP Transmission Control Protocol TSIG Transaction SIGnature TTL Time To Live URI Uniform Resource Identifier USB Universal Serial Bus VoIP Voice over IP XE Express Edition
X
XML Extensible Markup Language
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 1
1 UVOD
Potrebe po komuniciranju naraščajo iz dneva v dan in za ta namen imamo na voljo
različne stacionarne in mobilne telekomunikacijske storitve kot so stacionarna telefonija,
mobilna telefonija, IP (Internet Protocol) telefonija ter različne širokopasovne in optične
povezave. Vendar se pri tako velikem številu različnih možnosti pojavi problem, kako
enolično določiti posameznega uporabnika ne glede na uporabljeno tehnologijo
komuniciranja.
Vodilo in razlog za uvajanje novih sistemov in pripadajočih storitev znotraj sodobne
informacijske družbe so predvsem uporabniško profilirane vsebine, ki ne-le izboljšujejo
človeško sposobnost v poslovnem svetu v smislu dvigovanja donosnosti in oplemenitenja
izobraževanja ter zabavnega doživetja, temveč bogatijo življenje z razvojem
individualnega potenciala s pospeševanjem kreativnosti, rentabilnosti in informiranosti. V
ospredje stopajo mobilne komunikacije, ki posledično transformirajo sodobno
informacijsko družbo v smeri mobilnega življenjskega stila, pri tem pa se pojavljajo nove
družbene potrebe, kot so prisotnost, sledljivost, lokalizacija, poosebljanje in prepletanje
različnih principov sporočanja na tehnološkem ter predstavitvenem nivoju. Dogajanje
lahko povzamemo kot brezmejno mobilnost ali novo paradigmo, ki se rojeva iz hitro
rastoče konvergence inovacij, poslovnega sveta in mobilnega življenjskega stila.
Z razvojem elektronskih komunikacij temelječih na protokolu IP se je način, namen in
obseg medsebojnega komuniciranja dodobra spremenil. Uporabo donedavno najbolj
razširjene elektronske komunikacije na daljavo - klasične telefonije, temelječe na časovno
preklopnih protokolih, nadomeščajo nove generacije tehnologij, ki omogočajo široko
paleto komunikacijskih kanalov ter odprto polje za razvoj novih storitev in aplikacij.
Posledica številnih komunikacijskih kanalov in pestrosti storitev je množica naslovnih
in imenskih prostorov. Pristop, kjer si uporabniki sami gradijo in vzdržujejo lastne baze
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 2
kombinacij logičnih in fizičnih naslovov, je ustrezen le za omejeno število uporabnikov in
zato glede na rast IP domene ni več primeren. Za širšo uporabo storitev so potrebni
imeniki. V osnovi gre za kombinacijo razširjenega telefonskega imenika in sistema
domenskih naslovov. Sistem je poznan pod imenom ENUM (tElephone NUmber
Mapping) in v osnovi omogoča dostop do različnih tipov komunikacijskih kanalov
(stacionarna telefonija, faks, mobilna telefonija, elektronska pošta, itn.) in usmerjanje
prometa preko medmrežja.
Uporabniški segment ENUM sistema – Uporabniški ENUM imenik omogoča končnim
uporabnikom samostojno izbiro in nastavitve različnih načinov komunikacij ali izmenjave
vsebin z drugimi uporabniki. Sistem temelji na t.i. »opt-in« filozofiji [1], kjer se mora vsak
uporabnik, ki želi uporabljati in izkoriščati prednosti sistema, tudi vanj prijaviti in podati
svoje nastavitve. Z njimi sporoča drugim uporabnikom, kot tudi drugi njemu, na kakšen
način lahko v določenem času in prostoru med seboj komunicirajo. Na sliki 1.1 lahko
vidimo primer uporabe Uporabniškega ENUM sistema.
Slika 1.1: Primer uporabe Uporabniškega ENUM sistema
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 3
Uporabniški ENUM vključno z Univerzalnim komunikacijskim odjemalcem (v
nadaljevanju - celoten sistem) lahko povzamemo kot konvergenco ključnih tehnologij, ki
združuje poglavitne elemente interakcije znotraj sodobne informacijske družbe in
predstavlja osnovni element prihodnosti poslovnega in družbenega napredka, pri tem pa ne
gre toliko za tehnološki problem kot za konkurenčno storitveno prednost v globalni
inovacijski ekonomiji.
S tem diplomskim delom bi radi predstavili uporabniški segment sistema ENUM -
Uporabniški ENUM. Osnovni cilj diplomske naloge je raziskati obstoječe standarde in
pilotske projekte na področju dostopa do različnih tipov komunikacijskih kanalov preko
sistema ENUM, vzpostaviti preprost model Uporabniškega ENUM sistem in izdelati
aplikacijo za mobilni telefon, ki bo znala na podlagi pridobljenih informacij iz
Uporabniškega ENUM sistema komunikacijo tudi vzpostaviti.
Diplomsko delo je sestavljeno iz sedmih poglavij. Po kratkem uvodu bomo najprej za
lažjo predstavo in boljše razumevanje v drugem poglavju podali teoretično ozadje
posameznih orodij, tehnologij, sistemov in komunikacijskih protokolov, ki smo jih
uporabili pri načrtovanju in implementaciji celotnega sistema. Nato bomo v tretjem
poglavju opisali načrtovanje in razvoj posameznih sklopov sistema. V četrtem poglavju bo
podrobno predstavljeno delovanje celotnega sistema na testnih primerih. Prikazali in
opisali bomo pridobljene rezultate in težave, na katere smo naleteli, med izdelavo
diplomske naloge. Rezultati bodo zajemali funkcionalnosti, ki smo jih implementirali, in
tudi tiste, ki bi na osnovi ugotovitev še bile smiselne za razširitev predstavljenega sistema
in odjemalca. V petem poglavju je podan sklep diplomskega dela. Sledijo še uporabljena
literatura, viri in priloge.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 4
2 TEMELJI ENUM SISTEMA IN UPORABLJENA RAZVOJNA
ORODJA
Infrastruktura je temeljni strukturni element, ki skrbi za podporo ogrodja za celotno
strukturo. Pojem ima raznolike pomene glede na različna področja, v katerih se uporablja.
Največkrat se nanaša na različne načine prenosa s pomočjo cest, letališč, mostov, kakor
tudi za informacijske tehnologije. Infrastrukture so lahko razvite in funkcionalne v smislu
privatnega ali javnega značaja. Splošna uporaba koncepta infrastrukture ponuja
organizacijo in podporo za druge sisteme ali organizacije, katerim ta infrastruktura služi. Z
ekonomičnega stališča je infrastruktura temeljni element ekonomije, ki dopušča produkcijo
blaga in storitev brez da bi bili del produkcijskega procesa, saj zagotavlja le transport
surovin, podatkov oziroma končnih izdelkov.
Pri informacijskih tehnologijah se infrastruktura deli na strojno in programsko opremo.
Infrastruktura omogoča pretok informacij in po njej se v našem primeru pretakajo podatki.
Pravilna izbira infrastrukture ima veliko vlogo saj je z njo pogojen celoten sistem. Pri tem
imamo različne faktorje za zagotavljanje pretoka informacij kot so: prepustnost podatkov,
količina podatkov in odzivnost sistema. Tako za strojno kot za programsko opremo je
potrebno zbrati parametre in zahteve, ki jih morata izpolnjevati, da bo sistem zanesljiv,
hiter in da bodo uporabniki imeli pozitivno izkušnjo z uporabo že od samega začetka.
Za izbiro primerne infrastrukture je potrebno preučiti ustreznost programske opreme:
domenski strežnik, podatkovno skladišče in ostalo potrebno programsko opremo za
delovanje, urejanje in nadzor sistema. Vsa programska oprema potrebuje ustrezno delovno
okolje znotraj operacijskega sistema. Hkrati pa zahtevnost programske opreme pogojuje
zahtevnost strojne opreme. Sama strojna oprema je pogojena tudi s številom poizvedb na
sekundo, strukturo in velikostjo podatkovnega skladišča. Vsi podatki morajo biti varovani
in dostopni samo pooblaščenim osebam. Zagotoviti je potrebno tako kontrolo nad fizičnim
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 5
dostopom, kot kontrolo nad dostopom preko vseh ostalih komunikacijskih poti in
vmesnikov.
ENUM infrastruktura je sestavljena iz dveh sklopov, iz programske opreme in strojne
opreme. Pri tem programska oprema obsega operacijski sistem, DNS (Domain Name
System) strežnik, aplikacijski strežnik, spletno aplikacijo in podatkovno skladišče.
Osnovne naloge operacijskega sistema so zagotavljati stabilno in varno okolje za potrebe
ostale programske opreme, hkrati pa zagotavljati prilagodljivost na DNS strežnik in ostalo
programsko opremo, ki je potrebna za delovanje sistema. Ostala programska oprema
vsebuje spletne aplikacije ali spletne storitve, ki omogočajo vpisovanje novih zapisov,
urejanje obstoječih zapisov, določanje dovoljenj in privilegijev uporabnikov ter nadzor nad
delovanjem sistema.
2.1 Kaj je ENUM ?
ENUM lahko na zelo preprost način opišemo kot most med klasično telefonijo in
medmrežjem oziroma Internetom [2]. ENUM je običajno ime za skupek tehničnih
protokolov in ureditev infrastrukture, ki bo povezala običajni telefonski sistem z
medmrežjem - Internetom. ENUM je načrtovan za omogočanje globalnega dosega
uporabnikov na različnih elektronskih komunikacijskih napravah in aplikacijah z eno
identiteto oziroma z obstoječo telefonsko številko. Je standardiziran način pretvorbe
telefonskih številk v obliko, ki je primerna za vstop v medmrežje, na primer elektronska
pošta, VoIP (Voice over IP) in podobno. ENUM je protokol, ki določa, kako telefonsko
številko preslikati v DNS domenski prostor. Glede na namen uporabe in razlike v
poslovnih modelih ločimo uporabniški in infrastrukturni ENUM.
Idejna zasnova ENUM sistema je uporaba telefonskih številk, njihova transformacija v
enotne identifikacije virov URI (Uniform Resource Identifier) ter iskanje odgovorov po
principu DNS strukture, kar je dodobra uveljavljeno v IP svetu. Infrastruktura za ENUM je
zelo podobna infrastrukturi za domenske protokole in strežnike DNS. Hierarhična struktura
DNS strežnikov, ki omogoča delegacijo domen in dodeljevanje administracije manjšim
sklopom, je v svetovnem spletu dobro znana in uveljavljena, zato jo je tudi smiselno izbrati
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 6
kot osnovo za implementacijo Uporabniškega ENUM-a. Domenski strežniki so bistvena
komponenta v funkcionalnosti svetovnega spleta in vsem storitvam, ki jih ponuja.
Domenski strežnik DNS združuje različne vrste informacij s tako imenovanimi
domenskimi imeni. Najbolj pomembno pri tem je, da služi kot telefonski imenik za
svetovni splet, pri tem skrbi za preslikavo domenskih imen v pripadajoče IP naslove, ki so
potrebni za omrežno opremo, da ustrezno dostavi informacije preko svetovnega spleta.
Prav tako ti strežniki skrbijo za ostale storitve, kot so izmenjava elektronskih naslovov za
izbrane domene. Na enakovreden način so pri ENUM DNS strežniku shranjeni NAPTR
(Naming Authority Pointer) zapisi.
Najbolj osnova naloga domenskih strežnikov je preslikava imena gostiteljev v IP
naslove. Domenski strežniki imajo tudi druge pomembne naloge. Dodeljevanje domen
organizacijam neodvisno od fizične poti in hierarhije usmerjevalnikov, ki je predstavljena s
številčnimi IP naslovi. To pomeni, da lahko kontaktni podatki ostanejo enaki neodvisno od
številčne IP poti usmerjanja. Domenski strežniški sistem tudi razporeja odgovornosti za
dodeljevanje domenskih imen in skrbi za preslikave v IP omrežje z dovoljevanjem, da
veljaven strežnik za posamezno domeno sledi in skrbi za svoje spremembe ter da se pri
tem izogiba neprestanim potrebam za urejanje in spreminjaje centralnega registra.
Domenski strežnik mora vse podatke o zapisih shraniti. Za shranjevanje lahko uporablja
območne datoteke (angl. zone files) ali podatkovna skladišča. Območne datoteke v osnovi
omogočajo le ročno vpisovanje, kar je za dinamični sistem zelo neučinkovito. Podatkovna
skladišča omogočajo dinamično vpisovanje med delovanjem DNS strežnika.
DNS hierarhija omogoča drobljenje in decentralizacijo administriranja in upravljanja s
podatki, prav od vrhnjih slojev hierarhije do posameznih uporabnikov. DNS je izrazito
hierarhični model tako v administrativnem kot tehničnem pogledu. Temelji na delitvi
večjih domenskih prostorov na manjše oziroma na ustvarjanju poddomen. S vsako
poddomeno se vse pravice z upravljanjem poddomene in vseh nadaljnih poddomen prenese
na lastnika poddomene. DNS drevesna struktura in DNS protokol sta se v internetnem
okolju izkazala kot izjemno zanesljiva in učinkovita. Zato ni naklučje, da je bil DNS izbran
kot osnova za ENUM protokol. Slika 2.1 prikazuje primer DNS drevesa:
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 7
Slika 2.1: Primer DNS drevesa
DNS za preslikavo domenskih imen v IP naslove in delegacijo poddomen uporablja
posebne zapise v svoji podatkovni bazi. Tako se na primer za določitev IP naslova
strežnika uporablja A (Address) zapis ali naslovni zapis, ki preslika ime gostitelja
(hostname) v številčni naslov (IPv4 - Internet Protocol version 4). NS (Name Server) zapis
ali zapis domenskega strežnika se uporablja za preslikavo imena domene v seznam
domenskih strežnikov, ki upravljajo z izbrano domeno. SOA (Start Of Authority) zapis ali
zapis o začetku avtoritete določa domenski strežnik, ki nudi veljavne informacije o spletni
domeni. MX (Mail eXchange) zapis ali zapis za izmenjevanje pošte določa poštni strežnik,
ki je pristojen za sprejem elektronskih poštnih sporočil v imenu prejemnikove domene in
prednostne vrednosti, ki se uporabi za upoštevanje prioritete pri dostavi pošte, če je na
voljo več poštnih strežnikov. Za potrebe ENUM protokola se uporablja NAPTR zapis.
NAPTR zapis preslika telefonsko številko v URI, ki enoznačno določa, kako lahko
dostopamo do oglaševane storitve.
2.1.1 ENUM protokol
ENUM protokol uporablja enotne identifikatorje virov (URI), ki uporabljajo E.164.
E.164 je ITU-T (Telecommunication Standardization Sector) priporočilo, ki definira
mednarodni javni načrt za oštevilčevanje, ki je uporabljeno v PSTN in drugih podatkovnih
omrežjih. E.164 tudi definira obliko zapisa številk. Primer številke v formatu E.164 je
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 8
prikazan na sliki 2.2. Na sliki je tudi prikazana pretvorba E.164 številke v ENUM domeno,
ki poteka v štirih korakih.
Slika 2.2: Primer pretvorbe E.164 telefonske številke v ENUM domeno
V zgornjem primeru je vrhnja domena e164.arpa, ki je bila s strani ITU-T izbrana kot
vrhnja ENUM domena za uporabniški (javno dostopen) ENUM. Obrnjen vrstni red
telefonske številke prav tako sledi ITU-T sistemu mednarodnega številčenja, kar omogoča
delegacijo poddomen v e164.arpa drevesu na osnovi vhodne kode države, ki pa jo ravno
tako podeljuje ITU-T. Drevo e164.arpa je prikazano na sliki 2.3.
Slika 2.3: Hierarhija ENUM domenskega prostora, razdeljena na domene in pod domene
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 9
Za vsako storitev, ki se oglašuje na telefonski številki uporabnika, potrebujemo
ustrezen NAPTR zapis, ki vsebuje URI, na katerem je lahko uporabnik trenutno dosegljiv.
Primer NAPTR zapisa, ki vsebuje enoten identifikator vira (sip, email):
$ORIGIN 7.6.5.4.3.2.1.5.6.8.3.e164.arpa .
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
IN NAPTR 100 20 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
Tabela 2.1: Parametri NAPTR zapisa
Parameter Opis parametra
NAPTR Oznaka, ki določa, da gre za NAPTR zapis,
ORDER določa vrstni red, po katerem morajo biti NAPTR zapisi obravnavani,
PREFERENCE določa prioriteto obravnave v primeru več zapisov z enakim ORDER
parametrom,
SERVICES določa ENUM storitev, "E2U" označuje pretvorbo E.164 v URI,
FLAGS zastavice, kako interpretirati posamezne parametre (v uporabi
je zaenkrat samo "U"),
REGEXP regularni izraz, ki ga odjemalec uporabi pri naslednji poizvedbi, če
trenutna poizvedba ni dokončna,
REPLACEMENT zapis, ki ga odjemalec uporabi v regularnem izrazu za pridobitev
novega ključa za poizvedbo.
Telekomunikacijska oprema, ki podpira ENUM pred vzpostavitvijo komunikacijskega
kanala do uporabnika, pretvori ciljno telefonsko številko v domeno in izvede DNS
poizvedbo po NAPTR zapisih na ENUM domenski strežnik. Rezultat je lahko brez ali ima
več NAPTR zapisov, ki jih mora obdelati po vrstnem redu, kot ga določata parametra
»ORDER« in »PREFERENCE«. »ORDER« parameter določa vrstni red obravnave
zapisov v odgovoru, v primeru enakih vrednosti za »ORDER« pa »PREFERENCE«
parameter odjemalcu pove, kateremu zapisu ciljni uporabnik daje prednost. Kateri NAPTR
zapis bo dejansko izbran je pa odvisno od storitve, ki jo odjemalec potrebuje. Odločitev
preko katerega komunikacijskega kanala bo odjemalec poiskusil vzpostaviti komunikacijo
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 10
je prepuščena odjemalcu. Če je poizvedbo poslal poštni odjemalec, potem bo predvidoma
izbran NAPTR zapis, ki vsebuje URI za elektronsko pošto, če pa je poizvedbo poslalal SIP
(Session Initiation Protocol) odjemalec, se bo odločil za SIP URI.
2.1.2 Uporabniški ENUM
Uporabniški ENUM temelji na tehnologiji, ki uporablja ENUM infrastrukturo in E.164
identifikatorje. Definirana je v standardu RFC 3761 [3]. Idejna zasnova Uporabniškega
ENUM-a je sistem, ki uporablja obstoječe telefonske številke kot izhodiščni iskalni
parameter za več možnih načinov komuniciranja v omrežjih novih generacij (govor, fax,
elektronska pošta, mobilne komunikacije, tekstovna sporočila, spletni naslovi, itn.). Vsi
načini komuniciranja oziroma storitve morajo biti registrirane pri organizaciji IANA
(Internet Assigned Numbers Authority), ki je odgovorna za globalno usklajevanje DNS
korenov, IP naslavljanja in drugih virov internetnega protokola. Storitve, ki so registrirane
pri IANA lahko vidimo na sliki 2.4 [4].
Slika 2.4: Tabela ENUM storitev, ki so registrirane pri IANA
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 11
ENUM predvideva poslovni model, kjer je ENUM funkcionalnost ponujena neodvisno
od ponudnika ENUM storitev, ki je vrsta elektronske oblike vizitk. Podatki so zapisani v
domenskih strežnikih kot NAPTR zapisi. Telefonska številka postane univerzalni unikatni
ključ, ki je globalno dostopen vsem potencialnim stikom od uporabnika. Podatki
Uporabniškega ENUM-a so javno dostopni, kar pomeni, da vsi, ki poznajo globalni ključ,
torej telefonsko številko, imajo dostop do informacij o izbranem uporabniku. Uporabnik
ima nadzor nad svojimi izbranimi informacijami, ki so javno dostopne.
ENUM komunikacija se lahko vzpostavi tudi v obstoječe PSTN omrežje in obratno.
Tako je Uporabniški ENUM neobvezen kakor za klicanega uporabnika ali za uporabnika,
ki kliče. Torej se lahko dovolijo le tiste ENUM domene, za katere obstaja obstoječa
telefonska številka, za dosego tega je potrebna primerna administracija, identifikacija in
preverjanje.
Kompleksnost takšnega sistema, temelječega na omenjenem standardu, ki definira sam
protokol izmenjave podatkov, leži v poslovnem modelu. Ključni udeleženci tega
poslovnega modela so uporabniki, ki komunicirajo, operaterji različnih prenosnih omrežij
in storitev, operaterji posameznih številčnih blokov telefonskih številk, nacionalni
regulatorji, ki upravljajo relevantne panoge ter država, ki preko svojih vzvodov oblasti
pospešuje konkurenčnost gospodarstva ter elektronsko pismenost svojih državljanov.
Neposredna korist uporabe sistema Uporabniškega ENUM-a je v tem, da uporabnik, ki
želi vzpostaviti komunikacijski kanal z drugim uporabnikom, preko standardiziranega
protokola povpraša centralni register kontaktnih informacij, kako in z kakšnimi
prioritetami lahko doseže drugega uporabnika. Ker je med temi načini komunikacije vse
več takšnih, ki delujejo na komunikacijskih protokolih preko svetovnega spleta, in je
takšna komunikacija lahko tudi brezplačna, je zainteresiranost operaterjev, ponudnikov
storitev komunikacij na odplačni osnovi zelo majhna. Vseeno pa je njihova vloga v
poslovnem modelu Uporabniškega ENUM sistema ključna, saj brez njihove verifikacije
uporabnika kot upravičenca za uporabo posamezne telefonske številke, sistem ni mogoč.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 12
Telefonska številka, ki jo želi končni uporabnik Uporabniškega ENUM-a registrirati v
sistem in z njo upravljati v smislu brisanja, dodajanja in urejanja vnosov za storitve
oziroma komunikacijske kanale, ki se navezujejo na to številko, mora biti obstoječa in
aktivna pri ponudniku telefonskih storitev. Številka ne sme biti trajno ali začasno
izključena iz omrežja operaterja, pri katerem se nahaja. Preverjena mora biti skladnost
uporabnika in številke.
2.1.3 Infrastrukturni ENUM
Usmerjanje klicev med centralami ali med različnimi operaterji v klasičnem PSTN
omrežju temelji na statičnih konfiguracijah telekomunikacijske opreme. Vsaka sprememba
številskih blokov v številskem prostoru pomeni določen administrativni poseg na opremi,
zato pogoste spremembe niso zaželjene. Določitev izhodnega vmesnika na centrali se vrši
glede na rezultat analize predpon klicane telefonske številke. Z uvedbo prenosljivosti
telefonskih številk NP (Number Portability) se takšen sistem deloma poruši, saj je vsaka
prenešena številka v bistvu izjema in je promet do nje treba usmeriti drugam, kot to velja
za njen izvorni blok številk. Operaterji, ki nimajo takšne telekomunikacijske opreme, ki
podpira poizvedbe v podatkovne baze (LDAP, MySQL, ORACLE) imajo z usmerjanjem
prometa na prenešene številke precej težav. Infrastrukturni ENUM je v prvi vrsti namenjen
operaterjem. Operaterjem nudi odgovor na dve pomembni vprašanji, kje je številka in kako
naj pridem do nje. Vso kontrolo nad zapisi v ENUM podatkovni bazi ima operater. Z
upravljanjem NAPTR zapisov odloča, kako naj ostali operaterji usmerjajo promet v
njegovo omrežje. Usmerjanje podatkovnih paketkov v IP svetu ima v primerjavi z
usmerjanjem klicev v PSTN omrežju še eno pomembno lastnost: je dinamično. V IP svetu
in podatkovnih omrežjih je usmerjanje paketov realizirano na nižjih tehničnih nivojih in
ustrezni usmerjevalni protokoli poskrbijo, da bo paket prišel na cilj. S prehodom na VoIP
storitve postane tudi usmerjanje klicev dinamično, saj je to v bistvu še vedno samo
usmerjanje podatkovnih paketov.
Pravilno zasnovana ENUM postavitev in njegova uporaba operaterjem omogoča
dinamično usmerjanje prometa glede na trenutne potrebe in razpoložljivost opreme. Stroški
usmerjanja prometa se zmanjšajo in odprejo se možnosti za uvedbo novih storitev, ki do
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 13
sedaj niso bile možne oziroma so bile težko izvedljive in cenovno nezanimive.
Infrastrukturni ENUM pogosto ni javno dostopen končnim uporabnikom temveč je
namenjen izključno le operaterjem in drugim pravnim subjektom.
2.2 Java Enterprise Edition (Java EE 5)
Platforme na osnovi programskega jezika Java so z nami že poldrugo desetletje, od leta
1996 (JDK 1.0) [9]. Platforma Java EE predstavlja enovit standard za razvijanje in
nameščanje poslovnih informacijskih rešitev. Namenjena je razvoju porazdeljenih, varnih,
zmogljivih in učinkovitih informacijskih rešitev. Zato se z njo srečamo v osrčju
informacijskih rešitev večine podjetij. Predvsem s predstavitvijo različice EE (Enterprise
Edition) je platforma postala prva izbira mnogih organizacij in strokovnjakov pri gradnji
zahtevnih informacijskih rešitev. Specifikacije platforme Java EE 5 so prešle v končno
različico leta 2006 iz predhodne platforme J2EE 1.4. Njihovi snovalci so si ob širjenju
nabora funkcionalnosti zadali zelo pomemben cilj: omogočiti več funkcionalnosti in
storitev z manj vloženega truda končnih razvijalcev ali preprosteje rečeno z manj dela
narediti več. Poenostavljen razvoj se odraža v nižjem številu vrstic programske kode,
potrebnih za implementacijo istega problema kot pri predhodnih verzijah. K temu
pripomore velik nabor privzetih vrednosti, odprava deskriptorjev XML ter uvedba notacij.
Java EE 5 prinaša boljšo podporo spletnim storitvam, podpira več standardov, povezanih z
njimi. Poenostavljen je programski model EJB (Enterprise JavaBeans) in prehod od
aplikacij k storitvam. Pomembna pridobitev je aplikacijski programski vmesnik za trajnost
JPA (Java Persistence API), ki je namenjen upravljanju s podatki relacijskih baz, ter nova
tehnologija JSF (JavaServer Faces), ki predstavlja učinkovitejši pristop k načrtovanju in
izdelavi spletnih aplikacij in grafičnih uporabniških vmesnikov.
S specifikacijami različice 5 je platforma doživela mnogo pomembnih sprememb,
vendar nič drastično novega. Rečemo lahko, da združuje tehnologije, ki so se nakopičile
skozi razvoj platforme in so prerasle nekdanje okvirje in omejitve. Zato so jim postavili
druge, višje okvirje. Za osnovo so vzeli standardno različico platforme, ki so ji dodali
številne razširitve in tudi spremembe. Poleg združitve s standardno različico (J2SE)
specifikacija uvaja tudi dodatne zahteve in nekatera neobvezna priporočila. Poleg
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 14
dopolnitev obstoječih ogrodij iz J2SE in knjižnic so se v platformi pojavile tudi nekatere
nove.
Java EE še naprej ostaja sinonim za platformo, ki omogoča doseganje naprednih
funkcij informacijskih sistemov na enostaven način, podpira prenosljivost rešitev, dopušča
enostavno prilagajanje, vključuje visoko razpoložljivost, ponuja enostavne mehanizme
nameščenja rešitev in je naravnana na dolgo življenjsko dobo informacijskih sistemov. Na
področju poenostavljenega razvoja ponujajo največ novosti specifikacije različice 5 in
trenutne verzije 6, prihajajo pa specifikacije različice 7.
Java EE aplikacijski model se začne s programskim jezikom Java in javanskim
navideznim strojem. Preverjena prenosljivost, varnost in razvijalska produktivnost, ki jih
programski jezik in navidezni stroj prinašata, oblikujejo osnove aplikacijskega modela.
Java EE platforma uporablja porazdeljen večnivojski aplikacijski model za poslovne
aplikacije [10]. Aplikacijska logika je razdeljena na komponente v skladu s funkcijo, ki jo
opravljajo. Različne aplikacijske komponente omogočajo povezovanje komponent Java EE
aplikacij, ki so nameščene na različnih javanskih navideznih strojih, vendar so odvisne od
nivoja večnivojskega Java EE okolja, h kateremu pripadajo. Slika 2.5 prikazuje dve
večnivojski Java EE aplikaciji, razdeljeni v nivoje. Java EE aplikacijski deli so
predstavljeni kot Java EE komponente. Arhitektura Java EE definira nivo odjemalca,
vmesni nivo, ki lahko vsebuje podnivoje, in spodnji nivo. Nivo odjemalca podpira veliko
različnih odjemalcev, ki lahko tečejo znotraj in zunaj lokalnega omrežja in s tem tudi
požarnega zidu. Vmesni nivo je v našem primeru sestavljen iz spletnega in poslovnega
podnivoja. Vmesni nivo preko spletnega vsebnika (angl. web container) na spletnem
podnivoju odjemalcem zagotavlja storitve in kliče poslovno logiko (angl. business logic),
ki jo imamo v EJB komponentah, in se izvaja v EJB vsebniku (angl. EJB container). Na
spodnjem EIS (Enterprise Information System) nivoju lahko tečejo različni informacijski
sistemi, ki so dosegljivi preko stadardnih vmesnikov.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 15
Slika 2.5: Večnivojske aplikacije (nivoji in komponente)
Zgoraj smo že omenili, da so Java EE aplikacije zgrajene iz Java EE komponent. Java
EE komponenta je samostojna funkcionalna enota programske opreme, ki je s
pripadajočimi razredi in datotekami (xml, konfiguracijskimi) dodana aplikaciji Java EE,
kjer lahko komunicira z ostalimi komponentami. Java EE specifikacije definirajo naslednje
Java EE komponente:
• Aplikacijski odjemalci in apleti so komponente, ki tečejo na odjemalčevi strani,
• javanski servleti (angl. Java Servlets), ogrodje za kreiranje predstavitvenega sloja
spletnih aplikacij JSF in javanske strežniške strani JSP (JavaServer Pages) so
spletne komponente, ki tečejo na strežniški strani,
• ter EJB strežniška zrna, ki vsebujejo poslovno logiko in jo izvajajo na strežniški
strani.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 16
2.3 Eclipse (Software Development Kit)
Z razvojem odprtokodnega projekta Eclipse je v poznih devetdesetih letih pričel
laboratorij OTI (Object Technology International), ki je del podjetja IBM Kanada [13].
Novembra 2001 je podjetje skupaj z osmimi drugimi organizacijami ustanovilo Eclipse
konzorcij in nedobičkonosno odprtokodno skupnost Eclipse.org, ki sta nadaljevala z
razvojem orodja. Januarja 2004 je bila ustanovljena fundacija Eclipse. Konzorcij Eclipse
danes združuje že okoli 150 članov, med katerimi so tudi svetovno znana podjetja, kot so
Ericsson, Hewlett Packard, Intel, Red Hat in Borland. Prva različica razvojnega okolja je
bila izdana novembra 2001, tej pa so kmalu sledile novejše in bolj izpopolnjene verzije.
Eclipse 3.0, ki je izšel 21. junija 2004, temelji na arhitekturi izvajalnega okolja OSGi. Na
začetku je bilo orodje izdano pod licenco CPL (Common Public Licence), ki so jo kasneje
spremenili v EPL (Eclipse Public Licence).
Eclipse je prosto dostopno razvojno okolje za razvoj programske opreme v različnih
programskih jezikih in vsebuje integrirano razvojno okolje IDE (Integrated Development
Enviroment) ter razširljiv sistem za dodajanje vtičnikov (angl. plug-ins). Vtičniki so
strukturirani sklopi programske kode, ki dodajajo nove funkcionalnosti k razvojnemu
okolju [14]. Funkcionalnost se lahko doda v obliki programskih knjižnic (Java razredi z
javnimi aplikacijskimi vmesniki), razširitvijo platforme ali celo z dokumentacijo. Vtičniki
lahko definirajo razširitvene točke, ki so dobro opredeljeni stični kraji, kjer lahko drugi
vtičniki dodajajo funkcionalnosti. Vsak podsistem v platformi je sam po sebi strukturiran
kot niz vtičnikov, ki implementirajo nekatere ključne funkcionalnosti. Nekateri vtičniki
dodajajo vidne funkcije platformi z uporabo razširitvenega modela, drugi pa doprinašajo
razredne knjižnice, ki se lahko uporabijo pri implementaciji razširitev sistema. Na sliki 2.6
je diagram iz navodil za razvijanje vtičnikov, ki prikazuje arhitekturo Eclipse SDK
(Software Development Kit). Zaradi kompleksnosti je projekt razdeljen na tri podprojekte:
orodja za razvoj v Javi JDT (Java Development Toolkit), okolje za razvoj vtičnikov PDE
(Plug-in Development Environment) in platforma Eclipse.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 17
Slika 2.6: Arhitektura aplikacije Eclipse SDK
Razvojno okolje je večji del napisano v programskem jeziku Java, uporabi se lahko za
razvoj programske opreme v Javi, z uporabo raznih vtičnikov pa lahko razvojno okolje
razširimo tudi na druge programske jezike kot so Ada, C, C++, COBOL, Perl, PHP,
Python, Ruby (vključno z Ruby on Rails ogrodjem), Scala, Clojure in Scheme. IDE se
pogosto poimenuje po programskem jeziku, v katerem je razvoj omogočen, torej Eclipse
JDT za jezik Java, Eclipse ADT za jezik Ada, Eclipse CDT za jezik C/C++ in Eclipse PDT
za jezik PHP. Prednost uporabe Eclipse se pokaže pri razvoju zahtevnih programov, ki
uporabljajo kompleksne knjižnice, za katere je potrebno podrobno poznavanje delovanja in
hierarhije razredov. Večina knjižnic, tudi komercialnih, ima tudi dodatke, ki omogočajo
lažjo uporabo z dodano pomočjo in raznimi čarovniki. Tudi pri običajnih knjižnicah se
pokažejo prednosti, saj Eclipse prebere zaglavne datoteke (angl. header) in zna sproti
razširjati in pripraviti pomoč za argumente funkcij, ki jih uporabljamo. Vgrajene ima še
različne brskalnike kode in podporo za razhroščevanje (angl. debugging). Z različnimi
dodatki oziroma vtičniki se da doseči tudi izboljšano integracijo s servisi za nadzor kode
(subversion, git, perforce) ali spletnimi servisi (gForge). Velika prednost uporabe te
platforme je tudi možnost uporabe na mnogih med seboj različnih operacijskih sistemih,
kot so Linux, Microsoft Windows, Unix, Solaris in drugih.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 18
Glavni skupini komponent v orodju Eclipse sta perspektive in pogledi. Perspektiva je
okolje pod katerim zaslon Eclipse trenutno deluje. Splošno povedano imamo za vsak jezik
drugačno perspektivo: C/C++ perspektivo, Java perspektivo, Python perspektivo, itd.
Obstaja tudi debug ali razhroščevalna perspektiva. Perspektive so paketi dodatkov, ki jih
običajno naložimo ločeno od Eclipse orodja po potrebi. Med njimi se da zelo preprosto
preklapljati. Vsaka perspektiva vsebuje določeno število podoken oziroma pogledov.
Naprimer, za Java programsko kodo smo v Java perspektivi, medtem ko urejamo in
zaganjamo svojo kodo. Imamo brskalnik po mapah, datotekah, projektih in pogled z
urejevalnikom kode za vsako datoteko, ki jo trenutno urejamo, pogled povzetek, ki
prikazuje vse glavne komponente te kode (funkcije, globalne spremenljivke), konzolni
pogled, kjer se izvaja običajni vhod/izhod, itd. Med delom na Java programski kodi, lahko
občasno uporabimo tudi razhroščevalnik, v tem primeru lahko začasno preklopimo na
razhroščevalno (angl. debug) perspektivo, ki ima določeno število pogledov. Večina
jezikovnih perspektiv vključuje navigacijski pogled, kjer so navedeni projekti. Za C/C++ je
imenovan C/C++, za Python je imenovan Pydev Package Explorer, za Javo Package
Explorer, itd. Lahko pa uporabimo običajen generični navigacijski pogled imenovan
Navigator. Iz Eclipse razvojnega orodja lahko preko ustreznih dodatno nameščenih
vtičnikov konfiguriramo in zaganjamo različne aplikacijske strežnike, kot so JBoss,
Apache Tomcat, GlasFish, Weblogic in podobne.
2.4 Operacijski sistem Android
Android je programska platforma oziroma fleksibilen in nadgradljiv operacijski sistem
za pametne mobilne telefone, ki temelji na prirejenem Linux-ovem jedru. Razvijati ga je
začelo podjetje Android Inc., iz Pala Alta v Kaliforniji. Leta 2005 je bil prevzet s strani
Googla in leta 2007 s strani Open Handset Alliance OHA (Open Handset Alliance). Open
Handset Alliance je ime za poslovno združenje številnih podjetji, ki ga je Google ustanovil
v prizadevanju k skupnemu razvoju odprtih standardov na področju prenosnih naprav, k
čemur teži Android. Združenje OHA teži k pospešenemu razvoju inovacij na področju
mobilnih storitev ter se zavzema za bogatejše, cenejše in boljše mobilno doživetje vsakega
posameznika. Združenje je bilo javnosti uradno predstavljeno 5. novembra 2007, ko je bil
uradno napovedan tudi Android. Takrat je združenje štelo 34 podjetij. Združenje danes
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 19
šteje okrog 80 pomembnih podjetij s področja tehnologije programske in strojne opreme
ter telekomunikacij [15].
Android je v prvi vrsti namenjen mobilnim telefonom in tabličnim računalnikom, v
prihodnosti pa naj bi z njim opremili tudi nekatere druge naprave. Ime platforme oziroma
operacijskega sistema izhaja iz angleške besede »android«, ki pomeni robota, ki izgleda in
se obnaša kot človek. Google je izdal večino Androidovih programskih kod pod licenco
Apache License - brezplačne in odprtokodne licence. Brezplačna programska licenca
zahteva ohranjanje avtorskih pravic in odgovornosti, ne zahteva pa distribucijskih pravic.
To pomeni, da če je uporabljena programska koda razširjena kot brezplačna, jo lahko
uporabimo v plačljivi aplikaciji, kjer moramo navesti tudi uporabljene avtorske pravice in
odgovornosti. Nekaj Androidovih programskih kod pa je izdanih tudi pod licenco GPLv2,
(GNU General Public License), ki je največkrat uporabljena licenca za odprto programsko
opremo.
Odprtokodnost Androida prinaša naslednje prednosti:
• Za potrošnike to pomeni, da imajo na voljo cenejše in bolj funkcionalne mobilne
naprave, ter večje število inovativnih storitev.
• Proizvajalcem mobilnih telefonov omogoča znižanje stroškov razvoja programske
opreme in hitrejšo realizacijo svojih konceptov, prav tako pa jim ob fleksibilnosti
sistema še vedno prinaša možnost krojenja lastne identitete z razvojem svojih
rešitev.
• Podjetja, ki se ukvarjajo s programsko opremo, lahko ceneje in enostavneje
izdelujejo programske komponente, ki bodo na voljo velikemu številu uporabnikov.
Android temelji na Linux jedru in GNU programski kodi. Kljub skupni osnovi z
operacijskim sistemom Linux je okrnjen in prirejen za mobilne naprave. Temelji na
različici Linux 2.6 za temeljne storitve sistema, kot so varnost, upravljanje s pomnilnikom,
obvladovanje procesov, omrežni sklad in gonilniški model. Jedro deluje tudi kot abstraktna
plast med strojno opremo in ostalo programsko opremo, je monolitno in v enem kosu
združuje vse svoje funkcionalnosti. Operacijski sistem je sestavljen iz 12 milijonov vrstic
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 20
programske kode, njegovo jedro je napisano v programskem jeziku C, knjižnice v
programskem jeziku C++, uporabniški vmesnik v programskem jeziku Java, preostali del
pa je označevalni jezik XML (Extensible Markup Language). Sistem Android je razdeljen
na 5 glavnih komponent. Komponentna zgradba sistema je prikazana na sliki 2.7 [16].
Slika 2.7: Diagram glavnih komponent operacijskega sistema Android
Na najnižji plasti komponentnega diagrama je umeščeno Linux jedro, ki je odgovorno
za upravljanje s procesi, večnitnost, mrežno podporo, upravljanje s pomnilnikom in
upravljanje z gonilniki. Linux jedro služi tudi kot abstrakni nivo med strojno opremo in
ostalim programskim skladom. Plast višje imamo združeni dve komponenti. Prva
komponenta je skupek Android knjižnic, ki so napisane v jeziku C in C++. Funkcionalnosti
knjižnic so razvijalcem na voljo preko Android aplikacijskega ogrodja in zajemajo
podporo za 2D in 3D grafiko, strukturiran označevalni jezik SQLite z zmogljivim
relacijskim pogonom podatkovnega skladišča, podporo za multimedijo, podporo za bitno
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 21
in vektorsko pisavo ter drugo. Druga komponenta druge plasti je Androidovo izvajalno
okolje, ki vsebuje Dalvik navidezni stroj s knjižnicami jedra. Dalvik navidezni stroj deluje
kot vmesnik med operacijskim sistemom in aplikacijami. Java je osnova za vse aplikacije,
ki tečejo na Androidu, zato Dalvik poskrbi za prevod javanske programske kode v kodo, ki
jo operacijski sistem razume. Vsaki aplikaciji pripada lasten navidezni stroj. S tem različne
aplikacije ne vplivajo ena na drugo in napaka v aplikaciji ne vpliva na delovanje celotnega
sistema. Aplikacijsko ogrodje na tretji plasti zagotavlja odprtost razvojne platforme in
razvijalcem ponuja možnost razvoja izjemno naprednih in inovativnih aplikacij.
Prostovoljno lahko izkoristijo funkcionalnosti strojne opreme, dostopajo lahko do
informacij o lokacijah, nastavljajo alarme, dodajajo obvestila v statusno vrstico in še veliko
več. Imajo neomejen dostop do ogrodja vmesnikov, ki jih uporabljajo jedrne aplikacije.
Arhitektura aplikacij je zastavljena tako, da poenostavi ponovno uporabo komponent, torej
vsaka aplikacija lahko uporabi funkcije vseh drugih aplikacij. Ta mehanizem dovoljuje tudi
uporabnikom, da te komponente zamenjajo. Na vrhu modela so prednaložene osnovne
javanske aplikacije, kot so imenik, e-poštni odjemalec, mape, budilka, internetni brskalnik,
aplikacija za klicanje, aplikacija za pošiljanje SMS sporočil (Short Message Service),
MMS (Multimedia Messaging Service) sporočil in drugo. Uporabnik nanje ni vezan,
sistem mu omogoča, da jih lahko kadarkoli zamenja.
Izredno pomemben element pri (ne)uspehu določenega izdelka imata uporabniška
izkušnja in z njo povezan uporabniški vmesnik. Priznati je treba, da se lahko uporabnik
naprave z Androidom nanj hitro privadi, saj njegova uporaba praktično ne zahteva
posebnega učenja. Pri namestitvi v ustrezno strojno opremo, je tudi ustrezno odziven.
Uporabnik lahko delovno okolje (beri: namizje zaslona) oblikuje v skladu s svojimi željami
in potrebami. Pomembnejše pa je dejstvo, da Android podpira večopravilnost. Aplikacije
lahko zato delujejo tudi v »ozadju« in še vedno kot aktivne beležijo vse potrebne
informacije in uporabljajo potrebne komponente (npr. GPS-modul) ali opozarjajo na
dogodke (npr. končan prenos datoteke, novo elektronsko sporočilo).
Jasno je, da je pri razvoju Androida Google napeljal vodo tudi na svoj mlin.
Vzpostavljena je močna povezanost naprav z Androidom in Googlovimi storitvami.
Uporabnik ima stalno ažurne in varno shranjene podatke, ne glede na tip naprave (naprava
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 22
z Androidom, osebni računalnik, prenosnik), Google pa večno zadovoljnega in lojalnega
uporabnika storitev. Preizkušen in v praksi uspešen model, ki je uporabljen za Applove
iPhone, uporablja pogosto tudi Android. Aplikacije je mogoče preprosto, hitro in
največkrat brezplačno, namestiti v napravo z Androidom brez osebnega računalnika. Na
koncu pa vsekakor zelo pomembno dejstvo – naprave z Androidom je mogoče razmeroma
preprosto posodobiti, seveda pod pogojem, da je nova različica na voljo tudi za napravo, ki
jo uporabnik ima.
2.5 Android programski paket (Software Development Kit)
Android programski paket za razvoj aplikacij SDK je skupek razvijalskih orodij za
platformo Android. V SDK paketu so vključena orodja za razvoj in sicer razhroščevalnik,
knjižnice, navidezni emulator ali simulator mobilne naprave, dovršena dokumentacija in
nekaj osnovnih primerov z vodiči (angl. tutorials). Pri vzpostavitvi razvojnega okolja
potrebujemo še Apache Ant, javanski razvojni paket JDK in Python 2.2 ali novejši, ki pa
so že vključeni v SDK paket. Edino uradno podprto razvojno okolje IDE je Eclipse od
različice 3.4 naprej z dodanim vtičnikom ADT (Android Development Tools). Možna je
uporaba tudi drugih urejevalnikov besedil za urejanje javanskih in XML datotek, s katerimi
se operira preko ukazne vrstice. Upravljanje preko ukazne vrstice je mogoče tudi za
priključene naprave.
Android SDK vsebuje emulator oziroma virtualno mobilno napravo, ki teče na
razvojnem računalniku. Razvijalcu pomaga pri razvijanju aplikacije, saj si z njim lahko
pomaga pri testiranju brez prisotnosti fizične Android naprave oziroma mobilnega
telefona. Simulira vse strojne in programske lastnosti tipične mobilne naprave. Okno
emulatorja vsebuje celoten nabor možnih gumbov za izvajanje akcij z uporabo miške ali
tipkovnice in ekran, kjer vidimo izvajanje aplikacije. Pomemben del emulatorja je
konfiguracija navidezne naprave AVD (Android Virtual Device). AVD-ji nam omogočajo
spreminjanje različice Android okolja, vrsto izgleda emulatorja in željeno konfiguracijo
strojne opreme navidezne naprave. Simuliramo lahko različne naprave in različice
operacijskega sistema Android. Trenutno imamo na voljo SDK pakete za različice Android
operacijskega sistema 1.5, 1.6, 2.1-update 1, 2.2, 2.3.1 in 2.3.3, ter možnosti strojne sestave
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 23
emulatorja (podpora GPS, kamera, SD kartica, pospeškometer, itd.). Ko imamo aplikacijo
nameščeno na emulator, lahko ta uporablja storitve Android platforme za povezovanje z
drugimi aplikacijami, predvajanja zvoka in videa, dostopa do omrežja, komunikacije z
uporabnikom in podobno. Ker je emulator navidezna naprava, ki simulira delovanje fizične
naprave, ima tudi omejitve in nima podpore za nameščanje in sprejemanje klicev, USB
(Universal Serial Bus) povezavo, zajem slike in videa, priključeno slušalko, Bluetooth,
zaznavanje stanja baterije, zaznavanje stanja povezanosti in zaznavanje vstavljene SD
(Secure Digital) kartice. Na sliki 2.8 imamo primer emulatorja.
Slika 2.8: Primer Android emulatorja za operacijski sistem Android 2.1 (Eclair)
Android SDK vsebuje razhroščevalno orodje DDMS (Dalvik Debug Monitor Server),
ki ponuja storitev posredovanja vrat, zajem slike na ekranu naprave, informacije o
procesih, izpis sklada in niti, dnevnike, simulacijo sprejemanja klicev in SMS sporočil,
navidezno spreminjanje lokacije in več [17]. Omogoča tudi uporabo zastavic (angl.
watches) in prekinitvenih točk (and. breakpoints), kot so razvijalci vajeni pri razvoju
programske opreme v skorajda vseh naprednejših razvojnih okoljih (IDE). DDMS lahko
deluje z emulatorjem in povezano napravo. Če sta oba povezana in tečeta hkrati, bo DDMS
kot privzetega obravnaval emulator. DDMS deluje kot vmesnik med IDE in aplikacijami,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 24
ki tečejo na napravi. Vsaka aplikacija teče v svojem procesu, ki gosti svoj navidezni stroj.
Vsak proces posluša DDMS na svojih vratih. Ko navidezni stroj teče, DDMS pridobi
identifikator procesa PID (Process IDentifier) od navideznega stroja in se poveže z
razhroščevalnikom navideznega stroja. Tako lahko poteka komunikacija po žičnem
protokolu med DDMS in navideznim strojem. Za vsak navidezni stroj DDMS odpre svoja
vrata, povezave se vzpostavljajo od vrat 8600 naprej.
Oblikovanje grafičnega vmesnika aplikacije poteka z urejanjem XML datotek, kar je
zelo podobno urejanju spletnih strani s spreminjanjem HTML (Hyper Text Markup
Language) datotek. Pri izdelavi aplikacij ne moremo mimo mehanizma, imenovanega
namen (angl. intent). Namen je podoben komunikaciji med procesi IPC (Inter Process
Communication). Gre za podatkovno strukturo, ki vsebuje opis akcije, ki se mora izvesti in
nosi dve informaciji. Akcija (npr. prikaz »ACTION_VIEW«) in podatek, nad katerim naj
se ta akcija izvede (npr. telefonska številka »tel51234567«). Namen se najpogosteje
uporablja za zagon aktivnosti in storitev.
Pri razvoju aplikacij je zelo pomembna datoteka »AndroidManifest.xml«, brez katere
aplikacije ne delujejo. S to datoteko se aplikacija predstavi operacijskemu sistemu Android
in med drugim vsebuje naslednje informacije:
• Ime javanskega paketa, ki služi tudi kot unikatni identifikator.
• Seznam glavnih komponent sistema (aktivnosti, storitve, sprejemniki in ponudniki
vsebin).
• Seznam dovoljenj, ki so potrebna za delovanje aplikacije.
• Minimalno verzijo Android operacijskega sistema, ki je potrebna za delovanje
aplikacije.
Prevedena javanska koda s potrebnimi viri se se zapakira v arhivsko datoteko (.apk).
Vse kar je zapakirano v eni takšni arhivski datoteki, se smatra kot ena aplikacija. Preden
lahko aplikacijo uporabimo na Android napravi, ali jo pošljemo v Google Android Market,
jo moramo digitalno podpisati. Zadostuje že podpis z lastnim certifikatom, kar nam
omogoča tudi čarovnik znotraj programskega okolja Eclipse.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 25
2.6 Aplikacijski strežnik (JBoss AS 5)
JBoss AS (JBoss Application Server) je najbolj razširjen odprtokodni aplikacijski
strežnik na trgu. Aplikacijski strežnik lahko namestimo na več operacijskih sistemov, kjer
je prisoten javanski navidezni stroj JVM (Java Virtual Machine). Pomembna značilnost te
vrste programske opreme je ta, da ne implementira samo strežnika, ki teče na Javi, ampak
dejansko implementira tudi Java EE del Java okolja. JBoss AS 5 je v celoti kompatibilen z
Java EE 5, vključno z naprednimi storitvami kot so gruče (angl. clustering), predpomnilnik
(angl. cache), spletne storitve (angl. web services), strežniška javanska zrna EJB
(Enterprise JavaBeans), javanska sporočilna zrna JMS (Java Message Service), delo s
transakcijami JTA (Java Transaction API) in mnogimi drugimi. Naslednji diagram na sliki
2.9 prikazuje pregled projektov skupnosti JBoss.org vključno z JBoss AS in njegovimi
sestavnimi komponentami [23].
Slika 2.9: Projekti skupnosti JBoss.org, JBoss AS 5 s komponentami
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 26
JBoss AS 5 je zgrajen na vrhu novega JBoss mikrovsebnika (JBoss Microcontainer).
JBoss mikrovsebnik je lahki vsebnik, ki podpira neposredno uvajanje, konfiguriranje in
življenjski cikel navadnih javanskih objektov POJO (Plain Old Java Object). Aplikacijski
strežnik uporablja mikrovsebnik za integracijo celovitih storitev s spletnim vsebnikom
(servleti in JSP) in EJB vsebnikom, ter za uporabo in upravljanje orodij z namenom
zagotavljanja standardnega Java EE okolja. Če želimo, lahko dodatne storitve dodamo
oziroma uvedemo na vrhu Java EE in s tem se zagotovimo funkcionalnosti, ki jih
potrebujemo. Nepotrebne storitve pa lahko preprosto odstranimo s spremembo
konfiguracije strežnika. Mikrovsebnik lahko uporabimo, da to storimo tudi v drugih
okoljih, kot sta Tomcat in GlassFish, odkar lahko nanj priklopimo različne modele
nalaganja razredov (angl. classloading models) v fazi uvajanja storitev. Projekt JBoss
Microcontainer je samostojen in nadomešča JBoss JMX (Java Management Extensions)
mikrojedro (JBoss JMX Microkernel), uporabljeno v JBoss AS 3.x in 4.x. Cilji JBoss
Microcontainer projekta so bili:
• Narediti projekt JBoss Microcontainer takšen, da bo dostopen kot samostojen
projekt.
• Osvojiti strategijo JBoss POJO vmesne programske opreme.
• Omogočiti JBoss storitvam, da se bodo zlahka uporabljale v drugih vsebnikih.
• Dovoliti funkcijam, da se bodo lahko uporabljale v strožjih okoljih (npr. Appleti,
J2ME in podobno).
• Upravljanje s POJO konfiguracijami, podpora za medsebojno odvisnost in podpora
za delovanje v gručah.
JBoss AS ima vgrajen spletni vsebnik Apache Tomcat, na katerem tečejo HTML strani,
JSP strani in servleti. Kot EJB vsebnik uporablja lastno implementacijo zadnje revizije
specifikacije strežniških zrn JBoss EJB. Podprta EJB 3.0 specifikacija je globoka prenova
in poenostavitev specifikacije EJB. Podporo za JTA nudi prav tako preko svoje
implementacije JBoss JTA [24]. Kot privzeti ponudnik trajnosti je uporabljen Hibernate.
Pri nameščanu oziroma uvajanju aplikacij se uporabljajo uvajalni deskriptorji DD
(Deployment Descriptor), ki z XML strukturo natančno določajo kako in v kateri vsebnik
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 27
strežnika naj se določena komponenta, modul ali aplikacija uvede (angl. deploy).
Uporabljeni so različni deskriptorji in sicer uvajanje modulov s strežniškimi zrni (EJB) se
opiše v deskriptorju »jboss.xml«, uvajanje spletne aplikacije (WAR) v »jboss-web.xml«,
uvajanje celovite aplikacije (EAR) v »jboss-app«, pri uvajanju trajnosti (JPA) pa
uporabimo deskriptor »persistence.xml« [24].
JBoss EAP (JBoss Enterprise Application Platform) je strogo preizkušena, stabilna in s
strani JBoss/RedHat podprta platforma za razvoj in uvajanje Java aplikacij in storitev. V
EAP so integrirane programske kode oprtokodnih projektov skupnosti JBoss.org. Celoto
sestavljajo JBoss AS s podporo za delovanje v gručah, ogrodje Hibernate in ogrodje JBoss
Seam, z enojnim posodobitvenim tokom in večnivojsko vzdrževalno politiko. JBoss EAP
je certificiran za 17 operacijskih sistemov, za 5 sistemov za upravljanje s podatkovnimi
skladišči in JVM kombinacijami. Platforma vključuje tudi JBoss razvojni studio (JBoss
development Studio).
2.7 Sistem domenskih imen (DNS strežnik BIND 9)
DNS je distribuirana, hierarhična baza, katere prvotni namen je pretvarjanje uporabniku
prijaznih domenskih imen (www.teletech.si) v numerične IP številke (84.255.212.18) in
obratno [5]. DNS se zraven pretvorbe uporablja tudi za shrambo in pošiljanje informacij o
strežnikih elektronske pošte (MX zapisi). DNS strežniki delujejo na vratih (angl. port) 53
in to na TCP in UDP prenosnem sistemu. Protokol predvideva, da se povpraševanja
izvajajo preko UDP protokola, sam prenos iz primarnih na druge strežnike pa naj zaradi
pravilnosti podatkov poteka preko TCP protokola.
Domensko ime je način imenovanja računalnika ali druge mrežne naprave. Kot primer
www.teletech.si je domensko ime, ki pripada spletnemu strežniku podjetja Teletech.
Domenska imena so hierarhično organizirana v domene. Kot primer www.teletech.si je
domensko ime domene teletech.si, ki pa je poddomena domene si, ki pa je poddomena
korenske (root) domene. Domenska imena in domena so v približno enaki relaciji kot so
datoteke v direktorijih. Imamo en glavni korenski direktorij (root) in v tem korenskem
direktoriju lahko imamo več direktorijev, v katerih lahko imamo več datotek itd. Če
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 28
primerjamo direktorije z domenami vidimo razliko samo v označevanju. Pri direktorijih
imamo poševnico (/) ali levo poševnico (\) odvisno od operacijskega sistema, pri domenah
pa imamo piko (.). Vsako domeno lahko administriramo kot posamezno celoto (tako
imenovana območja – a zone), ki lahko vsebuje, ali pa tudi ne vsebuje raznorazne
poddomene. S piko ločene komponente domenskega imena imenujemo labele. Vsaka
labela je lahko dolga maksimalno 63 znakov in celotno domensko ime ne sme presegati
255 znakov. Čeprav sam DNS sistem nas ne omejuje z uporabo posebnih znakov v
domenskem imenu, lahko naletimo na raznorazne težave v aplikacijah, ki uporabljajo
domenska imena. Da se izognemo težavam je priporočljivo uporabiti le črke, številke in
znak minus (-), posebno pri domenskih imenih za A in za MX zapise.
Korenski imeniki vedo, kje se nahajo njegovi avtoritativni imenski strežniki za vsako
vrhovno cono in za nekatere cone so korenski imeniki tudi domenski strežniki (angl. top-
level zone). Tako v procesu iskanja imena, korenski strežniki pomagajo pri razreševanju od
osnovnega strežnika pa vse tja do računalnika na željenem naslovu. Vrhovne cone
predstavljajo delček naslovov dodeljenih različnim telesom: državam (vsaka država ima
svojo labelo - kratico), korporacijam in organizacijam. Te administrira internacionalna
organizacija z imenom ICANN (Internet Corporation for Assigned Names and Numbers).
DNS ime ponazarja ime v hierarhiji, s tem, da je na prvem mestu točno ime računalnika, na
zadnjem mestu pa od kod izvira (primer: vilma.teletech.si). Primeri vrhovnih con so .com
(namenjena predvsem uporabi v komercialne namene), .org (namenjena predvsem za
neprofitne namene), .net (namenjena predvsem za organizacije, ki se ukvarjajo z
omrežjem), .edu (namenjena v izobraževalne namene), .int (namenjen predvsem za
internacionalne organizacije) ipd. Danes ta izbor dodelitve imen ni več tako strogo
kategoriziran in omogoča uporabo zgoraj navedenih domen za drugačne namene.
Nacionalne poddomene administrirajo organizacije, ki organizirajo poddomene raznim
uporabnikom (bodisi privatnim ali javnim). Vsaka poddomena mora biti registrirana na
domenskem strežniku, ki mora vključevati domeno v svoji bazi domen. Primarni DNS
strežnik, poznan pod imenom »primary master« ali pa samo kot »primary«, je ime
strežnika, ki hrani DNS podatke za določeno cono. Sekundarni DNS strežnik ali
»secondary DNS server«, je domenski strežnik, ki vodi vsebino primarnega DNS strežnika,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 29
za primer, ko je s primarnim DNS strežnikom kaj narobe. Kopija DNS strežnika se ne
ustvarja ročno, ampak se avtomatsko kopira iz primarnega DNS strežnika. Sekundarni
DNS strežnik v časovnih intervalih povpraša primarni DNS strežnik, ali so se podatki kaj
spremenili in v primeru sprememb izvede prenos podatkov (zone transfer). Vsaka domena,
naj bi za optimalno delovanje imela vsaj dva strežnika (primarnega in sekundarnega),
lahko pa jih ima celo več. TTL (Time To Live) ponazarja čas, koliko časa so podatki v bazi
DNS veljavni. Ta čas se uporabi tudi pri predpomnenju domen v različnih DNS strežnikih.
Po preteklem času (TTL) se predpomnilnik obnovi. Podatki v DNS strežniku so
organizirani v tako imenovanih zapisih virov RR (Resource Records). Vsako domensko
ime ima eno ali več zapisnih virov, ki so različnih tipov, za shranjevanje različnih tipov
podatkov.
BIND je daleč najbolj razširjena odprtokodna DNS programska oprema na internetu in
je implementacija DNS protokolov [6]. DNS protokoli so del osnovnih internetnih
standardov. Ime BIND je kratica za »Berkeley Internet Domain Name«, saj programska
oprema izvira iz kalifornijske univerze Berkeley (iz začeteka 80-tih let). Zagotavlja
zanesljivo in stabilno platformo, na vrhu katere lahko organizacije gradijo porazdeljene
računalniške sisteme z zagotovostjo, da so ti sistemi v celoti skladni s standardi DNS.
Primerna je za obsežne, visoko kakovostne in zanesljive aplikacije. Distribucija BIND
programske opreme je sestavljena iz treh delov:
• DNS strežnik: Ta program se imenuje »named« in se izgovarja "name-dee",
pomeni "name daemon" oziroma imenski proces. Ta proces odgovarja na
poizvedbe, ki so mu bile poslane v skladu s pravili, določenimi v standardih DNS
protokolov.
• DNS knjižnica razreševalnika: Knjižnica, vključena v BIND distribucijo, vsebuje
vse programske komponente in vmesnike za preslikavo domenskih imen in
internetnih naslovov, namenjena pa je aplikacijam, ki potrebujejo storitev
imenskega razreševanja.
• Programska orodja za testiranje strežnikov: To so orodja, ki se lahko
uporabljajo za testiranja, vključena so v distribucijo z namemnom, da se lahko v
primeru razvoja lastnega testiranja razvijalec prepriča o pravilni konfiguraciji
strežnika.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 30
BIND različice 4 in 8 so uradno odsvetovane, saj zanje ni podpore pri odpravi hroščev
in varnostnih popravkih. Podjetje ISC (Internet System Consortium), ki je razvilo in sedaj
vzdržuje trenutno različico BIND, spodbuja vse uporabnike, da nadgradijo na najnovejšo
različico BIND 9 [7]. BIND 9 je obnovljena različica, ki zajema vsa področja osnovne
BIND arhitekture nižjih različic. Nekatere pomembne značilnosti BIND 9 so DNS Security
(DNSSEC - DNS Security Extensions, TSIG - Transaction SIGnature), IPv6 - Internet
Protocol version 6, izboljšave DNS protokola (IXFR – Incremental Zone Transfer in DNS,
DDNS - Dynamic DNS, EDNS0 – Extended DNS, DNS Notify), večprocesorska podpora
in izboljšana arhitekturna prenosljivost.
2.8 Aplikacijski programski vmesnik za DNS (dnsjava 2.0.8)
Aplikacijski programski vmesnik »dnsjava2.0.8« je implementacija DNS v
programskem jeziku Java [8]. Podpira vse definirane tipe zapisov vključno z DNSSEC tipi
in tudi neznane tipe. Lahko se uporabi za poizvedbe, prenose območij oziroma con in
dinamične posodobitve. Vključuje predpomnilnik, ki ga lahko uporabljajo odjemalci in
minimalno implementacijo strežnika. Podpira TSIG overjena sporočila, delno DNSSEC
verifikacijo in EDNS0.
Vmesnik »dnsjava2.0.8« zagotavlja funkcionalnosti, ki presegajo funkcionalnosti v
razredu »java.net.InetAddress« z enakim področjem uporabe iz osnovnega nabora knjižnic
Jave. Odkar je vmesnik napisan v celoti v programskem jeziku Java, so funkcionalnosti
implementirane z uporabo niti (threads), in v mnogih primerih je delovanje veliko hitrejše
kot pri implementacijah z uporabo »java.net.InetAddress« razreda. Na sliki 2.10 je
predstavljen primer uporabe niti.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 31
Slika 2.10: Primer procesa z dvema nitima, ki se izvajata hkrati
Z uporabo vmesnika je omogočen višji in nižji nivo dostopa do DNS. Naloge na višjem
nivoju opravljajo poizvedbe za zapise po imenu, tipu, razredu in vračajo odgovor ali razlog
za napako. Obstajajo tudi naloge, podobne tistim v razredu »java.net.InetAddress«. Za
zmanjševanje števila nepotrebno poslanih DNS poizvedb se uporablja tudi predpomnilnik
(cache). Če je odgovor na DNS poizvedbo negativen, se določen čas (TTL) enake
poizvedbe (za isto domeno) dejansko ne izvršujejo, ampak se odgovor vrne iz
predpomnilnika. S tem preprečimo nepotrebno večkratno zaporedno poizvedovanje za
domeno, za katero je odgovor negativen oziroma zanjo ni podatkov. Naloge na nižjem
nivoju omogočajo neposredne manipulacije DNS sporočil in zapisov, ter dovoljujejo
nastavljanje dodatnih nastavitev. Vmesnik vsebuje preprosto orodje za izvajanje DNS
poizvedb, orodje podobno standardnemu »dig« orodju, dinamični odjemalec za
posodabljanje in preprost le avtoritativni (authoritative-only) strežnik:
• dig: klon orodja »dig«, ki je del domenskega strežnika BIND,
• update: dinamični odjemalec za posodabljanje z dodatnimi funkcionalnostmi,
• jnamed: preprost le avtoritativni strežnik (brez predpomnilnika, nerekurziven),
uporaba nepriporočljiva za produkcijska okolja in testiranje,
• lookup: preprost program, ki poišče zapise, povezane z imeni, če tip ni določen, se
opravi poizvedba po naslovu.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 32
Vmesnik »dnsjava2.0.8« je dostopen pod licenco BSD (Berkeley Software
Distribution) na spletni strani http://www.xbill.org/dnsjava/. BSD licenca je zelo preprosta,
saj dovoljuje uporabo programske opreme, distribucijo izdelka in izvorne kode. Dovoljeno
je spreminjanje in vključevanje v drugo programsko opremo brez omejitev. Edina zahteva
je, da se navede imena vseh avtorjev v izvorni kodi in dokumentaciji programa. Imen
avtorjev ni dovoljeno uporabljati za promocijo izdelka brez predhodnega pisnega
dovoljenja.
2.9 Podatkovna baza Oracle 10g
Podatkovna baza Oracle je najpomembnejši produkt podjetja Oracle Corporation. Ta
sistem za upravljanje z relacijskimi bazami podatkov je doživel že nekaj poimenovanj,
uporabniki pa ga pogosto kar poimenujejo Oracle. Podjetje Oracle Corporation izdeluje
tudi orodja za razvoj podatkovnih skladišč in srednje nivojske sisteme programske opreme,
programsko opremo za upravljanje virov ERP (Enterprise Resource Planning), programsko
opremo za upravljanje odnosov s strankami CRM (Customer Relationship Management) in
programske opreme za upravljanje oskrbovalne verige SCM (Supply Chain Management).
Larry Ellison je s prijateljema in takratnima sodelavcema Bobom Minerjem in Edom
Oatesom leta 1977 začel s podjetjem SDL (Software Development Laboratories). SDL je
razvilo prvo verzijo programske opreme Oracle in leta 1979 je podatkovna baza izšla pod
imenom Oracle V2. Od takrat je nastalo 10 glavnih verzij in nekaj vmesnih z dodatki in
popravki. Ime Oracle izvira iz imena projekta CIE, na katerem je Ellison delal pred tem
[18].
Veliko število podatkov in transakcij med njimi, hitrost operacij in potreba po čim večji
zanesljivosti in odzivnosti so le nekateri faktorji, ki dajejo prednost Oracle bazi pred
množico konkurenčnih produktov, kot so npr. zaprtokodni IBM DB2, Microsoft SQL
Server in odprtokodni PostgresSQL, Firebird in MySQL. Oracle podatkovna baza
omogoča napredno varnost (angl. advanced security), podatkovni sef (angl. database
valut), podatkovno rudarjenje (angl. data mining), varnostno oznako (angl. label security),
paketni management (angl. management packs), podatkovno skladišče – Oracle OLAP,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 33
izgradnjo podatkovnega skladišča (angl. Oracle warehouse builder) in testiranje aplikacij
(angl. Oracle real application testing). Delo s podatkovno bazo oracle je kar precej
zahtevno, vendar prednosti odtehtajo slabosti. V Oracle podatkovni bazi je možno nadzirati
vse od izvajanja poizvedb, do analize obnašanja podatkovne baze, kar na nivoju aplikacije
bistveno izboljša odzivnost podatkovne baze. Za vnašanje in pridobivanje podatkov se
uporablja SQL (Structured Query Language) jezik za delo s podatkovnimi bazami.
Zelo znana okrnjena brezplačna različica podatkovne baze Oracle Database 10g XE
(Express Edition), s katero je Oracle leta 2006 želel razširiti krog uporabnikov. Temelji na
Oracle Database 10g Release 2 kodni osnovi, ki je brezplačna za razvoj, uvajanje in
distribucijo, hitro snemljiva iz Interneta in lahka za administracijo ter vzdrževanje. Je
primerna za razvijalce odprtokodnih aplikacij v različnih programskih jezikih, kot so Java,
PHP, .NET in podobnih. Oracle je brezplačno različico omejil na tak način, da lahko
uporabniki v podatkovnem skladišču hranijo največ 4 GB podatkov, deluje le na enem
procesorju in podpira največ 1 GB pomnilnika na strežniku, sicer pa vsebuje skoraj vse
ostale lastnosti njihovih večjih izdelkov.
Oracle podatkovna baza ni le podatkovna zbirka, nabor tabel s podatki, ampak vsebuje
tudi celo vrsto drugih objektov in orodij, ki nam omogočajo delo z njimi. V podatkovni
bazi lahko izvajamo programe, napisane v proceduralnem jezilu PL/SQL (Procedural
Language/SQL). Te lahko shranimo v obliki funkcij, procedur, paketov (angl. packages)
ali prožilcev (angl. triggers). Kot vsak programski jezik, tudi PL/SQL razpolaga z vrsto
namenskih knjižnic, ki njegovo uporabo razširijo na različna tehnoliška področja. Tako
lahko v programih uporabljamo HTTP (HyperText Transfer Protocol) transportni protokol,
pišemo in beremo iz datotek na operacijskem sistemu, generiramo in nalagamo XML
datoteke in podobno. Zaradi močne podpore XML standardu velikokrat Oracle podatkovno
bazo imenujemo tudi XML DB. V podatkovno bazo lahko naložimo celo Java izvajalno
programsko kodo. Znotraj procesa podatkovne baze teče tudi JVM proces, ki je sposoben
to kodo tudi izvajati. Dostop do Java razredov je mogoč preko Java shranjenih procedur
(Java Stored Procedures), ki so dejansko PL/SQL ovojnice nad Java objekti. Tako lahko
objekte uporabljamo v PL/SQL kodi in jih integriramo s podatkovno bazo.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 34
PL/SQL proceduralni jezik
Značilnosti naravnega jezika so neformalnost ali šibka formalizacija. Stavki v
naravnem jeziku so velikokrat dvoumni. Zato ni primeren za delo z računalnikom ali
podatkovno bazo. Ukaze v naravnem jeziku posnema jezik SQL. SQL je najbolj razširjen
in standardiziran povpraševalni računalniški jezik, ki omogoča kreiranje, spreminjanje,
branje in manipulacijo s podatki, shranjenimi v relacijski podatkovni bazi. Širitev jezika
gre v smeri podpore objektno relacijskim podatkovnim bazam. Jezik SQL je standardiziran
(ANSI - American National Standards Institute/ISO - International Organization for
Standardization), vendar je upoštevanje standardov s strani nekaterih proizvajalcev
sistemov za upravljanje s podatkovno bazo (SUPB) vprašljivo.
SQL je programski jezik, ki v svoji osnovni različici nima nekaterih klasičnih
programskih konstruktov (vejitev, zank), je bolj deklarativne narave in je namenjen
manipulaciji s podatki. V SQL-u povemo le kaj želimo, ne pa tudi kako naj se to izvede.
Obstajajo tudi izvedenke SQL-a, denimo proceduralni jezik PL/SQL, ki zadošča vsem
kriterijem programskega jezika in ima spremenljivke, krmilne stavke, zanke, izjeme in
podobno. Polja so prav tako podprta, čeprav na nekoliko nenavaden način, ki vključuje
uporabo PL/SQL zbirk (angl. collections). PL/SQL zbirke so nekoliko zapleteno poglavje.
Sintaksa tega proceduralnega jezika je podobna sintaksi programskega jezika Ada.
PL/SQL je torej Oraclova proceduralna razširitev jezika SQL za Oracle-ovo relacijsko
podatkovno bazo [20][21].
Oraclove shranjene funkcije in procedure se lahko združujejo v pakete. Takšen način
programiranja izboljšuje preglednost in učinkovitost. Za delo s PL/SQL je Oracle razvil
grafični programski paket Oracle SQL Developer, ki je posebno prilagojen za Oracle-ovo
podatkovno bazo in ne deluje z nobeno drugo relacijsko podatkovno bazo.
Oracle SQL Developer
Oracle SQL Developer je brezplačno in v celoti podprto integrirano razvojno grafično
okolje korporacije Oracle, ki poveča produktivnost in poenostavlja naloge za razvoj baze
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 35
podatkov [19]. Uporaba SQL Developer orodja razvijalcem omogoča pregled, urejanje in
ustvarjanje objektov (tabel, prožilcev, sekvenc) v podatkovnem skladišču, izvajanje SQL
stavkov, urejanje in razhroščevanje PL/SQL stavkov, kreiranje in izvajanje SQL poročil in
vodenje različic datotek.
Orodje je razvito v programskem jeziku Java in za delovanje potrebuje programsko
okolje JDK (Java Development Kit) vključno z javanskim izvajalnim okoljem JRE (Java
Runtime Enviroment), ki sta že vključena v instalacijski datoteki. Tako lahko teče na
operacijskih sistemih Windows, Linux in Mac OS X in to je velika prednost, ki spodbuja k
rasti števila razvijalcev, ki uporabljajo različne platforme hkrati. Uporaba različnih
platform pomeni tudi, da lahko razvijalci namestijo SQL Developer na istem sistemu kot je
zbirka podatkov in se oddaljeno povežejo s svojih namiznih računalnikov, s čimer se
izognejo odjemalec-strežnik omrežnemu prometu.
Privzet način povezave na podatkovna skladišča Oracle 9.2.0.1 in kasnejše izdaje
vključno z ekspresnimi izdajami (XE) je preko tankega JDBC (Java DataBase
Connectivity) gonilnika. Povezave so možne tudi na druga podatkovna skladišča kot so
IBM DB2 LUW, MySQL, Microsoft SQL Server, Microsoft Access, Sybase Adaptive
Server in Teradata za brskanje po objektih, podatkih in migracije.
Prožilec, shranjena procedura in shranjena funkcija
Prožilec (angl. trigger) predstavlja poseben primer PL/SQL programske kode oziroma
shranjene procedure, ki se samodejno izvede ob določenem dogodku na določeni tabeli ali
pogledu v podatkovni bazi. Splošna shranjena procedura ali funkcija se lahko pokliče iz
ukazne vrstice ali iz katere druge procedure ali funkcije, medtem ko se prožilec sproži
samodejno ob določenem dogodku. Dogodki oziroma operacije, ki lahko povzročijo
proženje so:
• DML (Data Manipulation Language) stavki (INSERT, UPDATE, DELETE) na
določeni tabeli ali pogledu na izbiro kateregakoli uporabnika (slika 2.11).
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 36
• DDL (Data Definition Language) stavki (CREATE, ALTER, DROP) na izbiro
določene sheme/uporabnika ali na izbiro katerekoli sheme/uporabnika v podatkovni
bazi.
• Prijava/odjava uporabnika, zagon/zaustavitev sistema, določene napake, prav tako
na izbiro določene sheme/uporabnika ali na izbiro katerekoli sheme/uporabnika v
podatkovni bazi.
Slika 2.11: Primer proženja prožilcev pri izvajanju DML stavkov nad tabelo
Prožilci, shranjeni v podatkovni bazi lahko vključujejo SQL in PL/SQL ali Java stavke,
da tečejo kot enota in lahko kličejo shranjene procedure ali funkcije. Vendar pa se
procedure in prožilci razlikujejo po načinu, kako jih pokličemo. Procedura je program, ki
predstavlja eno ali več akcij in jo imenujemo tudi izvršljiv programski stavek. Procedura
ima lahko vhodne in izhodne informacije, ki jih podajamo preko liste parametrov.
Program, podoben proceduri, ki vrača eno vrednost in se uporablja kot izraz, imenujemo
funkcija. Za razliko od klica procedure, ki je samostojno izvršljiv stavek, lahko klic
funkcije obstaja le kot del izvršljivega stavka, kot element v izrazu ali privzeta vrednost v
deklaraciji spremenljivke. Procedura se lahko požene izrecno na zahtevo uporabnika,
aplikacije ali prožilca. Prožilci so izvedeni s strani podatkovne baze na prožilne dogodke,
ne glede na to kateri uporabnik je povezan ali katera aplikacija je bila uporabljena. Prožilec
se večinoma uporablja za ohranjanje celovitosti informacij v podatkovni bazi [20][22].
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 37
Sekvenca
Sekvenca (angl. sequence) ali zaporedje je objekt v podatkovni bazi, ustvarjen s strani
uporabnika, ki si ga lahko deli več uporabnikov. Sekvenca samodejno generira unikatna
cela števila za vsako vrstico tabele. Tipično se uporablja za generiranje vrednosti
primarnega ključa pri tabelah in tako nadomešča programsko kodo, vrednost pa mora biti
unikatna za vsako vrstico tabele. Sekvenca nastaja tako, da se vrednost povečuje ali
zmanšuje (običajno za 1) z interno Oracle-ovo rutino. Sekvenca je lahko objekt, ki ni
potraten s časom, saj zmanjšamo količino programske kode aplikacije, ki je potrebna, da
rutino generiranja unikatnih vrednosti implementiramo programsko v aplikaciji. Zaporedja
številk so shranjena in nastajajo neodvisno od tabel, zato lahko določeno zaporedje
uporabimo za več tabel [20]. Podatki, ki jih sekvenca nosi so (slika 2.12):
• Ime sekvence,
• ali zaporedje narašča ali pada,
• interval med vrednostmi in
• ali naj so polja generiranih sekvenc shranjena v pomnilniku.
Slika 2.12: Primer urejanja sekvence z orodjem Oracle SQL Developer
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 38
Indeksiranje tabel
Indeks (angl. index) predstavlja opcijsko strukturo oziroma konceptualni del tabele, ki
omogoča hiter dostop do podatkov in je iz logičnega ter fizičnega vidika neodvisen od
podatkov tabele. Če se indeks optimalno oblikuje in uporabi, lahko v veliki meri pripomore
k hitrejhšemu dostopu do podatkov tabele in hitrejšemu povezovanju tabel. Indeks lahko
sestavimo iz enega ali več polj oziroma atributov tabele, da pohitrimo izvajanje SQL
stavkov nad tabelo. Nad tabelo imamo lahko več indeksov, ki so sestavljeni iz različnih
kombinacijah posameznih polj tabel in tako ustrezajo več različnim SQL stavkom. Število
indeksov je potrebno ohranjati na nizki stopnji, pred kreiranjem indeksa pa se moramo
prepričati, ali bo indeks sploh učinkovit. Pred kreiranjem indeksa je potrebno poznati
selektivnost atributa ali skupine atributov, saj je to pogosto merilo za učinkovitost indeksa.
Atributi in indeksi so selektivni takrat, ko vsebujejo veliko število unikatnih vrednosti. To
pomeni, da nimajo ponavljajočih se vrednosti oziroma je le-teh malo. Selektivni indeksi so
bolj učinkoviti kot ne-selektivni, saj bolj natančno določajo lokacijo posamezne vrednosti
ali skupine [21].
Podatkovna datoteka je datoteka s podatki in jo imenujemo tudi osnovna datoteka.
Indeksna datoteka je datoteka z indeksi. Indeks je sestavljen iz iskalnega ključa in kazalca
na zapis v podatkovni datoteki. Vrednosti polj, po katerih je datoteka indeksirana, pa
sestavljajo iskalni ključ. Na sliki 2.13 lahko vidimo primer osnovnih komponent pri
indeksiranju:
Slika 2.13: Podatkovna in indeksna datoteka ter iskalni ključ
Indekse lahko ločimo tudi na primarne in sekundarne indekse. Primarni indeksi so
indeksi po poljih, ki vsebujejo primarni ključ. Vsak iskalni ključ kaže natanko na en zapis
v podatkovni datoteki. Datoteka je urejena po ključu. Sekundarni indeksi pa so ostali
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 39
indeksi, ki ne temeljijo na poljih, ki vsebujejo primarni ključ. Vsaka datoteka lahko ima
primarni indeks ali indeks gruče ter več sekundarnih indeksov. Dobro poznani in veliko
uporabljeni so tudi indeksi s sestavljenim iskalnim ključem (angl. composite index, včasih
tudi poimenovan concatenated index). To so indeksi, ki so ustvarjeni na več poljih
določene tabele in jih uporabimo za kombinacije polj, po katerih pogosto iščemo.
Prisotnost indeksa v aplikaciji je transparentna, kar pomeni, da aplikacija ne potrebuje
nobenih dodatnih nastavitev ali kodiranja. SUBP v primeru obstoja indeksa pri dodajanju,
brisanju in spreminjanju vrstic tabele sam poskrbi za vzdrževanje indeksa. Pri Oracle-u je
privzeta in najbolj uporabljena struktura indeksa uravnovešeno drevo B-tree (balanced tree
index). Oracle ponuja več struktur indeksiranja, ki zagotavljajo dodatno funkcionalnost
delovanja:
• B-tree indeksi,
• B-tree indeksi gruče,
• razpršeni (hash) indeksi,
• bitni indeksi,
• bitni stični indeksi.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 40
3 IMPLEMENTACIJA UPORABNIŠKEGA ENUM SISTEMA IN
UNIVERZALNEGA MOBILNEGA ODJEMALCA
V tem poglavju se bomo osredotočili na implementacijo celotnega sistema
Uporabniškega ENUM-a, vključno z univerzalnim mobilnim odjemalcem. Naša cilj je bil
izdelati celovit sistem, katerega primarna naloga je, da omogoča uporabnikom preko
odjemalcev pridobiti podatke o komunikacijskih kanalih, na katerih so drugi uporabniki
dosegljivi. Vzpostavitev komunikacije po pridobljenih komunikacijskih poteh z
odjemalcem pa je sekundarna naloga.
Razvoj sistema bomo najprej razdelili na posamezne sklope in nato razvoj vsakega
sklopa natančneje razdelali. Pri razvoju smo uporabili določene že obstoječe segmente in
jih priredili načrtovanim funkcionalnostim, določeni segmenti pa so razviti na novo glede
na predvidene funkcionalnosti sistema. Pri razvoju smo uporabili napredna programska
orodja, ki omogočajo izredno hiter razvoj poslovnih rešitev.
Danes je programski jezik Java prodrl v številne pore računalništva, od mobilnih
naprav pa vse do najzmogljivejših strežnikov, ki krmilijo ključne poslovne procese. Zato
smo za implementacijo večjega dela segmentov uporabili javansko platformo, ki temelji na
programskem jeziku Java. Prav tako je razvijalcem, ki se odločijo za uporabo Jave na voljo
veliko naprednih razvojnih orodij npr. NetBeans, Eclipse, Borland JBuilder, Oracle
JDeveloper, JCreator in veliko obstoječih odprtokodnih rešitev. Nekateri obstoječi
segmenti (BIND), ki smo jih uporabili in priredili načrtovanim funkcionalnostim, so
napisani v standardiziranem nizkonivojskem programskem jeziku C.
3.1 Delitev sistema po sklopih
Celoten sistem lahko v osnovi razdelimo na dva dela. Delitev je ponazorjena na sliki
3.1.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 41
Slika 3.1: Uporabniški ENUM vključno z odjemalci
Na eni strani imamo različne odjemalce, ki so lahko bodisi namizne aplikacije za
osebne računalnike, aplikacije za mobilne telefone različnih platform ali preprosti
usmerjevalni sistemi, ki imajo podprto DNS poizvedovanje. Poizvedovanje s strani
odjemalca lahko na našem sistemu izvedemo na dva načina in sicer kot DNS poizvedbo
oziroma DIG ali preko HTTP poizvedbe.
Strežniški del na drugi strani zagotavlja dostopnost informacij o drugih uporabnikih na
zahtevo, hranjenje in ažuriranje le-teh. Pridobivanje informacij deluje po principu zahteva
– odgovor (angl. Request - Response). Za poizvedovanje z DNS poizvedbo uporabljamo na
strežniški strani BIND domenski strežnik. Domenski strežnik na podlagi poizvedbe iz
podatkovne baze preko PL/SQL shranjene strežniške procedure pridobi podatke in jih vrne
uporabniku v obliki NAPTR zapisov. V okviru spletne aplikacije za ažuriranje podatkov v
podatkovni bazi smo implementirali tudi javanski strežniški programček ali servlet. Servlet
je vmesnik za aplikacije - odjemalce, kjer DNS poizvedbe ni mogoče implementirati, saj
ima platforma, na kateri se izvajajo, tehnične omejitve (primer: aplikacije v okolju J2ME).
Servlet poskrbi, da se na podlagi HTTP zahteve DNS poizvedba izvede na strežniški strani,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 42
kjer ni tehničnih omejitev, rezultat poizvedbe pa se iz NAPTR zapisov zapakira v XML
obliko in se posreduje odjemalcu v HTTP odgovoru. Strukturo sporočila, v katerega
zapakiramo vsebino NAPTR zapisov, smo definirali sami.
Spletna aplikacija, ki preko Hibernate ali Java Persistence API različice objektno
relacijske preslikave dostopa do podatkovne baze Uporabniškega ENUM sistema,
omogoča uporabnikom avtorizacijo, ažuriranje svojih podatkov in ažuriranje
komunikacijskih kanalov (dodajanje, brisanje in urejanje), ki so vezani na uporabnikovo
nosilno telefonsko številko. Administratorju sistema spletna aplikacija omogoča
upravljanje z uporabniki (brisanje uporabnikov iz sistema, začasen izklop uporabnikov in
ponoven vklop), urejanje registracijskih zahtevkov novih uporabnikov in kreiranje novih
uporabniških računov in gesel oziroma identifikacijskih številk za preverjanje uporabnikov
preko klicnega odzivnika.
3.2 Vzpostavitev razvojnega okolja za sistem Uporabniški ENUM
Strežnik in operacijski sistem
Razvojno okolje sistema smo postavili na strežniku Hewlett-Packard HP ProLiant
DL380 G5. Uporabili smo operacijski sistem Linux Centos (Linux različica 2.6.18-
53.el5xen, gcc različica 4.1.2 20070626 (Red Hat 4.1.2-14)).
Oracle Database 10g Express Edition
Na strežnik smo namestili podatkovno bazo Oracle Database 10g Express Edition
(Oracle Database XE). Z Oracle-ove spletne strani http://www.oracle.com smo sneli
ustrezno verzijo podatkovne baze Oracle Database XE ter ustrezne verzije Oracle Instant
Client Basic Lite, Oracle Instant Client SDK in Oracle Instant Client Sql Plus:
• Oracle Database XE 10.2g, samodejna namestitev preko RPM (Red Hat Package
Manager) paketov, oracle-xe-10.2.0.1-1.0.i386.rpm in oracle-xe-client-10.2.0.1-
1.0.i386.rpm,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 43
• Oracle Instant Client Basic Lite 10.2, ročna namestitev arhiva instantclient-
basiclite-linux32-10.2.0.3-20061115.zip,
• Oracle Instant Client SDK 10.2, ročna namestitev arhiva instantclient-sdk-
linux32-10.2.0.3-20061115.zip,
• Oracle Instant Client Sql Plus 10.2, ročna namestitev arhiva instantclient-sqlplus-
linux32-10.2.0.3-20061115.zip.
Vse tri Oracle Instant Client arhive smo razširili v skupen imenik
/usr/local/instantclient_10_2. V tem imeniku smo naredili dve bližnjici (angl. link) in sicer
z ukazoma:
ln -s libclntsh.so.10.1 libclntsh.so
ln -s libocci.so.10.1 libocci.so
Nato smo pot /usr/local/instantclient_10_2 do tega imenika dodali v konfiguracijsko
datoteko »/etc/ld.so.conf« in osvežili nastavitve poti z ukazom:
ldconfig
Java Development Kit
S spletne strani http://java.sun.com smo sneli JDK paket za operacijski sistem Linux.
Ta paket vsebuje tudi JRE, ki je potreben za izvajanje Java aplikacij. Paket jdk-1_5_0_19-
linux-i586.bin smo shranili v lokalni imenik /usr/local/. Najprej smo s spodnjim ukazom
paketu spremenili pravice in paketu dovolili izvajanje:
chmod 777 jdk-1_5_0_19-linux-i586.bin
Nato smo paket razširili v imenik /usr/local/jdk1.5.0_19. Na ta imenik smo naredili
bližnjico »java« v imeniku /usr/local z ukazom:
ln -s /usr/local/jdk1.5.0_19/ java
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 44
V imeniku /etc/profile.d smo pripravili datoteko oziroma skripto »java.sh«, v kateri
smo nastavili sistemsko spremenljivko JAVA_HOME tako, da kaže na zgoraj ustvarjeno
bližnjico. To smo storili tako, da smo v datoteko »java.sh« zapisali naslednjo vsebino:
export JAVA_HOME=/usr/local/java
export PATH=$JAVA_HOME/bin:$PATH
Ob vsakem zagonu operacijskega sistema ali ponovni prijavi se samodejno poženejo
vse skripte v /etc/profile.d, torej tudi skripta »java.sh« in tako se sistemska spremenljivka
JAVA_HOME samodejno nastavi na pot do izvornega imenika JDK. Na zelo enostaven
način lahko po potrebi sistemsko JRE, ki je že v JDK, zamenjamo s preusmeritvijo
bližnjice »java« na drug izvorni imenik druge različice JDK. Da ročno sprožimo zagon
skript v /etc/profile.d, lahko poženemo ukaz su (angl. switch user) v ukazni vrstici
operacijskega sistema in tako nastavimo pot do izvornega imenika JDK, kot je definirano v
skripti »java.sh«.
Aplikacijski strežnik JBoss 5.1.0.GA
JBoss aplikacijski strežnik, v nadaljevanju JBoss AS je najbolj pogosto uporabljen
javanski aplikacijski strežnik na trgu. Je odprtokodni projekt, ki je dostopen na spletnem
naslovu http://www.jboss.org/. Sneli smo arhiv takrat zadnje produkcijske različice
aplikacijskega strežnika jboss-5.1.0.GA.zip. Arhiv smo razširili v imenik /usr/local/jboss-
5.1.0.GA.
Enako kot smo nastavili sistemsko spremenljivko za sistemsko Javo, smo to storili tudi
za aplikacijski strežnik. V imeniku /etc/profile.d smo pripravili datoteko oziroma skripto
»jboss.sh«, v kateri smo nastavili sistemsko spremenljivko JBOSS_HOME tako, da kaže
na izvorni imenik aplikacijskega strežnika, torej /usr/local/jboss-5.1.0.GA. To smo storili
tako, da smo v datoteko »jboss.sh« zapisali naslednjo vsebino:
export JBOSS_HOME=/usr/local/jboss-5.1.0.GA
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 45
Skripti za zagon strežnika »run.sh« ali zaustavitev »shutdown.sh« se nahajata v
podimeniku /usr/local/jboss-5.1.0.GA/bin. Da lahko strežnik zaženemo in zaustavimo, smo
jima morali nastaviti pravice izvajanja:
cd /usr/local/jboss-5.1.0.GA/bin
chmod 755 run.sh
chmod 755 shutdown.sh
Zagon in zaustavitev strežnika iz ukazne vrstice naredimo z ukazoma:
./run.sh -c domena -b 0.0.0.0 &
./shutdown.sh -S
možne domene: default, all, standard, minimal, web
S parametrom (-c) določimo domeno, v kateri bomo strežnik zagnali, medtem ko s
parametrom (-b) pa lahko specificiramo, na katerem IP naslovu bo strežnik dosegljiv
odjemalcem. (&) na koncu ukaza pomeni, da izvajanje procesa postavimo v ozadje.
Da zagotovimo aplikacijskemu strežniku samodejen zagon tudi po izpadih električnega
napajanja ali po ponovnem zagonu strojne opreme, lahko aplikacijski strežnik zaganjamo
in ugašamo kot storitev (angl. service), ki jo vnesemo v določene zagonske nivoje Linux
operacijskega sistema. Najprej ustvarimo skupino uporabnikov »jboss« (groupadd jboss).
Nato ustvarimo uporabnika »jboss« in ga dodamo v omenjeno skupino uporabnikov
(useradd –g jboss jboss, usermod –g jboss jboss). Dovoliti (rekurzivno) je potrebno še, da
lahko uporabnik »jboss« zaganja vse skripte v izvornem imeniku aplikacijskega strežnika
/usr/local/jboss-5.1.0.GA (chown –R jboss /usr/local/jboss-5.1.0.GA).
V podimeniku /usr/local/jboss-5.1.0.GA/bin so pripravljene tri storitvene skripte, ki so
prilagojene različicam Linux sistemom. V našem primeru smo uporabili skripto
»jboss_init_redhat.sh«, jo preimenovali v »jboss« in nastavili naslednje parametre:
# chkconfig: 345 90 10
# description: Runs the JBoss Application Server
# processname: jboss
JBOSS_HOME="/usr/local/jboss-5.1.0.GA"
ime procesa
izvorni imenik strežnika
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 46
JBOSS_USER="jboss"
JAVAPTH="/usr/local/java/bin"
JBOSS_IP="0.0.0.0"
JBOSS_BIND_ADDR="-b $JBOSS_IP"
uporabnik, ki ga lahko požene
pot do sistemske Jave
IP naslov aplikacijskega strežnika
Skripto »jboss« z ustrezno nastavljenimi parametri smo premaknili v imenik /etc/rc.d/init.d
in ji nastavili pravice za izvajanje (chmod 755 jboss).
Strežnik se sedaj lahko zažene in ustavi kot storitev, preverimo lahko tudi status
procesa:
service jboss start
service jboss stop
service jboss status
Storitev »jboss« zažene aplikacijski strežnik kot uporabnik »jboss«. Nato dodamo
storitev »jboss« še v zagonske nivoje (2, 3, 4 in 5) operacijskega sistema, da zagotovimo
samodejen zagon aplikacijskega strežnika:
[root@uenum ~]# chkconfig --level 2345 jboss on
[root@uenum~]# chkconfig --list | grep jboss
jboss 0:off 1:off 2:on 3:on 4:on 5:on 6:off
3.3 Podatkovna baza Uporabniškega ENUM sistema
Starejše različice domenskega strežnika BIND niso podpirale mehanizmov za
shranjevanje in iskanje podatkov o območjih oziroma conah v podatkovnih bazah, ampak
so bili podatki shranjeni v tekstovnih območnih datotekah (angl. zone files). Analizirali
smo strukturo tekstovnih območnih datotek in obstoječega gonilnika za podatkovno bazo
MySQL, po katerem smo jemali zgled za razvoj Oracle gonilnika. Na osnovi rezultatov
analize smo pripravili tabele, v katere lahko shranjujemo vse potrebne podatke za sestavo
NAPTR zapisov. V podatkovno bazo smo prestavili tudi osnovne zapise (SOA, NS in A)
iz tekstovne območne datoteke, ki nosijo dodatne informacije, kot so TTL, ki ponazarja
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 47
čas, koliko časa so podatki v bazi veljavni in podobne. Na sliki 3.2 je prikazan primer
takšne tekstovne datoteke.
Slika 3.2: Primer tekstovne datoteke z območji oziroma conami
Podatkovna baza vsebuje 10 tabel, 8 sekvenc, 8 prožilcev in 2 PL/SQL shranjeni
strežniški proceduri kot prikazuje slika 3.3. Sekvence in prožilce potrebujemo za
implementacijo samodejnega povečevanja primarnih ključev v tabelah ob dodajanju novih
vnosov. MySQL podatkovna baza za to poskrbi sama, pri Oracle podatkovni bazi pa je
potrebno to realizirati za vsako tabelo s primarnim ključem in sicer z eno sekvenco in enim
prožilcem za vsako tabelo.
Slika 3.3: Tabele, sekvence, prožilci in PL/SQL shranjene procedure
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 48
Sekvenc in prožilcev za tabeli DNS_INFO in DNS_TEMPORARY nismo potrebovali,
saj nimata primarnega ključa. Tabela DNS_TEMPORARY je začasna tabela, ki jo
uporablja shranjena strežniška procedura DNS_LOOKUP pri sestavljanju NAPTR zapisov.
Vsebina te tabele se po izvedbi procedure počisti. V tabeli DNS_INFO so shranjeni
osnovni trije zapisi (SOA - Start of authority, NS - Name server in A - Address), ki so
potrebni za delovanje domenskega strežnika BIND in jih domenski strežnik prebere s
shranjeno strežniško proceduro DNS_ALLNODES. Tabela PROPERTY je bila predvidena
za razne nastavitve, ki jih uporabljamo v spletni aplikaciji, a smo nastavitve prestavili v
nastavitveno datoteko projekta spletne aplikacije.
V tabelah USERS in USERROLES se nahajajo podatki o uporabniških računih, torej
nosilne telefonske številke oziroma uporabniška imena, kodirana gesla in uporabniške
vloge (angl. user roles) za spletno aplikacijo. Registracijski zahtevki uporabnikov se
hranijo v tabeli REGREQUEST. Vsak uporabnik mora najprej podati registracijski
zahtevek, na podlagi katerega lahko administrator sistema kreira nov uporabniški račun z
geslom, ki ga nato ob registraciji vpiše v tabelo USERS. V vsakem registracijskem
zahtevku je shranjen kontaktni elektronski poštni naslov in nosilna telefonska številka. To
zadostuje, da lahko administrator stopi v kontakt z uporabnikom in preveri njegovo
identiteto bodisi z SMS sporočilom, telefonskim klicem ali preko telefonskega odzivnika,
zato drugih podatkov o uporabniku ne bomo hranili. V tabeli REGREQUEST imamo še
dve zastavici, s katerima označimo, ali je uporabnik že registriran in ali si mora obvezno
spremeniti geslo. Sprememba gesla je lahko zahtevana v več primerih, ki jih bomo razložili
pri opisu spletne aplikacije.
Vsi podatki, ki opisujejo komunikacijske kanale, na katerih je uporabnik dosegljiv in so
vezani na nosilno telefonsko številko, so shranjeni v tabelah SERVICE, PARAMETER,
NAPTRRECORD in NAPTRDATA. V tabeli SERVICE imamo shranjene vse ENUM
storitve, za katere si uporabnik lahko doda nov zapis. Pri Uporabniškem UNUM-u
uporabljamo NAPTR zapise, zato imajo vse storitve enak tip zapisa, to je NAPTR. Vsaka
storitev v tej tabeli ima tudi določen TTL, tip storitve in podtip storitve. Vse storitve imajo
v tabeli PARAMETER vnaprej določene parametre, njihove vrednosti in pravila, kako naj
shranjena PL/SQL procedura DNS_LOOKUP sestavi NAPTR zapis skupaj s podatki,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 49
vnesenimi s strani uporabnika, ki so shranjeni v tabeli NAPTRDATA. Pravila določajo,
kateri podatki so obvezni, za katerimi mora obvezno vriniti presledek, kateri so uporabniku
vidni pri urejanju in za katere je dovoljeno, da jih lahko ažurira. V tabeli NAPTRRECORD
imamo shranjene vse unikatne identifikacijske ključe vseh NAPTR zapisov, ki so jih vnesli
uporabniki. Ko se v tabelo NAPTRDATA shranijo vsi parametri NAPTR zapisa, ki jih je
vnesel uporabnik preko spletne aplikacije, potrebujemo za vse parametre en unikaten
identifikacijski ključ, ki označuje, da ti parametri pripadajo določeni storitvi, uporabniku in
navsezadnje NAPTR zapisu. Da preprečimo podvajanje in napake, ki bi se lahko pojavile
ob hkratnem dodajanju NAPTR zapisov dveh različnih uporabnikov, zagotovimo unikaten
ključ vsakega novega NAPTR zapisa s predhodnim enojnim vnosom v tabelo
NAPTRRECORD. Vpišemo indeks uporabnika in indeks ENUM storitve. Tako dobimo s
sekvenco in prožilcem unikaten identifikacijski ključ, ki ga uporabimo pri vnosu
parametrov za ta NAPTR zapis v tabelo NAPTRDATA. Slika 3.4 prikazuje vse tabele in
njihove medsebojne relacije v podatkovni bazi.
Slika 3.4: Tabele z vsemi polji, tipi polj, indeksi in medsebojnimi relacijami
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 50
Nekatere tabele smo tudi indeksirali. To pomeni, da smo analizirali SQL poizvedovalne
stavke spletne aplikacije in poiskali najpogosteje uporabljene kombinacije parametrov
(najpogosteje so to ključi), ki se pojavljajo v pogojnih delih SQL stavkov. Nato smo na te
kombinacije postavili indekse, primarni ključi v tabelah pa so že v osnovi indeksirani. Pri
poizvedovanju po tabelah, ki vsebujejo veliko podatkov, lahko indeksiranje zelo pohitri
iskanje, saj v primeru uporabe pravilno nastavljenih indeksov ob poizvedovanju ne
izvajamo iskanja po vseh vrsticah tabele (FTS – Full Table Scan).
3.4 PL/SQL shranjene strežniške procedure
Domenski strežnik BIND se povezuje na podatkovno bazo Oracle preko gonilnika.
SQL poizvedovanj ne izvaja neposredno na podatkovno bazo, ampak vse podatke, ki jih
potrebuje, pridobi preko dveh shranjenih PL/SQL strežniških procedur DNS_ALLODES
in DNS_LOOKUP. Procedura DNS_ALLODES vrne domenskemu strežniku vse zapise iz
tabele DNS_INFO. Procedura nima vhodnih parametrov, kot izhodni parameter pa vrne
REF kazalec (REF cursor). REF kazalec je v bistvu podatkovni tip. Spremenljivka,
ustvarjena na podlagi takšnega podatkovnega tipa, je v splošnem imenovana spremen-
ljivka kazalca. S takšno spremenljivko imamo hitro referenco na dejanski kazalec na
podatke, ki jih ima v RAM-u shranjene procedura (najpogosteje so to interna PL/SQL
polja, ki jih v proceduri dobimo z poizvedovalnimi stavki iz tabel). Primer shranjene
PL/SQL strežniške procedure:
CREATE OR REPLACE
PROCEDURE DNS_ALLNODES (refcursor OUT SYS_REFCURSOR) AS
BEGIN
OPEN refcursor FOR
SELECT TTL, NAME, RDTYPE, RDATA FROM DNS_INFO;
END DNS_ALLNODES;
Vsa poslovna logika iskanja podatkov za določeno telefonsko številko in sestavljanje
NAPTR zapisov je v shranjeni PL/SQL strežniški proceduri DNS_LOOKUP. Vhodni
podatek procedure je celotno ENUM ime domene, rezultat pa REF kazalec na polja s
podatki, ki jih dobimo z SQL poizvedbo na tabelo DNS_TEMPORARY, v kateri je
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 51
procedura predhodno pripravila podatke o NAPTR zapisih. Primer rezultata procedure, če
jo pokličemo s testnim ENUM imenom domene » 7.6.5.4.3.2.1.5.6.8.3.e164.arpa «:
VARIABLE rs REFCURSOR;
BEGIN
"DNS_LOOKUP"('7.6.5.4.3.2.1.5.6.8.3.e164.arpa', :rs);
END;
/
print rs;
Tabela 3.1: Rezultat shranjene strežniške procedure DNS_LOOKUP
TTL RDTYPE RDATA
5
5
5
5
5
5
5
5
NAPTR
NAPTR
NAPTR
NAPTR
NAPTR
NAPTR
NAPTR
NAPTR
100 60 "u" "E2U+web:http" "!^.*$!http://www.enum.si!" .
100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
100 80 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
100 30 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
100 80 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
100 40 "u" "E2U+sms:tel" "!^.*$!tel:38651234567!" .
100 20 "u" "E2U+pstn:tel" "!^.*$!tel:38651234567!" .
100 50 "u" "E2U+mms:tel" "!^.*$!tel:38651234567!" .
Procedura najprej v ENUM imenu domene preveri dolžino telefonske številke vključno
z območno kodo in kodo države. Telefonska številka se nahaja na levi strani ENUM imena
domene pred drugo-nivojsko domeno e164.arpa, ki se uporablja izključno za pretvorbo
telefonskih številk v ENUM domene (primer: 7.6.5.4.3.2.1.5.6.8.3.e164.arpa). Nato izreže
telefonsko številko, odstrani ločilne pike in zamenja vrstni red številk, da dobimo
telefonsko številko vključno z obema predponama (38651234567). Izhodna koda države
(00 ali +) se v ENUM sistemu pri številkah ne uporablja. Ko je določena telefonska
številka, poznamo tudi morebitno uporabniško ime za to številko, saj so uporabniška imena
računov enaka nosilnim telefonskim številkam brez izhodne kode države.
Na podlagi telefonske številke oziroma uporabniškega imena procedura iz tabele
USERS prebere identifikacijski ključ uporabnika, s katerim poišče podatke za NAPTR
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 52
zapise tega uporabnika. Iz tabele NAPTRDATA prebere vse podatke za NAPTR zapise,
vnešene s strani uporabnika, hkrati pa v tabeli NAPTRRECORD preveri, kateri od NAPTR
zapisov so veljavni oziroma za katere uporabnik želi, da so vidni. Da lahko sestavi NAPTR
zapise, potrebuje še dodatne podatke za vsako ENUM storitev iz tabele SERVICE in vse
vnaprej definirane parametre za vsako ENUM storitev iz tabele PARAMETER.
Vsi podatki se sestavijo v NAPTR zapise po pravilih, ki so definirana ob vsakem
parametru v tabeli PARAMETER. Pravila so podana z atributi oziroma zastavicami
parameter_valueRequired, parameter_valueSpace, parameter_dataRequired,
parameter_dataSpace. Sestavljeni NAPTR zapisi se zapišejo v začasno tabelo
DNS_TEMPORARY. Izhodni parameter procedure DNS_LOOKUP je REF kazalec na
podatke v začasni tabeli.
3.5 Domenski strežnik BIND
S spletne strani smo sneli izvorno kodo za domenski strežnik BIND bind-9.4.2.tar.gz
in jo razširili v imenik /root/bind/bind-9.4.2 . V programskem jeziku C smo po zgledu
gonilnika za podatkovno bazo MySQL razvili gonilnik za podatkovno bazo Oracle
oracledb.zip, preko katerega bo domenski strežnik povezal in dostopal do PL/SQL
shranjene strežniške procedure na Oracle-u. Izvorno datoteko gonilnika »oracledb.c« in
knjižnico »oracledb.h« smo prenesli v izvorni imenik domenskega strežnika:
tar xzvf bind-9.4.2.tar.gz
unzip oracledb.zip
mv oracledb.c /root/bind/bind-9.4.2/bin/named
mv oracledb.h /root/bind/bin/named/include/named
cd bind-9.4.2
razširitev arhiva BIND strežnika
razširitev gonilnika za Oracle
prestavitev datoteke
prestavitev datoteke
postavimo se v izvorni imenik
Da zna domenski strežnik BIND uporabiti ta gonilnik, je bilo potrebno dopolniti
datoteko »/root/bind/bind-9.4.2/bin/named/Makefile.in« in tako vključiti gonilnik:
DBDRIVER_OBJS = oracledb.@O@
DBDRIVER_SRCS = oracledb.c
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 53
DBDRIVER_INCLUDES = -I/usr/local/instantclient_10_2/sdk/include
DBDRIVER_LIBS = -L/usr/local/instantclient_10_2 -locilib
V glavni izvorni datoteki domenskega strežnika BIND »/root/bind/bind-
9.4.2/bin/named/main.c« smo vključili še knjižnico gonilnika »oracledb.h« na
predvidenem mestu:
/* * Include header files for database drivers here. */ /* #include "xxdb.h" */ #include <named/oracledb.h>
Nato smo gonilnik registrirali v proceduri setup() tako, da smo dodali vrstico za klic
funkcije oracledb_init(), ki se nahaja pred klicem funkcije ns_server_create():
/* * Add calls to register sdb drivers here. */ /* xxdb_init(); */ oracledb_init();
Preklic registracije se izvede v proceduri cleanup() s klicem funkcije oracledb_clear(),
za funkcijo ns_server_destroy():
/* * Add calls to unregister sdb drivers here. */ /* xxdb_clear(); */ oracledb_clear();
Potrebno je bilo izvesti še postopek konfiguracije, prevajanja in namestitve BIND-a:
# ./configure # make # make install
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 54
Na koncu smo morali urediti datoteko z nastavitvami »/etc/named.conf« za storitev
»named«. V njej je bilo potrebno definirati, da bo domenski strežnik za izbrano domeno
»6.8.3.e164.arpa« iskal podatke v lokalni Oracle podatkovni bazi:
zone "6.8.3.e164.arpa" in { type master; notify no; database "oracledb 127.0.0.1:1521/xe enum enum99"; };
Primer datoteke »named.conf« je v oracledb.zip arhivu in smo jo po urejanju
premaknili v imenik /etc z ukazom:
mv named.conf /etc
Domenski strežnik BIND smo na takšen način priredili do te mere, da pri DNS
poizvedbah za domeno »6.8.3.e164.arpa« podatke o NAPTR zapisih poišče v Oracle
podatkovni bazi preko PL/SQL shranjene strežniške procedure.
Domenski strežnik poženemo iz imenika /usr/local/sbin z ukazom:
./named
3.6 Orodje za DNS poizvedovanje v programskem jeziku Java
Pri implementaciji DNS poizvedbe v naših odjemalcih (v okviru spletne aplikacije in v
Java servletih) smo uporabili zadnjo različico implementacije DNS v programskem jeziku
Java in sicer »dnsjava« (različica 2.0.8). S spletne strani http://www.dnsjava.org/ smo sneli
arhiv dnsjava-2.0.8.zip, v katerem je vsa izvorna koda vmesnika vključno z Javadoc
dokumentacijo. Sneli smo tudi JAR (Java ARchive) knjižnico dnsjava-2.0.8.jar, ki
vsebuje vse prevedene razrede vmesnika in jo dodali h knjižnicam projekta spletne
aplikacije Uporabniškega ENUM sistema in v projekt Android mobilne aplikacije -
odjemalca. Aplikacijski programski vmesnik »dnsjava« je odprtokoden projekt in je prosto
dostopen.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 55
Funkcionalnosti aplikacijskega programskega vmesnika so razdeljene v 4 pakete
razredov (org.xbill.DNS, org.xbill.DNS.security, org.xbill.DNS.spi, org.xbill.DNS.utils).
Pri implementaciji DNS poizvedbe na Uporabniški ENUM sistem smo uporabili nekaj
razredov iz paketa org.xbill.DNS:
• Lookup: Razred za izvedbo DNS poizvedbe. Vhodni podatki konstruktorja razreda
so ime domene, tip zapisov (ki jih pričakujemo od domenskega strežnika) in
nastavitev iz razreda DClass. Razred Lookup lahko uporabimo večkrat, vendar ne v
več programskih nitih hkrati.
• SimpleResolver: Implementacija preprostega razreševalnika (resolver), ki pošlje
eno poizvedbo na en strežnik. SimpleResolver ravna s TCP poskusi, varnostjo
transakcij (TSIG) in EDNS0.
• Record: Generični DNS zapis vira (vsebuje ime, tip, razred, ttl in rdata), specifični
tipi zapisov so razširjeni iz tega razreda.
• NAPTRRecord: Java razred za NAPTR zapis.
• Type: Razred s konstantami in funkcijami, povezanimi z DNS tipi.
• Cache: Razred predpomnilnika za DNS zapise. Predpomnilnik je vezan na
vrednost ttl, in zapise hrani, dokler ne poteče njihova validacijska perioda. Hranijo
se tudi negativni odgovori, da se prepreči nepotrebno ponavljanje spodletelih DNS
poizvedb.
• DClass: Razred s konstantami in funkcijami, povezanimi z DNS razredi.
ENUM DNS poizvedbo smo v naših odjemalcih implementirali v štirih korakih.
Najprej smo v prvem koraku instancirali razred Lookup in mu v konstruktorju nastavili
ime domene, tip zapisov (Type.NAPTR) in dodatni nastavitveni parameter iz razreda
DClass, ki določa poizvedovanje po Internetu (DClass.IN). V drugem koraku smo razredu
Lookup nastavili preprost razreševalnik. Da preprečimo privzeto uporabo predpomnilnika
za hranjenje negativnih odgovorov, v tretjem koraku razredu Lookup pred vsako
poizvedbo nastavimo prazen predpomnilnik. Za izvršitev poizvedbe je potreben klic
metode »run()« razreda Lookup. Primer implementacije DNS poizvedbe:
Lookup lkup = new Lookup('7.6.5.4.3.2.1.5.6.8.3.e164.arpa', Type.NAPTR, DClass.IN);
lkup.setResolver(new SimpleResolver('192.168.0.104')); //preprost razreševalnik
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 56
Cache cch = new Cache(DClass.IN); //Internet
cch.clearCache();
lkup.setCache(cch);
Record records[] = lkup.run();
Pri poizvedbi smo uporabili preprosti razreševalnik (angl. Simple Resolver), saj
potrebujemo eno poizvedbo na en domenski strežnik. Ko instanciramo razreševalnik, je
potrebno nastaviti v konstruktorju IP naslov ENUM domenskega strežnika, nato pa
instanciran razred razreševalnika nastavimo razredu Lookup z metodo »setResolver()«.
Lahko bi poizvedbo izvedli tudi z razširjenim razreševalnikom (angl. Extended Resolver),
ki omogoča pošiljanje več poizvedb na več domenskih strežnikov, vendar v našem primeru
ni bilo potrebno. Razredu Lookup nastavimo še prazen predpomnilnik, ki smo ga
instancirali tako, da smo v konstruktorju razreda Cache podali konstanto DClass.IN, ki
določa poizvedovanje po Internetu. S klicem metode »run()« razreda Lookup izvedemo
poizvedbo in rezultat poizvedbe (NAPTR zapise) zapišemo v polje »records«. Stanje
rezultata poizvedbe lahko preverimo z metodo »getResult()«, ki vrne kodo rezultata
poizvedbe. Kode rezultata poizvedbe so lahko med 0 in 4 in so definirane v razredu
Lookup.
Tabela 3.2: Definicija kod rezultata DNS poizvedbe
org.xbill.DNS.Lookup
Koda Ime konstante Opis
0 Lookup.SUCCESSFUL Poizvedba je bila uspešna.
1 Lookup.UNRECOVERABLE Poizvedba je spodletela zaradi napake na strežniku ali podatkih.
2 Lookup.TRY_AGAIN Poizvedba je spodletela zaradi napake omrežju.
3 Lookup.HOST_NOT_FOUND Gostitelj ne obstaja.
4 Lookup.TYPE_NOT_FOUND Gostitelj obstaja, ampak ni zapisov, ki bi ustrezali iskanemu tipu zapisov iz poizvedbe.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 57
Če smo v rezultatu poizvedbe dobili kodo Lookup.SUCCESSFUL (0) , smo pri branju
zapisov iz polja »records« v zanki vsak zapis pretvorili v tip NAPTRRecord. Tako smo
lahko iz vsakega NAPTR zapisa izluščili potrebne podatke z metodami razreda
NAPTRRecord in sicer »getService()«, »getRegexp()«, »getOrder()« in »getPreference()«.
Na voljo imamo še druge metode, ki jih lahko uporabimo za pridobitev drugih parametrov
NAPTR zapisa (Flags, Replacement, AdditionalName). V primeru negativnega rezultata
poizvedbe pa se ponovno poizvedovanje določi glede na kodo napake v rezultatu.
3.7 Servlet za DNS poizvedovanje iz J2ME aplikacij
S standardnimi J2ME omrežnimi programskimi vmesniki (angl. network API) DNS
poizvedovanje z orodjem »dnsjava« ni izvedljivo, zato smo poizvedbe s strani J2ME
odjemalca realizirali preko HTTP povezave, ki pa je podprta. Orodje »dnsjava« namreč
potrebuje nekaj dodatnih knjižnic in sicer razrede iz paketov java.io.* in java.net.*, J2ME
pa je zelo okrnjena različica in teh vmesnikov ne vključuje. Poizvedbo smo izvedli na
strežniški strani (Java EE), podatke o NAPTR zapisih pa do odjemalca prenesemo po
HTTP protokolu preko servleta. Z J2ME odjemalcem lahko naredimo HTTP poizvedbo
(request) in v HTTP odgovoru (angl. response) dobimo NAPTR zapise v XML obliki, ki
pa jo je zelo preprosto razčleniti v okolju J2ME in tako izluščiti podatke iz NAPTR
zapisov, ki jih potrebujemo za vzpostavitev komunikacije po različnih komunikacijskih
kanalih. Pravilo, po katerem NAPTR zapise zložimo v XML smo določili sami.
Poslovno logiko (angl. back-end business logic) za DNS poizvedovanje z orodjem
»dnsjava« smo implementirali v enterprise java zrnu EJB. Do metode »getNaptrRecords()«
zrna EnumDNSQueryBean (vmesnik EnumDNSQuery) je mogoče dostopati preko
lokalnega (ista JVM) ali oddaljenega vmesnika (druga JVM). V servletu (angl. front-end
interface) s klicem metode tega EJB zrna izvedemo DNS poizvedbo, zapakiramo rezultat v
XML obliko in pošljemo v HTTP odgovoru nazaj k odjemalcu. Primer, kako v URL naslov
servleta, na katerega naredimo HTTP poizvedbo, dodamo vhodni parameter (telefonsko
številko) za DNS poizvedbo:
http://10.10.50.52:8080/uenum/DoDNSQueryMobile?number=38651123456
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 58
Rezultat HTTP poizvedbe je XML sporočilo z NAPTR zapisi:
<?xml version="1.0" encoding="UTF-8"?>
<u-enum-response>
<u-enum-naptr>
<email order="100" preference="30">mailto:[email protected]</email>
<email order="100" preference="80">mailto:[email protected]</email>
<sms order="100" preference="40">tel:38651123456</sms>
<pstn order="100" preference="20">tel:38651123456</pstn>
<mms order="100" preference="50">tel:38651123456</mms>
<web order="100" preference="60">http://www.teletech.si</web>
<sip order="100" preference="10">sip:[email protected]</sip>
<sip order="100" preference="80">sip:[email protected]</sip>
</u-enum-naptr>
<u-enum-status>
<code>0</code>
<failure-description>OK.</failure-description>
</u-enum-status>
</u-enum-response>
V odgovoru imamo tudi element, ki nosi informacijo o statusu DNS poizvedbe na
strežniški strani.
Tabela 3.3: Kode napak v HTTP odgovoru
Koda Opis
S_OK=0
E_First_Digit_Zero = 101
E_Prefix_Error = 102
E_Invalid_Number_Length = 103
E_No_ENUM_Data = 104
E_Invalid_Digits = 105
E_Network_Error = 106
E_Server_Data_Error = 107
Vse OK!
Prvi znak telefonske številke ne sme biti 0!
Napačna predpona telefonske številke!
Napačna dolžina številke!
Ni podatkov za to telefonsko številko!
Neveljavni znaki v telefonski številki!
Napaka na omrežju!
Napaka v podatkih ali na strežniku!
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 59
E_No_Number_In_Request = 108
E_Unknown_Error = 999
Manjka številka v HTTP poizvedbi!
Neznana napaka!
3.7.1 NAPTR zapisi v XML obliki (pravilo)
V HTTP odgovoru servleta imamo element <u-enum-response>, ki nosi vse
informacije o poizvedbi. Sestavljen je iz dveh podelementov <u-enum-naptr> in <u-
enum-status>. V elementu <u-enum-naptr> so podani vsi NAPTR zapisi uspešne DNS
poizvedbe na strežniški strani. NAPTR zapisi se dodajo kot samostojni podelementi, ime
pa dobijo glede na ime storitve iz NAPTR zapisa. Kot dodatna parametra imajo podana še
vrstni red in prioriteto (order, preference). Element <u-enum-status> vsebuje statusne
informacije, torej kodo in opis morebitne napake pri DNS poizvedovanju.
3.8 UENUM - Enterprise aplikacija Uporabniškega ENUM sistema
Enterprise aplikacija Uporabniškega ENUM sistema je napisana v programskem jeziku
Java na platformi Java EE 5 in predstavlja vmesnik med uporabniki in podatkovno bazo
sistema. Aplikacijo smo razvili v razvojnem okolju Eclipse Java EE 3.5.1 in je nameščena
na aplikacijskem strežniku JBoss 5.1.0.GA. Vsi podatki se hranijo v podatkovni bazi
Oracle 10g Express Edition. Do podatkovne baze aplikacija dostopa preko ogrodja za delo
s trajnimi objekti (entitetami) – JPA (Java Persistence API), različice objektno relacijske
trajnosti ali perzistence in implementacije poizvedbenega servisa. JPA ima zmogljiv nabor
vmesnikov za razvoj objektno orientiranih trajnih razredov. Uporablja asociacije,
polimorfizem, dedovanje, kompozicije in zbirke (angl. collections) trajnih razredov. Je kot
del Enterprise Java Beans 3.x – EJB specifikacije in zamenjava za EJB 2 CMP (Container-
Managed Persistence) entitetna zrna. Eden glavnih konceptov JPA je upravljavec trajnosti
(angl. persistence manager), ki skrbi za t.i. kontekste trajnosti. Z njegovo pomočjo lahko
objekte umeščamo v trajen kontekst (torej zahtevamo njihovo brezpogojno trajnost), jih iz
njega začasno ali trajno umikamo, po njih poizvedujemo s pomočjo naprednega
poizvedovalnega jezika ipd. Nefunkcionalne zahteve, kot so upravljanje z dostopom do
podatkovne baze, varovanje dostopa, zagotavljanje transakcijskega obnašanja,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 60
predpomnjenje objektov in obnašanja ob kaskadnih dogodkih nam ponuja ponudnik trajosti
(provider – uporabili smo Hibernate kot JPA ponudnik).
Aplikacija je zapakirana v EAR (Enterprise ARchive) arhivsko datoteko (slika 3.5), ki
je standardna JAR arhivska datoteka s končnico *.ear. Uporaba EAR datotek in modulov
omogoča zbrati več različnih Java EE aplikacij, ki uporabljajo iste komponente, v celoto.
Dodatno kodiranje ni potrebno, sestavili in zapakirali smo le različne module v en EAR
arhiv.
Slika 3.5: Struktura arhiva »uenum.ear«
Arhiv »uenum.ear« je sestavljen iz modula spletne aplikacije »uenumadmin.war«, java
arhiva EJB strežniških zrn »uenumapp.jar« s poslovno logiko in xml konfiguracijskih
datotek, ki se nahajajo v različnih imenikih. Spletni modul in EJB modul sta v aplikacijo
vključena v datoteki »application.xml«. Nastavitve celotne aplikacije so zapisane v
datotekah »application.conf« in »global.jndi«. V datoteki »jboss-app.xml« sta v aplikacijo
vključeni storitev za pošiljanje elektronskih sporočil (definirana je v datoteki »mail-
service.xml«) in podatkovni vir (data source - definiran je v datoteki »eu-ds.xml«) preko
katerega z JPA ogrodjem dostopamo do podatkovne baze. Vse nastavitve za trajnost so v
XML datoteki »persistence.xml«, kjer se za povezavo do baze sklicujemo na zgoraj
omenjen podatkovni vir. To XML datoteko dodamo v arhiv EJB strežniških zrn
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 61
»uenumapp.jar«. Datoteka »jspUserMessage_sl_Sl.properties« je nabor virov (resource
bundle), v katerem je definiran celoten uporabniški vmesnik vključno z opozorili in
tekstovnimi opisi napak. S to datoteko definiramo jezik uporabniškega vmesnika, ki ga
zelo preprosto spremenimo z zamenjavo datoteke s prevedeno datoteko v drugi jezik.
3.8.1 Spletni in EJB vsebnik
Konceptualno platforma v osnovi vsebuje Java EE aplikacijski strežnik JBoss, ki je
osrednji del izvajalnega okolja Java EE aplikacije »uenum.ear«, in je sestavljen iz dveh
vsebnikov (angl. containers): vsebnika strežniških zrn EJB in spletnega vsebnika (slika
3.6) [28].
Slika 3.6: Uporabljene Java EE komponente
Grafični uporabniški vmesnik (GUI), preko katerega lahko uporabnik v spletnem
brskalniku izvaja vse implementirane funkcionalnosti, smo izdelali z javanskimi
strežniškimi stranmi JSP in skupino tehnik AJAX (angl. asynchronous JavaScript and
XML). Ajax je akronim za asinhroni JavaScript in XML ali drugače, Ajax je skupina
povezanih tehnik za razvoj spletnih strani, uporabljenih za kreiranje interaktivnih spletnih
aplikacij. Spletne strani in spletne vnosne forme smo oblikovali v HTML jeziku in obliko
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 62
oziroma izgled definirali s CSS (Cascading Style Sheets) predlogami. Nato z uporabo Ajax
tehnik osvežujemo samo določene dele posameznih strani. Povečanje odziva in
interaktivnosti spletnih strani je dosežena z izmenjavo majhne količine podatkov med
odjemalcem (spletnim brskalnikom) in aplikacijskim strežnikom, tako da se spletne strani
ob posameznih akcijah, ki jih uporabnik preko spletnega brskalnika sproži k strežniku, ne
nalagajo v celoti. Ob JSP straneh v okviru spletnega vsebnika tečejo tudi strežniški
programi ali servleti (servlets). To so krajši programi, ki se izvajajo na strani spletnega
strežnika. Po definiciji so to moduli, ki tečejo znotraj servisov, orientiranih na
zahtevo/odgovor (angl. HTTP request/response oriented), in jih na nek način tudi
razširjajo. Seveda mora strežnik, na katerem bi radi takšne programe izvajali, vsebovati
JVM, sicer nam takšni programi ne koristijo. S servleti smo realizirali navigacijo med JSP
stranmi, uporabljamo pa jih tudi za povezavo do podatkovne baze preko EJB zrn. Podatke,
ki jih preberemo iz podatkovne baze, v nekaterih servletih zapišemo v HTML obliko in s
pomočjo Ajax tehnik osvežimo samo določen del JSP strani.
V EJB vsebniku imamo EJB strežniška sejna zrna, v katerih je vsa poslovna logika
vključno z logiko za dostop do podatkov preko JPA ogrodja (ponudnik Hibernate). V
vmesniku (angl. interface) »CrudService« so navedene generične metode, s katerimi
ustvarjamo, iščemo/beremo, posodabljamo in brišemo entitete (CRUD - Create, Find/Read,
Update, Delete) in metode za kreiranje dinamičnih in poimenovanih poizvedb
(NamedQueries). Vse navedene metode so implementirane v zrnu »CrudServiceBean«.
Metode za kreiranje dinamičnih in poimenovanih poizvedb so implementirane z metodami
entitetnega upravljalca (createQuery, createNativeQuery, createNamedQuery), in jih
uporabljamo za izvrševanje poizvedovalnih stavkov (slika 3.7). Z metodo »createQuery«
lahko izvajamo poizvedovalne stavke zapisane v JPQL (Java Persistence Query Language)
jeziku, z metodo »createNativeQuery« lahko izvajamo osnovne SQL poizvedbe, medtem
ko metoda »createNamedQuery« omogoča, da poizvedovalne stavke (v jezikih JPQL ali
SQL) vnaprej pripravimo in poimenujemo v posamezni entiteti, nato pa jih po imenu
izvršimo. Sproti lahko ob izvedbi nastavljamo parametre v pogojnem delu poizvedovalnih
stavkov. To so poimenovane poizvedbe (ang named queries) in morajo imeti unikatno ime,
saj se nanje sklicujemo po imenu.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 63
Slika 3.7: Primer poimenovanih poizvedovalnih stavkov
Primer, kako smo uporabili zgoraj naveden, vnaprej pripravljen in unikatno
poimenovan poizvedovalni stavek (»serviceId« spremenljivka je primarni ključ entitete, v
katero želimo prebrati podatke iz tabele s tem primarnim ključem) lahko vidimo na sliki
3.8:
Slika 3.8: Primer uporabe poimenovanega poizvedovalnega stavka
Kompleksnejša poizvedovanja, dodajanje vnosov in brisanje smo izvedli na zgoraj
naveden način, medtem ko manjša iskanja in urejanja pa smo izvedli z osnovnimi CRUD
metodami. Rezultat vseh teh metod so lahko polja oziroma zbirke entitet ali samo ena
entiteta (primer: findNamedQuerySingle). Primer, kako smo na podlagi primarnega ključa
poiskali določenega uporabnika v tabeli »USERS« (z uporabo entitete »Users«) in mu
spremenili določen podatek imamo na sliki 3.9:
Slika 3.9: Primer uporabe osnovnih CRUD metod
Torej s podatki v podatkovni bazi lahko delamo neposredno s CRUD metodami ali
preko metod za delo s poizvedovalnimi stavki. Vse metode so implementirane v zrnu
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 64
»CrudServiceBean«. V tem zrnu izvajamo vse fizične dostope do podatkovne baze preko
entitetnega upravljalca (EntityManager). Z vsemi entitetami upravlja entitetni upravljalec,
ki ga predstavlja instanca javax.persistence.EntityManager (slika 3.10).
Slika 3.10: Povezava med trajnim kontekstom in entitetnim upravljalcem
Vsaka instanca entitetnega upravljalca je povezana z perzistentnim ali trajnim
kontekstom (persistence context). Trajni kontekst opredeljuje področje, pod katerim so
posamezne entitete ustvarjene, vztrajne in odstranjene. EJB vsebnik, ki je del Java EE
aplikacijskega strežnika, samodejno poskrbi, da je entitetni upravljalec na voljo vsem
komponentam aplikacije znotraj ene same transakcije JTA (Java Transaction Architecture).
Do njega lahko preprosto dostopamo kjerkoli znotraj aplikacije preko notacije
@PersistenceContext.
Entitete, ki jih uporabljamo v CRUD metodah, so aplikacijsko definirani objekti, ki
predstavljajo določeno tabelo v podatkovni bazi. Atributi oziroma lastnosti posamezne
entitete so preslikava polj enega zapisa tabele iz baze. Trajnost objekta, identiteta objekta,
kontekst transakcije in razdrobljenost so lastnosti, ki takšen objekt naredijo entiteto. Vsaka
entiteta ima tudi metapodatke. Metapodatki opisujejo entiteto in omogočajo sloju, ki skrbi
za trajnost, da prepozna, interpretira in pravilno upravlja z entiteto od trenutka, ko je
naložena glede na sklic nanjo. Vsaki entiteti jih lahko dodamo na dva načina: z notacijami
ali v dodatni XML datoteki za vsako entiteto. Mi smo entitete opisali z notacijami, ki so
programske funkcije in omogočajo strukturiranim in tipiziranim podatkom, da se pripnejo
k izvorni kodi. Na spodnjih slikah so prikazane notacije, ki smo jih dodali k razredu in
posameznim metodam. K razredom (slika 3.11) smo dodali notaciji @Entity in @Table, s
katerima določimo objekt oziroma razred kot entiteto in označimo katere tabele preslikava
je ta entiteta.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 65
Slika 3.11: Notacije ob razredu - entiteti
Z notacijami k primarnemu ključu v tabeli (entiteti) smo določili tudi način
samodejnega povečevanja primarnih ključev za 1 ob dodajanju novih vnosov v tabelo. Z
notacijo @SequenceGenerator nad razredom določimo način samodejnega povečevanja
ključa oziroma generator, v našem primeru s pomočjo vnaprej definirane sekvence
»DNS_INFO_SEQ«, ki se nahaja na podatkovni bazi Oracle. Notacija @GeneratedValue
priredi ta generator k polju »DNS_INFO_ID«, ki je primarni ključ tabele »DNS_INFO« v
podatkovni bazi. S pomočjo sekvence se nato primarni ključ samodejno povečuje za 1 ob
dodajanju novih vnosov z osnovnimi in dodatnimi CRUD metodami. Pri vseh atributih
entitete imamo notacijo @Column, s katero določimo, katero polje v tabeli je preslikano v
določen atribut. Notacija @Id določa primarni ključ tabele oziroma entitete. Primeri notacij
so prikazani na sliki 3.12.
Slika 3.12: Notacije ob metodah za primarni ključ
V aplikaciji uporabljamo tri sejna EJB zrna brez stanja (angl. stateless). Da je zrno brez
stanja oziroma ne ohranja sejnega stanja, označimo razred zrna z notacijo @Stateless. V
zrnu »EnumDNSQueryBean« je implementirana DNS poizvedba. Metode s poslovno
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 66
logiko za pisanje in branje iz podatkovne baze so implementirane v sejnih zrnih
»EditDataBean« in »GetNAPTRDataBean«. V prvem zrnu so metode za urejanje podatkov
v bazi, medtem ko v slednjem imamo samo bralne metode. Obe zrni uporabljata osnovne
in dodatne CRUD metode, do katerih dobimo dostop, če z notacijo @EJB povemo, da
želimo referenco na sejno zrno »CrudServiceBean«. Z notacijo naredimo referenco na
poslovni vmesnik EJB sejnega zrna in tako injiciramo sejno zrno »CrudServiceBean«, zrni
»EditDataBean« in »GetNAPTRDataBean«, pa postaneta odjemalski sejni zrni. Sejno zrno
»CrudServiceBean« ima atribut za opravljanje s transakcijo nastavljen na vrednost
TX_MANDATORY. Atribut za opravljanje s transakcijo @TransactionAttribute vsebuje
tudi parameter, s katerim povemo za kakšen tip transakcije gre (TransactionAttributeType).
Tip transakcije lahko določimo za celoten razred ali za posamezno metodo v razredu,
odvisno od zahtev. Na sliki 3.13 imamo primer nastavitve atributa za opravljanje s
transakcijo nad celotnim razredom, kar pa pomeni, da velja za vse metode razreda.
Slika 3.13: Nastavitev atributa za opravljanje s transakcijo nad razredom
Tip transakcije TX_MANDATORY pomeni, da EJB vsebnik ob vsakem klicu
katerekoli metode tega zrna iz drugih sejnih EJB zrn – odjemalcev preveri, ali je klic
metode iz odjemalca opravljen v okviru že odprte transakcije. Če odjemalec ni začel
transakcije oziroma nima nobene odprte, ko se sklicuje na zrno, vsebnik vrne izjemo (angl.
exception), da je zahtevana transakcija (TransactionRequired). Zato smo v vseh odjemalnih
sejnih zrnih, ki injicirajo zrno »CrudServiceBean« in kličejo njegove metode, nastavili
atribut za opravljanje s transakcijo na vrednost TX_REQUIRES_NEW. S tem smo dosegli,
da se ob klicu metod v odjemalnih sejnih zrnih iz servletov odpre nova transakcija, s katero
pristopimo do metod v zrnu »CrudServiceBean«, v okviru nje izvajamo operacije nad
bazo, in jo nato zaključimo, ko zapustimo metodo odjemalnega sejnega zrna. Če na tej poti
od odjemalnega sejnega zrna do sejnega zrna »CrudServiceBean« pride do napake, se
izvede povrnitev v prvotno stanje (angl. rollback). Torej razveljavijo se vse spremembe, ki
so se zgodile v okviru te transakcije do nastanka izjeme. Tukaj je zelo pomembno, kam
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 67
imamo umeščeno notacijo za določitev tipa transakcije @TransactionAttribute. Če je
notacija umeščena nad razred bo povrnitev v prvotno stanje zajemala vse kar se je dogajalo
po vseh metodah, če pa imamo notacijo nad posameznimi metodami, pa samo v tisti
metodi, kjer je prišlo do izjeme oziroma napake (torej vsak klic posamezne metode se
zgodi znotraj svoje transakcije).
Torej, če povežemo še javanski strežniški programček - servlet in EJB sejno zrno,
imamo vse Java EE komponente povezane v celoto. Povezavo med servleti in EJB sejnimi
zrni smo izvedli z dodatnim razredom »BeanLocator«, ki vsebuje metodo »locate«, s
katero v kontekstu po imenu zrna poiščemo EJB sejno zrno. Povezava na zrno je lahko
lokalna ali oddaljena (angl. local or remote). Uporabili smo lokalno povezavo (slika 3.14).
Povezava na zrno se izvede z iskanjem po kontekstu, kot je prikazano na sliki 3.15.
Slika 3.14: Povezava na sejno zrno v servletu
Slika 3.15: Iskanje zrna po kontekstu
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 68
3.8.2 Konfiguracija trajnosti (JPA s ponudnikom Hibernate)
Za povezavo EJB-jev do Oracle podatkovne baze smo potrebovali dve XML
konfiguracijski datoteki. V datoteki »ue-ds.xml« smo definirali podatkovni vir (angl. data
source), v katerem so podani vsi parametri, ki so potrebni za povezavo do podatkovne
baze. JNDI (Java Naming and Directory Interface) ime podatkovnega vira je »UE-ds«, kot
vidimo na sliki 3.16.
Slika 3.16: Nastavitev JDBC podatkovnega vira
Pri poenostavljeni konfiguraciji podatkovnega vira lahko imamo več različnih
elementov sheme na najvišjem nivoju XML deskriptorja (slika 3.17). In sicer mbean, no-
tx-datasource, local-tx-datasource, xa-datasource, ha-local-tx-datasource, ha-xa-
datasource .
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 69
Slika 3.17: Možni vrhnji elementi sheme podatkovnega vira
Uporabili smo local-tx-datasource vrhnji element XML sheme, ki se uporablja za
določanje (org.jboss.resource.connectionmanager) nastavitev LocalTxConnectionManager
storitve. Element nosi vse potrebne osnovne podatke za povezavo z bazo. S transakcijami
upravlja upravljalec transakcij. Tako definiran podatkovni vir določa vir podatkov, ki
uporablja transakcije vključno s porazdeljenimi transakcijami v okviru lokalnega
aplikacijskega strežnika, vendar pa ne omogoča porazdeljenih transakcij med več
aplikacijskih strežnikov. Druga XML datoteka »persistence.xml« je standardna
konfiguracijska datoteka za vzpostavitev trajnosti v JPA in omogoča popolno
prilagodljivost za konfiguriranje entitetnega upravljalca. V tej datoteki (slika 3.18)
določimo ponudnika trajnosti (Hinernate – org.hibernate.ejb.HibernatePersistence), tip
transakcije (JTA – Java Transaction API), JDBC podatkovni vir, ki ga želimo uporabiti, in
dodatne nastavitve, ki zadevajo transakcije, povezavo do baze in ponudnika trajnosti
Hibernate. Na JBoss AS je privzeti in edini podprt/priporočen JPA ponudnik Hibernate.
Vsi ti podatki so zajeti v enoti trajnosti (angl. persistence-unit), ki mora imeti unikatno ime
znotraj nalagalca razredov, kjer je zajeta. Na podatkovni vir se sklicujemo po JNDI imenu
podatkovnega vira. Datoteko »persistence.xml« smo dodali v imenik /META-INF znotraj
JAR arhiva »uenumapp.jar«, ki vsebuje entitetna zrna.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 70
Slika 3.18: Nastavitev enote trajnosti v datoteki »persistence.xml«
3.8.3 Konfiguracija modula za prijavo uporabnika v portal (angl. login module)
V spletni aplikaciji »uenumadmin«, ki služi urejanju uporabnikov, registracijskih
zahtevkov in uporabniških podatkov smo za prijavno avtentikacijo uporabnika uporabili
avtentikacijski mehanizem, ki bazira na prijavni formi (angl. form-based login
authentication). Preko vnosne forme uporabnik vnese uporabniško ime in geslo ter s
klikom na gumb »Prijava« sproži preverjanje uporabnika v povezavi s podatki v
podatkovni bazi. Preverjanje uporabnika se izvrši v naslednjih korakih (slika 3.19) [25]:
1) Odjemalec zahteva dostop do zaščitenega vira,
2) če odjemalec ni avtenticiran, strežnik preusmeri odjemalca na prijavno stran
(login.jsp),
3) odjemalec predloži (angl. submit) prijavno formo na strežnik,
4) če prijava po preverjanju uporabniških podatkov uspe, strežnik preusmeri
odjemalca na zahtevan vir, če prijava ne uspe, je odjemalec preusmerjen na stran z
opisom napake (error.jsp).
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 71
Slika 3.19: Avtentikacija z vnosno formo (angl. form-based authentication)
Preverjanje uporabnika na strežniški strani smo izvedli s prijavnim modulom (angl.
login-module) »org.jboss.security.auth.spi.DatabaseServerLoginModule«, ki ga imamo na
voljo v okviru aplikacijskega strežnika Jboss. To je JDBC prijavni modul, ki podpira
avtentikacijo in preslikavo vlog. Uporabimo ga lahko, če imamo podatkovno bazo
naravnano tako, da imamo v njej določene podatke o uporabnikih (uporabniško ime, geslo
in vlogo). V podatkovni bazi smo pripravili tabelo »USERS«, v kateri hranimo podatke o
registriranih uporabnikih spletne aplikacije.
Na strežniški strani smo v konfiguracijsko datoteko »/usr/local/jboss-
5.1.0.GA/server/default/conf/login-config.xml« dodali novo aplikacijsko politiko (angl.
application-policy) z določenimi nastavitvami za uporabo prijavnega modula. V
aplikacijski politiki smo definirali avtentikacijo in vključili zgoraj omenjeni prijavni
modul. Aplikacijski politiki smo dodelili ime, na katerega se sklicujemo v spletni
aplikaciji. Pri nastavitvah prijavnega modula v XML deskriptorju imamo na voljo več
nastavitvenih parametrov, uporabili smo samo tiste, ki jih potrebujemo. S parametrom
dsJndiName smo nastavili podatkovni vir, preko katerega prijavni modul v podatkovni
bazi spletne aplikacije preveri podatke o uporabniku. Uporabili smo kar podatkovni vir, ki
ga uporablja tudi spletna aplikacija in sicer »UE-ds«. Nastavili smo tudi tip algoritma in
format kodiranja, ki ga uporabimo pri prikritju uporabniškega gesla. S parametrom
hashAlgorithm smo nastavili po kakšnem algoritmu želimo zgostiti geslo (MD5 ali SHA-
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 72
1), parameter hashEncoding pa določa format kodiranja zgoščenega gesla (hex ali
Base64). Parametra principalsQuery in rolesQuery smo uporabili, da smo prijavnemu
modulu podali vnaprej pripravljen SQL stavek za preverjanje kombinacije uporabniškega
imena in gesla, ter SQL stavek za pridobitev vloge uporabnika. Na sliki 3.20 imamo primer
nastavitve aplikacijske politike na strežniški strani.
Slika 3.20: Nastavitev aplikacijske politike na strežniški strani
V spletni aplikaciji smo pripravili vnosno formo za prijavni modul. Vnosna forma
vsebuje dve vnosni polji in sicer polje za uporabniško ime in polje za geslo. Pri uporabi
JAAS (Java Authentication and Authorization Service) mehanizma je zelo pomembno, da
smo vnosno polje za uporabniško ime poimenovali »j_username«, vnosno polje za geslo
pa »j_password« [26]. Potrebno je bilo še parameter akcija (angl. action) prijavne vnosne
forme nastaviti na »j_security_check«. S pritiskom na gumb »Prijava« uporabnik nato
predloži podatke iz vnosne forme na strežnik (angl. submit). V spletni aplikaciji smo
morali še vključiti uporabo prijavnega modula. To smo izvedli v dveh XML datotekah, ki
sta pomembni za delovanje spletne aplikacije. V datoteki »jboss-web.xml« v spletni
aplikaciji smo navedli varnostno domeno (angl. security-domain), ki se po imenu povezuje
z aplikacijsko politiko na aplikacijskem strežniku (slika 3.21).
Slika 3.21: Povezava varnostne domene z aplikacijsko politiko
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 73
V datoteki »web.xml«, ki opisuje spletno aplikacijo, smo definirali dve varnostni
omejitvi (angl. security-constraint) in sicer po eno za vsako uporabniško vlogo (uporabnik
– UEUser, administrator - UEAdmin). Uporabniške vloge iz podatkovne baze smo navedli
kot varnostne vloge (angl. security-role) v spletni aplikaciji in jih nato vključili v
varnostnih omejitvah (slika 3.23) [27]. Z varnostnimi omejitvami smo zaščitili določene
vire v spletni aplikaciji in sicer tako, da smo podali URL poti do virov, ki so zaščiteni
glede na vlogo prijavljenega uporabnika. Podali smo tudi nastavitve za prijavo, ki zadevajo
obliko avtentikacije (angl. form-based), sklic na varnostno domeno (UEWebRealm) in
navajajo poti do strežniških strani »login.jsp« in »error.jsp«, ki jih potem prijavni modul
uporabi za preusmerjanje ob poskusu dostopa odjemalca do zaščitenega vira. Na takšen
način smo v spletni aplikaciji zagotovili dva nivoja dostopa, kot uporabnik ali kot
administrator glede na uporabniško vlogo prijavljenega uporabnika. Za avtorizacijo
spletnih virov nato prijavni modul poskrbi sam. Za dodatno avtorizacijo spletnih virov ali
posameznih vsebin znotraj virov lahko poskrbimo dodatno še sami – programsko, kot je
prikazano na sliki 3.22.
Slika 3.22: Primer programske avtorizacije vsebine
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 74
Slika 3.23: Nastavitve varnostnih omejitev, varnostnih vlog in prijavnih nastavitev
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 75
3.9 Teledroid ENUM – univerzalni mobilni komunikacijski odjemalec
Univerzalni mobilni komunikacijski odjemalec Teledroid ENUM je mobilna aplikacija,
ki deluje na platformi Android in mobilnemu telefonu z operacijskim sistemom Android
prinaša podporo za Uporabniški ENUM sistem (E.164 preslikava telefonskih številk).
Aplikacijo smo razvili za mobilni operacijski sistem Android 2.3.3 Gingerbread v
javanskem razvojnem okolju Eclipse, z nameščenim vtičnikom ADT in Android
programskim paketom SDK. Med razvojem smo aplikacijo testirali na emulatorju, ki ga
vsebujejo orodija ADT in na fizični mobilni napravi Samsung Galaxy S2.
Slika 3.24: Drevesna struktura Android projekta
Struktura projekta za platformo Android v
razvojnem okolju Eclipse je zelo podobna
strukturi običajnih javanskih projektov namiznih
in spletnih aplikacij. Na sliki 3.24 je prikazana
drevesna struktura projekta. Projekt vsebuje dva
ključna imenika in sicer »src« in »bin«. V
imeniku »src« se nahajajo razredi z izvorno
kodo (*.java), med tem ko v skritem imeniku
»bin« pa imamo že prevedene javanske razrede
(*.class) in končni arhiv (*.apk), ki ga lahko
prenesemo na mobilno napravo ter namestimo
aplikacijo. V imenik »gen« vtičnik razvojnega
okolja Eclipse samodejno generira »R.java«
datoteko, ki je indeks do vseh virov, ki jih
imamo definirane v datoteki. S pomočjo tega
razreda lahko hitro dostopamo do virov, ki jih
imamo vključene v projekt. V imenik »lib«
lahko dodamo zunanje knjižnice, kot v našem
primeru knjižnica »dnsjava-2.0.8«, s katero smo
implementirali ENUM DNS poizvedbo.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 76
Imenik »res« se uporablja za ureditev grafične podobe uporabniškega vmesnika
aplikacije. Vanj lahko shranimo razne slikovne elemente (slike, ikone) in xml datoteke, v
katerih je definirana grafična podoba posameznih aktivnosti. Vsebuje lahko tudi xml
datoteke, v katerih lahko definiramo določene vire (razne tekstovne nize in podobno), na
katere se kasneje v drugih xml datotekah sklicujemo kar po imenu. Zelo pomembna je
datoteka »AndroidManifest.xml«, ki opisuje celotno aplikacijo. Struktura datoteke je
prikazana na sliki 3.25.
Slika 3.25: Datoteka AndroidManifest.xml
Ta datoteka navaja vse uporabljene aktivnosti, določa aktivnost, ki se prva naloži ob
zagonu aplikacije, določa pravice uporabnika, minimalno potrebno različico operacijskega
sistema, ime aplikacije, ikono aplikacije in še več. V projektu imamo še konfiguracijsko
datoteko »application.conf«, kjer so shranjene nastavitve, ki jih uporabnik vnese in služijo
za pravilno izvedbo ENUM DNS poizvedbe.
Aplikacija ima dve aktivnosti. Prva aktivnost služi izvedbi ENUM DNS poizvedbe in
prikazu rezultatov le-te. Ob zagonu aplikacije se ta aktivnost prva naloži. Implementirana
je v razredu »TeledroidENUMGUI.java«, njeno grafično podobo pa določa datoteka
»main.xml«. Z drugo aktivnostjo lahko uporabnik ureja nastavitve za poizvedbo, ki so
shranjene v zgoraj omenjeni datoteki »application.conf«. Implementirana je v razredu
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 77
»SetEnumPreferences.java«, njeno grafično podobo pa določa datoteka
»enumpref.xml«. Oba razreda razširjata razred »android.app.Activity« iz nabora
razredov, ki jih v projekt vključuje sistemska knjižnica »android.jar« (Android 2.3.3).
Datoteki xml, ki določata grafično podobo posameznih aktivnosti, definirata vse vsebovane
elemente (gumbe, vnosna polja, tekstovne oznake in podobno). V imeniku »src« z izvorno
kodo imamo še nekaj pomožnih razredov:
• »Confs.java«: razred s statičnimi nastavitvami za celotno aplikacijo,
• »DataChecker.java«: razred za preverjanje telefonske številke (dolžina, pravilnost
predpone, nedovoljeni znaki),
• »GetDnsRecords.java«: implementacija ENUM DNS poizvedbe,
• »NaptrResult.java«: javanski objekt (POJO) za prenos polja NAPTR zapisov in
statusne kode v aktivnost po opravljeni ENUM DNS poizvedbi,
• »Prop.java«: razred za branje uporabniških nastavitev iz datoteke za ENUM DNS
poizvedbo.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 78
4 EKSPERIMENTALNI REZULTATI
UENUM spletna aplikacija ima tri glavne naloge. Omogoča obstoječim uporabnikom
urejanje svojih komunikacijskih kanalov, omogoča potencialnim uporabnikom registracijo
oziroma prvo prijavo v sistem in administratorju sistema administriranje uporabnikov ter
registracijskih zahtevkov. Prijava v portal je možna v dveh nivojih in sicer kot
administrator ali uporabnik. Vsem uporabnikom, tudi neprijavljenim oziroma
neregistriranim, je omogočena ENUM DNS poizvedba preko spletne aplikacije (slika 4.1).
Funkcionalnosti UENUM spletne aplikacije:
• ENUM DNS poizvedba neposredno na lokalni domenski strežnik Bind,
• oddaja zahtevka za registracijo novega uporabnika (neregistrirani uporabniki),
• prijava v portal – avtentikacija in avtorizacija,
• oddaja zahtevka za obnovitev pozabljenega gesla (registrirani uporabniki),
• sprememba gesla za prijavo (registrirani uporabniki),
• sprememba naslova elektronske pošte uporabnika (registrirani uporabniki),
• urejanje NAPTR zapisov uporabnika (dodajanje, urejanje, brisanje in začasen
izklop posameznih NAPTR zapisov – registrirani uporabniki),
• urejanje registracijskih zahtevkov (administratorji),
• urejanje uporabnikov (administratorji),
• preverjanje uporabnika ob registraciji preko SMS sporočila za mobilne uporabnike
in preko klicnega odzivnika za stacionarne uporabnike.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 79
Slika 4.1: Spletna aplikacija Uporabniškega ENUM sistema
4.1 ENUM DNS poizvedba
ENUM DNS poizvedbo lahko naredimo neposredno na lokalni domenski strežnik
BIMD iz spletne aplikacije (orodje dnsjava), iz ukazne vrstice (orodje DIG) ali drugih
odjemalcev, ki so lahko na mobilnih telefonih, osebnih računalnikih in drugih sistemih s
podprto ENUM DNS poizvedbo. Na spodnjih slikah 4.2 in 4.3 sta primera rezultatov
poizvedbe iz spletnega vmesnika in iz ukazne vrstice za testno mobilno telefonsko številko
+38651123456. Po vnosu telefonske številke uporabnika (vključno s klicno kodo države in
kodo omrežne skupine) dobimo kot rezultat poizvedbe vse storitve oziroma
komunikacijske kanale (načine komuniciranja) do uporabnika, za katerega smo izvedli
poizvedbo.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 80
Slika 4.2: Primer testne ENUM DNS poizvedbe iz spletne aplikacije
Slika 4.3: Primer testne ENUM DNS poizvedbe iz Linux ukazne vrstice
Meritve časa trajanja poizvedb smo opravili na poizvedbah, opravljenih z orodjema
»DIG« in »dnsjava«. Prvo orodje predpomnilnika ne podpira, medtem ko slednje pa ima
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 81
možnost uporabe predpomnilnika. Najprej smo čas trajanja izmerili pri obeh orodjih brez
uporabe predpomnilnika in sicer lokalno na strežniku in iz drugega Linux strežnika, nato
pa smo izmerili še čas trajanja poizvedbe z orodjem »dnsjava« in uporabo predpomnilnika.
Čas trajanja poizvedbe (tabela 4.1) je pri poskusih poizvedovanj kar različen, velik vpliv
pri hitrosti odgovora na poizvedbo pa ima uporaba predpomnilnika na strani odjemalca, ki
poizveduje.
Tabela 4.1: Izmerjeni časi trajanja poizvedb za različna orodja in povprečni časi
Poizvedovanje Predpomnilnik Meritve (ms) Povprečje (ms)
Lokalno (spletna aplikacija - dnsjava) Ne 73,84,66,95,84,68 78,33
Lokalno (spletna aplikacija - dnsjava) Da 1,<1,<1,<1,1,<1 <1
Drug strežnik (spletna aplikacija -
dnsjava)
Ne 63,93,94,78,94,78 83,33
Drug strežnik (spletna aplikacija -
dnsjava)
Da <1,<1,1,<1,<1,<1 <1
Lokalno (ukazna vrstica - DIG) Ne 25,24,29,26,26,21 25,16
Drug strežnik (ukazna vrstica - DIG) Ne 26,29,27,26,26,27 26,83
Razlik med poizvedovanjem lokalno ali iz drugega strežnika v omrežju skorajda ni. Le
nekaj milisekund. Povprečni čas poizvedovanja z orodjem »DIG« brez predpomnilnika je
znašal nekje med 25 in 27 milisekundami. Povprečni čas poizvedovanja z orodjem
»dnsjava« brez predpomnilnika se je gibal med 78 in 84 milisekundami, ko pa smo
uporabili predpomnilnik, pa je poizvedba trajala manj kot 1 milisekundo, saj se poizvedba
ni dejansko izvršila na domenski strežnik, ampak se je rezultat vrnil iz predpomnilnika na
strani odjemalca. Čas, kako dolgo ostane rezultat za določeno poizvedbo v predpomnilniku
določa TTL vrednost ob NAPTR zapisih. TTL vrednost pove odjemalcu, kako dolgo
(koliko sekund) naj za določeno poizvedbo hrani NAPTR zapise v predpomnilniku.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 82
4.2 Funkcionalnosti pri neregistriranih in neprijavljenih uporabnikih
Neregistrirani in neprijavljeni uporabniki imajo možnost pošiljanja ENUM DNS
poizvedb. Neregistrirani uporabniki lahko v spletni aplikaciji podajo zahtevek za
registracijo novega uporabnika . V osnovnem meniju je dosegljiv zavihek »Registracija«, v
katerem se nahaja spletna forma za vnos osnovnih zahtevanih podatkov za registracijski
zahtevek. Postopek preverjanja uporabnika je prikazan na sliki 4.4.
Slika 4.4: Postopek preverjanja uporabnika
Uporabnik mora vnesti telefonsko številko, za katero želi ustvariti uporabniški račun.
Številko mora vnesti brez izhodne klicne kode (00 ali +), vključno s vhodno klicno kodo
države in omrežno kodo brez vodilne ničle (0) . Primer telefonske številke, ki bo v
nadaljevanju tudi uporabniško ime (38651234567). Potrebno je določiti tudi tip številke,
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 83
torej stacionarna ali mobilna številka, in podati kontaktni naslov elektronske pošte
uporabnika, ki se kasneje uporablja pri preverjanju uporabnika ob registraciji in pri
posredovanju novega uporabniškega gesla, v primeru, da je uporabnik le-tega pozabil ali
izgubil. Ko uporabnik odda registracijski zahtevek, mora počakati na potrditev zahtevka s
strani administratorja. Od sistema dobi obvestilo v spletni aplikaciji po oddaji zahtevka
(slika 4.5). V primeru registracije mobilne številke bo uporabnik dobil začasno avtomatsko
generirano identifikacijsko številko po SMS sporočilu, če pa gre za registracijo stacionarne
številke, pa po elektronski pošti na naslov, ki ga je navedel v registracijskem zahtevku.
Identifikacijska številka je 5 mestna in sestavljena iz samih številk, da je uporabna tudi pri
klicnem odzivniku. V obeh primerih je potrebno počakati na potrditev zahtevka s strani
administratorja (slika 4.6). Administrator to stori pod zavihkom »Administracija/Urejanje
registracij«. Na svoj elektronski naslov so vsi administratorji tudi obveščeni o novih
registracijskih zahtevkih, ki čakajo na potrditev.
Slika 4.5: Zahtevek za registracijo novega uporabnika in obvestilo po oddaji le-tega
Slika 4.6: Potrjevanje registracijskih zahtevkov s strani administratorja
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 84
4.2.1 Preverjanje uporabnika pri registraciji mobilne številke
Če gre za registracijo mobilne številke in je uporabnik na to številko po oddaji zahtevka
prejel SMS sporočilo z identifikacijsko številko, je uporabnik že preverjen in lahko s to
številko izvede prvo prijavo v spletno aplikacijo. Vsebina SMS sporočila:
Pozdravljeni,posredujemo Vam avtomatsko generirano identifikacijsko številko oz.
geslo za prvo prijavo:64909 Lep pozdrav,SI-USER ENUM sistem
Takoj po prijavi je zahtevana sprememba gesla, uporabnik vidi desno zgoraj v spletni
aplikaciji opozorilo (Opozorilo: Priporočena je sprememba gesla.) tako dolgo, dokler
prvega gesla ne spremeni.
4.2.2 Preverjanje uporabnika pri registraciji stacionarne številke
Če gre za stacionarno številko, pa je preverjanje z SMS sporočilom nemogoče, zato
uporabnika identificiramo preko telefonskega odzivnika. Po potrditvi zahtevka s strani
administratorja, dobi uporabnik 5 mestno avtomatsko generirano identifikacijsko številko
po elektronski pošti in navodila kako z odzivnikom to geslo omogočiti za prvo prijavo.
Vsebina elektronske pošte:
Zadeva: SI-USER ENUM sistem - identifikacijska številka
Vsebina: Pozdravljeni, glede na Vaš registracijski zahtevek preko spletne strani SI-USER ENUM sistema Vam posredujemo avtomatsko generirano identifikacijsko številko, ki jo vnesite v avtomatski odzivnik, ki ga pokličete iz vaše registrirane telefonske številke: 54300 Številka avtomatskega odzivnika: +38659091933 Identifikacijska številka je tudi vaše prvo prijavno geslo po uspešni aktivaciji preko avtomatskega odzivnika. Prosimo, da si geslo spremenite ob prvi prijavi! Lep pozdrav
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 85
SI-USER ENUM sistem
Identifikacijska številka v primeru registracije stacionarne številke postane prvo
prijavno geslo komaj po preverjanju preko telefonskega odzivnika. Preverjanje poteka
tako, da uporabnik pokliče iz stacionarne številke, ki jo želi registrirati na odzivnik in po
navodilih po pisku odtipka 5 mestno identifikacijsko številko. Sistem nato preveri
kombinacijo stacionarne telefonske številke in identifikacijske številke in ustrezno
omogoči kreiranega uporabnika v sistemu ali ga zavrne in mu omogoči ponoven vnos
številke. Ko je uporabnik uspešno preverjen preko odzivnika se lahko s to identifikacijsko
številko kot prvo geslo tudi prijavi. Po prijavi je prav tako priporočena sprememba gesla.
4.3 Funkcionalnosti pri registriranih-prijavljenih uporabnikih
Registriran uporabnik, ki je prijavljen v spletno aplikacijo, lahko ažurira podatke o
svojih komunikacijskih kanalih. Dovoljeno mu je dodajati, brisati, urejati in izključevati
obstoječe NAPTR zapise, ki so vezani na njegovo telefonsko številko. Spremeni lahko tudi
svoje prijavno geslo in naslov elektronske pošte. V primeru, da pozabi svoje prijavno geslo
ima kot neprijavljen uporabnik tudi možnost zahteve za spremembo gesla.
4.3.1 Ažuriranje NAPTR zapisov
Uporabnik ima v zavihku »Urejanje NAPTR« dostop do dveh vnosnih form, s katerima
lahko ažurira komunikacijske kanale (sliki 4.7 in 4.8).
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 86
Slika 4.7: Vnosna forma za dodajanje NAPTR zapisov
Pri dodajanju novih NAPTR zapisov uporabnik najprej na desni strani izbere storitev,
za katero želi ustvariti NAPTR zapis. Ob izbiri storitve se mu v vnosni formi določeni
parametri prednastavijo in mu jih ni dovoljeno spreminjati, ker so vnaprej določeni.
Dovoljene parametre pa lahko sam izpolni. Z gumbom »Dodaj NAPTR zapis« se zapis
pripne k telefonski številki. Privzeto je, da je NAPTR zapis ob nastanku vključen. Kasneje
lahko uporabnik določene zapise kratkoročno ali dolgoročno izključi (primer: v času
letovanja v tujini si lahko NAPTR zapis za domačo stacionarno številko ali služben
mobilni telefon izključi).
Vnosna forma za urejanje NAPTR zapisov omogoča uporabniku spreminjanje
obstoječih zapisov, brisanje in izključevanje. Do parametrov posameznega zapisa lahko
dostopa tako, da obstoječi zapis (komunikacijski kanal) izbere na desni strani. V vnosni
formi se izpolnijo parametri NAPTR zapisa glede na izbiro, le-te pa lahko nato ažurira.
Spreminjanje parametrov in izključevanje zapisa potrdi z gumbom »Shrani NAPTR zapis«,
izbran zapis pa lahko izbriše z gumbom »Izbriši NAPTR zapis«.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 87
Slika 4.8: Vnosna forma za urejanje NAPTR zapisov
4.3.2 Sprememba gesla in naslova elektronske pošte
Spremembo prijavnega gesla in naslova elektronske pošte lahko uporabnik izvede
preko spletnih form v zavihkih »Spremeni geslo« in »Urejanje uporabnika«. Pri spremembi
gesla je potrebno vnos novega gesla pred potrditvijo ponoviti (slika 4.9).
Slika 4.9: Vnosni formi za spremembo naslova elektronske pošte in prijavnega gesla
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 88
4.3.3 Zahteva za novo avtomatično generirano prijavno geslo
Če uporabnik pozabi ali izgubi prijavno geslo, lahko kot neprijavljen uporabnik zaprosi
za novo 8 mestno začasno geslo, ki se po oddanem zahtevku avtomatično generira iz
številk in znakov ter pošlje na elektronski naslov. To lahko stori v vnosni formi
»Pozabljeno geslo«, ki je dostopna brez prijave (slika 4.10). Obvezen je vnos
uporabniškega imena in elektronskega naslova, ki mora sovpadati s tistim, ki ga ima
uporabnik vnešenega kot kontakni elektronski poštni naslov.
Slika 4.10: Vnosna forma za zahtevek po novem prijavnem geslu
S podatki, ki jih uporabnik dobi na elektronski naslov, lahko izvede prijavo in ponovno
je z obvestilom desno zgoraj pozvan, da takoj spremeni začasno geslo. Vsebina elektronske
pošte:
Zadeva: SI-USER ENUM sistem – pozabljeno geslo
Vsebina: Pozdravljeni, na Vašo zahtevo preko spletne strani SI-USER ENUM sistema Vam posredujemo avtomatsko generirano novo geslo: 0qkkTycz Prosimo, da si geslo spremenite ob prvi prijavi! Lep pozdrav SI-USER ENUM sistem
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 89
4.4 Funkcionalnosti pri administratorjih
Vsak administrator si lahko na enak način kot uporabnik spremeni prijavno geslo in
naslov elektronske pošte, na katerega dobiva vsa obvestila o novih nepotrjenih
registracijskih zahtevkih in podobno. Na voljo ima še dva dodatna zavihka
»Administracija« in »Statistika«.
4.4.1 Urejanje uporabnikov in registracij
Administratorji imajo v zavihku »Administracija« na voljo dve funkcionalnosti, s
katerima lahko urejajo že obstoječe uporabniške račune in nepotrjene registracijske
zahtevke, za katere so prejeli obvestila na elektronski naslov. Zavihek
»Administracija/Urejanje uporabnikov« omogoča iskanje po uporabnikih glede na
telefonsko številko oziroma uporabniško ime in filtriranje izključenih uporabnikov ali
tistih, ki jim novo generirano geslo še ni bilo posredovano (slika 4.11). Ko administrator
uporabnika najde po zgoraj navedenih iskalnih metodah, ga lahko izbriše, izključi/vključi
ali vsili spremembo gesla. Vsiljena sprememba gesla pomeni, da se iz varnostnih razlogov
na zahtevo administratorja sproži proces, ki uporabniku avtomatično generira novo
prijavno geslo, mu to sporoči po elektronski pošti in mu doda v njegov uporabniški račun
obvestilo, da naj si ob prvi naslednji prijavi spremeni geslo.
Če administrator uporabnika izbriše, pomeni to popolno odstranitev iz Uporabniškega
ENUM sistema. Pobrišejo se vsi NAPTR zapisi tega uporabnika in uporabniški račun.
Potreben je ponoven postopek registracije. V primeru izključitve pa uporabnik in njegovi
NAPTR zapisi ostanejo v sistemu onemogočeni, in je mogoče uporabnika vključno z
NAPTR zapisi kadarkoli vključiti nazaj v sistem.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 90
Slika 4.11: Spletna forma za upravljanje z uporabniki
V zavihku »Administracija/Urejanje registracij« lahko administratorji potrdijo
registracijske zahtevke uporabnikov (slika 4.12). V tej fazi razvoja sistema še ni
implementirana funkcionalnost preverjanja telefonske številke glede na tip številke. Sistem
ob vnosu zahtevka preveri samo format telefonske številke, število mest, vhodno kodo
države in omrežno kodo. Torej naloga administratorja je, da preveri v registru številskih
blokov Agencije za pošto in elektronske komunikacije RS (APEK) ali je telefonska
številka v registracijskem zahtevku pravilno označena kot mobilna ali stacionarna. V
primeru potrjevanja registracijskega zahtevka za dejansko stacionarno številko po metodi
za potrjevanje mobilne, uporabnik ne bo dobil SMS-a ali elektronske pošte z navodili za
klicni odzivnik.
Slika 4.12: Spletna forma za potrjevanje in brisanje registracijskih zahtevkov
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 91
4.4.2 Pregled dnevnih statistik in log datotek
V zavihku »Statistika« ima vsak administrator omogočen vpogled v dnevno statistiko
uporabe spletne aplikacije sistema. Na voljo je dnevni pregled nad številom prijav v
spletno aplikacijo, številom novih registracijskih zahtevkov, številom potrjenih zahtevkov,
številom dodanih NAPTR zapisov, številom poizvedovanj preko spletne aplikacije in
vpogled v log datoteko spletne aplikacije, kot je prikazano na sliki 4.13.
Slika 4.13: Informativni statistični podatki za administratorja
4.5 ENUM poizvedba na mobilnem odjemalcu in komunikacija
Mobilni odjemalec uporabniku omogoča, da pred vzpostavitvijo komunikacije z
željeno osebo na mobilnem telefonu, preko Uporabniškega ENUM sistema na podlagi
telefonske številke, ki je univerzalni unikatni ključ za sistem, preveri o možnih dodatnih
komunikacijskih kanalih do željene osebe. Če dodatne komunikacijske kanale dobi v
rezultatu poizvedbe, lahko z obstoječimi vmesniki in aplikacijami operacijskega sistema
Android vzpostavi komunikacijo.
Aplikacija vsebuje dve aktivnosti, v katerih sta implementirani dve funkcionalnosti. To
sta ENUM DNS poizvedba in urejanje nastavitev za poizvedbo. Prvi pogoj za delovanje
aplikacije je aktivna povezava do Interneta, ki je lahko bodisi mobilni podatkovni prenos
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 92
preko mobilnega omrežja ali povezava v brezžično omrežje, ki ima dostop do Interneta.
Drugi pogoj so ustrezne nastavitve v aplikaciji, ki določajo naslov ENUM DNS strežnika,
vhodno klicno kodo države in ENUM domeno. Aktivnost aplikacije, kjer lahko te
parametre nastavljamo, lahko vidimo na sliki 4.14. Druga aktivnost implementira ENUM
DNS poizvedbo. Ob vnosnem polju za telefonsko številko imamo tudi dva gumba, prvi se
uporablja za proženje poizvedbe, drugi pa za dostop do aktivnosti za ažuriranje nastavitev
poizvedbe. Pod iskalno vnosno formo imamo prostor za prikaz rezultata, ki je lahko
obvestilo o morebitni napaki pri poizvedbi ali v primeru uspešne poizvedbe seznam
komunikacijskih kanalov. Druga aktivnost aplikacije je prikazana na sliki 4.15. Vidimo
lahko uspešno poizvedbo s komunikacijskimi kanali in dve neuspešni poizvedbi. Druga
poizvedba je bila neuspešna, ker testna telefonska številka +38651234568 nima vnešenih
komunikacijskih kanalov, pri tretji pa je prišlo do napake pri poizvedovanju. Takšna
napaka se lahko pojavi, če nimamo aktivne internetne povezave ali pa je prisotna kakšna
druga napaka pri povezavi do ENUM DNS strežnika oziroma je strežnik nedosegljiv.
Slika 4.14: Nastavitve parametrov ENUM DNS poizvedbe
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 93
Slika 4.15: ENUM DNS poizvedbe
V primeru, da uporabnik aplikacije napačno vnese telefonsko številko, se poizvedba ne
izvede. Možni sta dve napaki, ki se izpišeta uporabniku na zaslon mobilnega telefona:
»Dolžina telefonske številke je napačna!« ali »Številka vsebuje neveljavne znake!«.
V primeru uspešne poizvedbe lahko uporabnik poskuša vzpostaviti komunikacijo preko
komunikacijskih kanalov, za katere je dobil NAPTR zapise v odgovoru na poizvedbo.
Enostavno preko zaslona na dotik pritisne na željeno storitev in komunikacija se lahko
vzpostavi v ustreznem vmesniku ali dodatno nameščeni aplikaciji. Za vzpostavitev
komunikacije po ENUM storitvah pstn:tel, sms:tel in mms:tel, kjer imamo v NAPTR
zapisu telefonsko številko s vsemi priponami, se uporabi kar Androidov vgrajeni izbirnik
(angl. dailer). V izbirniku imamo na voljo vzpostavitev običajnega glasovnega klica, video
klica in pošiljanje tekstovnih ter multimedijskih sporočil. Na sliki 4.16 je prikazana
vzpostavitev običajnega klica in pošiljanje SMS ali MMS sporočil preko vgrajenega
izbirnika. Telefonska številka se samodejno prenese v izbirnik.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 94
Slika 4.16: Glasovni klic, pošiljanje SMS in MMS sporočil
Pri ENUM storitvi sip se lahko SIP klic vzpostavi le s pomočjo dodatno nameščenega
SIP odjemalca, ker operacijski sistem Android nima integriranega takšnega vmesnika. Zato
je za komunikacijo potrebno namestiti ustrezno dodatno aplikacijo. Na sliki 4.17 lahko
vidimo, kako nas operacijski sistem pred vzpostavitvijo SIP klica vpraša, s katerim
nameščenim odjemalcem želimo to storiti.
Slika 4.17: Izbira odjemalca za vzpostavitev SIP klica
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 95
Če imamo na operacijskem sistemu nameščenih več odjemalcev za elektronsko pošto
vključno z Googlovim računom in več internetnih brskalnikov, nas sistem prav tako
vpraša, s katerim odjemalcem ali brskalnikom želimo dejanje (pošiljanje elektronske pošte
ali obisk internetne strani) izvesti (slika 4.18).
Slika 4.18: Pošiljanje elektronske pošte in obisk spletne strani
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 96
5 SKLEP
S tem diplomskim delom smo predstavili uporabniški segment sistema ENUM -
Uporabniški ENUM. Zasnova, definicija in implementacija Uporabniškega ENUM sistema
v diplomskem delu temelji na obstoječih standardih izmenjave podatkov in hkrati ponuja
takšen poslovni model, ki omogoča nadzor in potrebno administracijo, hkrati pa zagotavlja
polno fleksibilnost, enostavno uporabo, široko dostopnost in varnost za končne
uporabnike.
Najprej smo podali teoretično ozadje posameznih orodij, tehnologij, sistemov in
komunikacijskih protokolov, ki smo jih potrebovali pri načrtovanju in razvoju
Uporabniškega ENUM sistema ter univerzalnega mobilnega komunikacijskega odjemalca.
Ob tem smo pregledali uveljavljene modele in pilotske projekte Uporabniških ENUM
sistemov v tujini ter obstoječe ENUM standarde. Nato smo opisali implementacijo
učinkovitega in preprosto razširljivega modela Uporabniškega ENUM sistema, izdelavo
spletne aplikacije za urejanje NAPTR zapisov in administracijo uporabnikov v sistemu, ter
izdelavo prototipa univerzalnega mobilnega komunikacijskega odjemalca. Podali smo tudi
eksperimentalne rezultate. S kombinacijo Uporabniškega ENUM sistema in univerzalnega
mobilnega komunikacijskega odjemalca smo rešili problem enolične določitve uporabnika
ne glede na uporabljeno tehnologijo komuniciranja. Unikatni ključ do uporabnika je
telefonska številka, na podlagi katere dobimo vse možne komunikacijske kanale do
uporabnika. Nato lahko z odjemalcem komunikacijo do njega tudi vzpostavimo.
Zanimiva informacija za uporabnika pri vzpostavitvi govornega klica z drugim
uporabnikom bi recimo še bila pri katerem operaterju se drug uporabnik nahaja, saj ima to
velik vpliv na ceno pogovora. To bi lahko bil naslednji korak za razširitev Uporabniškega
ENUM sistema. Omenjeno informacijo lahko Uporabniški ENUM sistem pridobi s
povezavo do Infrastrukturnega ENUM sistema ali neposredno s sistemom prenosljivosti
številk (angl. Number Portability System). Dodatna razširitev univerzalnega mobilnega
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 97
komunikacijskega odjemalca pa bi lahko bila integracija v Android operacijski sistem v
smislu avtomatizirane ENUM DNS poizvedbe ob poskusu vzpostavitve govornega ali
video klica iz imenika. V trenutni izvedbi aplikacije lahko uporabnik to stori le ročno z
vpisom telefonske številke v mobilno aplikacijo.
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 98
6 LITERATURA IN VIRI
[1] Preslikava telefonskih številk. Dostopno: http://en.wikipedia.org/wiki/Telephone_number_mapping (obiskano: februar 2011)
[2] ENUM – Most med telefonijo in internetom. Dostopno: http://archive.eurescom.eu/message/messageSep2004/ENUM_The_bridge_between_telephony_and_Internet.asp (obiskano: februar 2011)
[3] ENUM. Dostopno: http://www.ietf.org/rfc/rfc3761.txt (obiskano: februar 2011)
[4] Registrirane ENUM storitve. Dostopno: http://www.iana.org/assignments/enum-services/enum-services.xml (obiskano: februar 2011)
[5] DNS sistem/strežnik. Dostopno: http://en.wikipedia.org/wiki/Domain_Name_System (obiskano: februar 2011)
[6] Kaj je BIND? Dostopno: http://www.isc.org/software/bind/whatis (obiskano: februar 2011)
[7] BIND9. Dostopno: http://www.bind9.net (obiskano: februar 2011)
[8] dnsjava orodje. Dostopno: http://www.xbill.org/dnsjava (obiskano: februar 2011)
[9] Zgodovina Jave. Dostopno: http://en.wikipedia.org/wiki/Java_version_history (obiskano: februar 2011)
[10] Java EE 5. Dostopno: http://download.oracle.com/javaee/5/tutorial/doc/index.html (obiskano: marec 2011)
[11] Mike Keith, Merrick Schincariol, Pro JPA 2: Mastering the Java Persistence API. Apress, 2009
[12] James L. Weaver, Kevin Mukhar, Jim Crume, Chris Zelenak, Beginning Java EE
5: From Novice to Professional. Apress, 2005
[13] Zgodovina Eclipse SDK. Dostopno: http://en.wikipedia.org/wiki/Eclipse_(software) (obiskano: marec 2011)
[14] Eclipse SDK. Dostopno: http://help.eclipse.org/helios/index.jsp (obiskano: marec 2011)
[15] Android OS. Dostopno: http://en.wikipedia.org/wiki/Android_(operating_system) (obiskano: marec 2011)
[16] Kaj je Android? Dostopno: http://developer.android.com/guide/basics/what-is-android.html (obiskano: marec 2011)
[17] Razhroščevalno orodje DDMS. Dostopno: http://developer.android.com/guide/developing/debugging/ddms.html (obiskano: marec 2011)
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 99
[18] Korporacija Oracle. Dostopno: http://en.wikipedia.org/wiki/Oracle_Corporation (obiskano: marec 2011)
[19] Oracle SQL Developer. Dostopno: http://www.oracle.com/technetwork/developer-tools/sql-developer/learnmore/index.html (obiskano: marec 2011)
[20] Podatkovne baze. Dostopno: http://wwwlovre.appspot.com/resources/material/students/courses/scripts/laboratory_practice.pdf (obiskano: marec 2011)
[21] Koncepti Oracle podatkovne baze. Dostopno: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm (obiskano: marec 2011)
[22] Oracle prožilci. Dostopno: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/triggers.htm (obiskano: marec 2011)
[23] JBoss AS 5 arhitektura. Dostopno: http://docs.jboss.org/jbossas/docs/Administration_And_Configuration_Guide/5/html_single/index.html#JBoss_AS5_Architecture (obiskano: marec 2011)
[24] Funkcije JBoss AS 5. Dostopno: http://www.ibm.com/developerworks/websphere/library/techarticles/0910_jain/0910_jain.html (obiskano: marec 2011)
[25] Avtentikacija z vnosno formo. Dostopno: http://download.oracle.com/javaee/1.4/tutorial/doc/Security5.html (obiskano: april 2011)
[26] Java EE avtentikacija z vnosno formo. Dostopno: http://onjava.com/pub/a/onjava/2002/06/12/form.html (obiskano: april 2011)
[27] Definiranje varnostnih zahtev v spletnih aplikacijah. Dostopno: http://download.oracle.com/javaee/5/tutorial/doc/bncbe.html (obiskano: april 2011)
[28] Luka Pavlič, Poenostavitve Java EE, Inštitut za informatiko, FERI, Univerza v Mariboru, 2007. Dostopno: http://164.8.251.136:8080/lp/pages/sl/publics/ots07/ots07.pdf (obiskano: junij 2011)
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 100
7 PRILOGE
7.1 Seznam slik
Slika 1.1: Primer uporabe Uporabniškega ENUM sistema ................................................... 2
Slika 2.1: Primer DNS drevesa .............................................................................................. 7
Slika 2.2: Primer pretvorbe E.164 telefonske številke v ENUM domeno ............................. 8
Slika 2.3: Hierarhija ENUM domenskega prostora, razdeljena na domene in pod domene . 8
Slika 2.4: Tabela ENUM storitev, ki so registrirane pri IANA ........................................... 10
Slika 2.5: Večnivojske aplikacije (nivoji in komponente) .................................................. 15
Slika 2.6: Arhitektura aplikacije Eclipse SDK .................................................................... 17
Slika 2.7: Diagram glavnih komponent operacijskega sistema Android............................ 20
Slika 2.8: Primer Android emulatorja za operacijski sistem Android 2.1 (Eclair) .............. 23
Slika 2.9: Projekti skupnosti JBoss.org, JBoss AS 5 s komponentami ............................... 25
Slika 2.10: Primer procesa z dvema nitima, ki se izvajata hkrati ........................................ 31
Slika 2.11: Primer proženja prožilcev pri izvajanju DML stavkov nad tabelo ................... 36
Slika 2.12: Primer urejanja sekvence z orodjem Oracle SQL Developer ........................... 37
Slika 2.13: Podatkovna in indeksna datoteka ter iskalni ključ ............................................ 38
Slika 3.1: Uporabniški ENUM vključno z odjemalci .......................................................... 41
Slika 3.2: Primer tekstovne datoteke z območji oziroma conami ....................................... 47
Slika 3.3: Tabele, sekvence, prožilci in PL/SQL shranjene procedure ............................... 47
Slika 3.4: Tabele z vsemi polji, tipi polj, indeksi in medsebojnimi relacijami ................... 49
Slika 3.5: Struktura arhiva »uenum.ear« ............................................................................. 60
Slika 3.6: Uporabljene Java EE komponente ...................................................................... 61
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 101
Slika 3.7: Primer poimenovanih poizvedovalnih stavkov ................................................... 63
Slika 3.8: Primer uporabe poimenovanega poizvedovalnega stavka .................................. 63
Slika 3.9: Primer uporabe osnovnih CRUD metod ............................................................. 63
Slika 3.10: Povezava med trajnim kontekstom in entitetnim upravljalcem ........................ 64
Slika 3.11: Notacije ob razredu - entiteti ............................................................................. 65
Slika 3.12: Notacije ob metodah za primarni ključ ............................................................. 65
Slika 3.13: Nastavitev atributa za opravljanje s transakcijo nad razredom ......................... 66
Slika 3.14: Povezava na sejno zrno v servletu..................................................................... 67
Slika 3.15: Iskanje zrna po kontekstu .................................................................................. 67
Slika 3.16: Nastavitev JDBC podatkovnega vira ................................................................ 68
Slika 3.17: Možni vrhnji elementi sheme podatkovnega vira ............................................. 69
Slika 3.18: Nastavitev enote trajnosti v datoteki »persistence.xml« ................................... 70
Slika 3.19: Avtentikacija z vnosno formo (angl. form-based authentication) ..................... 71
Slika 3.20: Nastavitev aplikacijske politike na strežniški strani ......................................... 72
Slika 3.21: Povezava varnostne domene z aplikacijsko politiko ......................................... 72
Slika 3.22: Primer programske avtorizacije vsebine ........................................................... 73
Slika 3.23: Nastavitve varnostnih omejitev, varnostnih vlog in prijavnih nastavitev ......... 74
Slika 3.24: Drevesna struktura Android projekta ................................................................ 75
Slika 3.25: Datoteka AndroidManifest.xml ......................................................................... 76
Slika 4.1: Spletna aplikacija Uporabniškega ENUM sistema ............................................. 79
Slika 4.2: Primer testne ENUM DNS poizvedbe iz spletne aplikacije ................................ 80
Slika 4.3: Primer testne ENUM DNS poizvedbe iz Linux ukazne vrstice .......................... 80
Slika 4.4: Postopek preverjanja uporabnika ........................................................................ 82
Slika 4.5: Zahtevek za registracijo novega uporabnika in obvestilo po oddaji le-tega ....... 83
Slika 4.6: Potrjevanje registracijskih zahtevkov s strani administratorja ............................ 83
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 102
Slika 4.7: Vnosna forma za dodajanje NAPTR zapisov ...................................................... 86
Slika 4.8: Vnosna forma za urejanje NAPTR zapisov ........................................................ 87
Slika 4.9: Vnosni formi za spremembo naslova elektronske pošte in prijavnega gesla ...... 87
Slika 4.10: Vnosna forma za zahtevek po novem prijavnem geslu ..................................... 88
Slika 4.11: Spletna forma za upravljanje z uporabniki ........................................................ 90
Slika 4.12: Spletna forma za potrjevanje in brisanje registracijskih zahtevkov .................. 90
Slika 4.13: Informativni statistični podatki za administratorja............................................ 91
Slika 4.14: Nastavitve parametrov ENUM DNS poizvedbe ............................................... 92
Slika 4.15: ENUM DNS poizvedbe ..................................................................................... 93
Slika 4.16: Glasovni klic, pošiljanje SMS in MMS sporočil............................................... 94
Slika 4.17: Izbira odjemalca za vzpostavitev SIP klica ....................................................... 94
Slika 4.18: Pošiljanje elektronske pošte in obisk spletne strani .......................................... 95
7.2 Seznam preglednic
Tabela 2.1: Parametri NAPTR zapisa ................................................................................... 9
Tabela 3.1: Rezultat shranjene strežniške procedure DNS_LOOKUP ............................... 51
Tabela 3.2: Definicija kod rezultata DNS poizvedbe .......................................................... 56
Tabela 3.3: Kode napak v HTTP odgovoru ......................................................................... 58
Tabela 4.1: Izmerjeni časi trajanja poizvedb za različna orodja in povprečni časi ............. 81
7.3 Naslov študenta
Damjan Kojc
Trčova 239, 2229 Malečnik
Slovenija
Tel.: +38651690074
Elektronska pošta: [email protected]
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 103
7.4 Kratek življenjepis
Rojen: 27.05.1981 v Mariboru
Šolanje: 1988-1996 Osnovna šola Angela Besednjaka, Maribor
1996-2000 Srednja elektro - računalniška šola (računalniški tehnik), Maribor
2000-2011 Fakulteta za elektrotehniko, računalništvo in informatiko (Univerzitetni študijski program Elektrotehnika - Elektronika), Maribor
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 104
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 105
Univerzalni komunikacijski odjemalec s podporo za Uporabniški ENUM Stran 106