UNI Kojc Damjan 1981 - CORE · inovacijski ekonomiji. S tem diplomskim delom bi radi predstavili...

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

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


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


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.


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


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


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:


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


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


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


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


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č.


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


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


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.


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.


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.


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.


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


š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


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


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


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


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,


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.


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


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


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


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,


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.


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.


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.


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,


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.


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


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).


• 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].


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


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


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.


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.


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,


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,


• 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


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


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


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


č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


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,


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


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


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


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


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


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.


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


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.


Č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


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!


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,


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


»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


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.


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


»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.


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


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


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


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 .


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.


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).


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-


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


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


Slika 3.23: Nastavitve varnostnih omejitev, varnostnih vlog in prijavnih nastavitev


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.


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


»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.


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.


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.


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


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.


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,


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


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


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).


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«.


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


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


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.


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


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


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


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.


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


Č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


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


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.


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)


[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)


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


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


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]


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

UNI Kojc Damjan 1981 - CORE · inovacijski ekonomiji. S tem diplomskim delom bi radi predstavili...

Documents

Transcript of UNI Kojc Damjan 1981 - CORE · inovacijski ekonomiji. S tem diplomskim delom bi radi predstavili...