analiza oracle portala in razvoj spletne aplikacije …

Evgen Meklav

ANALIZA ORACLE PORTALA IN RAZVOJ

SPLETNE APLIKACIJE NA OSNOVI

ADF KOMPONENT

Diplomsko delo

Maribor, julij 2009

I

Diplomsko delo univerzitetnega študijskega programa

ANALIZA ORACLE PORTALA IN RAZVOJ SPLETNE APLIKACIJE NA

OSNOVI ADF KOMPONENT

Študent: Evgen Meklav

Študijski program: UN Računalništvo in informatika

Smer: Informatika

Mentor: izred. prof. dr. Branko Matjaž Jurič

Somentor: doc. dr. Boštjan Brumen

Lektorica: Pavla Premoša

Maribor, julij 2009

UNIVERZA V MARIBORU

__________________________________________________

II

(ime fakultete oz. visoke strokovne šole)

Številka: _________________

Datum: __________________

SKLEP O DIPLOMSKEM DELU

1. ________________________________, študent-ka univerzitetnega (visokošolskega strokovnega) študija ________________________________, izpolnjuje pogoje, zato se mu dovoljuje izdelati diplomsko delo.

2. Tema diplomskega dela je s področja katedre/oddelka/inštituta __________________________________________________________________________, pri predmetu ____________________________________. Mentor-ica: ____________________________

Somentor-ica: __________________________

3. Naslov diplomskega dela: ________________________________________________ _____________________________________________________________________

4. Vsebina diplomskega dela: _______________________________________________ _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5. Diplomsko delo je potrebno izdelati skladno z »Navodili za izdelavo diplomskega dela« in ga oddati v ____ izvodih do _____________ v referatu za študentske zadeve.

Predstojnik katedre/oddelka/inštituta:

________________________

Mentor:

_______________________

Dekan-ica:

______________________

III

ZAHVALA

Zahvaljujem se mentorju, za pomoč in vodenje

pri opravljanju diplomskega dela. Hvala tudi

Pavli za nesebično pomoč pri lektoriranju in

podpori pri delu.

Posebej se zahvaljujem mami in babici, ki so mi

omogočili študij.

IV

ANALIZA ORACLE PORTALA IN RAZVOJ SPLETNE

APLIKACIJE NA OSNOVI ADF KOMPONENT

Ključne besede: Portal, ADF, Oracle

UDK: 004.774:004.777(043.2)

Povzetek

V diplomski nalogi smo identificirali in analizirali lastnosti portalov. Proučili smo

standarde in specifikacije za razvoj portalov na platformi Java EE. V teoretičnem delu

smo se natančneje seznanili, proučili in analizirali Oracle Portal in Oracle ADF

komponente. Teoretska znanja smo v praktičnem delu nadgradili s poskusom razviti

praktično aplikacijo – spletno aplikacijo z uporabo ADF komponent in Oracle Portal-a.

Praktično aplikacijo smo zgradili z uporabo ADF komponent. Zajemala je izgradnjo

poslovne logike, izgradnjo uporabniškega vmesnika, vgradnjo zaščite v aplikacijo in

spletne storitve, ki je kreirala PDF dokument. Že zgrajeno spletno aplikacijo smo

vgradili v Oracle Portal, ki predstavlja celovito in logično povezano strukturo za

razvijanje, razvoj in upravljanje portalov. Iz spletne aplikacije v praktičnem delu smo

razvili portlet, ki je z uporabo koncepta SOA arhitekture (WSRP tehnologije)

prikazoval aplikacijo na ločenem aplikacijskem strežniku in v Oracle Portal-u.

V

ANALYSIS OF ORACLE PORTAL AND DEVELOPMENT WEB

APPLICATION BASED ON ADF COMPONENTS

Key words: Portals, ADF, Oracle

UDK: 004.774:004.777(043.2)

Abstract

In the Thesis we identified and analyzed the characteristics of portals. We examined the

standards and specifications for the portal development on the Java EE platform. In

theoretical work we have specifically acquainted, studied and analyzed Oracle Portal

and Oracle ADF components. We extended theoretical knowledge in practical work

section with the experiment to develop a practical application - Web application using

the ADF components and Oracle Portal.

Practical application was built using the ADF components. It included building of

business logic, user interface, application security and Web services, which generated

PDF document. Already built web application we have included into Oracle Portal,

which presents a comprehensive and logical structure for the development of integrated

development and management portals. In practical work we have deveoloped web

application into Portlet, which is using the concept of SOA architecture (WSRP

technology) where application is run on a separate application server and on the Oracle

Portal.

VI

VSEBINA

SKLEP O DIPLOMSKEM DELU .............................................................. II

1 UVOD ............................................................................................................................ 1

1.1 PREDSTAVITEV PROBLEMA ............................................................................. 1

1.2 NAMEN, CILJI DIPLOMSKEGA DELA .............................................................. 1

1.3 METODE RAZISKOVANJA ................................................................................. 1

2 SPLOŠNO O PORTALU ............................................................................................. 3

2.1 VRSTE PORTALOV .............................................................................................. 4

2.2 ZGRADBA PORTALA .......................................................................................... 9

2.3 LASTNOSTI PORTALA ...................................................................................... 11

2.4 PREDNOSTI PORTALA ...................................................................................... 14

2.5 CRM ..................................................................................................................... 15

2.6 CMS ....................................................................................................................... 17

3 ORACLE ADF KOMPONENTE ............................................................................. 22

3.1 ORACLE ADF ARHITEKTURA ......................................................................... 22

3.2 POSLOVNO STORITVENI NIVO (ANGL. BUSSINESS SERVICES) ............................ 23

3.2.1 ADF poslovne komponente (angl. ADF Business Components) .................... 23

3.3 MODEL (ANGL. MODEL) ......................................................................................... 26

3.3.1 ADF Model ..................................................................................................... 26

3.4 KONTROLNI NIVO (ANGL. CONTROLLER) .............................................................. 28

3.4.1 ADF kontroler (angl. ADF Controller) ......................................................... 28

3.5 POGLED (ANGL. VIEW) ........................................................................................... 28

3.5.1 ADF Faces ...................................................................................................... 29

3.5.2 ADF zaščita ................................................................................................... 31

3.5.3 Avtorizacija .................................................................................................... 32

3.5.4 Avtentifikacija ................................................................................................. 34

4 ORACLE PORTAL .................................................................................................. 36

4.1 PREDSTAVITEV ................................................................................................ 36

VII

4.2 ARHITEKTURA ORACLE PORTALA .............................................................. 37

4.2.1 WSRP ............................................................................................................. 39

4.2.2 Spletna storitev (angl. Web Services) ............................................................. 41

4.2.3 JSR 168 Container ........................................................................................ 42

4.3 ADMINISTRACIJA .............................................................................................. 44

4.3.1 Tipi uporabnikov ........................................................................................... 45

4.3.2 Skupine uporabnikov ...................................................................................... 46

4.4 PORTLETI ............................................................................................................ 48

4.5 ENKRATNA PRIJAVA ........................................................................................ 50

4.6 NAVIGACIJA ....................................................................................................... 52

4.7 RELACIJA MED ADF IN ORACLE PORTALOM ........................................... 52

5 PRAKTIČNI DEL ...................................................................................................... 54

5.1 ADF KOMPONENTE (SPECIFIKACIJA) .................................................................... 54

5.1.1 Diagram primera uporabe ............................................................................. 54

5.1.2 Opredelitev problema .................................................................................... 55

5.1.3 Opis tabel ....................................................................................................... 56

5.2 PRISTOP K RAZVOJU PRAKTIČNEGA DELA ............................................... 59

5.3 IZGRADNJA POSLOVNE LOGIKE ................................................................... 59

5.4 GRADNJA UPORABNIŠKEGA VMESNIKA .................................................... 61

5.4.1 Uporabniški vmesnik za urejanje vozil ........................................................... 64

5.4.2 Uporabniški vmesnik za urejanje vrste obračuna .......................................... 64

5.4.3 Uporabniški vmesnik za urejanje osebe ......................................................... 65

5.4.4 Uporabniški vmesnik za iskanje potnega naloga ........................................... 66

5.5 PROBLEMI PRI GRADNJI UPORABNIŠKEGA VMESNIKA ........................ 67

5.6 IZGRADNJA PDF DOKUMENTA ...................................................................... 67

5.7 VARNOST ADF APLIKACIJE ............................................................................ 71

5.8 PORTLETIZACIJA ADF APLIKACIJE PREKO WSRP PROTOKOLA .......... 74

5.9 ANALIZA ORACLE PORTALA ......................................................................... 76

5.10 REGISTRACIJA WSRP PORTLETA ................................................................ 79

5.11 SKLEP ................................................................................................................. 80

6 ZAKLJUČEK ............................................................................................................. 82

VIII

7 VIRI, LITERATURA ................................................................................................. 84

8 PRILOGE .................................................................................................................... 88

8.1 SEZNAM SLIK ..................................................................................................... 88

8.2 SEZNAM PREGLEDNIC IN KOD ........................................................................................ 89

8.3 NASLOV ŠTUDENTA ..................................................................................................... 90

8.4 KRATEK ŽIVLJENJEPIS .................................................................................................. 90

Analiza Oracle portala in razvoj spletne aplikacije na osnovi ADF komponent Stran 1

1 UVOD

1.1 PREDSTAVITEV PROBLEMA

Živimo v dobi, v kateri se nenehno srečujemo z informacijami. Do njih dostopamo z

različnimi mediji, zlasti internetom za lažji pregled informacij. Najprej so se razvili spletni

imeniki, ki so nudili lažji pregled informacij. V njih so avtorji spletnih strani vnašali

najnujnejše podatke o svoji spletni strani (naziv, naslov in kratek opis). Kasneje so spletni

imeniki prerasli v spletne iskalnike, ki so že vsebovali algoritme za samodejno iskanje

spletnih vsebin. Taki iskalniki so kmalu postali preobsežni in nepregledni pri posredovanju

informacij, saj je bilo informacije čedalje težje najti. Razvil se je nov sistem obvladovanja

podatkov, t.i. spletni portali (kasneje samo portali).

Bistvo portalov je prav efektivno zbiranje in distribucija informacij. Običajni dostop

do podatkov je zakodiran v portalski kodi, kar poveča stroške razvijanja in vzdrževanja ter

zmanjša uporabnost rešitev. Oracle pa je razvil rešitev, ki nudi poenoten dostop do

različnih virov podatkov in jih prikazuje na enostaven in organiziran način. Oracle Portal

predstavlja portal, kot vir vseh potrebnih informacij znotraj organizacije in tako z njihovo

centralizacijo poveča preglednost podatkov.

1.2 NAMEN, CILJI DIPLOMSKEGA DELA

Identificirati in analizirati lastnosti portalov.

Proučiti standarde in specifikacije za razvoj portalov na platformi Java EE.

Podrobno se seznaniti z Oracle Portalom.

Proučiti in analizirati ADF.

Razviti praktično aplikacijo – aplikacijo z uporabo ADF in Oracle Portala.

1.3 METODE RAZISKOVANJA

Diplomska naloga je razdeljena na dva dela, teoretični in praktični del.


V teoretičnem delu bomo podali splošni pregled spoznanj in teorije, in sicer bomo

uporabili deskriptivno metodo podajanja teorije.

Najprej se bomo osredotočili na portale v splošnem pogledu. Poskusili bomo

definirati portale; kaj so in kdaj so začeli dobivati tako pomembno vlogo. Predstavili bomo

razloge, na podlagi katerih se podjetja odločajo za izgradnjo portalov in osvetlili njihove

prednosti. Skušali bomo podati nazorno razdelitev portalov glede na vrste, čeprav je portal

dejansko hibridne narave in ga zato težko uvrstimo v eno samo vrsto [34]. Nato bomo

opisali zgradbo portala iz logičnega vidika, t.j. modulov, ki sestavljajo portal, in iz

uporabniškega vidika, torej kot ga vidi uporabnik. Sledil bo opis lastnosti oziroma

funkcionalnosti, ki jih portal omogoča uporabniku. V tretjem poglavju bomo podrobneje

predstavili ADF komponente. V četrtem poglavju bomo spoznali Oracle portal (kaj je, opis

arhitekture, administracijo, enkratno prijavo in navigacijo).

Praktičnega dela naloge se bomo lotili z empirično metodo. Zgradili bomo

aplikacijo z uporabo ADF komponent. Znotraj ADF aplikacije bomo definirali in uporabili

spletno storitev. Nato bomo iz spletne aplikacije naredili portlet ter preko WSRP protokola

poskušali prikazati na Oracle portalu.


2 SPLOŠNO O PORTALU

Začetki portalov segajo v pozna 90-a leta prejšnjega stoletja. Sama beseda „portal“ v

SSKJ-ju (Slovarju slovenskega knjižnega jezika) pomeni arhitekturno poudarjen vhod v

stavbo (ponavadi je predstavljal vhod v kakšno katedralo). Druga razlaga besede portal je,

da izvira iz latinščine in pomeni glavni vhod ali vrata.

Prva znana, bolj strokovna, definicija portala sega v leto 1998, ko sta Shilakes in

Tyleman iz podjetja Merill Lynch definirala poslovni portal takole: „Informacijski portal

je programska rešitev, ki omogoča podjetju, da ponudi notranje in zunanje informacije

uporabnikom in nudi uporabnikom enotno pot do informacij, ki jih potrebujejo za

oblikovanje poslovnih odločitev.“[6]. Portali so informacijska središča, ki spletnim

uporabnikom ponujajo različne informacije, aplikacije in informacijske storitve. V tej

množici podatkov se uporabnik vedno težje znajde, zato narašča trend izgradnje portalov,

ki uporabnikom ne le ponujajo kopice podatkov, ampak mu omogočajo zlasti njihovo

personalizacijo.

Portal lahko v grobem definiramo kot okno, ki omogoča transparenten dostop do

informacijskih objektov, generiranih z raznimi aplikacijami in analitičnimi orodji za

izdelovanje predefiniranih poročil in generiranje novih. Ali povedano enostavneje: portal

je točka na spletišču, ki nam nudi ogromne količine podatkov oziroma storitev. Vendar je,

tako kot ostale stvari v našem okolju, šel tudi portal skozi nekatere ključne faze razvoja; od

imenikov in iskalnikov do portalov, kot jih poznamo danes, ki omogočajo proces

prilagajanja uporabniku oziroma sistem personalizacije. To pomeni, da uporabnik ob

registraciji v poljuben portal vnese osebne podatke in osebna zanimanja. Na podlagi

vnešenih atributov sistem zgradi za vsakega uporabnika poseben profil, ki najbolje odseva

njegove interese. Na podlagi tega profila portal razvršča uporabnike po skupinah in vrši

selekcijo zanimivih in želenih informacij ob vsakokratni prijavi v sistem oziroma njegovi

uporabi. Pri tem ima pomembno vlogo tudi vsebina portala, njeno vsakodnevno

spreminjanje, izgled in hitrost nalaganja posamezne strani. To so bistvene stvari, ki

omogočajo obdržati ali na novo privabiti uporabnika. Uporabniki se načeloma ne odločajo

za velike migracije iz enega portala na drugega, saj to s sabo potegne tudi novo

prilagajanje. Vendar se to dogaja, kadar uporabnik sam oceni, da kvaliteta vsebine ne

zadošča več njegovim interesom. Da bi se portali še bolj približali uporabnikom, so


kasneje dodajali na portale razne ankete in forume, s pomočjo katerih so dobili povratne

informacije, o tem, kaj si uporabniki želijo. Velikokrat lahko zasledimo na portalu razne

aktualne dnevne novice, kot so vreme, nagradne igre, ipd. Pomembno je, da uporabnik

lahko dostopa do portalnih vsebin z različno strojno opremo, kot so brskalniki preko

osebnih računalnikov ali WAP sistemov na telefonih ter z drugimi napravami za

komuniciranje s portali.

Bistvena razlika, ki je nastala med navadno spletno stranjo in portalom, je, da je portal

dinamična stran, ki ima zagotovljeno vsakodnevno ažuriranje in le-to lahko izvaja tudi

uporabnik, ki nima posebnega ali prav nobenega znanja o programiranju, saj mu že sama

tehnologija - portal omogoča preprosto dodajanje in urejanje besedila. Omogoča nam

sistem sledenja aktivnosti uporabnika. Na ta način izdeluje vzorce obnašanja in

samodejnega prilagajanja vsebin njegovim potrebam. Ena ključnih razlik pa je sistem

personalizacije oziroma zmožnost osebnega prilagajanja delovnega okolja z uporabo

filtriranja informacij, naročanja nanje in na informacijske storitve. Po drugi strani navadne

spletne strani niso tako enostavne za delo iz več razlogov. Prvi razlog je sprememba

vsebin. Uporabniki, ki želijo spreminjati vsebino strani, morajo poznati spletni jezik, s

katerim je bila izdelana spletna stran. Drugi razlog se nahaja v samem spreminjanju

vsebine, ki je precej zamudno in nepraktično, posledično tudi precej drago. Ponavadi je

namreč potrebno, da sta na razpolago najmanj dva uporabnika (urednik in programer).

Tudi oblikovanje navadne spletne strani ni preprosto, saj ne podpira konstantnih izgledov

(„angl. look and feelov“) in nobenih vnaprej narejenih predlog („angl. templatov“).

Elementi, ki so skupni skoraj vsem portalom in jih mora portal vsebovati, so skupna

vstopna točka oziroma nek uporabniški vmesnik, integracija najrazličnejših informacij,

zagotavljanje sistema personalizacije, podpora različnim storitvam in prilagajanje prikaza

vsebine za različne prejemnike (RSS, WAP, ...).

2.1 VRSTE PORTALOV

Zaradi vsesplošne uporabe portalov, ki ponujajo raznolike informacije, je težko

določiti mejnike, kam kateri spadajo. Ne glede na to obstajajo značilnosti, ki so skupne

skoraj vsem vrstam portalov in ki predstavljajo potrebne pogoje, da lahko neko spletno

stran imenujemo portal.


Portale, ki jih bomo opisali v nadaljevanju, lahko delimo na osebne, javne in

poslovne portale [33, 37]. Lahko jih delimo tudi glede na „širino“ publike, ki ji je portal

namenjen (vertikalni in horizontalni) [32]. Poskušali bomo zajeti obe delitvi hkrati.

Javni portali so velika spletna mesta, ki uporabnikom ponujajo širok spekter vsebin.

Sem sodijo portali velikih podjetij kot so Yahoo, Altavista in MSN. Primer

javnega portala prikazuje slika 1, in sicer portal MSN. Namenjeni so zelo

širokemu spektru uporabnikov, ki jih združujejo skupni interesi (izbrana tematika,

skupni poklic). Javni portali nudijo velike količine smiselno urejenih podatkov in

informacijskih storitev. Svoje storitve ponujajo preko imeniških struktur. Pri teh

vrstah portalov avtorizacija ni nujna. Potrebna je le, kadar želimo dostopati do

vseh vsebin in storitev, ki jih portal nudi. Zagotavljajo torej tudi personalizacijo

podatkov. Delimo jih na:

Slika 1: Javni portal msn

- splošno javne portale, beležijo največje število obiskov na dan (mesečno

približno 10 milijonov obiskovalcev). So nasledniki internetnih iskalnikov,

ki so svojo dejavnost razvili v portale, iskalnike pa ohranili kot del portala.

Njihova vsebina pokriva zelo splošno področje, saj gre za razgledane

uporabnike (yahoo.com, altavista.com, msn.com ...).


- industrijske portale, ki so vezani na neko določeno skupino ljudi, s

skupnimi poslovnimi interesi. Zajema tisti segment ljudi, ki želi med sabo

poslovati, si izmenjavati podatke in nastopati na tržišču kot predstavniki

določene stroke. Primeri takšnih portalov so npr. portali s ponudbo

proizvajalcev avtomobilov in ponudnikov sestavnih delov.

- bloge ali spletnike, ki predstavljajo nov trend javnih portalov. So nekakšni

spletni dnevniki, ki jih ustvarjajo uredniki, za katere ni nujno, da obvladajo

kakšen programski jezik. Vsebina je poljubna in zato tudi precej raznolika,

saj odseva urednikove interese, izobrazbo, zanimanja, nazore. Pri klasičnih

forumih lahko objavi novico vsak uporabnik. Uporabniki so si enakovredni.

Pri blogih dodaja novice na portal samo urednik, komentirajo jih lahko vsi

uporabniki, v kolikor urednik to dopušča. Pomemben del bloga je RSS, ki

ni nujno vezan samo na blog, ampak se lahko pojavi tudi pri ostalih vrstah

portalov, omogoča pa nam prebiranje novic brez obiska samega portala.

Osebni portali so portali, ki vsakemu uporabniku posebej omogočajo, da definira

svoje delovno okolje („angl. Workplace“ vsebino, oblike, informacijske vire in

storitve), ki ga želi uporabljati. Poleg klasičnega dostopa do informacij in

informacijskih sistemov, lahko do vsebin dostopamo tudi z dlančniki in mobilnimi

telefoni. Poznamo dve podskupini:

- mobilni portali, ki so namenjeni tistim uporabnikom, ki si želijo hiter

dostop do informacij o različnih stanjih (stanje na cesti, cene, statusi naročil

in plačil). Do njih lahko dostopajo s pomočjo dlančnikov in mobilnih

telefonov.

- portali v različnih napravah, so portali, ki jih največkrat zasledimo v

televizorjih (v raznih hotelih) in v avtomobilih (prikažejo pozicijo, vreme,

stanje na cestah ...).

Poslovni portali so interna vstopna točka v podjetju. Služijo upravljanju z znanjem,

komunikaciji z dobavitelji in strankami. Namenjeni so ožjemu krogu ljudi,

največkrat samo strankam, poslovnim partnerjem in zaposlenim. Slednji na tem


mestu dobijo vse potrebne informacije o poslovnih procesih, ki se odvijajo znotraj

podjetja. Služijo tudi podpori raznih vnaprej določenih ciljev (npr. vzpostavitev

centra za samopodporo strank). Primer poslovnega portala prikazuje slika 2.

Slika 2: Primer poslovnega portala enaa.com

Poznamo več vrst poslovnih portalov [37]:

portali za odločanje (angl. Decision Portals), ki imajo enotno vstopno

točko, ki ima dostop do vseh informacij, potrebnih za odločanje. Namenjeni

so predvsem vodstvenim delavcem in drugim zaposlenim. V ta namen

uporabljajo in združujejo informacije iz različnih analitskih virov. Mnoga

podjetja imajo veliko število implementiranih sistemov za poročanje. Med

njimi je zelo pogost sistem OLAP, ki izdeluje različna poročila.

dokumentni portali (angl. Publishing Portals), ki so orientirani na reševanje

problemov z veliko količino dokumentov (kot npr. opisov produktov,

poročila o raziskavah ...), ki jih podjetje objavlja na internetnih straneh.

Poudarek je predvsem na kategorizaciji, iskanju in personalizaciji.


portali za skupinsko delo (angl. Collaborative Portals), temeljijo predvsem

na zagotavljanju interakcije med zaposlenimi, strankami in poslovnimi

partnerji. Lahko so del sistema za upravljanje odnosov med zaposlenimi v

podjetju in strankami. Ti portali so sporočilno usmerjeni, poudarek imajo na

odzivanju uporabnikov in e-mail integraciji. Sem spadajo t.i. timski portali

(angl. Team Portals), ki podpirajo manjše delovne skupinice, vključujejo

interne in eksterne sodelavce. Običajno so vezani na izmenjavo informacij

(poročila o delu, vključevanje novih sodelavcev), ki jih uporabniki sami

objavljajo.

operativni portali (angl. Operational Portals), so predvsem portali, ki

ponujajo zaposlenim in poslovnim partnerjem prijazen in enostaven način

dostopa do vseh poslovnih aplikacij podjetja.

portali za e-poslovanje služijo trem poslovnim procesom (B2B, B2C, B2E).

B2B (angl. Business to Bussines); njihov namen je posredovati

poslovnim partnerjem informacije o ceni, količini in zalogi izdelkov,

na podlagi katerih se ti odločijo o nakupu. Njihov namen je privabiti

čim več partnerjev in dobaviteljev ter podpirati celotne procese in

poslovne aktivnosti za celo podjetje.

B2C (angl. Business to Consumer); njihova naloga je, da privabljajo

potencialne kupce v čim večji meri in jih poskušajo zadržati.

Izvajajo aktivnosti zaračunavanja, naročanja, ponujanja izdelkov in

podporo sistema med prodajalcem in stranko.

B2E (angl. Buisness to Employe); njihova naloga je povezovanje

med zaposlenimi, zagotavljanje poslovnih informacij oziroma

oskrbovanje zaposlenih s strukturiranimi in nestrukturiranimi

informacijami. Izboljšuje poslovna odločanja in poslovne procese.

EIP (angl. Enterprise Information Portals) oziroma podjetniški portali

predstavljajo vhodna vrata (na spletu) znotraj podjetja. V večini primerov

gre za privatne in varovane portale. Pomembna značilnost EIP portalov je,

da so prešli iz dokumentno orientiranega okolja v dinamični informacijski

model in so centralizirani ter omogočajo stranki ali uslužbencu enostaven


dostop do poročil, storitev in pravil, s katerimi podjetje razpolaga.

Usmerjeni so v poslovanje z vsemi oblikami, ki jih poznamo preko interneta

(B2B, B2C, B2E). Prilagojeni so za vsako podjetje posebej. Leta 1998 je

Merrill Lynch predvideval, da bo uporaba EIP sistemov kmalu prehitela

ERP market [5].

Osnovno delitev portalov povzemamo v tabelaričnem prikazu, kot jih prikazuje tabela 1.

Tabela 1: Tabelarični prikaz predstavljenih portalov

Vrste portalov

Javni Osebni Poslovni

1. splošno javni2. industrijski3. blogi

(1) mobilni(2) predstavitev v

različnih napravah

1. za odločanje(1) dokumentni(2) za skupinsko delo

(3) timski(4) operativni (5) za e-poslovanje

(6) B2B(7) B2C(8) B2E

(9) podjetniški

2.2 ZGRADBA PORTALA

Portal je zgrajen iz različnih komponent na različnih nivojih, kot prikazuje slika 3. Na

najnižjem nivoju je prikazan sloj že obstoječih in tehnološko zastarelih aplikacij z

neobstoječimi uporabniškimi vmesniki. Sledi sloj, ki je namenjen povezovanju med

obstoječimi aplikacijami, podatkovnimi bazami, imeniškimi strežniki, spletnimi storitvami

in sistemi za integracijo aplikacij. Višji nivo je namenjen funkcijskim komponentam, ki so

namenjene komunikaciji z uporabniškim vmesnikom, ki ga upravlja uporabnik. Zadnji

predstavitveni nivo je namenjen vsem napravam, ki znajo komunicirati in predstaviti

vsebino portala [34].


Slika 3: Prikaz logične zgradbe portala [34]

Uporabniški nivo portala pomeni tisti nivo, ki ga vidimo ob vstopu v nek portal. Slika 4

prikazuje primer portala mestne občine Maribor, ki ima elemente splošno javnega portala.

Na vrhu portala je glava portala, sledita ji navigacija in baner. Slednji ima poljubno sliko,

ki se navadno menjuje. Pod baner-jem na čisto levi strani je meni, ki nam omogoča izbor

želenih vsebin portala, ki ležijo v sredini. Pod menijem na levi strani so hitre povezave na

druge aktualne strani. Na desni strani portala, čisto zgoraj, je iskalnik, ki omogoča hitro

iskanje vsebin po portalu. Takoj spodaj je jezikovni meni, ki omogoča izbiro jezika

(angleški ali nemški), pod njim se nahajajo aktualni podatki. Čisto spodaj zaključuje portal

t.i. noga portala.


Slika 4: Primer portala mesta Maribor kot ga vidi uporabnik

(www.maribor.si)

2.3 LASTNOSTI PORTALA

Portalna struktura pomaga pri kreiranju, integriranju in upravljanju s podatkovno

vsebino. S pomočjo portala lahko vsebino poljubno prikazujemo, organiziramo in

oblikujemo v neko smiselno celoto, ki bo za uporabnika čimbolj razumljiva. Na ta način

povečamo učinkovitost iskanja informacij, prav tako pa administratorju olajšamo delo pri

pomoči uporabnikom.

Osnovne lastnosti portala so upravljanje z dokumenti, iskanje informacij, integracija

aplikacijskih storitev znotraj IS in z zunanjim IS, navzkrižno povezovanje vsebin in

storitev, omogočanje storitev sodelovanja, kategorizacija informacij, zagotavljanje

neodvisnosti podatkov od njihove predstavitve v različnih elektronskih medijih,

predstavitev informacij v več jezikih, avtentifikacija in avtorizacija dostopa do podatkov in

storitev ter zagotavljanje varnosti, personalizacija z vidika vsebin in vizualnega izgleda.

http://www.maribor.si/podrocje.aspx


Upravljanje z dokumenti

Portal omogoča nadzorovano spreminjanje želenih dokumentov in s tem zagotavlja, da ne

prihaja do izgubljanja ali podvajanja vsebin. Omogoča tako imenovan “ angl. check out“,

kar pomeni, da bo urednik oziroma uporabnik datoteko spreminjal, in “angl. check in“, kar

pomeni, da je končal s spreminjanjem in dodal datoteko nazaj. Beleži zgodovino

spreminjanja dokumenta tako, da lahko v vsakem trenutku izvemo, kdo in kdaj je

spreminjal dokument.

Iskanje informacij

Gre za kategorizacijo podatkov na podlagi ti. meta-podatkov. Iskalniki preiskujejo spletne

strani rekurzivno, po principu iz spletne strani izvlečenih naslovov. Vsaka raziskana stran

se indeksira. Če je potrebno primerno uteži, hkrati pa se analizira njena vsebina tako, da se

ustvarjajo meta-podatki. Drug način za ustvarjanje meta-podatkov je uporaba šifrantov, ki

podrobneje okarakterizirajo podatke.

Integracija aplikacijskih storitev in vsebin znotraj portala in z zunanjimi

informacijskimi sistemi

Portal je zasnovan po sistemu modularizacije. Imamo nek centralni modul, ki mu po

potrebi dodajamo nove module oziroma funkcionalnosti. Za dinamičnost portala je

potrebno zagotoviti čim večjo učinkovitost navigacije med ali nad moduli. Funkcionalnost

portala povečamo tako, da omogočimo povezavo zunanjih storitev s samo hierarhično

strukturo. Integracija med portali in storitvami portala je možna preko vmesnika, ki je

definiran na osnovi standardov XML, WSDL ... Komunikacija med storitvijo in portalom

poteka na osnovi protokolov SOAP, XML - HTTP in IIOP. Da bi uporabnik uporabljal

določeno storitev, ima zgrajen uporabniški vmesnik, ki skrije komunikacije, ki se odvijajo

v ozadju in opravi transformacijo v ciljni uporabniški vmesnik (HTML in WML).

Navzkrižno povezovanje vsebin in storitev [8]

Gre za povezovanje različnih vsebin in storitev na portalu. npr. predstavljamo turistično

kmetijo. Na ta opis se vežejo navzkrižni podatki o tem, koliko stanejo kosila, kakšna je

cena prenočišča, kakšne aktivnosti ponuja, kje se nahaja, ....


Omogočanje storitev sodelovanja

Pomeni sodelovanje, kjer se le-to zaračunava (npr. neko podjetje želi oglaševati na našem

portalu proti plačilu).

Kategorizacija informacij

Pri tem gre za smiselno urejanje podatkov in informacij po kategorijah (šport,

gospodarstvo, svet in Slovenija ...).

Zagotavljanje neodvisnosti podatkov od njihove predstavitve v različnih

elektronskih medijih

Uporabnik lahko dostopa do vsebine in funkcij portala ne glede na elektronski medij

(WAP telefoni, dlančniki, internet, informacijskih terminali in interaktivne televizije), ki ga

želi uporabiti. Portali morajo v ta namen vsebovati posebno večslojno arhitekturo, ki

temelji na izdelavi in transformaciji XML dokumentov.

Večslojna arhitektura je sestavljena iz:

• uporabniških vmesnikov za posamezne skupine elektronskih naprav in

medijev,

• transformacijskih adapterjev za posamezne skupine naprav in medijev in

• strežnika dokumentov.

Predstavitev informacij v več jezikih

Zaradi neomejenega dostopa je pomemben segment portala tudi internacionalizacijo.

Pomeni, da portal podpira poleg nacionalnega jezika (npr. slovenščine) še vsaj enega bolj

razširjenih jezikov (angleški, nemški, španski, francoski ali italijanski ...). Tako uporabniki

(tujci), ki se zanimajo za portal ali storitev, ki jo portal ponuja, lažje pridobivajo želene

informacije (Npr. rusko podjetje se zanima za poslovanje s slovenskim. Informacije o

dejavnosti, kontaktu lahko tako pridobi že na spletnem portalu v želenem jeziku ali jeziku,

ki mu je najbližji).

Avtorizacija in avtentifikacija

Primer avtorizacije prikazuje slika 5. Uporaba avtorizacije je enostavna, saj zahteva od nas

le uporabniško ime in geslo, ki smo ga predhodno dobili ob kreiranju računa. Poznamo tudi

način avtorizacije s pomočjo digitalnega certifikata, ki ga dobimo ob pravilni registraciji v

sistem. To se uporablja predvsem za HTTPS portale. Sama avtorizacija se izvrši le enkrat


in mora delovati za celotni čas uporabnikovega obiska. Namenjena je tudi preprečevanju

dostopa do vsebin portala uporabnikom, ki zato niso registrirani. [8]

Slika 5: Avtorizacija v sistem [8]

Personalizacija z vidika vsebine in vizualnega izgleda

Gre za proces, ki se izvrši v fazi avtentifikacije v sistem. Vsak uporabnik ima možnost, da

kreira svoj profil. To mu omogoča sistem portala v fazi kreiranja računa, kjer odgovarja na

razna vprašanja, na podlagi katerih se oblikuje njegov spekter zanimanj. Drugi način

personalizacije je avtomatičen. Sistem sam sledi uporabniku, njegovim klikom na želeno.

Na podlagi tega mu ustvari profil in ga avtomatsko razvrsti v neke kategorije s podobnimi

interesi. Tem kategorijam priredi informacije in pogled nanje. Določena obvestila lahko

uporabnik po predhodnem naročilu dobiva v svoj elektronski predal ali v obliki SMS ali

MMS sporočil. Druga obvestila portal sam pošilja naokoli, seveda glede na vlogo, ki jo

ima uporabnik v sistemu (npr. vodje programerjev želijo biti obveščeni o tem, kaj

posamezen programer dela) [8, 26] .

2.4 PREDNOSTI PORTALA

Težnja po izgradnji portalov v zadnjih letih zelo narašča. Portal prinaša nov način

komuniciranja, ki ima številne prednosti, tako za uporabnika kot za podjetje. Naštejmo

nekaj najbolj pomembnih [33]:

1. Je zanesljivo komunikacijsko sredstvo, ki nudi informacije tako zaposlenim, kot

strankam.


2. Omogoča podporo poslovanju preko interneta, kar je tako za poslovne partnerje kot

za navadne stranke zelo pregledno in udobno. Naročila lahko oddajo iz domačega

fotelja vsak dan ne glede na dneve in pozne ure.

3. Omogočajo neomejeno širjenje poslovanja in sklepanje partnerstev širom sveta.

4. Z informacijami, ki jih zbirajo o strankah, ponudniki izvajajo tržne analize in akcije,

kar jim omogoča konkurenčne prednosti.

5. Zaradi zelo strukturiranih informacij imajo uporabniki manj težav pri iskanju

koristnih informacij, ki jih lahko uporabijo tudi pri poslovnih priložnostih.

6. Zaradi poslovanja, ki se odvija preko interneta, je ponudniku omogočena izjemna

avtomatizacija poslov, kar ima za posledico nižje stroške poslovanja. Tako lahko

pridobi tudi stranka, saj ji ni potrebno plačevati raznih stroškov (administrativni

stroški, provizije), ki nastajajo pri navadnem poslovanju.

2.5 CRM

CRM je poslovna strategija podjetja, ki se v večini primerov uporablja znotraj portala.

CRM poslovni strategiji sledi tudi Oracle Portal, ki ga bomo podrobneje predstavili v po-

glavju 4. Kot prikazuje slika 6, CRM povezuje ljudi in tehnologijo z organizacijo z name-

nom, da bi s strankami ustvarili dolgoročne stike [12]. Podjetje, ki želi uspeti, mora pozna-

ti želje strank, njihove nakupovalne navade, demografske značilnosti, saj mora izbrati pravi

komunikacijski kanal za interakcijo z njimi. Ker je konkurenca oddaljena le nekaj klikov z

miško, morajo podjetja vložiti veliko truda v razvoj čvrstih odnosov z uporabniki in v ne-

govanje njihove lojalnosti. Osnovni namen CRM-ja je tako zagotoviti informacije oziroma

podatke o stranki v vsakem trenutku in na način, kot jih potrebujejo, da oblikujejo profil

posamezne stranke. Na ta način lahko podjetje poglobi odnos s stranko z dodajanjem udob-

nosti, prijetnosti, učinkovitosti, prihranka pri stroških in z obsežno paleto dodatnih storitev.

Vse te lastnosti omogoča portal, ki obenem služi tako podjetju kot stranki. Portal, grajen s

CRM poslovno strategijo, nudi podjetju enotno in stalno osveženo bazo podatkov, do kate-

rih se lahko dostopa mobilno od koderkoli. Standardizirane podatke je mogoče enostavno

izvoziti za druge namene (Access, Excel). Možno je določati nivoje dostopa in privilegije

posameznega uporabnika. Skratka, za podjetja je tak portal preprost za upravljanje s podat-

ki in omogoča velik pregled in nadzor nad poslovanjem.


Tudi za stranko je personaliziran portal zanimivejši. Vzame ji manj časa, da najde že-

leno in bolj se lahko posveti stvarem, ki jo zares zanimajo.

Slika 6: Primer CRM-ja v podjetju [12]

Upravljanje s strankami je sistem z arhitekturo, ki za celovit pogled na stranko zajema

tri vidike:

Operativni CRM, ki se nanaša na izvajanje postopkov, s katerimi se podjetje

povezuje s strankami, sprejema in posreduje naročila, opravlja transakcije in

strankam ponuja dodatne storitve in podporo. Značilno za to vrsto CRM-ja je

prenova avtomatizacije oziroma informatizacija poslovnih procesov na področjih,

ki vsakodnevno sodelujejo s strankami (prodaja in storitvene aktivnosti).

Vključujejo vzpostavitev klicnega centra in spletnega portala. Ključno za

opravljanje operativnega CRM-ja je vzpostavitev povezanosti vseh sistemov

znotraj podjetja. Operativni CRM torej ne izboljšuje direktne povezave odnosa do

strank, ampak je namenjen izboljšanju organiziranosti podjetja.

Organizacijski CRM omogoča stranki stik s podjetjem. Zagotavlja sodelovanje med

dobavitelji, partnerji in strankami, kar omogoča izboljšave postopkov in pripomore

k zadovoljevanju potreb strank. Vmesniki (elektronska pošta, konferenca, klepet

…) zagotavljajo interakcijo med organizacijo in strankami. Skrbijo za informacije

znotraj podjetja glede stvari, ki se zadevajo njihovih strank in aktivnosti. Te

informacije zna razširjati in jih deliti.


Analitični CRM, ki predstavlja aplikacije, ki podjetju omogočajo analizo podatkov

z namenom uspešnejšega komuniciranja s stranko in upravljanja poslovne

uspešnosti. Gre za analiziranje, modeliranje in ocenjevanje podatkov o strankah, ki

so v podatkovnih skladiščih ali podatkovnih zbirkah, z namenom ustvarjati

medsebojno koristne odnose. Sem spadajo sistemi za trženje in orodja za analizo

prodaje. Gre za glavnega uporabnika podatkov, ki jih zagotavlja operativni CRM.

Samo z analizo podatkov o strankah lahko podjetje bolje razume vzorce obnašanja,

trende, ki se pojavljajo in lahko izpelje vzročne povezave, kar pomaga napovedati

obnašanje in zadovoljstvo strank, ki je ključnega pomena za uspeh. Analiza je za

uspeh CRM-ja najbolj kritična.

2.6 CMS

Portali lahko za upravljanje s spletno vsebino v portalu uporabljajo CMS sistemov, ki

jih prikazujemo na sliki 7. CMS temelji na dinamični strežniški tehnologiji PHP-ja, v

povezavi s podatkovno bazo (najpogosteje MySQL). Eden večjih CMS sistemov je Oracle

Portal. CMS omogoča hitro, enostavno (ne zahteva posebnega predznanja zahtevnih

programskih jezikov) urejanje (dodajanje in spreminjanje preprostega besedila, slik in

dokumentov) spletne vsebine preko vmesnika, ki ga podpirajo spletni brskalniki (med

njimi najpogosteje Firefox in Internet Explorer). Prav tako vsebuje avtomatsko kreiranje

vsebine za spletne iskalnike, oddaljen dostop do urejevalnika iz katerega koli računalnika z

internetno povezavo, dodajanje in urejanje CSS funkcij, HTML funkcij, kodnih vstavkov

(BLOB), uporabnikov in novic. Poleg tega, da je CMS namenjen avtomatizaciji spletnih

vsebin, je uporaben tudi na drugih področjih kot so: multimedija, tiskani mediji, saj je prav

tako primerna za upravljanje s katalogi, časopisi, CDROM-i ali knjigami.


Slika 7: Primer vnosa besedila s pomočjo CMS. [36]

Enostavno urejanje in vzdrževanje portala je cilj vsakega skrbnika portala. Tako

prihrani pri času in ponudi uporabniku bolj kakovostne vsebine, ki jih hitreje osvežuje. S

spletno vsebino se ukvarja ponudnik sam, saj lahko v okviru izdelane grafične podobe

poljubno dodaja nove vsebinske sklope, informacije in jih osveži. Celotno vsebino spletnih

strani lahko spreminja kjerkoli in kadarkoli. Zadostuje namreč že delujoča internetna

povezava in delujoč internetni strežnik z delujočo CMS aplikacijo. Uredniku omogoča, da

z vnaprej pripravljenimi predlogami (angl. templates) objavi spletno vsebino na portal, ki

jo je odobril glavni urednik. Grafični oblikovalec sodeluje le občasno, ko je potrebno

spremeniti obliko določene predloge ali ustvariti novo. Poglavitna slabost uporabe CMS-ja

je omejitev, ki jo predstavlja struktura vsebine, saj česarkoli ne moremo dati na portal [35].

Če upoštevamo dejstvo kot npr., da „Prva postavitev spletne ponudbe predstavlja le

10% stroškov, levji delež preostalih 90% gre na račun osveževanja vsebine.“ [35], lahko

rečemo, da je CMS aplikacija ekonomsko ugodna. Uporaba CMS aplikacije omogoča tudi

avtomatizacijo poslovnih procesov. Za objavljanje spletnih vsebin namreč sedaj

potrebujemo le urednika brez razvojne skupine, ki je prej zagotavljala objavo spletnih


vsebin na portalu. Slika 8 prikazuje graf, ki prikazuje razliko ročnim načinom vzdrževanja

vsebine in CMS sistemom.

Slika 8: Graf obsega vzdrževanja vsebine s pomočjo CMS-ja in ročnega vzdrževanja [35]

Pomanjkljivosti in prednosti, na katere lahko naletijo CMS uporabniki, so naslednje

[36]:

Pri komercialnih sistemih imajo uporabniki zagotovljen nadaljnji razvoj, podporo

pri uporabi, kjer imajo zapisana popolna navodila za uporabo in specifične

prilagoditve za vsakega uporabnika posebej. Pri teh sistemih je glavna prednost

podpora pri uvajanju sistema v podjetje in zagotavljanje njegovega nadaljnjega

razvoja. Vendar imajo tudi slabosti: že sam nakup takšnega sistema je lahko zelo

drag, tudi same prilagoditve niso poceni.

Odprtokodni sistemi so sicer zastonj in imajo poleg aplikacije priloženo tudi

izvorno kodo, ki jo potrebujemo, kadar želimo prilagajati rešitve zase. Po drugi

strani tu ni garancije, da vse deluje brezhibno. Če neka verzija zaide v slepo ulico,

lahko to za nas pomeni konec. Nihče nam namreč ne zagotavljala podpore,

specifičnih lastnosti za posameznega uporabnika in podpore pri uvajanju sistema v

podjetju.

Slika 9 prikazuje vse akterje, ki nastopajo in komunicirajo med sabo v CMS sistemu.

Spletni urednik preko CMS dostopa do aplikacijskega strežnika, ki shranjuje podatke in jih

hkrati prikazuje končnemu uporabniku na portalu.


Slika 9: Pregled toka prenosa podatkov [36]

CMS sistemi omogočajo različne funkcionalnosti glede na zahteve uporabnikov.

Najpogosteje omogočajo naslednje funkcionalnosti [35]:

preprosto, hitro oblikovanje brez napak in urejanje spletnih vsebin,

možnost integracije zunanjih CSS stilov, kar zagotavlja samostojno oblikovanje

stilov spletnih vsebin in možnost večkratne uporabe ter samostojnega

dopolnjevanja,

dodajanje in urejanje slik, grafov in povezav,

samostojno urejanje strukture strani spletnega mesta, gradnje menijev in

podmenijev,

vključevanje že vnaprej izdelanih modulov ali obrazcev za vnos podatkov na

spletni strani (ankete, forume, koledar ...),

možnost dodajanja dokumentov na spletno stran (pdf, doc, zip ...),

časovno vodenje objave vsebine (določimo, kdaj naj se vsebina objavi in kako

dolgo naj bo na prvi strani),

možnost uvoza in izvoza podatkov v Word, Excel, Access ...,

kreiranje podatkov za RSS sisteme vsebin,

kreiranje meta oznak, ki so pomembne za lociranje spletnih strani v iskalniku,

možnost dodeljevanja pravic upravljanja (večuporabniški sistem z reguliranim

dostopom področnih urednikov do posameznih vsebin),


administracijo baze partnerjev in avtomatizirano korespondenco z njimi v smislu

obveščanja partnerjev o aktivnostih podjetja,

možnost administracije uporabnikov,

podrobno statistiko obiskanosti portala,

arhiviranje podatkov,

kontrolo verzij za objavo (katera verzija dokumenta se bo objavila danes, jutri - gre

za časovno vodenje objav spletnih vsebin),

zmanjševanje stroškov vzdrževanja in osveževanja spletnih vsebin,

gradnjo hierarhičnih menijev in podmenijev ter avtomatični sistem navigacije,

urejanje različnih jezikovnih različic, ki se vsebinsko in grafično ujemajo z

originalno vsebino.

Možnosti, ki jih ponujajo CMS sistemi, so praktično neomejene, saj je večina sistemov

zasnovana modularno. Na ta način omogoča fleksibilnost v smislu dodajanja vedno novih

in spreminjajočih se obstoječih funkcionalnosti.


3 ORACLE ADF KOMPONENTE

Oracle ADF komponente sestavljajo celovito rešitev za gradnjo modulov, saj pokrivajo

vsak segment MVC arhitekture. Spadajo med 4GL jezike - jezike četrte generacije, ki so v

celoti objektno orientirani in imajo v naprej zgrajene komponente. Komponente so

zgrajene na J2EE odprto kodnih standardih, z namenom poenostavitve in pohitritve

izgradnje modulov, ki temeljijo na SOA arhitekturi [29]. S tem ko podpirajo J2EE odprto

kodne standarde jih lahko namestimo na vsak aplikacijski strežnik, ki podpira te standarde

(Oracle, WebSphere, Tomcat ...), neodvisno od proizvajalca [17]. S pomočjo ADF

komponent lahko naredimo aplikacijo od najnižjega nivoja (zajemanje podatkov) do

najvišjega nivoja (prikaz podatkov na ekranu). Uporaba ADF komponent zmanjša potrebo

po pisanju programske kode, saj vnaprej pripravljene komponente omogočajo hitro in

enostavno gradnjo aplikacij. Tako se razvijalec v večji meri posveča vsebini. Na ta način

zmanjšamo napake človeškega faktorja, ki bi lahko nastale pri implementaciji. ADF

komponente in Oracle JDeveloper predstavljata okolje, ki podpira celotni razvojni cikel

aplikacije (načrtovanje, razvoj, testiranje in namestitev na strežnik) [29].

3.1 ORACLE ADF ARHITEKTURA

Oracle ADF arhitektura implementira MVC (angl. Model View Controller)

arhitekturo, ki predstavlja model gradnje spletnih aplikacij. Arhitektura zagotavlja

precejšnjo neodvisnost med nivoji, poenostavitev vzdrževanja in boljšo preglednost

problema. Manjša sklopljenost MVC arhitekture pomeni večjo neodvisnost med

posameznimi moduli. Omogoča ponovno uporabo posameznih modulov v obstoječi ali

novi aplikaciji. Sama izbira na določenem nivoju je neodvisna in omogoča izbiro najboljše

možne tehnologije za gradnjo aplikacije [1]. Oracle ADF arhitektura je sestavljena, kot

prikazuje slika 10, iz [28]:

− pogleda (angl. View), ki zajema grafične komponente za prikazovanje poslovne

logike uporabniku,

− krmilnika (angl. Controller), ki interpretira ukaze miške in tipkovnice poglednemu

ali modelnemu nivoju, ki se temu ustrezno spreminjata in


− modela (angl. Model), ki predstavlja logiko aplikacije, podatke domene in ponuja

svoje stanje ter se odziva na zahteve po spremembi.

− poslovno storitvenega nivoja (angl. Business services), ki je najnižji nivo v Oracle

ADF arhitekturi in zagotavlja komponentam neposredno delo s podatkovno bazo.

Slika 10: Prikaz ADF komponent [28]

3.2 POSLOVNO STORITVENI NIVO (angl. Bussiness services)

Predstavlja nivo neposredne komunikacije s podatkovnim izvorom. Zagotavlja dostop

do podatkovnega izvora, upravljanje s transakcijami in izvajanjem poslovne logike. V

poslovno storitvenem nivoju se nahaja več vrst tehnologij za zajemanje podatkov iz baze

(Web Services, EJB, JavaBeans, kot prikazuje slika 10). V praktičnem delu bomo

uporabili ADF poslovne komponente.

3.2.1 ADF poslovne komponente (angl. ADF Business Components)

ADF poslovne komponente zagotavljajo gradnike, s pomočjo katerih enostavno in na

deklarativen način zgradimo poslovno logiko. Njihova primarna funkcija je zajemanje in

vnašanje podatkov v podatkovni izvor. Lahko pa z njimi tudi zgradimo E-R diagram in ga

nato shranimo v katerikoli podatkovni izvor. Omogočajo tudi obratni inženiring (angl.

Reverse engineering), kar pomeni, da lahko že predhodno zgrajen podatkovni model v

podatkovnem izvoru uporabimo pri gradnji aplikacije. Praviloma so komponente zgrajene

iz Jave in XML datoteke, ali samo iz XML datoteke. XML dokument vsebuje definicijo

komponente. Z Java kodo pa preberemo informacije, shranjene v XML dokumentih. Java

predstavlja modularen in prenosljiv jezik, idealen za komunikacijo med poslovnimi


aplikacijami, medtem ko XML jezik omogoča poljubno razširljivost in prilagodljivost. To

zagotavlja ADF poslovnim komponentam, da se lahko povežejo do podatkov, neodvisno

od izvora podatkov. Vso poslovno logiko lahko prenesemo na katerikoli aplikacijski

strežnik. V Orale ADF arhitekturi se nahaja na najnižjem nivoju [18]. Spodnja slika 11

prikazuje vse možne načine gradnje poslovne logike znotraj Oracle JDeveloperja.

Slika 11: Prikaz vseh možnih načinov izgradnje poslovne logike s pomočjo ADF [18]

Osnovni gradniki ADF poslovnih komponent [18]:

⇒ Entitetni objekt in asociacije (angl. Entity Object and Associations)

Entitetni objekt je preslikava tabele iz podatkovne baze v aplikacijo. Vsak

atribut v podatkovni bazi se preslika v ustrezen podatkovni tip v aplikaciji.

Vsebujejo različne funkcije, ki nam olajšajo delo in pohitrijo izgradnjo

aplikacije. Vsebuje funkcijo za validacijo vsakega posameznega atributa (od

primerjalnega seznama vrednosti, vrednosti vnosa od do, “regular expression1“

in poljubno definirane validacije z Java metodo).

Entitetni objekt omogoča avtorizacijo vsakega atribua posebej. Vsakemu

uporabniku ali skupini uporabnikov lahko določimo pravice za delo s

posameznim atributom. Entitetni objekt omogoča predefiniranje privzete

1Je tekstovni vzorec, narejen v skladu s sintaktičnimi pravili.


poslovne logike na osnovi jave. Za povezovanje entitet uporabljamo asociacije.

Le-te omogočajo vse možne povezave, ki jih poznamo v E-R diagramu.

⇒ Pogledni objekt in povezave (angl. View Object and Links)

Je komponenta, ki nam omogoča pisanje poljubnih SQL stavkov za želeno

entiteto ali nad več entitetami v poslovni logiki oziroma nad želeno tabelo ali

več tabelami v podatkovni bazi. Kot rezultat nam vračajo podatke iz

podatkovne baze.

Komponenta omogoča dinamično prikazovanje podatkov glede na vhodne

spremenljivke. To dosežemo s funkcijo “angl. Bind Variables“, kjer

specificiramo vse spremenljivke, za katere želimo, da bi se njihove vrednosti

dinamično spreminjale v SQL stavku. Omogoča, da lahko predefiniramo java

razrede, ki jih je komponenta generirala kot privzete, glede na uporabnikove

zahteve. Pogledne povezave (angl. Links) določajo povezavo med dvema

poglednima objektoma. Omogočajo vse vrste povezav, ki jih lahko naredimo v

E-R modelu.

⇒ Aplikacijski modul (angl. Application Modul)

Je transakcijska komponenta, ki jo uporabljamo za vključevanje poglednih

objektov v aplikacijski modul in njihovo testiranje. Narejena je s pomočjo

ADF Swing komponent in predstavlja namizno (angl. desktop) aplikacijo za

povezovanje s podatkovno bazo. Omogoča vnašanje, brisanje, validiranje

pravilnega vnosa in pregled podatkov iz podatkovne baze. Z aplikacijskim

modulom dodajamo poslovno logiko v ADF podatkovno kontrolno zbirko

(angl. ADF Data Controls Palette), ki omogoča enostavno preslikavo poslovne

logike na uporabniško stran (angl. JSF page).

Če želimo, lahko predefiniramo Java razrede, ki jih komponenta generira kot

privzete glede na uporabnikove zahteve.

⇒ Domena (angl. Domain)


Predstavlja povezave med podatkovnimi tipi v poslovni logiki in podatkovnimi

tipi v podatkovni bazi. Primer: če izberemo za spremenljivko v poslovni logiki

podatkovni tip številka (angl. Number), lahko za to spremenljivko izberemo

(angl. Number ali angl. Float), kot podatkovni tip v podatkovni bazi.

3.3 MODEL (angl. Model)

Zagotavlja abstraktni nivo nad modelnim nivojem in omogoča uporabniškemu in

kontrolnemu nivoju, da dela z različnimi implementacijami poslovnih storitev. Predstavlja

povezovalni nivo med poslovno storitvenim in uporabniškim nivojem. Zagotavlja funkcije

za zajemanje in vnašanje podatkov iz in v poslovno storitveni nivo.

3.3.1 ADF Model

Zagotavlja enoten vmesnik za dostop do kateregakoli tipa poslovne storitve. V ta

namen je implementiran JSR-227, imenovan tudi (angl. Data Control) in nam omogoča

ločevanje poslovnega od uporabniškega dela. S tem nam nazorno prikaže koncept, ki so ga

posnemali od SOA arhitekture znotraj aplikacije. Omogoča namreč, da s pomočjo različnih

tehnologij, ki smo jih uporabili v poslovni logiki, predstavimo poslovno logiko

poglednemu nivoju na enak način.

Tehnologija, za preslikavo poslovne logike, ki smo jo uporabili pri ADF komponentah

je ADF aplikacijski modul (angl. ADF Application Modules), ki je del storitvenih razredov

modula za poslovne komponente (angl. ADF Business Components module) [18].

Podpira dve komponenti, ki zagotavljata ločevanje poslovnega in uporabniškega nivoja:

ADF kontrolna zbirka podatkov (angl. ADF Data Controls), le-ta prikazuje

preslikavo poslovne logike. Preslikamo jo lahko s pomočjo aplikacijskega modela

(angl. Application Module), Java razreda, XML, spletne storitve ali iz Enterprise

JavaBeans (EJB) Session Beans.

ADF povezavo podatkov (angl. ADF Data Bindings), ki zagotavlja povezavo med

ADF Faces komponentami, to so že pripravljene komponente, ki temeljijo na Javi,

in podatki v podatkovni bazi. Za vsak uporabniški vmesnik oziroma JSF stran se v

ozadju kreira “angl. page definition file“. “angl. Page definition file“ je XML

datoteka, ki vsebuje podatke o objektih, ki so na uporabniškem vmesniku. Poznamo


več vrst povezav do podatkov. Prva je “angl. Iterator bindings“, ki nam omogoča

preslikavo iz vrstic v podatkovni bazi v dinamično tabelo. Druga je “angl. Value

bindings“, ki poveže UI komponento s podatkovnim tipom v podatkovni bazi.

Tretja vrsta pa je “angl. Action bindings“, ki sproži zahteve uporabnika nad zbirko

podatkov [28].

Primer uporabe:

Medtem ko povlečemo komponento iz “angl. Data Control Palette“ (to je del, kjer so

prikazane vse komponente, ki jih uporabljamo pri “Data Controlls“) na JSF stran, se

avtomatično kreirajo spodaj naštete stvari:

• “DataBindings.cpx“ datoteka - je datoteka, ki vsebuje podatke o definicijski

datoteki, JSF strani in podatek o imenu preslikane poslovne logike.

• ADF Bindings (oracle.adf.model.servlet.ADFBindingFilter ) filter - je filter, ki se

ustvari v web.xml datoteki in nam pove, kateri del poslovne logike se je preslikal na

stran.

ADF fazni poslušalec (angl. ADF phase listener), ki ga prikazuje koda 1, se uporablja za

izvrševanje ADF življenjskega cikla. ADF fazni poslušalec posluša vse faze, če je potrebno

karkoli izvršiti pred ali po kreiranju stran.

<faces-config xmlns="http://java.sun.com/JSF/Configuration">

<lifecycle>

<phase-listener>

oracle.adf.controller.faces.lifecycle.ADFPhaseListener

</phase-listener>

</lifecycle>

</faces-config>

Koda 1: Koda, ki se avtomatično doda v datoteko faces-config.xml ob dodani logiki na stran

[19]

• Definicijska datoteka (angl. Page Definition File) je datoteka, ki vsebuje podatke o

komponentah, ki so na pripadajoči JSF strani.

http://java.sun.com/JSF/Configuration


3.4 KONTROLNI NIVO (angl. Controller)

Kontrolni nivo zagotavlja mehanizem, ki nadzira potek izvajanja dinamičnih spletnih

aplikacij. Komunicira z uporabniškim nivojem in zagotavlja pretvorbo klientovih akcij v

akcije, ki jih razume modelni nivo. Vsebuje sistem za upravljanje z napakami. Poznamo

dve osnovni kontrolni možnosti znotraj MVC arhitekture. Prva je “angl. Apache Jakarta

Struts Controller“ in druga možnost pa je JSF kontroler (angl. JSF Controller). Prvi je že

v zatonu in ga še redko uporabljajo za gradnjo spletnih aplikacij. Drugi način kontrole pa

se še vedno intenzivno uporablja z manjšimi izboljšavami. Eni izmed tistih, ki so naredili

določene izboljšave, so bili tudi pri ADF komponentah.

3.4.1 ADF kontroler (angl. ADF Controller)

Predstavlja kontroler, ki podeduje lastnosti JSF kontrolerja z dodanimi lastnimi

izboljšavami. Ena izmed najbolj pomembnih omogoča ponovno uporabo poteka opravil

(angl. Task Flow) v drugih aplikacijah in pošiljanje parametrov med njimi. Primer prikaza

kontrolnega nivoja je slika 12 spodaj. Prikazan je deklarativen način “faces-config.xml“

datoteke. To je datoteka, v kateri je definiran kontrolni nivo aplikacije.

Slika 12: Prikaz datoteke faces-config.xml [28]

3.5 POGLED (angl. View)

Pogledni ali predstavitveni nivo si najlažje predstavljamo kot nivo, kjer gradimo

uporabniški vmesnik za dostop in upravljanje uporabnika s spletno aplikacijo. Predstavlja


najvišji nivo v MVC arhitekturi in hkrati najbližji uporabnikovemu razumevanju. Na tem

nivoju imamo različne tehnologije, s pomočjo katerih gradimo uporabniški vmesnik, med

katerimi so: HTML, JSP, JSF, Swing, ADF Faces itd. Za vsako od teh naštetih tehnologij

imamo že v naprej pripravljene komponente, ki omogočajo hitrejšo, robustnejšo in

enostavnejšo gradnjo uporabniškega vmesnika. Torej, pogledni nivo predstavlja vizualno

predstavitev poslovne logike. Pogledni nivo je lahko spletni odjemalec ali namizna

aplikacija odjemalec – strežnik.

3.5.1 ADF Faces

ADF Faces temelji na JavaServer Faces (JSF) kompatibilnih knjižnicah, ki ponujajo

širok spekter obogatenih UI komponent za razvoj JSF aplikacij. Zasnovan je na JSR-1271

specifikaciji, zato je uporaben v katerikoli spletni aplikaciji, ki temelji na JSF [15].

ADF zagotavlja konsistentni videz aplikacije, kar uporabniku omogoča, da se osredotoči

na postavitev komponent na uporabniškem vmesniku. Knjižnica, ki sestavlja ADF Faces,

nudi podporo za internacionalizacijo spletne strani. Omogoča prikaz uporabniškega

vmesnika in vsebine ne glede na odjemalno napravo, sposobnost osveževanja poljubnega

dela strani kar pomeni, da lahko zgradimo interaktivno spletno stran, ki osvežuje prikaz

brez osvežitve celotne strani. Omogoča validacijo na strani odjemalca.

Primer komponente ADF Faces 10.1.3

ADF Faces Core so komponente, ki omogočajo izgradnjo dinamičnega uporabniškega

vmesnika. Namespace: http://xmlns.oracle.com/adf/faces

Short name: af

<af:chooseDate> na sliki 13 prikazujemo primer ADF komponente, ki uporabniku

omogoča enostavno izbiro datuma.

Slika 13: Primer izbire datuma ADF Faces 1Je specifikacija arhitekture in API-jev, z namenom poenostavitve in pohitritve izgradnje uporabniških

vmesnikov, ki temeljijo na Javi.


Oracle je ADF Faces nadgradil v Oracle ADF Faces Rich Client Components, ki so

predstavniki Web 2.0 tehnologije [16]. Razvil se je iz JSF 1.2. Vsebuje celoten JavaScript

API. Poudarek je na uporabniku zelo všečni komponenti, predvsem privlačnega videza

komponente in barvne usklajenosti. Tako je obogatil samo interaktivnost komponente.

Dodane so tudi nove komponente. Združljiv je z ADF kontrolerjem, ki podpira “angl.

TaskFlow“ in označevanje, in ADF Modelom, ki podpira povezovanje podatkov.

Zagotavljajo tudi “angl. ADF Data Visualization“ komponente, ki sposobne prikazovanja

dinamičnih grafov, merilnih naprav in ostalih grafičnih komponent, ki prikažejo realne

podatke [15].

Primer komponente ADF Faces Rich Client

ADF Faces Rich UI so komponente, ki temeljijo na JavaScripti in so bile prvič

dodane kot knjižnica v Jdeveloper 11.

Namespace: http://xmlns.oracle.com/adf/faces/rich

Short name: af

<af:chooseDate> predstavlja komponento, slika 14, z istimi funkcionalnostmi kot

komponenta na sliki 13.

Slika 14: Primer izbire datuma ADF Faces RC

Oracle ADF Swing predstavlja razvojno okolje namizno zasnovanih odjemalec-

strežnik aplikacij in večplastnih podatkovnih aplikacij v Javi znotraj Oracle JDeveloper-ja

in Oracle ADF Frameworka. Oracle ADF Swing vsebuje ozek povezovalni nivo, ki se

obnaša kot model v Swingu. Povezava med Swing komponentami in poslovno logiko je

osnovana na deklarativni ravni. Oracle ADF Swing vsebuje vizualno razvojno okolje za

podatkovne aplikacije, ki je primerljivo z Oracle Forms in drugimi 4GL razvojnimi okolji.

http://xmlns.oracle.com/adf/faces/rich


ADF Mobile je nadgradnja Oracle ADF za mobilne uporabnike. Le-ti lahko dostopajo

do mobilnih aplikacij do podatkov v realnem času brez kakšnih posebnih zahtev glede

namestitve. ADF Mobile podpira UI komponente, ki so optimizirane za prikaz na

mobilnih napravah. Vsebuje tudi AJAX napredne funkcije, ki podpirajo validacijo na strani

odjemalca in osvežitev točno določenega dela strani [15].

3.5.2 ADF zaščita

ADF zaščita je namenjena preprečevanju nepooblaščenih dostopov v aplikacijo,

njenih strani, podatkov in funkcij. Najprej je bilo potrebno vse nastavitve za

implementacijo zaščite v aplikacijo narediti ročno, od verzije JDeveloper 10.1.3.0 pa je

ADF Varnost (angl. ADF Security) vgrajena kot produkt, ki nam omogoča zelo enostavno

in hitro vgradnjo zaščite v aplikacijo na deklarativni način. Za zaščito uporablja J2EE

upravljavca vsebnikov (angl. Container-manage) za avtentifikacijo na enega izmed

naslednjih načinov: “angl. Basic Authentication“, “angl. Digest Authentication“, “angl.

Forms-Based“, “angl. Client Certificate“. Med razvijanjem in testiranjem aplikacije je

ADF zaščita nastavljena v “system-jazn-data.xml“ datoteki, ki temelji na XML varnostnem

repozitoriju za Oracle JAAS. Datoteka vsebuje uporabnike, gesla, uporabniške skupine in

ADF varnostna JAAS dovoljenja (angl. ADF Security JAAS Permissions). Po namestitvi

na Oracle Application Server je lahko zaščita spremenjena na OID (angl. Oracle Internet

Directory) [14].

J2EE varnostne vloge so definirane v web.xml datoteki in povezane z uporabniki in

skupinami v “system-jazn-data.xml“ datoteki. Če se ime vloge iz web.xml datoteke ujema

z imenom skupine v “system-jazn-data.xml“ datoteki, ne potrebujemo nobenega

nadaljnjega povezovanja. Če se pa imena ne ujemata, potem se morata povezati preko

“orion-application.xml“ datoteke, ki je konfiguracijska datoteka za LDAP [27]. Primer

kode 3 spodaj kaže, kako programsko preverimo, če je ADF varnost vključena.

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()) {

Permission p = new RegionPermission("view.pageDefs.page1PageDef", "Edit");AccessController.checkPermission(p);// izvedi zaščitno akcijo


} catch (AccessControlException ace) { // sporoči sporočilo ob zavrnitvi dostopa

}

Koda 3: Primer preverjanja vključenosti zaščite nad modulom

3.5.3 Avtorizacija

Avtorizacija je namenjena preprečitvi dostopa do vsebin za katere uporabnik nima

pravic. Temelji na JAAS, ki omogoča preverjanje uporabnikov, definiranih v skupinah v

aplikaciji (v datoteki web.xml) in v skupinah na aplikacijskem strežniku (v datoteki

system-jazn-data.xml). Uporabniki so lahko shranjeni v različnih izvorih (LDAP, XML

datoteki …) [27]. Spodaj na sliki 15 prikazujemo uporabnika, ki želi dostopati do spletnih

vsebin.

Slika 15: Prikaz avtorizacije uporabnika v aplikacijo [27]

Avtorizacija v ADF Security je definirana preko Java Permission, določena pa je

deklarativno za “angl. iterator bindings“, “angl. action bindings“, “angl. method

binding“ in za celotno “angl. ADF page definition“ datoteko, kot prikazuje tabela 2.

Tabela 2: Tabelarični prikaz avtorizacije v ADF aplikaciji [27]

ADF

Modelni

Objekti Področje delovanja Vpliv na komponente v uporabniškem vmesniku

Povezova grant – lahko dodeljuje Na straneh, ki omogočajo izvajanje prilagoditve, je vsaka


ADF

Modelni


lni

vmesnik

za spletno

stran

pravice na strani povezava ali gumb nastavljena tako da onemogoča dostop

uporabnikom, ki nimajo zahtevanih dovoljenj.

edit – lahko ureja vsebino

na strani

Če ima uporabnik dovoljenje samo za ogled (angl. view), ne

pa tudi za urejanje (angl. edit), potem so vsi vneseni podatki

prikazani samo za branje (angl. read only).

personalize – dovoljuje

uporabniku prilagoditev

strani

Strani, ki omogočajo personalizacijo, so prikazane in

dostopne le uporabnikom, ki imajo ta dovoljenja.

view – lahko vidi stran Uporabnik, ki nima tega dovoljenja, bo prikazan kot

avtorizacijska napaka (angl. authorization error).

Povezova

nje

dinamični

h polj

read – lahko bere vrnjene

vrstice

Vse vrstice podatkov bodo vrnjene. Uporabnik lahko določi,

kaj bo prikazano ali nadgrajeno z individualnimi dovoljenji

za posamezen atribut

update – lahko nadgradi

podatke v vrstici

„Commit operation“ , ki je nastavljena kot „command

button“, ni omogočena uporabnikom, ki nimajo nastavljene te

pravice. Namesto omejevanja spreminjanja celotne vrstice,

lahko omejimo vsak posamezen atribut.

create – lahko ustvari

novo vrstico

„Create operation“ , ki je nastavljena kot „command button“,

ni omogočena uporabnikom, ki nimajo te pravice.

delete – lahko zbriše

vrstico

„Delete operation“, ki je nastavljena kot „command button“,

ni na voljo uporabnikom, ki nimajo te pravice.

Povezova

nje metod

invoke – metoda, ki lahko

izvrši

Če je metoda povezana z „command button“, je ta gumb

onemogočen za uporabnike brez te pravice. Če je metoda

sprožena implicitno, se izvrši samo za uporabnike, ki imajo to

pravico.

Povezova

nje na

read – lahko bere Vrednosti atributov bodo prikazane.


ADF

Modelni


nivoju

atributov

vrednosti atributov

update – lahko nadgradi

vrednost atributov

Vsi vneseni podatki bodo prikazani samo za branje za

uporabnike brez tega dovoljenja.

3.5.4 Avtentifikacija

Na sliki 16 vidimo primer implicitne avtentifikacije za dostop do ADF spletne vsebine.

Implicitna avtentifikacija pomeni, da hoče uporabnik dostopati do ADF spletne vsebine

brez vnaprejšnje avtentifikacije. Le-ta se izvede preko servleta, ki je definiran, kot

“adfAuthentication“ v “web.xml“ datoteki.

Slika 16: Prikaz implicitne avtentifikacije [27]

Postopek avtentifikacije je sledeč:

Ko zahtevamo spletno stran, ADF povezovalni filter za servlet preusmeri zahtevo

na ADF avtentifikacijski servlet in shrani logično operacijo, ki je sprožila vpis.

(Korak 1)


ADF avtentifikacijski servlet ima Java EE varnostne omejitve, ki povzroči da Java

EE vsebnik sproži nastavljen vpisni mehanizem. (Korak 2)

• Prikaže se vpisna stran za avtentifikacijo. (2a)

• Uporabnik vnese podatke za vpis. (2b)

• Vneseni podatki se pošljejo nazaj do vsebnika z metodo

j_security_check(). (2c)

• Java EE vsebnik avtentificira uporabnika z uporabo avtentifikacijskega

modula (2d)

Po uspešni avtentifikaciji vsebnik preusmeri uporabnika nazaj do servleta, ki je

sprožil avtentifikacijo. (Korak 3)

In na koncu ADF avtentifikacijski servlet preusmeri uporabnika do prvotno želene

vsebine. (Korak 4)

Eksplicitna avtentifikacija se izvrši, ko uporabnik, preden dostopa do ADF spletne

vsebine, zahteva obrazec za vpis v aplikacijo. Izvrši se postopek avtentifikacije, ki je enak,

kot pri implicitni avtentifikaciji. Po končanem postopku ga le-ta vrne nazaj na stran, kjer je

zahteval avtentifikacijo s to razliko, da je sedaj avtentificiran.


4 ORACLE PORTAL

4.1 PREDSTAVITEV

Oracle portal (v nadaljevanju OP) je spletni produkt, ki omogoča gradnjo, nameščanje

in upravljanje s portleti oziroma spletno vsebino [30]. Je naslednik WebDB1 okolja, ki je

temeljilo na HTML orodju za razvijanje dinamičnih spletnih strani in aplikacij. Izgradnja

portala z OP ne zahteva dodatne programske opreme, kakor tudi ne posebnega znanja

kateregakoli programskega jezika. Izvede se v celoti preko brskalnika. Dostopen je preko

brskalnikov (Firefox, Internet Explorer, Google Chrome ...), ki za naslavljanje uporabljajo

URL. Tudi upravljanje s portalom je preprosto, saj prav tako ne zahteva 3GL

programerskih izkušenj. OP namreč vsebujejo že pripravljene standardne predloge za

izgradnjo poročil, grafov in raznih izpisov podatkov iz podatkovne baze [30].

OP je zgrajen iz infrastrukturnega in iz aplikativnega dela. Infrastrukturni del vsebuje

aplikacijski server, na katerem temelji celotni OP. Aplikativni del pa predstavlja portlete,

ki gradijo OP.

Za gradnjo aplikacije v praktičnem delu diplomske naloge smo uporabili OP 10.1.4

verzijo, ki predstavlja že tretjo generacijo Oracle AS. Zasnovana je bila kot nova vodilna

podjetniška rešitev za podjetja, ki potrebujejo celovito in logično povezano strukturo za

razvijanje, razvoj in upravljanje portalov. Temelji na novem konceptu izgradnje aplikacije,

ki se imenuje SOA. Le-ta predstavlja nove temelje za oblikovanje in izgradnjo aplikacij,

kot tudi novo pot za že zgrajene obstoječe sisteme in poslovne aplikacije. SOA je tudi

temelj celovite in integrirane podjetniške aplikacije za sistemsko programsko opremo.

OP vsebuje orodja za kreiranje aplikacij, ki nam omogočajo dinamično predstavitev

podatkovne baze. Te komponente vsebujejo obrazce za vnos podatkov, poročil, diagramov,

koledarjev, menijev, ... Orodja za sledenje nam izpišejo odzivni čas, ime osebe, ki zahteva

neko dejanje in varnostno zgodovino za te komponente. OP podpira še dodatna orodja, ki

zagotavljajo uporabnikom brskanje po podatkovni bazi (tabele, poglede, PL/SQL rutine,

indeksiranje, ...) preko HTML strani in OP vmesnika. Strani portala2 so zgrajene iz

komponent (portletov), ki omogočajo dostop do spletne strani, aplikacij, poročil, novic in 1 WebDB je je eno zadnjih spletnih orodij RDBMS (angl. Relational database management system ), ki ga je izdalo podjetje Oracle in

se uporablja za razvijanje in upravljanje s portalom.


ostalih stvari. Portlete1 lahko razvijejo uporabniki sami, lahko pa jih izberejo med že

narejenimi Oracle portleti ali katerimi drugimi. OP zagotavlja storitve kot so prijava,

sortiranje vsebine, iskanje, integracijo menijev in varnost.

Uporabnikom ponuja centraliziran dostop do podatkov, aplikacij in poslovnih

procesov. Večina portalov podpira le dostop do informacij, OP pa omogoča tudi dostop do

spletnih servisov, sistemov in aplikacij. Razvil je še koncept integracije BPM orodja s

portalom. Vodilna ideja je bila, da bi OP 10.1.4 omogočal smiselno združevanje poslovne

logike (angl. business intelligence applications), poslovnih procesov (angl. business

process systems) in spletnih servisov (angl. web services) v enovito produktivno okolje.

Nadalje se je razvijal in bogatil s pomočjo povezovanja z ostalimi programi, kot so

Microsoft Office in Windows namizje. OP je del Oracle Application Server-ja.

4.2 ARHITEKTURA ORACLE PORTALA

Arhitektura OP je troslojna, kot prikazuje slika 17. Prvi sloj predstavlja podatkovni

strežnik. Drugi sloj predstavlja aplikativni strežnik, ki omogoča prikaz posameznih

aplikacij, s katerimi uporabnik dostopa do želenih podatkov. Tretji sloj predstavlja

„lahkega“ odjemalca (angl. „thin client“), t.j. uporabnika, ki se preko OP poslužuje

aplikacij, ki nudijo informacije, shranjene v podatkovni bazi [38].

Slika 17: Prikaz troslojne arhitekture OP [38]2 Portal je spletna aplikacija, ki vsebuje personalizacijo, enkratno prijavo, upravljanje z vsebino in gosti predstavitveni nivo

informacijskega sistema.1 Portlet je neodvisna komponenta, ki temelji na javi in jo upravlja vsebnik portletov, izvaja zahteve in generira dinamično vsebino.

Sestavljena je iz JSP strani in servletov, ki so zapakirani v WAR datoteko z web.xml namestitveno datoteko. Vsebuje še datoteko

portlet.xml, ki vsebuje vse meta podatke, ki jih vsebnik portletov potrebuje za izvajanje portletov.


Infrastrukturni del (angl. Infrastructure Tier) vsebuje komponente za avtentifikacijo

uporabnika in podatke za aplikacije na OP. Ta del vsebuje 4 komponente [31]:

Application Server Control Console - ta konzola je namenjena upravljanju

komponent. Z njo lahko začnemo/ustavimo storitev, poljubno nastavljamo

komponente in nadziramo strežnik.

Oracle Application Server Metadata Repository - vsebuje sheme, ki jih uporablja

Oracle AS, OP ... Nameščen je na Oracle Database 10g.

Oracle Internet Directory je LDAP - strežnik, ki vsebuje uporabniške račune za

vpis in delo s spletnimi moduli na OP.

Oracle Application Single Sign-On (SSO) - zagotavlja avtentifikacijo uporabnika.

Srednji del (angl. Middle-Tier) predstavlja naslednje komponente [31]:

Application Server Control Console - ta konzola je namenjena upravljanju

komponent. Z njo lahko začnemo/ustavimo storitev, poljubno nastavljamo

komponete in nadziramo strežnik.

Oracle Application Server Containers for J2EE - portalni servleti uporabljajo

Oracle AS vsebnik za J2EE.

Oracle HTTP Server – temelji na Apache strežniku. Je spletni poslušalec za OC4J

in okolje za statične ter dinamične spletne strani.

Oracle Application Server Web Cache – je integriran znotraj OP z namenom

shranjevanja strani za hitrejše delovanje

Odjemalski del (angl. Client Tier) predstavlja navaden spletni brskalnik za dostop do

portala. Komunicira preko HTTP ali HTTPS protokola.


4.2.1 WSRP

WSRP je standard za spletni protokol, ki ga je odobril OASIS. Uporablja se za

komunikacijo z oddaljenimi portleti. Določa komunikacijski vmesnik spletnih storitev za

interaktivne, predstavitveno usmerjene spletne storitve. WSRP lahko vsebuje širok nabor

oddaljenih vsebin, portalskih programov in aplikacij, ki skrbnikom portalov omogočajo

enostavno integracijo na želene portale. WSRP lahko primerjamo s HTTP protokolom, ki

omogoča interakcijo z oddaljenim HTTP strežnikom, ki prikazuje spletne vsebine in

storitve za vnos podatkov s pomočjo brskalnika. WSRP storitve se hitreje prilagajajo na

spremembe, saj so sinhrono in UI orientirane [3].

Podobno deluje tudi WSRP protokol, ki se izvaja med aplikacijama: porabnikom (angl.

Consumer), ki se obnaša kot odjemalec, in izdelovalcem (angl. Producer), ki zagotavlja

UI. Pri tem porabnik s pomočjo WSRP protokola pošilja zahteve spletnim storitvam,

izdelovalec pa na podlagi odgovorov zgradi uporabniški vmesnik.

V WSRP tehnologiji nastopajo štirje akterji [11]:

Porabnik je sistem, ki komunicira s spletnim strežnikom in sestavlja portlete v

neko celoto ter jih prikazuje končnemu uporabniku. Zaradi njegove povezovalne

vloge ga pogosto primerjamo s preklopnikom sporočil “angl. message switches“,

ki usmerja sporočila na različne strani. Tipičen primer je aplikacija e-trgovine, ki

vsebuje različne izdelke na spletni strani.

Izdelovalec WSRP-ja nudi enega ali več portalskih programov, ki jih aplikacije

porabnika lahko pokličejo. Portal izdelovalca prejme od portala porabnika zahteve

za storitev WSRP-ja. Ko portal izdelovalca prejme zahtevo za storitev WSRP, jo

izdelovalec generira in vrne portalu porabnika, ki je izdal zahtevo.

Glavne prednosti izdelovalca pred brskalnikom so:

− da izdelovalec lahko združi nekaj UI komponent v eno spletno stran in ponuja

dodatke kot so personalizacija, prilagodljivost in varnost.

− da izdelovalec ima opravka z deli in ne s celotnim dokumentom. Te dele dobi

od različnih proizvajalcev in jih združi v eno stran, ki ji potem določi izgled.


Portlet (angl. Portlets), ki je nameščen na strežniku spletnih storitev in generira

spletno vsebino ter zagotavlja povezavo s to vsebino. V glavnem portleti

vključujejo dve vrsti konfiguracije:

logično specifikacijo strežniškega okolja in

posebno konfiguracijo katerih koli nastavitev ali lastnosti portletov,

ki so lahko javno dostopni.

Končni uporabnik (angl. End User) uporabnik portala.

WSRP definira vmesnike, ki jih mora WSRP izdelovalec implementirati, WSRP

porabnik pa jih mora uporabljati, če želi komunicirati s portleti na oddaljenih strežnikih.

WSRP specifikacija zahteva, da vsak WSRP izdelovalec implementira spodaj navedena

prva dva vmesnika, medtem ko dovoljuje, da ostala dva implementira po želji.

Opis vmesnika za storitev (angl. Service Description Interface) (nujen) dovoljuje

WSRP strežniku, da ponudi svoje zmožnosti perspektivnemu izdelovalcu. WSRP

izdelovalec uporablja ta vmesnik za iskanje strežnika in deluje kot mehanizem, ki

pregleduje in sestavlja portlete. Na voljo so tudi podatki o tem, ali strežnik podpira

registracijo, inicializacijo piškotov preden lahko izdelovalec vzpostavi stik s

katerim koli portletom. Ravnotako vsebuje podatek o strežniških tehničnih

zmožnostih [11].

Označevanje vmesnika (angl. Mark-up Interface) (nujen) dovoljuje WSRP

izdelovalcu komunikacijo s portleti, ki so na WSRP strežniku. Na primer: klient bo

uporabil to vrsto vmesnika, kadar bo uporabnik želel vnesti kakšne podatke v

portal.

Registracija vmesnika (angl. Registration Interface) (poljubno) dovoljuje WSRP

strežniku, da zahteva od WSRP izdelovalca registracijo preden lahko komunicira s

storitvami preko vmesnika. Na voljo ima tri operacije za registracijo:

- register (), ki dovoljuje da se lahko porabnik registrira pri izdelovalcu

- modifyRegistration () dovoljuje, da porabnik spremeni vrsto registracije.

- deregister () omogoča prekinitev registracije.


Vmesnik za upravljanje s portleti (angl. Portlet Management Interface)

(poljubno) daje WSRP izdelovalcu dostop do življenjskega cikla portleta.

Izdelovalec ima možnost prilagajanja lastnosti portletov in celo zmožnost uničiti

primerek njihovega oddaljenega portleta.

WSRP specifikacija je standard, ki določa vmesnik za komunikacijo s spletno

vsebino, njenimi uporabniškimi vmesniki in servisi, ki so na oddaljenih strežnikih. Primer

arhitekture WSRP specifikacije predstavlja slika 18.

Slika 18: Arhitektura WSRP specifikacije [3]

4.2.2 Spletna storitev (angl. Web Services)

Spletna storitev je načrtovan sistemski program za podporo večvrstnemu

komuniciranju med računalniki preko interneta. Podpira direktno komunikacijo z drugimi

programskimi aplikacijami in je sposobna prepoznati XML dokumente. Je samozadostna

modularna aplikacija, ki je lahko opisna, objavljena, locirana in poklicana preko spleta.

Za opis spletnih storitev uporabljamo WSDL jezik, ki temelji na XML jeziku. Spletna

storitev je napisana v WSDL dokumentu in objavljena v UDDI registru. S pomočjo WSDL

jezika specificiramo dogovor med izdelovalcem in klientom. Za obliko sporočila, ki ga


prenašamo preko HTTP ali SMTP protokola, uporabljamo SOAP, ki je W3C standard

protokol. SOAP sporočila pošiljamo med izdelovalcem in porabnikom v SOAP ovojnici,

kjer si izmenjujeta zahteve in odgovore [10].

SOAP ovojnice, ki se pošiljajo med izdelovalcem in porabnikom in so prikazane v kodi 2,

so v obliki XML in izgledajo takole:

<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">

<env:Body>

<m:ValidatePostcode env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"

xmlns:m="http://www.somesite.com/Postcode">

<Postcode>WC1A8GH</Postcode>

<Country>UK</Country>

</m:ValidatePostcode>

</env:Body>

</env:Envelope>

Koda 2: SOAP ovojnice [10]

Lastnosti spletnih storitev so, da temeljijo na XML, ki je osnova za integracijo na

nivoju podatkov. Predstavlja nekakšno osnovo za sisteme, ki si izmenjujejo dokumente.

Podpira šibko sklopljenost in grobo granulacijo. Ima možnost sinhronega in asinhronega

delovanja. Podpira RPC in skrije implementacijske podrobnosti, saj uporabnika spletne

storitve ne zanima, kako in v katerem jeziku je spletna storitev narejena. Je ekonomična,

saj jo lahko ponovno uporabimo, in preprosta za namestitev. Delo z njo je avtomatsko in

ne potrebuje človeka, ki bi odgovarjal na zahteve. Nenazadnje je prenosljiva brez večjih

omejitev, glede števila aplikacije, okolja, na katerem se izvaja, in bazo, s katero

komunicira.

4.2.3 JSR 168 Container

JSR 168 vsebnik je spletna komponenta, ki temelji na Java tehnologiji1. Namenjen je

bil standardizaciji komunikacije med portleti, vsebniki portletov in končnimi uporabniki.

JSR 168 skrbi za izvajanje portletov, upravlja z njihovimi življenjskimi cikli, ki jih

zagotavlja z ustreznim izvajalnim okoljem. Zagotavlja tudi stalen prostor za ohranjanje

1 Leta 2003 je bil sprejet standard, ki zagotavlja, da je JSR 168 prenosljiv in razširljiv na kateremkoli J2EE 1.4 vsebniku.


nastavitev portletov. Vsebnik portletov lahko deluje kot del aplikacije portala ali tudi

neodvisno od nje [7].

Življenjski cikel portleta upravlja vsebnik portletov, ki:

zagotavlja portlete z zahtevanim izvajalnim okoljem in stalen spomin za prioritetne

portlete,

procesira zahteve in generira dinamično vsebino.

Slika 19 prikazuje komunikacijo med končnim uporabnikom in portalom.

Uporabnikove zahteve so postrežene s pomočjo vsebnika portletov, ki dinamično pretvarja

portlete v željen portal. Portleti komunicirajo s podatkovno bazo, spletno storitvijo in

poslovno logiko.

Slika 19: Prikaz komunikacije med uporabnikom in portletom [7]

.

Cilji JSR 168 so [7]:

Določati izvajalno okolje in vsebnik portletov za portlete.

Določati API med portleti in vsebniki portletov.

Zagotavljati mehanizme za shranjevanje začasnih in stalnih podatkov.

Zagotavljati mehanizem, ki dovoljuje portletom vključevanje servletov in JSP

(JavaServer Page) strani.

Pakiranje portletov, ki dovoljujejo lahko namestitev.

Omogočati prenos kode portletov med JSR 168 portali.


Izvajati JSR 168 portlete kot oddaljene portlete z uporabo WSRP protokola.

Vsebnik portletov upravlja s portleti in jih zagotavlja zahtevanemu izvajajočemu

okolju. Komunikacija portletov s pomočjo vmesnika poteka preko metode

“processAction()“, ki je zadolžena za vnosne akcije s strani uporabnika in preko metode

“render ()“, ki je klicana vsakič, ko želimo portlet prepisati. Osnovna tri stanja, v katerih se

lahko portlet nahaja, so pogled (angl. view), urejanje (angl. edit) in pomoč (angl. help). Ta

stanja uporablja privzeta “angl. render ()“ metoda, ki se odloči, katero metodo naj pokliče

na nižjem nivoju. Stanje je lahko zapisano kjerkoli v kodi portleta z uporabo portletov API,

ki določajo pogojno stanje, ki je odvisno od trenutnega stanja.

Stanje oken prikazuje skupek prostorov spletne strani portala, ki bodo dodeljeni

vsebini generiranega portleta. Portlet uporablja stanje oken za odločanje količine

informacij, ki jih bo prikazal. Portleti lahko programsko spremenijo stanje okna, medtem

ko izvajajo zahtevane akcije.

JSR 168 določa naslednje stanje oken [7]:

„angl. Normal“ je privzeto stanje oken. Gre za stanje, ko portlet deli stran z

drugimi portleti.

„angl. Maximized“ pomeni, da je lahko portlet edini portlet na spletni strani ali da

ima portlet več prostora v primerjavi z drugimi portleti na spletni strani. Posledično

je vsebina bogatejša v primerjavi z normalnim stanjem okna.

„angl. Minimized“ pomeni, da portlet izpiše minimalno število informacij ali

nobene.

4.3 ADMINISTRACIJA

Oracle AS portal zagotavlja mehanizem, s pomočjo katerega lahko določamo

posameznemu uporabniku ali celotni skupini želene pravice [20]. Administracija je

namenjena preprečevanju zlorabe dostopov. Uporabniki so ali neprijavljeni ali kontrolirani

s pomočjo dostopnega lista LDAP, ki določa, kateri uporabnik ali skupina lahko

komunicira z objektom (stranjo) in do katere mere [39]. OP vsebuje več nivojev določanja

pravic. Omenili smo že pravice nad aplikacijo. Le-te dovoljujejo uporabniku, da razpolaga


s portleti in si tako sam personalizira in spreminja izgled svoje strani. To pomeni, da če

uporabniku niso dodeljene pravice nad aplikacijo, ne more uporabljati nabora portletov in

razpolagati z njimi. Drugi del pa so pravice na samem portalu. Izdelovalec, in kasneje

skrbnik portala, lahko za posamezno stran posebej specificira, kdo jo lahko uporablja. To

naredi tako, da v nastavitvah strani določi, kateri uporabniki oziroma skupine uporabnikov

lahko dostopajo do te strani. Spet lahko vse naredi brez znanja programiranja. Vsako stran

lahko razdeli na več segmentov, v katere dodaja portlete in določa pravice nad

posameznimi segmenti. Upravljanje s pravicami je zelo uporabno in v okolju OP

enostavno. Uporabniku ni potrebno izdelovati posameznih strani za posameznika ali

skupine uporabnikov, ampak naredi eno stran in s pomočjo pravic določa, katera skupina

lahko vidi in uporablja določeno stran, oziroma posamezen segment strani [38].

OP omogoča tudi administracijo podatkovne baze, kreiranje sheme in vlog. Lahko nam

vrača podatke o tehničnih zmogljivostih podatkovne baze do podatkov, ki služijo nadzoru

nad izvajanjem podatkovne baze.

4.3.1 Tipi uporabnikov

Pravice, ki jih ima uporabnik, so določene za vsako stran posebej in se avtomatsko

prenašajo po hierarhiji navzdol na njihove podstrani in tako naprej.

Obstajajo štirje različni tipi uporabnikov [23]:

administrator, ki ima celosten dostop do vsakega dela portala,

upravljalec portala, ki ima pravico dostopa do posamezne spletne strani,

urednik portala, ima pravico za dodajanje in urejanje vsebine strani

obiskovalec, ki ima pravico do ogleda strani, ne more pa je spreminjati.

Pravice zajemajo različen obseg nalog, ki jih lahko izvaja točno določen tip uporabnikov.

Najpogostejše pravice so [39]:

• Pravica ogleda (angl. View Privileges)


Vsak uporabnik, ki se lahko vpiše na OP, ima avtomatsko pravico ogleda vsaj na

njihovi domači strani. Vsak uporabnik lahko izvaja vpis in izpis iz portala, urejanje

svojega profila in iskanje po vsebini.

• Sodelovalne pravice (angl. Contribute Privileges)

Uporabnik s pravico sodelovanja lahko stori vse, kar lahko stori uporabnik s

pravico ogleda. Dodatno pa lahko dodaja in ureja vsebine na strani, briše vsebine,

tudi tiste, ki jih je nekdo drug dodal na stran, izrezuje, kopira in lepi vsebino.

• Urejevalne pravice (angl. Manage Privileges)

Uporabniki s pravico urejanja lahko izvajajo vse, kar lahko izvajajo uporabniki s

pravico sodelovanja. Lahko pa tudi določajo privilegije na strani, spreminjajo

imena začetne strani ali njene podstrani, brišejo najvišje strani, dodajajo, brišejo,

urejajo in menjujejo vrstni res podstrani, izrezujejo in kopirajo podstrani in

spreminjajo podstrani v drugo začetno stran.

• Administratorske pravice (angl. Admnistrator Privileges)

Administrator je uporabnik z neomejenimi pravicami. Edini lahko ustvarja začetne

strani oziroma določa njihov vrstni red, določa spremembo stila portala, ureja

začetne napise, dodaja, spreminja ali briše uporabniške račune, dodaja e-naslove ali

URL vsebine na domačo stran portala in dodaja ostale administratorje.

4.3.2 Skupine uporabnikov

Skupine uporabnikov so namenjene administratorju, da mu olajšajo dodeljevanje

želenih pravic uporabnikom. Skupine omogočajo večjo preglednost nad uporabniki. Med

nameščanjem Oracle AS portala se kreirajo naslednje skupine uporabnikov [21, 24]:

⇒ Prijavljeni uporabniki (angl. Authenticated Users) so uporabniki, ki uspešno

opravijo avtentifikacijo v portal. Imajo pravico, da ustvarjajo strani in stile na

portalu. Običajno sodijo v to skupino administratorji podatkovne baze.

⇒ Bazni uporabniki (angl. Data Base Administrators) je edina skupina uporabnikov,

ki ji je dovoljeno upravljanje s podatkovno bazo. Njihove pravice obsegajo:

upravljanje z vsemi skupinami na portalu, stranmi in njihovimi stili,


upravljanje z vsemi portleti, uporabniškimi profili, aplikacijami za dobavo

podatkov iz baze in z vsemi ostalimi aplikacijami na portalu,

upravljanje s shemami v podatkovni bazi, skupinami uporabnikov in z zapisi o

portalu,

izvoz/uvoz objektov portala, vključno z objekti v skupni rabi.

⇒ Administratorji portala (angl. Portal Administrators) lahko končajo katerokoli

opravilo znotraj portala razen tistih, ki se navezujejo na povpraševanje iz baze in

urejanja skupin (razen skupine „angl. portal administrators“ in „angl. portal

publishers“ ter tistih skupin, ki jih eksplicitno določajo). Imajo naslednje globalne

pravice na portalu:

upravljanje z vsemi skupinami na portalu, stranmi in stili stranmi,

upravljanje z vsemi portleti, uporabniškimi profili, aplikacijami za dobavo

podatkov iz baze in vsemi ostalimi aplikacijami na portalu,

urejanje skupin uporabnikov,

upravljanje z zapisi o portalu in možnostjo uvoza/izvoza objektov na portalu,

razen objektov, ki so v skupni rabi.

Po privzetem sodijo v to skupino uporabniki, ki so v skupini DBA in administratorji

portala.

⇒ Razvijalci portala (angl. Portal Developers) lahko ustvarijo aplikacijo, ki bo

zajemala podatke iz podatkovne baze za naslednje portlete: obrazec, poročilo in

graf. Imajo naslednje globalne privilegije:

ustvarijo lahko aplikacijo, ki bo zagotavljala podatke iz baze in

upravljajo lahko s komponentami v skupni rabi.

sem sodi skupina baznih uporabnikov in administratorjev podatkovne baze

⇒ Oglaševalci portletov (angl. Portlet Publisher), lahko objavljajo strani urejajo

njihovo navigacijo in zagotavljajo portlete, ki bodo zajemali podatke iz podatkovne

baze in jih prikazovali na portalu. Njihov globalni privilegij je, da lahko vse

portlete objavi. Sem sodi skupina administratorjev portala [23].


4.4 PORTLETI

Portleti so standardizirani in varni objekti, ki proizvajajo področje HTML-ja. Lahko so

vgrajeni v statične povezave, zunanje aplikacije, ali v dinamično generirane gibljive

module. Portleti predstavljajo osnovni gradnik uporabniškega vmesnika. Podatke črpajo iz

podatkovne baze in jih v želeni obliki predstavijo uporabniku. To so predvsem razni

obrazci za vnos podatkov v bazo, razne poizvedbe, meniji in grafi, ki predstavljajo

množice podatkov v grafičnem načinu. Portlete izdelujemo v posebnem delu portala, kjer

jih tudi razvrščamo v posamezne aplikacije. Le-te se predstavljajo uporabniku kot nabor

portletov (angl. Portlet Providers), od koder lahko uporabnik sam jemlje nove portlete in

jih dodaja na svojo stran. Gradnike lahko izbira samo iz tistega nabora portletov, do katerih

ima pravico dostopati. Dostopne pravice določa administrator portala ali lastnik nabora [4].

Vrste portletov [2]:

Komplet portletov (angl. Bundled portlets) so portleti, v katerih se nahaja veliko

število zapakiranih portletov. Vse pomembnejše funkcije na portalu so dosegljive

preko njih. Vključujejo administracijo, razvoj in internetno vsebino.

Partnerski portleti (angl. Partner portlets) podpirajo portlete, njihove aplikacije

in opravila preko Oracle partnerske iniciative (angl. Oracle Portal Partner

Initiative).

Poljubni portleti (angl. Custom portlets) zagotavljajo orodje za ustvarjanje in

upravljanje s portleti, ki določajo uporabniško specifično vsebino ali aplikacijo.

Obstajata dve metodi za kreiranje priljubljrnih portletov:

1. „angl. Built in portlets“, ki vsebuje kategorije:

Vsebina direktorija (angl. Folder Content), omogoča uporabniku, da

lahko lastno vsebino v direktorija organizira, klasificira, ureja brez

posredovanja spletnega nadzornika ali razvijalca. Direktorij je lahko

kasneje objavljen kot portlet.

Strukturni podatki (angl. Structed data) so komponente OP, ki

dajejo razvijalcem možnost, da zgradijo module kot so forme,

poročila in grafi, ki so lahko kasneje objavljeni kot portleti.


Spletna stran (angl. Web Site) je dinamična komponenta, ki

zagotavlja hiter in enostaven način izgradnje portletov iz obstoječih

spletnih funkcionalnosti s preprostim izrezovanjem in kopiranjem

HTML kode. Dinamične strani lahko nato objavimo kot portlete.

2. Programirani portleti (angl. Programatic portlets) podpirajo vrsto

kreiranja portletov preko javnih API-jev. Razvijalci portala naredijo paket

ali razred, ki da na voljo metode, ki jih zahteva API. Potem morajo

registrirati nabor portletov v OP. Na voljo sta dve vrsti implementacije:

Shranjeni postopki (angl. Stored procedures). Koda portleta je

napisana v proceduri za shranjevanje z uporabo PL/SQL ali Jave in

nam omogoča shranjevanje podatkov v podatkovno bazo. OP

komunicira direktno s portleti z uporabo prehoda, zagotovljenega s

produktom. Hranjene procedure so zelo primerne, kadar je potrebno

izvesti veliko izmenjav s podatkovno bazo.

HTTP. V tem primeru so portleti in podporniki implementirani v

vseh spletnih razvijalskih okoljih. OP komunicira s temi podporniki

in uporabljajo XML za pošiljanje in prejemanje strukturiranih

podatkov. Ta pristop je najbolj primeren za spletne razvijalce z

uporabo nekih tretjih orodij.

Stanje portletov (zahtevana stanja) [2]:

Uredi (angl. Edit) je klicana s strani doEdit() metode, ko je portlet v stanju

urejanja. Uporabniku je na voljo vsebina in kontrola nad portletom, ki jo

lahko spreminja.

Pogled (angl. View) je klicana s pomočjo doView() metode, ko je portlet v

stanju ogleda vsebine. Uporabniku zagotavlja celovit pregled nad vsebino

portleta.

Pomoč (angl. Help) kličemo s pomočjo doHelp() metode takrat, ko želimo,

da portlet preide v stanje pomoči uporabniku. Prikaže mu stran z navodili za

uporabo.


Stanje portletov (opcijsko; portlet jih lahko vsebuje, ni pa nujno) [2]:

O (angl. About) izpiše namen uporabe portleta, ustvarjalca, verzijo in ostale

informacije.

Nastavitve (angl. Config) prikaže eno ali več oken za konfiguracijo in

dovoljuje administratorju urejanje nastavitev za ostale uporabnike.

Uredi privzeto (angl. Edit Defaults) nastavi privzete vrednosti za

konfigurabilne nastavitve, ki jih ponavadi spreminjamo v Edit načinu.

Predogled (angl. Preview) izpiše predogled.

Natisni (angl. Print) izpiše pogled, ki je primeren za tiskanje.

4.5 ENKRATNA PRIJAVA

Enkratna prijava zagotavlja uporabniku prijavljanje z veljavnim uporabniškim imenom

in geslom, ki mu omogoči dostop do vsebine OP glede na njegov tip računa. Ker je geslo

zahtevano samo enkrat, si lahko uporabnik izbere kompleksnejše geslo in si s tem zagotovi

večjo varnost. Enkratna prijava zmanjša tudi administrativne stroške, ker ne potrebujemo

večkratnih računov.

Enkratno prijavo sestavljajo naslednje komponente [25]:

Strežnik za enkratno prijavo (angl. Single Sign-On Server), ki je sestavljen iz

programske logike, OracleAS podatkovne baze, Oracle HTTP serverja in OC4J

serverja, ki omogočajo varen vpis v aplikacije. Te aplikacije so v dveh oblikah, v

partnerski in v zunanji aplikaciji. V obeh primerih se vpišemo samo enkrat in

dostopamo do aplikacij.

Partnerske aplikacije (angl. Partner Application) predstavljajo Oracle AS

aplikacije, ki delegirajo avtentifikacijsko funkcijo serverju za enkratno prijavo.

Avtentifikacijski modul, ki se imenuje “angl. mod_osso“, sprejme podatke o

prijavljenem uporabniku namesto uporabniškega imena in gesla. Partnerske

aplikacije so odgovorne, da določijo, ali je uporabnik, ki se je prijavil preko Oracle


AS prijave, pristojen za uporabo aplikacije ali ne. Primeri partnerskih aplikacij so

Oracle AS Portal, Oracle AS Discoverer in Oracle Delegated Administration

Services.

Mod_osso je Oracle HTTP strežnik, ki zagotavlja avtentifikacijo za uporabo Oracle

AS aplikacij. Zamenjal je Java okolje za enkratno prijavo (Single sign on SDK), ki

so jo uporabljali v prejšnjih verzijah za integracijo partnerskih aplikacij v Oracle

AS Single Sign-On. Če je mod_osso namestljiva na aplikacijskem strežniku, se s

tem poenostavi avtentifikacijski proces s serviranjem, kot edinim partnerjem

aplikacije za strežnik enkratne prijave. Na ta način mod_osso izrisuje

avtentifikacijo, transparentno do Oracle AS aplikacije. Po avtentifikaciji

uporabnika mod_osso prenese preproste vrednosti glave, ki jih aplikacija lahko

uporablja za avtorizacijo uporabnika. Te vrednosti so uporabniško ime, jezik in

območje.

Oracle Internet Directory je skladišče vseh uporabnikov, ki uporabljajo račun za

enkratno prijavo. Strežnik za enkratno prijavo avtentificira uporabnika glede na

vnose v skladišču tako, da dobi uporabnikove atribute iz skladišča, ki omogočajo

preverbo uporabnika.

Oracle Identity Management Infrastructure je okolje, ki skrbi za varnost

življenjskega cikla uporabnika in ostalih omrežnih entitet. V tem delu se nahajajo

vse komponente, ki skrbijo za varno prijavljanje uporabnika v sistem.

Dostop do partnerskih aplikacij, ki so varovana z mod_osso aplikacijo, prikazuje slika

20. Dostop do partnerskih aplikacij poteka takole [25]:

1. Uporabnik želi dostopati do partnerske aplikacije.

2. Uporabnik je preusmerjen na strežnik za enkratno prijavo, kjer mora

vpisati svoje pravilne podatke, ki jih strežnik preveri v Oraclovem imeniku

(Oracle Internet Directory) in, če so pravilni, uporabniku omogoči dostop

do partnerskih aplikacij.

3. Aplikacija postreže zahtevano vsebino.


Slika 20: Dostop do partnerske aplikacije [25]

4.6 NAVIGACIJA

Pomembna lastnost pri gradnji portala je oblika in izgradnja navigacije. Oracle AS

portal vsebuje že zgrajene navigacijske objekte, ki pomagajo zgraditi navigacijo med

stranmi [20]. Vključuje avtomatsko zgrajene povezave do domače strani portala,

avtomatsko generirane in objavljene objekte s skupno klasifikacijo in navigacijo strani.

Zagotavlja možnost dodajanja navigacijske strani ročno ali opisno. V ročnem načinu

naredi svojo lastno navigacijsko stran, jo objavi kot portlet in jo doda kamorkoli na stran.

V opisnem načinu oblikuje portlet za iskanje vsebine po meri, ki lahko išče vsebino po

atributih, kategoriji, datumu kreiranja, avtorju in avtomatsko objavi rezultate v strani

portleta [22].

Navigacijska stran je poseben tip strani, ki je lahko vključena na ostalih straneh, da

zagotavlja skladnost navigacijskih elementov. Navigacijska stran lahko vsebuje logotip,

naslov strani, povezavo za prijavo in povezavo do osnovne strani, kot je domača stran.

Tipične navigacijske strani so uporabljene za navigacijske elemente, reklamne oglase v

glavi strani in povezave v nogi strani.

4.7 RELACIJA MED ADF IN ORACLE PORTALOM

Če primerjamo Oracle ADF in OP ugotovimo, da sta to dva ločena Oracle produkta, ki

pa imata tudi nekaj skupnih točk. Ena izmed njih je, da lahko s pomočjo obeh produktov


naredimo spletni modul, ki bo zajemal podatke iz podatkovne baze in jih prikazoval

končnemu uporabniku. Oba produkta imata že implementirani rešitvi za zagotavljanje

zaščite v modulu in tako lahko ponudita personalizirane podatke za avtentificiranega

uporabnika. Nenazadnje oba produkta potrebujeta za svoje delovanje aplikacijski strežnik,

na katerem sta nameščena.


5 PRAKTIČNI DEL

V praktičnem delu smo raziskovali gradnjo spletnih aplikacij z uporabo ADF

komponent. Želeli smo podrobneje preučiti funkcionalnosti in zgradbo OP.

5.1 ADF KOMPONENTE (specifikacija)

Aplikacijo smo razvijali v okolju Jdeveloper 10.1.3.2 Studio Edition. Za shranjevanje

podatkov smo uporabili MySQL 5.1 Server.

5.1.1 Diagram primera uporabe

Diagram primera uporabe je diagram, ki prikazuje funkcionalnosti, ki jih mora sistem

nuditi. Med najpomembnejše gradnike spadata akter in primer uporabe. Akter predstavlja

vlogo posameznika v sistemu, ki komunicira z določenim poslovnim procesom, ki ga

opisuje primer uporabe. Povezava med njima je asociacija. Na sliki 21 vidimo diagram

primera uporabe za spletno aplikacijo EPN, ki smo jo implementirali v praktičnem delu.


Slika 21: Primer diagrama uporabe za EPN

5.1.2 Opredelitev problema

Zamislili smo si problem izgradnje aplikacije elektronskega potnega naloga (v

nadaljevanju EPN), na katerem smo preverjali in raziskovali funkcionalnost ADF

komponent. Najprej smo definirali obseg funkcionalnosti in sam potek izgradnje aplikacije

EPN. Glavne funkcionalnosti, ki jih bo aplikacija EPN podpirala so:

• vnašanje, spreminjanje in brisanje šifranta oseb,

• vnašanje, spreminjanje in brisanje šifranta vozil,

• vnašanje, spreminjanje in brisanje šifranta vrsta obračunov,

• elektronska izpolnitev potnega naloga,


• dinamično dodajanje vrste obračunov v EPN,

• predogled obračuna EPN,

• možnost zapisa v bazo,

• možnost kreiranja PDF dokumenta in tiskanja potnega naloga,

• iskanje po številki in letnici potnega naloga,

• vgradnja zaščite v aplikacijo, ki nam omogoča avtentifikacijo in avtorizacijo

uporabnika.

5.1.3 Opis tabel

Podroben pregled atributov znotraj vsake entitete je razložen v nadaljevanju. Za

potrebe izdelave EPN smo definirali tabele: Obracungl, Oseba, Vozilo, Obracunpoz,

VrstaObracuna, Caspotovanja, Naloga.

V tabeli “Obracungl“, kjer shranjujemo podatke o obračunih potnih nalogov, se nahajajo

naslednji atributi:

• Obracunglid - ki predstavlja enolično identifikacijsko številko o potnem

nalogu,

• Letopn - predstavlja leto kreiranja potnega naloga,

• Stevpn - predstavlja zaporedno številko potnega naloga za tekoče leto,

• Osebaid - predstavlja identifikacijsko številko osebe, ki potuje na službeno pot,

• Odgovorenid - predstavlja identifikacijsko številko osebe, ki je odobrila izdajo

naloga za potni nalog,

• Voziloid -predstavlja identifikacijsko številko vozila, ki je bil uporabljen za

prevoz na službeno pot,

• Prevozlasten - predstavlja atribut, ki pove ali smo potovali z lastnim

avtomobilom ali službenim,

• Datumobracuna - pove, kdaj je bil potni nalog narejen,

• Krajpotovanja - predstavlja cilj potovanja,

• Vsikraji - izpiše vse kraje, tudi vmesne in obratno pot potovanja,

• Zacetnikraj - pove, kje smo začeli službeno pot.


Tabela “Oseba“predstavlja osebe, ki so odpotovale na službeno pot, in osebe, ki so to

dejanje odobrile. V tabeli imamo naslednje atribute za opis šifranta oseb.

• Osebaid - predstavlja identifikacijsko številko osebe, ki je potovala oziroma

odobrila službeno pot,

• Ime - predstavlja ime osebe,

• Priimek - predstavlja priimek osebe,

• Delovnomesto - predstavlja delovno mesto osebe v službi,

• Posta - predstavlja poštno številko osebe,

• Kraj - predstavlja kraj bivanja osebe,

• Ulica - predstavlja ulico bivanja osebe,

• Aktiven - pove ali je oseba še zaposlena ali ne,

• Posiljatelj - pove, ali je oseba odgovorna za napotitev druge osebe na službeno

pot.

Tabela “Vozilo“ predstavlja službena ali privatna vozila za vožnjo na službeno pot. V

tabeli imamo naslednje atribute za prikaz opis šifranta vozil:

• Voziloid - predstavlja identifikacijsko številko vozila v tabeli,

• Nazivozila - predstavlja ime oziroma tip vozila,

• Regstevilka - predstavlja registrsko številko vozila,

• Aktiven - pove, ali je avtomobil še v voznem stanju in pripravljen za službeno

potovanje ali je pokvarjen oziroma neuporaben,

• Sluzben - pove, ali je avtomobil službeni ali privatni.

Tabela “Obracunpoz“ je namenjena dodajanju poljubno velikega števila vrst obračuna

na potni nalog. Služi kot neka vrsta povezovalne tabele med “Obracungl“ in

“Vrstaobracuna“ tabelo. V njej se nahajajo naslednji atributi:


• Obracunpozid - predstavlja identifikacijsko številko obračuna pozicije,

• Obracunglobracunglid - predstavlja identifikacijsko številko potnega naloga, na

katerega se vežejo vrste obračuna,

• Vrstaobracunaid - predstavlja identifikacijsko številko za vrsto obračuna,

• Placapodjetje - pove, ali določeno vrsto obračuna plačamo s kartico ali

gotovino,

• Vrednostobracuna - pove znesek vrste obračuna.

Tabela “Vrstaobracuna“ je šifrant vrst obračuna, ki jih uporabnik dodaja po želji na

potni nalog. Tabela vsebuje naslednje atribute:

• Vrstaobracunaid - predstavlja identifikacijsko številko za vrsto obračuna,

• Nazivobracuna - pove ime vrste obračuna,

• Priloga - pove, kakšen dokaz imamo za nastale stroške,

• Aktiven - pove, ali je vrsta obračuna še veljavna ali ne.

Tabela “Caspotovanja“ je namenjena sledljivosti prihoda in odhoda osebe na

službeno potovanje. V tabeli so naslednji atributi:

• Caspotovanjaid - predstavlja identifikacijsko številko časa potovanja,

• Obracunglobracunglid - je identifikacijska številka potnega naloga,

• Casodhoda - pove, kdaj je oseba odšla na službeno pot,

• Casprihoda - pove, kdaj se je oseba vrnila s službene poti.

Tabela “Naloga“ je namenjena shranjevanju opisov nalog, na katere je bila poslana

določena oseba. V njej so naslednji atributi:

• Nalogaid - je identifikacijska številka za nalogo,

• Obracunglobracunglid - je identifikacijska številka potnega naloga, ki mu

pripada določena naloga,


• Opisnaloge - opiše namen potnega naloga.

5.2 PRISTOP K RAZVOJU PRAKTIČNEGA DELA

Najprej smo se spoznali s produkti, ki smo jih uporabil v praktičnem delu naloge.

Potem smo si zamislili problem EPN (elektronskega potnega naloga) in ga specificirali.

Določili smo tabele, atribute znotraj tabele in povezave med tabelami. Nato smo vsebinsko

določili, kaj vse bo zajemala aplikacija (poglavje 5.1.2). Zatem smo namestili vso potrebno

programsko opremo (Jdeveloper 10.1.3.2, MySQL Server 5.1, Oracle Portal 10.1.4) za

implementacijo aplikacije. Aplikacijo smo začeli v Jdeveloper-ju, kjer smo ustvarili novo

aplikacijo, ki je podpirala ADF poslovne komponente in ADF Faces komponente.

Aplikacijo smo razdelili na tri dele, in sicer na:

• modelni nivo, kjer smo imeli projekt “Model“ za gradnjo poslovne logike,

• pogledni in kontrolni nivo, kjer smo imeli projekt “ViewController“ za prikaz

uporabniškega vmesnika in implementacijo kontrolnega nivoja in

• spletno storitev, kjer je bil projekt “FopWS“ za generiranje PDF dokumenta.

Podrobnejši opis izgradnje aplikacije po nivojih je podan v nadaljevanju (glej poglavja 5.3,

5.4 in 5.6). Na koncu smo portletizirali spletne aplikacije, kjer smo s pomočjo WSRP

protokola iz spletne aplikacije naredili portlet, ki smo ga prikazali na oddaljenem

aplikacijskem strežniku in OP.

5.3 IZGRADNJA POSLOVNE LOGIKE

Aplikacije smo začeli graditi v projektu “Model“, kjer smo najprej naredili E-R

diagram s pomočjo ADF diagrama za poslovne komponente (angl. Business Components

Diagram). Slika 22 prikazuje zgrajen podatkovni model s pomočjo ADF diagrama za

poslovne komponente.


Slika 22: Prikaz E-R modela

Ko smo naredili E-R diagram, smo s pomočjo funkcije "angl. Generate->Database

Object for Diagrams" preslikali celoten E-R diagram v podatkovno bazo. Po uspešni

preslikavi iz entitetnega v relacijski model v podatkovni bazi smo nadaljevali z gradnjo

aplikacije s pomočjo ADF poslovnih komponent.

Kreirali smo vse komponente entitetnih objektov (angl. Entity Objects), ki so

preslikale tabele iz podatkovne baze v aplikacijo. Nato smo naredili vse pogledne objekte

(angl. View Objects) s pripadajočimi SQL stavki, ki so ustrezali naši logiki za zajemanje

podatkov iz podatkovne baze. Istočasno smo avtomatično preslikali vse pripadajoče

povezave med pogledi in entitetami. Ko smo imeli poslovno logiko narejeno, smo

uporabili komponento aplikacijski model (angl. Application Module). Z njo smo najprej

testirali pravilno delovanje poslovne logike, istočasno pa je preslikala celotno poslovno

logiko v uporabniški vmesnik. Ko smo imeli poslovno logiko preslikano na uporabniški

nivo, smo pričeli z gradnjo uporabniškega vmesnika.


5.4 GRADNJA UPORABNIŠKEGA VMESNIKA

Najprej smo naredili začetno stran, slika 23, ki je služila kot vhodna stran v aplikacijo.

Na tej strani smo naredili dinamični obrazec za izpolnjevanje potnih nalogov. Čisto zgoraj

imamo navigacijske komponente za urejanje šifrantov:

• “Vozilo Uredi“ je povezava do strani za urejanje vozil,

• “Obracun uredi“ je povezava do strani za urejanje obračunov,

• “Oseba uredi“ je povezava do strani za urejanje oseb.

Pod komponentami za urejanje šifrantov imamo možnost izpisa uporabnika, ki se je

prijavil v aplikacijo.

Nižje imamo primer menija, ki omogoča navigacijo do želene strani. Meni “Uredi“

vsebuje tri podmenije; “Oseba“, “Vozilo“, “Obračun“, ki omogočajo navigacijo vsak do

svojega urejanja šifrantov. Imamo še meni “Iskanje potnega naloga“, ki omogoča

navigacijo do strani za iskanje potnih nalogov.

Nadalje imamo “Številko pn“, ki je sestavljena iz zaporedne številke in letnice. Ti dve

številki se polnita avtomatično glede na zadnje vnešeno številko in letnico.

Na strani imamo na voljo še naslednje komponente:

• “Izberi osebo“ - predstavlja izbirni meni za izbiro osebe, ki želi oditi na službeno

potovanje. Ob izbiri določene osebe se avtomatično napolnijo podatki o ulici,

pošti in kraju,

• “Datum od“ - s pomočjo gumba za vnos datuma se vnese datum in ura odhoda,

• “Datum do“ - s pomočjo gumba za vnos datuma se vnese datum in ura prihoda,

• “Izberi avtomobil“ - je izbirni meni, ki ob izbiri avtomobila avtomatično napolni

polje z registrsko številko,

• “Začetni kraj“ - predstavlja vnosno polje za vnos kraja odhoda,

• “Kraj potovanja“ - predstavlja vnosno polje za vnos končnega kraja prihoda,

• “Opis“ - vnosno polje za opis dogodka, ki se bo zgodil oziroma namen potovanja

na službeno pot,


• “Na službeno potovanje odhaja po nalogu“ - predstavlja osebo, ki ima pravice za

odobritev službenega potovanja,

• “Obračun“ – sestavljajo naslednje komponente za dodajane stroškov na EPN

“Izberi Obračun“, predstavlja izbirni meni za izbiro vrste obračuna

Zraven imamo vnosno polje za vnos stroškov obračuna v evrih.

“Kartica“ je izbirni meni, ki pove, ali je bilo plačano s kreditno kartico ali ne.

Na koncu imamo še gumb “Dodaj“, ki doda obračun v dinamično tabelo

obračunov.

• “Akontacija“ je vnosno polje za vnos akontacije.

Gumb “Obračun“ omogoča navigacijo na stran, kjer imamo narejen obračun potnega

naloga.

Slika 23: Prikaz strani za vnos potnega naloga


Slika 24 prikazuje uporabniški vmesnik za obračun potnega naloga. Na njem se

nahajajo elementi iz začetne strani. Razlika je v tem, da tu preverimo, ali smo vnesli

pravilne podatke za EPN, vendar jih tu jih ne moremo popravljati. Za popravljenje se

moremo vrniti na začetno stran (gumb “Nazaj“). Poleg že opisanih komponent imamo na

voljo še komponente za skupni izračun stroškov potnega naloga:

• “Skupaj“ - predstavlja izračun, ki pove, koliko so znašali vsi dejanski stroški, ki

bremenijo podjetje,

• “Akontacija“ – pove, koliko denarja je oseba dobila vnaprej za službeno pot,

• “Kartica“ - pove, koliko stroškov je bilo plačanih s kartico,

• “Izplačilo“ - pove, koliko denarja dobi izplačanega glede na stroške oseba, ki jih je

imela,

• “Datum obračuna“- pove, kdaj smo potni nalog kreirali.

Dodani so gumbi za:

• “Vnos“ - za vnos obračuna v podatkovno bazo,

• “Nazaj“ - pomeni, da gremo na predhodno stran,

• Povezava - “Natisni“ naredi PDF izpis potnega naloga,

• “Komentarji napake“ - sporočajo morebitne napake, do katerih je prišlo v aplikaciji

na strani obračuna.

Slika 24: Prikaz strani za predogled obračuna


5.4.1 Uporabniški vmesnik za urejanje vozil

Na tej strani, slika 25, so prikazani vsi aktivni avtomobili. Če bi hoteli prikazati

neaktivne, bi morali iz izbirnega menija izbrati 0 in klikniti gumb “Poišči“. V tabeli imamo

tudi možnost “Izbire“ avtomobila, ki izbere želeni avtomobil za urejanje. Funkcionalnosti,

ki jih ima uporabnik na voljo za urejanje, so:

• “Ustvari“ - ob pritisku gumba “Ustvari“ se na novo vnesejo podatki o vozilu v

podatkovno bazo,

• “Izbriši“ - ob pritisku gumba “Izberi“ se prepišejo vnosna polja pod tabelo. Nato

lahko zapis izbrišemo iz podatkovne baze,

• “Spremeni“ - ob pritisku gumba “Izberi“ se prepišejo vnosna polja pod tabelo, ki

jih lahko nato poljubno spremenimo in shranimo v podatkovni bazi,

• “Nazaj“ - vrne na prvo stran, kjer vnašamo potni nalog.

Slika 25: Urejanje šifranta vozil

5.4.2 Uporabniški vmesnik za urejanje vrste obračuna

Na tej strani, slika 26, so prikazane vse aktivne vrste obračuna. Če bi hoteli prikazati

neaktivne, bi morali iz izbirnega menija izbrati 0 in pritisniti gumb “Poišči“. Možnosti, ki

jih imamo na voljo pri urejanju so:


• “Ustvari“ - ob pritisku gumba „Ustvari“ se na novo vnesejo podatki o vrsti

obračuna v podatkovno bazo,





• “Nazaj“ - vrne prvo stran, kjer vnašamo potni nalog.

Slika 26: Urejanje šifranta vrste obračuna

5.4.3 Uporabniški vmesnik za urejanje osebe

Na tej strani, slika 27, so prikazane vse aktivne osebe. Če bi hoteli prikazati neaktivne,

bi morali iz izbirnega menija zbrati 0 in pritisniti gumb “Poišči“. Možnosti za urejanje, ki

jih imamo na voljo, so:

• “Ustvari“ - ob pritisku gumba „Ustvari“ se na novo vnesejo podatki o vozilu v

podatkovno bazo,






• “Nazaj“ - vrne prvo stran, kjer vnašamo potni nalog.

Slika 27: Urejanje šifranta oseb

5.4.4 Uporabniški vmesnik za iskanje potnega naloga

Stran, slika 28, omogoča iskanje potnega naloga, pripravo za tiskanje in tiskanje PDF

datoteke.

• “Izhod“ - predstavlja navigacijo na začetno stran.

• “Priprava“ - predstavlja pripravo potnega naloga na tiskanje.

• “Najdi“ - služi za iskanje potnega naloga. V vnosno polje “Letopn“ moramo vnesti

leto potnega naloga in v polje “Stevpn“ moramo vnesti številko potnega naloga.

• “Natisni“ - pripravi PDF datoteko za tiskanje.

Slika 28: Stran za iskanje potnega naloga


5.5 PROBLEMI PRI GRADNJI UPORABNIŠKEGA VMESNIKA

Potrebno je bilo narediti komponento za vnos datuma in časa, ki jo ADF komponente

ne vsebujejo. Potrebovali smo jo za lažji vnos podatka o točnem času in datumu odhoda na

službeno pot. Na spletu smo poiskali skripto za izbiro datuma in ure, kot prikazuje slika 29.

Ta temelji na JavaScripti in se nam ob pritisku na gumb odpre novo okno, v katerem lahko

izberemo poljuben dan in uro.

Slika 29: Prikaz skripte za izbiro datuma in ure

Pri izgradnji dinamičnega dodajanja vrste obračuna v skupni obračun smo kreirali v

poslovni logiki nov pogledni objekt. Ta objekt je imel atribute, ki so bili začasni (angl.

Transient) in niso bili vezani na podatkovno bazo, kot vidimo na sliki 30.

Slika 30: Dodajanje obračunov v skupni obračun

5.6 IZGRADNJA PDF DOKUMENTA

Najprej smo pripravili okolje za gradnjo PDF dokumenta. Za generiranje PDF

dokumenta smo uporabili Apache FOP (angl. Formatting Objects Processor) verzijo 0.94.

Nato smo namestili produkta Altova XMLSpy in Altova StyleVision. S pomočjo Altova

XMLSpy smo zgradili XSD, iz njega pa XML datoteko, ki je služila za izgradnjo XSLT


datoteke. V kodi 4 vidimo primer dela XSD datoteke, ki je v aplikaciji služila za

dinamično dodajanje vrste obračunov v potni nalog.

<xs:element name="pozicije">

<xs:complexType>

<xs:sequence>

<xs:element name="obracunpozicije" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="naziv" type="xs:string"/>

<xs:element name="vrednost" type="xs:float"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

Koda 4: Del kode iz XSD dokumenta

S produktom Altova StyleVision smo naredili obliko izgleda PDF dokumenta na podlagi

XSD-ja in XML-ja. Slika 31 prikazuje primer generiranega PDF-ja z Altovo StyleVision.


Slika 31: Primer oblike PDF-ja znotraj Altove StyleVision

Ko smo končali z oblikovanjem in smo imeli XSLT generiran, smo naredili nov

projekt “FopWS“, v katerega smo dodali Apache FOP generator. Nato smo implementirali

metodo (koda 5), ki je klicala Apache FOP. Za vhodne parametre je uporabljala XSLT

datoteko in XML v binarni obliki, vrnila pa je PDF v binarni obliki.

System.setProperty("javax.xml.transform.TransformerFactory",

"org.apache.xalan.processor.TransformerFactoryImpl");

FopFactory fopFactory = FopTools.getFopFactory();

TransformerFactory tFactory = FopTools.getTransformerFactory();

FOUserAgent foUserAgent = fopFactory.newFOUserAgent();

out = new ByteArrayOutputStream();

Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, out);

Source xsltSrc = new StreamSource(new ByteArrayInputStream(xslt));

Transformer transformer = tFactory.newTransformer(xsltSrc);

Result res = new SAXResult(fop.getDefaultHandler());

Source xmlSrc = new StreamSource(new ByteArrayInputStream(xml));

transformer.transform(xmlSrc, res);

return out.toByteArray();

Koda 5: Primer uporabe Apache FOP-a


Ko smo metodo napisali, smo iz Java razreda naredili spletno storitev. Nato smo

prekopirali WSDL datoteko v projekt, kjer smo delali uporabniški vmesnik. Tam smo iz

WSDL datoteke naredili klienta, ki bo uporabljal spletno storitev. Zatem smo kreirali

servlet, razviden iz kode 7, za klicanje fop spletne storitve. Preden smo klicali fop spletno

storitev smo zapisali XML niz v sejo, kot prikazuje koda 6. XML niz smo zgradili z

uporabo dom4j knjižnice.

FacesContext fc = FacesContext.getCurrentInstance();

HttpServletRequest sr = (HttpServletRequest) fc.getExternalContext().getRequest();

sr.getSession().setAttribute("xml", document.asXML() );

Koda 6: Primer shranjevanja XML-ja v sejo

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException

{

try

{

adf.model.view.proxy.FopWSSoapHttpPortClient myPort =

new adf.model.view.proxy.FopWSSoapHttpPortClient();

fopClient = new FopWSSoapHttpPortClient();

}

catch (Exception e)

{

e.printStackTrace();;

}

// tukaj se izvede klic web servica za generiranje pdf datoteke

byte[] pdf =

fopClient.generirajXml2Pdf(sbXslt.toString().getBytes("UTF8"), xml.getBytes("UTF8") );

if (pdf == null)

response.setContentType("application/pdf");

response.getOutputStream().write(pdf); // izpis pdf porocila na browser.

}

}

Koda 7: Klic fop spletne storitve za generiranje PDF-ja


Rezultat klica spletne storitve dobimo v spletnem brskalniku preko URL naslova in je

viden na sliki 32.

Slika 32: Prikaz generiranega PDF dokumenta

5.7 VARNOST ADF APLIKACIJE

V aplikacijo smo vgradili zaščito s pomočjo produkta ADF Security. Le-ta omogoča

deklarativen način vgradnje vseh potrebnih nastavitev za zaščito aplikacije. Najprej smo

izbrali, naj aplikacija zahteva avtorizacijo (angl. Enforce Authorization). Izbrali smo tudi

spletno stran, kam se naj preusmeri po uspešno izvedeni avtorizaciji. Nato smo zahtevali

naj izvede avtorizacijo z metodo (angl. doAsPrivileged()) in je že implementirana v ADF

varnosti. Avtorizacija se primerja na osnovi XML (system-jazn-data.xml) datoteke, ki se

nahaja na aplikacijskem strežniku, ker je bolj primerna za uporabo v testni fazi izgradnje

aplikacije (za produkcijsko verzijo aplikacije je priporočljivo uporabiti povezavo do LDAP

sistema). Za avtentifikacijo smo uporabili angl. Form-Based Authentification, ki nudi

možnost izgradnje privzete vpisne strani in strani za sporočanje napačne avtentifikacije.


Vpisna stran je narejena v obliki forme, kot je razvidno iz slike 33, ki za avtentifikacijo na

strežniku uporablja “angl. j_security_check“ post metodo.

Slika 33: Prikaz vnosne forme za prijavo v aplikacijo

Nazadnje smo za zaščito spletne aplikacije nastavili vloge aplikacije. Definirali smo tri

vrste vlog: testerji, uredniki in obiskovalci, in jim omejili dostop do spletne strani glede na

vlogo uporabnika.

Nato smo znotraj aplikacije za vsako posamezno vlogo določili dostopne pravice do

strani in komponent na strani, ki jih je lahko uporabnik videl oziroma nad katerimi je lahko

izvajal akcije. Primer prijavljenega uporabnika v aplikacijo prikazuje slika 34.

Slika 34: Prikaz prijavljenega testnega uporabnika

V aplikaciji smo definirali naslednje tipe uporabnikov:

• Prvi tip uporabnika ima nastavljene pravice za testiranje, kot je razvidno iz slike 35.

V bistvu je to administrator. V aplikaciji lahko uporablja vse funkcije, ki so na

voljo.


Slika 35: Prikaz pravic testnega uporabnika

• Drugi tip uporabnika je uporabnik s pravicami urejanja in ga prikazuje slika 36.

Temu uporabniku smo dali možnost, da lahko v aplikaciji vidi vse podatke in jih

lahko tudi vnaša. Ne more pa brisati in spreminjati podatkov.

Slika 36: Primer uporabnika urejevalca

• Tretji tip uporabnika, ki smo si ga zamislili, je obiskovalec. Uporabnik, ki se prijavi

kot obiskovalec ima zelo omejene možnosti delovanja na strani. Kot je razvidno iz

slike 37, lahko ta tip uporabnika samo pregleduje podatke.


Slika 37: Prikaz pravic uporabnika obiskovalca

Težava se je pojavila pri izbirnem meniju. Čeprav smo za prijavljenega uporabnika

nastavili vse možne pravice za prikaz strani in komponent na njej, se podatki v izbirnem

meniju niso prikazali. Problem smo rešili tako, da smo na stran dodali tudi atribute, ki smo

jih uporabljali za prikaz v izbirnem meniju in jim dodelili pravice za prikazovanje.

5.8 PORTLETIZACIJA ADF APLIKACIJE PREKO WSRP PROTOKOLA

Portletizacijo ADF aplikacije smo naredili z namenom vključitve v OP in primerom

prikaza delovanja na dveh aplikacijskih strežnikih, Embedded OC4J aplikacijskem

strežniku in WebCenter Preconfigured OC4J aplikacijskem strežniku. S tem načinom

vgradnje aplikacije smo želeli prikazati delovanje SOA arhitekture na praktičnem primeru.

V ADF aplikacijo, katere cilj je bil portletizacija, smo v prvem koraku dodali knjižnico

“angl. Portlet Faces Bridge“. Ta knjižnica predstavlja del Oracle Webcentra in je

namenjena povezovanju portletov med sabo. Nato smo kreirali portlet.xml datoteko in

dodali ustrezno kodo, kodo 8, za portletizacijo.

<portlet-class>oracle.portlet.server.bridges.jsf.FacesPortlet </portlet-class>

<init-param>

<name>DefaultPage.view</name>

<value>/osnovna.jspx</value>


</init-param>

<init-param>

<name>BridgeLifecycleListeners</name>

<value>

oracle.portlet.server.bridges.jsf.adf.ADFFacesBridgeLifecycleListener,

oracle.portlet.server.bridges.jsf.adf.BindingFacesBridgeLifecycleListener

</value>

</init-param>

Koda 8: Primer portlet.xml datoteke

Naredili smo nov namestitveni profil (angl. Deployment Descriptor) Webcenter

application WAR. Z njim smo ADF aplikacijo dodali na WebCenter Preconfigured OC4J.

Sedaj smo preizkusili delovanje portleta preko URL naslova

(http://192.168.1.6:6688/adfdiploma/faces/portlets/wsrp1?WSDL) . Slika 38 prikazuje

primer prikaza WSRP storitve na URL naslovu.

Slika 38: Prikaz WSRP storitve

Na koncu smo naredili novo aplikacijo, ki je služila kot testna aplikacija za prikaz

WSRP portleta na Embedded OC4J strežniku. Znotraj testne aplikacije smo najprej

registrirali WSRP proizvajlca (angl. WSRP producer) s pomočjo čarovnika za registracijo.

Ta omogoča, da preko URL-ja dostopamo do izvorne aplikacije, ki je na WebCentru

Preconfigured OC4J strežniku. Kreirali smo še novo JSF stran in dodali nanjo registriran

WSRP portlet. Tako smo zaključili nalogo in sledil je preizkus.

Testno aplikacijo smo zagnali na strežniku (WebCentru Preconfigured OC4J) in dobili

rezultat, ki ga prikazuje slika 39. Kot vidimo, je izgled popolnoma identičen izvorni

http://192.168.1.6:6688/adfdiploma/faces/portlets/wsrp1?WSDL


aplikaciji (slika 22). Nato smo preizkusili tudi vse funkcionalnosti in ugotovili, da se

aplikacija obnaša popolnoma enako kot v primeru, če bi aplikacijo preizkušali na izvornem

aplikacijskem strežniku (Embedded OC4J).

Slika 39: Primer prikaza aplikacije preko WSRP-ja

5.9 ANALIZA ORACLE PORTALA

V drugem delu praktične naloge smo raziskovali Oracle Portal, z namenom spoznati

njegove funkcionalnosti v praksi, preizkušati njegove lastnosti (kreiranje novega

uporabnika, novih strani, določanje predlog, gradnjo aplikacije z Oracle komponentami).

Na sliki 40 vidimo vstopno stran v OP. Ponuja povezave do različne dokumentacije in

praktičnih primerov o funkcionalnostih OP. Do strani lahko dostopajo samo prijavljeni

uporabniki.


Slika 40: Primer vhodne strani v OP

Slika 41 prikazuje stran s pomočjo katere poteka administriranja OP, portletov in

podatkovne baze. Administracija OP zajema upravljanje z uporabniki, skupinami

uporabnikov ter določene storitve za nadzor funkcionalnosti OP. Naslednje, kar lahko

administriramo, so portleti, kjer lahko registriramo zunanje portlete za posameznega

uporabnika ali celo skupino. Nenazadnje lahko administriramo podatkovne baze. Tu lahko

kreiramo sheme in vloge za posamezno podatkovno bazo. Imamo pa tudi številne portlete

za nadzor delovanja podatkovne baze.


Slika 41: Primer administracije OP

V delu OP, kjer lahko gradimo lokalne portlete in jih kasneje vključujemo na stran.

Imamo že v naprej pripravljene gradnike, ki nas vodijo skozi posamezne čarovnike za

izgradnjo portletov. Začetna stran za gradnjo lokalnih portletov je razvidna iz slike 42.


Slika 42: Meni za gradnjo lokalnih portletov

5.10 REGISTRACIJA WSRP PORTLETA

Ker smo hoteli na koncu prikazati tudi ADF aplikacijo na OP, smo morali najprej

nadgraditi verzijo OP v 10.1.4, ki podpira tudi WSRP registracijo portletov. Na ta način

bomo predstavili SOA arhitekturo, ki omogoča delo z oddaljenimi portleti. Aplikacijo

znotraj OP smo registrirali s pomočjo portleta za registracijo WSRP portletov, razvidno iz

slike 43.

Slika 43: Prikaz portleta za registracijo WSRP v OP


Po končani vgradnji je sledil preizkus. ADF aplikacija je bila uspešno uvožena in

prikazana v OP. Pri samem preizkusu pa so bile ugotovljene tudi pomanjkljivosti.

Navigacija znotraj OP ni delovala in pri prikazu ADF komponent je prišlo do določenih

pomanjkljivosti, ki jih prikazuje slika 44.

Nato smo izvedli še uvoz ADF aplikacije v OP z uporabo portleta Web Clipping.

Ugotovili smo, da aplikacija v celoti deluje tako kot v prvotnem projektu.

Slika 44: Primer vgradnje ADF aplikacije v OP

5.11 SKLEP

V praktičnem delu smo utrdili in poglobili znanje o gradnji spletnih aplikacij.

Preizkusili smo, kako na enostaven in deklarativen način s pomočjo ADF komponent

zgraditi spletno aplikacijo, ki jo lahko načeloma namestimo na katerikoli aplikacijski


strežnik, ki ima podporo za J2EE aplikacije. Ugotovili smo, da je sama izgradnja spletne

aplikacije z ADF komponentami zelo enostavna in v določenih primerih celo ne potrebuje

programerskega znanja. ADF komponente pa nam nudijo veliko število že

implementiranih funkcionalnosti (primer ADF poslovne komponente nam nudijo

avtorizacijo in validacijo na nivoju poslovne logike, predefiniranje poslovne logike s

pomočjo Java razredov ...). Ponujajo širok nabor komponent za izgradnjo poslovne logike

in JSF ADF komponent za izgradnjo uporabniškega vmesnika. JSF ADF komponente so

odprtokodne in na voljo pod licenco Apache MyFaces Trinidad. Trenutna verzija ADF

komponent je 11.

Še eden izmed ADF produktov, ki nam olajša veliko dela in smo ga preizkusili, je

ADF varnost (angl. ADF Security) le-ta je od verzije JDeveloper-ja 10.1.3 naprej vgrajena

znotraj razvojnega okolja. S pomočjo tega produkta enostavno in na opisni način vgradimo

zaščito v spletno aplikacijo, ki ob prvem dostopu do aplikacije zahteva avtentifikacijo.

Nato na podlagi vnesenih podatkov izvede avtorizacijo v aplikacijo. Na ta način se

dejansko izvaja personalizacija storitev znotraj aplikacije za posameznega uporabnika. V

spletni aplikaciji nam je uspelo narediti spletno storitev in generirati odjemalca te spletne

storitve (preko WSDL datoteke).

V praktičnem delu smo uspeli prikazati spletno aplikacijo kot portlet, na dveh

različnih aplikacijskih strežnikih. Najprej smo portletizirali spletno aplikacijo v portlet,

nato pa smo preko WSRP protokola registrirali WSRP izdelovalca, ki je skrbel za prikaz

uporabniškega vmesnika na oddaljenem strežniku. Vajo smo ponovili v OP, kjer smo s

pomočjo portleta za registracijo oddaljenih portletov registrirali WSRP portlet. Na koncu

smo dobili rezultat. UI se je prikazal, vendar aplikacija ni delovala v skladu s pričakovanji.

Kot smo ugotovili, aplikacija ni delovala zato, ker JSR 168 in WSRP 1.0 ne podpirata

AJAX-a in še prikaza nekaterih ADF Faces komponent. Vse to bi naj bilo odpravljeno v

novi različici OP 11, ki bo podpiral WSRP 2.0 tehnologijo.


6 ZAKLJUČEK

Pri pisanju diplomske naloge sem prišel do spoznanj, da so portali postali vedno bolj

pomembno središče zbiranja informacij na enem mestu. Najbolj obiskani med njimi so

javni portali, ki omogočajo hitro in pregledno posredovanje informacij, ki so odvisne od

tipa portala. Portali se precej uporabljajo tudi v poslovne namene za komuniciranje in

zbiranje informacij o potencialni stranki ter v samih podjetjih za vodenje informacijskega

sistema.

Portal kot produkt, ki ga je zasnoval Oracle, omogoča hitro in precej enostavno

gradnjo spletnega portala znotraj OP. Ponuja številne portlete, ki so že v naprej

pripravljeniomogoča tudi, da sami zgradimo portlet s pomočjo čarovnikov za izgradnjo

lokalnih portletov. Za samo gradnjo portletov ne potrebujemo nobenega dodatnega

programerskega znanja, ampak samo brskalnik, s katerim dostopamo do storitve, ki

omogoča izgradnjo želenega portleta. Sčasoma se je OP čedalje bolj širil v svoji ponudbi in

tako postal za uporabnika vedno bolj in bolj zahteven. V bistvu ga v tem trenutku en sam

uporabnik ne more več obvladovati, razen v primeru, da se specializira zgolj za OP. V

zadnjih letih je moč opaziti, da se je razvoj na tem področju nekoliko upočasnil, saj je bila

zadnja verzija OP 10.1.4 izdana aprila leta 2006. Nova verzija OP 11 bo izdana

predvidoma 1. julija 2009. V tem času pa v ospredje vse bolj prihajajo aplikacije, narejene

z Web 2.0 tehnologijo, ki se izvajajo v brskalniku samem in na ta način razbremenijo

aplikacijski strežnik.

ADF komponente so namenjene gradnji poslovnih aplikacij od načrtovanja do

testiranja. Pokrivajo vsak segment v MVC arhitekturi in s tem odražajo samozadostnost za

gradnjo spletnih aplikacij. Gradnja aplikacije poteka na deklarativen način, v ozadju pa se

generira v J2EE kompatibilno Java kodo. Zato bi načeloma morale delovati na vseh

aplikacijskih strežnikih, ki podpirajo J2EE.

V delu, kjer smo analizirali OP smo ugotovili, da le-ta ponuja veliko možnosti za

vključevanje zunanjih vsebin v OP (Omniportlet, Web Clipping, External application in

Remote providers). Preučili smo dejansko gradnjo portletov znotraj portala in prišli do

ugotovitve, da je dokaj enostavna in izvedljiva na podlagi čarovnikov. OP ponuja

pripravljene administratorske rešitve za upravljanje s pravicami za posameznega


uporabnika ali skupine na portalu. Bogat je tudi meni z upravljanjem strani (kreiranje,

dodajanje, slogi, …).

Zamudna pa je namestitev, saj je precej kompleksna in potrebuje veliko resursov

(veliko delovnega spomina in zmogljiv procesor). Delo z OP je tudi precej neobvladljivo,

polno pomanjkljivosti (dosti popravkov) in odprtih vprašanj, ki jih je potrebno reševati na

forumih.


7 VIRI, LITERATURA

[1] Badiyani, R. (2007). Integrating Customer Touch Points – A Real World Use of

Oracle ADF. Pridobljeno 12.3.2008 iz http://www.singlequery.com/wp-

content/uploads/2007/03/2007_445_badiyani_ppr.pdf

[2] Brassington, P. A. (2000). Oracle Portal: A Roadmap For Success. Pridobljeno

12.3.2008 iz

http://www.nyoug.org/info/tech_journal/editors_choice_papers/2000_Brassington_Or

acle%20Portal.pdf

[3] Creating Java Portlets. (b.d.). Pridobljeno 15.3.2008 iz http://download-

west.oracle.com/docs/cd/B14099_12/portal.1014/b14135/pdg_java_intro.htm#sthref8

49

[4] Build Your Own Portlets. (b.d.). Pridobljeno 12.9.2008 iz http://download-

uk.oracle.com/docs/cd/A97335_01/portals.102/p_tour/qt_frm.htm

[5] Enterprise information portal. (b.d.). Pridobljeno 28.7.2007 iz

http://en.wikipedia.org/wiki/Enterprise_information_portal

[6] Finkelstein, C. In H. Aiken, P. (2000). Building corporate Portals with XML.

McGrawe Hill.

[7] Hepper, S. in Hesmer, S. (2003). Introducing the Portlet Specification, Part 1.

Pridobljeno 10.3.2008 iz http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-

portlet.html

[8] Internet. (b.d.). pridobljeno 12.3.2008 iz

http://mid.gov.si/mid/mid.nsf/V/K07A6B74D3D8527BEC1256C55003DBD88/$file/

LS_7_7_Internet.pdf

[9] Jacobi, J. (2005). Using the ADF Faces Dialog Framework. Pridobljeno

12.3.2008 iz

http://www.oracle.com/technology/products/jdev/101/howtos/adfdialog/index.html

[10] Jurič, Matjaž B. (2004). Modeli in odločitveni sistemi. Maribor: Fakulteta za

elektrotehniko,računalništvo in informatiko, Inštitut za informatiko.

http://www.oracle.com/technology/products/jdev/101/howtos/adfdialog/index.html

http://mid.gov.si/mid/mid.nsf/V/K07A6B74D3D8527BEC1256C55003DBD88/$file/LS_7_7_Internet.pdf

http://mid.gov.si/mid/mid.nsf/V/K07A6B74D3D8527BEC1256C55003DBD88/$file/LS_7_7_Internet.pdf

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-portlet.html

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-portlet.html

http://en.wikipedia.org/wiki/Enterprise_information_portal

http://download-uk.oracle.com/docs/cd/A97335_01/portals.102/p_tour/qt_frm.htm

http://download-uk.oracle.com/docs/cd/A97335_01/portals.102/p_tour/qt_frm.htm

http://www.nyoug.org/info/tech_journal/editors_choice_papers/2000_Brassington_Oracle%20Portal.pdf

http://www.nyoug.org/info/tech_journal/editors_choice_papers/2000_Brassington_Oracle%20Portal.pdf

http://www.singlequery.com/wp-content/uploads/2007/03/2007_445_badiyani_ppr.pdf

http://www.singlequery.com/wp-content/uploads/2007/03/2007_445_badiyani_ppr.pdf


[11] Kropp, A., Leue, C. in Thompson, R. (2003). Web Services for Remote Portlets

Specification. Pridobljeno 10.3.2008 iz http://www.oasis-

open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf

[12] Ladič, P. (2006). Kako uvesti CRM v organizacijo. Moj mikro, str.79.

Pridobljeno 28.4.2008 iz

http://www.mojmikro.si/mreza/za_mala_podjetja/kako_uvesti_crm_v_organizacijo

[13] Marcoux, E. (2007). 10 Reasons to choose ADF Faces. Pridobljeno 12.9.2008 iz

http://emarcoux.blogspot.com/2007/02/10-reasons-to-choose-adf-faces-article_11.html

[14] Nimphius, F. (2007). Introduction to ADF Security in Jdeveloper 10.1.3.2.

Pridobljeno 12.9.2008 iz

http://www.oracle.com/technology/products/jdev/howtos/1013/adfsecurity/adfsecurity

_10132.html

[15] Oracle ADF Faces Components. (b.d.).Pridobljeno 12.9.2008 iz

http://www.oracle.com/technology/products/adf/adffaces/adffaces1013.html

[16] Oracle ADF Faces Rich Client Components. (b.d.). Pridobljeno 12.9.2008 iz

http://www.oracle.com/technology/products/adf/adffaces/index.html

[17] Oracle Application Development Framework. (b.d.). Pridobljeno 12.9.2008 iz

http://en.wikipedia.org/wiki/Oracle_Application_Development_Framework

[18] Oracle® Application Development Framework. (2006). Pridobljeno 16.1.2009 iz

http://download.oracle.com/docs/pdf/B25947_01.pdf

[19] Oracle® Application Development Framework Developer's Guide. (b.d.).

Pridobljeno 16.1.2009 iz http://download.oracle.com/docs/cd/B25221_04/web.1013/

b25386/appendixA010.htm

[20] Oracle Application Server Portal. (b.d.). Pridobljeno 22.7.2008 iz

https://portal.rfsuny.org/portalHelp/ohw/state/content/locale.en/destination.0~-3~-

3~0~/navId.0/navSetId._/expanded.3~1~/oldNavSetId._/oldNavId.0/

[21] Oracle Application Server Portal. (b.d.). Pridobljeno 12.3.2008 iz

http://www.ntnu.no/portalHelp2/ohw/state/content/locale.en/destination.16~/navId.0/n

avSetId._/expanded.16~0~/oldNavSetId._/oldNavId.0/

http://www.ntnu.no/portalHelp2/ohw/state/content/locale.en/destination.16~/navId.0/navSetId._/expanded.16~0~/oldNavSetId._/oldNavId.0/

http://www.ntnu.no/portalHelp2/ohw/state/content/locale.en/destination.16~/navId.0/navSetId._/expanded.16~0~/oldNavSetId._/oldNavId.0/

https://portal.rfsuny.org/portalHelp/ohw/state/content/locale.en/destination.0~-3~-3~0~/navId.0/navSetId._/expanded.3~1~/oldNavSetId._/oldNavId.0/

https://portal.rfsuny.org/portalHelp/ohw/state/content/locale.en/destination.0~-3~-3~0~/navId.0/navSetId._/expanded.3~1~/oldNavSetId._/oldNavId.0/

http://download.oracle.com/docs/cd/B25221_04/web.1013/b25386/appendixA010.htm

http://download.oracle.com/docs/cd/B25221_04/web.1013/b25386/appendixA010.htm

http://download.oracle.com/docs/pdf/B25947_01.pdf

http://en.wikipedia.org/wiki/Oracle_Application_Development_Framework

http://www.oracle.com/technology/products/adf/adffaces/index.html

http://www.oracle.com/technology/products/adf/adffaces/adffaces1013.html

http://www.orablogs.com/fnimphius



http://emarcoux.blogspot.com/2007/02/10-reasons-to-choose-adf-faces-article_11.html

http://www.mojmikro.si/mreza/za_mala_podjetja/kako_uvesti_crm_v_organizacijo

http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf

http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf


[22] Oracle® Application Server Portal. (2005). Pridobljeno 12.3.2008 iz

http://download.oracle.com/docs/cd/B14099_13/portal.1014/b13809.pdf

[23] Oracle Application Server Portal Configuration Guide. (b.d.). Pridobljeno

12.3.2008 iz http://download-

west.oracle.com/docs/cd/B14099_19/portal.1014/b19305/cg_secur.htm#i1006489

[24] OracleAS Portal 10.1.4 New Features. (2006). Pridobljeno 15.3.2008 iz http://www.oracle.com/technology/products/ias/portal/pdf/portal_1014_new_features.pdf[25] Oracle Application Server Single Sign-On Administrator's Guide. (b.d.). Pridobljeno 16.1.2009 iz http://download-uk.oracle.com/docs/cd/B28196_01/idmanage.1014/b15988/concepts.htm [26] Oracle Application Server 10gOracle Personalization. (2005). Pridobljeno 16.1.2009 iz http://www.oracle.com/technology/products/personalization/pdf/faq.pdf[27] Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. (b.d.). Pridobljeno 16.1.2009 iz http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/adding_security.htm [28] Oracle JDeveloper 10g Overview. (2004). Pridobljeno 15.10.2008 iz http://download.oracle.com/otndocs/tech/ias/portal/files/RG/WhitePaper/jdev10g_overview.pdf[29] Oracle Jheadstart 10g for ADF. (b.d.). Pridobljeno 15.10.2008 iz

http://otndnld.oracle.co.jp/consulting/techprod/jheadstart/pdf/jhsdevguide.pdf

[30] Oracle Portal. (b.d.). Pridobljeno 15.3.2008 iz http://www.oracle.com/appserver/

portal_home.html

[31] Oracle Portal integration. (b.d.). Pridobljeno 22.7.2008 iz

www.enonic.com/binary?id=25200&download=true

[32] Osojnik, R. in Mišov, D. (2002). Spletni portali. Pridobljeno 12.3.2008 iz http://

www.drustvo-informatika.si/fileadmin/dsi2002/prispeliReferati/osojnik.doc

[33] Pohleven, M. (2006). Zgradite uspešen portal. infosrc.si, 47, 11-15. Pridobljeno

15.4.2008 iz http://www.src.si/library_si/pdf/infosrc/InfoSRC.SI%20-%202006-47.pdf

[34] Polančič, G., Vajde Horvat, R., in Rozman, I. (b.d.) Skupne značilnosti portalov.

Pridobljeno 10.07.2007 iz, http://lisa.uni-

mb.si/~polancic/si/raziskovalnoDelo/publikacije/Skupne%20znacilnosti

%20portalov.pdf

http://lisa.uni-mb.si/~polancic/si/raziskovalnoDelo/publikacije/Skupne%20znacilnosti%20portalov.pdf



http://www.src.si/library_si/pdf/infosrc/InfoSRC.SI%20-%202006-47.pdf

http://www.drustvo-informatika.si/fileadmin/dsi2002/prispeliReferati/osojnik.doc

http://www.drustvo-informatika.si/fileadmin/dsi2002/prispeliReferati/osojnik.doc

http://www.enonic.com/binary?id=25200&download=true

http://www.oracle.com/appserver/portal_home.html

http://www.oracle.com/appserver/portal_home.html

http://otndnld.oracle.co.jp/consulting/techprod/jheadstart/pdf/jhsdevguide.pdf

http://download.oracle.com/otndocs/tech/ias/portal/files/RG/WhitePaper/jdev10g_overview.pdf

http://download.oracle.com/otndocs/tech/ias/portal/files/RG/WhitePaper/jdev10g_overview.pdf

http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/adding_security.htm

http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/adding_security.htm

http://www.oracle.com/technology/products/personalization/pdf/faq.pdf

http://download-uk.oracle.com/docs/cd/B28196_01/idmanage.1014/b15988/concepts.htm

http://download-uk.oracle.com/docs/cd/B28196_01/idmanage.1014/b15988/concepts.htm

http://www.oracle.com/technology/products/ias/portal/pdf/portal_1014_new_features.pdf

http://www.oracle.com/technology/products/ias/portal/pdf/portal_1014_new_features.pdf

http://download-west.oracle.com/docs/cd/B14099_19/portal.1014/b19305/cg_secur.htm#i1006489

http://download-west.oracle.com/docs/cd/B14099_19/portal.1014/b19305/cg_secur.htm#i1006489

http://download.oracle.com/docs/cd/B14099_13/portal.1014/b13809.pdf


[35] Ribič, C. (2002). Upravljanje z vsebino. Pridobljeno 27.7.2007 iz

http://www.drustvo-informatika.si/dogodki/dsi-2002/

[36] Škrt, R. (2006). Odprtokodni sistemi za samostojno upravljanje spletnih vsebin.

Pridobljeno 24.7.2007 iz http://www.nasvet.com/cms-sistemi/

[37] Šmid, M. in Hvala, A. (2001). Portal - zgolj nova modna beseda ali naslednja

velika stvar?. infosrc.si, 30, 7-10. Pridobljeno 2.11.2008 iz


[38] Šturm, M. (2002). CRM in razvoj portalov s pomočjo Oracle Portal. Pridobljeno

12.3.2008 iz www.drustvo-

informatika.si/fileadmin/dsi2002/prispeliReferati/sturm.doc

[39] Understanding Oracle Instant Portal users. (b.d.). Pridobljeno 10.3.2008 iz

https://portal.mtt.fi/portalHelp2/ohw/state/content/locale.zh_TW/vtTopicFile.iphelp_h

s_TW|undusr~htm/group.instant/navId.3/navSetId._/

http://www.drustvo-informatika.si/dogodki/dsi2002/prispeliReferati/sturm.doc-



http://www.drustvo-informatika.si/fileadmin/dsi2002/prispeliReferati/sturm.doc

http://www.drustvo-informatika.si/fileadmin/dsi2002/prispeliReferati/sturm.doc


http://www.nasvet.com/cms-sistemi/

http://www.drustvo-informatika.si/dogodki/dsi-2002/


8 PRILOGE

8.1 SEZNAM SLIK

Slika1: Javni portal MSN

Slika 2: Primer poslovnega portala enaa.com

Slika 3: Prikaz logične zgradbe portala

Slika 4: Primer portala mesta Maribor, kot ga vidi uporabnik

Slika 5: Avtorizacija v sistem

Slika 6: Primer CRM-ja v podjetju

Slika 7: Primer vnosa besedila s pomočjo CMS

Slika 8: Graf obsega obsega vzdrževanja vsebine s pomočjo CMS-ja in ročnega

vzdrževanja

Slika 9: Pregled toka prenosa podatkov

Slika 10: Prikaz ADF komponent

Slika 11: Prikaz vseh možnih načinov izgradnje poslovne logike s pomočjo ADF

Slika 12: Prikaz datoteke faces-config.xml

Slika 13: Primer izbire datuma ADF Faces

Slika 14: Primer izbire datuma ADF Faces RC

Slika 15: Prikaz avtorizacije uporabnika v aplikaciji

Slika 16: Prikaz implicitne avtentifikacije

Slika 17: Prikaz trislojne arhitekture OP

Slika 18: Arhitektura WSRP specifikacije

Slika 19: Prikaz komunikacije med uporabnikom in portletom

Slika 20: Dostop do partnerske aplikacije

Slika 21: Prikaz E-R modela


Slika 22: Prikaz strani vnosa potnega naloga

Slika 23: Prikaz strani za predogled obračuna

Slika 24: Urejanje šifranta vozil

Slika 25: Urejanje šifranta vrste obračuna

Slika 26: Urejanje šifranta oseb

Slika 27: Stran za iskanje potnega naloga

Slika 28: Prikaz skripte za izbiro datuma in ure

Slika 29: Dodajanje obračunov v skupni obračun

Slika 30: Primer oblike PDF-ja znotraj Altove StyleVision

Slika 31: Prikaz generiranega PDF dokumenta

Slika 32: Prikaz vnosne forme za prijavo v aplikacijo

Slika 33: Prikaz prijavljenega testnega uporabnika

Slika 34: Prikaz pravic testnega uporabnika

Slika 35: Primer uporabnika upravljalca

Slika 36: Prikaz pravic uporabnika obiskovalca

Slika 37: Prikaz WSRP storitve

Slika 38: Primer prikaza aplikacije preko WSRP-ja

Slika 39: Primer vhodne strani v OP

Slika 40: Primer administracije OP

Slika 41: Meni za gradnjo lokalnih portletov

Slika 42: Prikaz portleta za registracijo WSRP v OP

Slika 43: Primer vgradnje ADF aplikacije v OP

8.2 Seznam preglednic in kod

TABELE Tabela 1: Tabelarični prikaz predstavljenih portalov


Tabela 2: Tabelarični prikaz avtorizacije v ADF aplikaciji

KODE

Koda 1: Koda, ki se avtomatično doda v datoteko faces-config.xml ob dodani logiki na stran

Koda 2: Primer preverjanja vključenosti zaščite nad modulom

Koda 3: SOAP ovojnice

Koda 4: Del kode iz XSD dokumenta

Koda 5: Primer uporabe Apache FOP-a

Koda 6: Primer shranjevanja XML-ja v sejo

Koda 7: Klic fop spletne storitve za generiranje PDF-ja

Koda 8: Primer portlet.xml datoteke

8.3 Naslov študenta

Evgen Meklav

Dobrič 20

3313 Polzela

Tel.: 031-718-335

e-mail: [email protected]

8.4 Kratek življenjepis

Rojen: 17.6.1981 v Celju

Šolanje:Osnovno šolo sem obiskoval na Polzeli, srednjo šolo v Velenju PTERŠ (poklicno

tehnično elektro in računalniško šolo)

mailto:[email protected]


UPORABLJENE KRATICE

• 3GL (angl. Third-generation programming language) – jeziki tretje generacije, kot

so C++, Java, Pascal ...

• 4GL (angl. fourth-generation programming language) – jeziki četrte generacije, ko

so EGL, ADF...

• ADF (angl. Application Development Framework) - okolje, ki je podprto z J2EE

standardom, namenjeno namiznim in internetnim aplikacijam

• API (angl. application programming interface) – predstavlja zbirko Java razredov

• B2B (angl. Business to Business) - vrsta elektronskega poslovanja med podjetjema

• B2C (angl. Business to Consumer) - vrsta elektronskega poslovanja med podjetjem

in stranko

• B2E (angl. Business to Employee) - vrsta elektronskega poslovanja med podjetjem

in zaposlenimi

• BLOB (angl. Binary Large Object) - podatkovna baza, v kateri so shranjene

digitalne informacije v različnih oblikah (besedilo, slika, avdio ali video posnetek)

• BPM (angl. Business Process Management) – poslovna logika, ki je osredotočena

na stranko in bi ga lahko poimenovali poslovni proces optimizacije

• E-R (angl. Entitiy Relationship) - diagram, ki prikazuje grafično odvisnost med

entitetami v podatkovni bazi

• EJB (angl. Enterprise JavaBeans) - Java zrna, ki so namenjena izgradnji poslovne

logike

• ERP (angl. Enterprise resource planning) – sistemi za načrtovanje virov znotraj

podjetja

• CMS (angl. Content Management System) - spletni program za tvorjenje, urejanje,

vzdrževanje, objavljanje in arhiviranje vsebine spletne strani

• CRM (angl. Customer Relationship Management) - poslovna strategija, ki se z

uporabo informacijske tehnologije osredotoča na potrebe strank

• CSS (angl. Cascading Style Sheet) - stilna predloga spletne strani


• HTML (angl. HyperText Markup Language) - označevalni jezik za oblikovanje

večpredstavnostnih dokumentov, ki omogočajo povezave znotraj dokumenta ali

med dokumenti

• HTTP (angl. Hypertext Transfer Protocol) - protokol za izmenjavo nadbesedil in

grafičnih, zvočnih in drugih večpredstavnostnih vsebin na spletu

• HTTPS (angl. Hypertext Transfer Protocol Secure) – protokol, ki je enak HTTP, le da

uporablja zakodirane znake za pošiljanje

• IIOP (angl. Internet Inter-ORB Protocol) - komunikacijski protokol med posredniki

zahtev objekta ORB, ki ga je standardizirala skupina OMG

• IS (angl. Information system) – informacijski sistem

• J2EE (angl. Java 2 Enterprise Edition) – najbolj razširjena platforma Jave za

programiranje strežnikov

• JAAS (angl. Java Authentication and Authorization Service) – Java varnostno

okolje za zagotavljanje varnosti v aplikaciji

• JSF (angl. JavaServer Faces) – je spletna kjnižnica, ki temelji na Java in je

namenjena za spletno programiranje

• JSP (angl. JavaServer Pages) – spletne strani za gradnjo uporabniških vmesnikov,

ki se pretvorijo v servlete

• JSR 227 (angl. Java Specification Requests) – standard za opisno povezovanje in

dostopanje do podatkov

• LDAP (angl. Lightweight Directory Access Protocol) – direktorij, v katerem so

shranjeni uporabniški računi z dovoljenji

• MMS (angl. Multimedia Messaging Service) - SMS, podprt s slikami

• MVC (angl. Model-View-Controller) - arhitektura, kjer so ločeni modelni, pogledni

in kontrolni nivoji

• OASIS (angl. Organization for the Advancement of Structured Information

Standards) – organizacija za napredek standardov za strukturirane informacije


• OLAP (angl. OnLine Analytical Processing) - analiza podatkov v podatkovni bazi,

podatkovnem skladišču

• PHP (angl. PHP Hypertext Preprocessor) - splošno uporaben skriptni programski

jezik, ki razlaga strežnik in je namenjen za izdelavo dinamičnih spletnih strani

• RSS (angl. Really Simple Syndication) - protokol, ki vzpostavlja okolje za objavo

in distribucijo spletnih vsebin v XML-formatu

• SDK (angl. Software Development Kit) - skupek razvijalskih orodij. ki omogočajo

programerju izgradnjo aplikacije

• SMS (angl. Short Message Service) - sistem za pošiljanje sporočil do 160 znakov

po mobilniku

• SQL (angl. Structured Query Language) - strukturiran povpraševalni jezik za delo

s podatkovnimi bazami

• SOA (angl. Service-Oriented Architecture) – storitvena arhitektura, ki dovoljuje

različnim aplikacijam izmenjavo podatkov

• SOAP (angl. Simple Object Access Protocol) - standard za spletne storitve, ki

temelji na XML

• Swing - predstavlja zbirko java knjižnic za gradnjo uporabniških vmesnikov

• XML (angl. eXtensible Markup Language) - format podatkov za izmenjavo

strukturiranih dokumentov v spletu

• UI (angl. user interface) – uporabniški vmesnik

• URL (angl. Uniform Resource Locator) – enoličen naslov za naslavljanje preko

HTTP protokola za dostop do aplikacij

• WAP (angl. Wireless Application Protocol) - protokol za dostop do spletnih strani

z brezžičnimi terminali

• WML (angl. Wireless Markup Language) – jezik, ki temelji na XML jeziku,

namenjen WAP sistemom, ki podpirajo prenos podatkov do telefonov

• WSDL (angl. Web Services Description Language) – jezik, ki temelji na XML

osnovi in podpira oblike za podporo spletnim servisom


• WSRP (angl. Web Service for Remote Portlets) – je protokol za dostop do

oddaljenih spletnih storitev

analiza oracle portala in razvoj spletne aplikacije …

Documents