ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY · Analiza povezljivosti portalnih...

Fakulteta za elektrotehniko, računalništvo in informatiko

Smetanova ulica 17 2000 Maribor, Slovenija

Marko Haložan

ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY

Diplomsko delo

Maribor, avgust 2016

i

ANALIZA POVEZLJIVOSTI PORTALNIH

KOMPONENT NA PLATFORMI LIFERAY

Diplomsko delo

Študent: Marko Haložan

Študijski program: Univerzitetni študijski program

Računalništvo in informatika

Smer: Informatika

Mentor: red. prof. dr. Marjan Heričko

Lektorica: Mateja Rogan

iii

ZAHVALA

Iskreno se zahvaljujem profesorju Marjanu Heričku

za vso podporo in pomoč pri izdelavi diplomske

naloge.

Zahvaljujem se tudi staršem, ki so mi omogočili

študij.

iv

ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY

Ključne besede: informacijski sistemi, portali, portleti, OpenSocial pripomočki, portalni

strežnik Liferay

UDK: 004.414.23(043.2)

Povzetek

Povezljivost med različnimi portalnimi komponentami znotraj enega portala je eno izmed

prizadevanj integracije, s katerimi se usklajujejo aktivnosti integriranih storitev. Pričujoča

naloga analizira mehanizme za povezljivost različnih portalnih komponent na platformi

Liferay. Podrobneje sta predstavljeni portalni komponenti portlet in pripomoček ter

platforma Liferay. Praktični del diplomske naloge zajema razvoj portalne aplikacije z

uporabo portletov in pripomočkov ter različnih mehanizmov integracije.

v

INTEROPERABILITY ANALYSIS OF LIFERAY PORTLETS

Key words: information systems, portals, portlets, OpenSocial gadgets, portal server

Liferay

UDK: 004.414.23(043.2)

Abstract

The interoperability between different portal components within a single portal is one of

the integration’s endeavors with which the actions of integrated services are coordinated.

This thesis analyzes mechanisms for the interoperability of different portal components on

the Liferay platform. The portal components portlet and gadget, and the platform Liferay

are presented in detail. The practical part covers the development of a portal application

with the use of portlets and gadgets, and various integration mechanisms.

vi

KAZALO

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

2 PORTALI ......................................................................................................... 3

2.1 Klasifikacija portalov ........................................................................................................... 3

2.2 Lastnosti portalov ................................................................................................................ 5

2.3 Trg poslovnih portalov ........................................................................................................ 7

3 PORTALNE KOMPONENTE ........................................................................ 12

3.1 Portleti ................................................................................................................................. 12

3.2 Pripomočki OpenSocial ..................................................................................................... 17

4 POSLOVNI PORTAL LIFERAY .................................................................... 22

4.1 Podpora povezljivosti portalnih komponent ................................................................... 27

5 PRAKTIČNI PRIKAZ PORTALA S POVEZANIMI KOMPONENTAMI ......... 28

5.1 Opis portalne aplikacije ..................................................................................................... 28

5.2 Opis atributov analize ........................................................................................................ 32

5.3 Razvoj portletov in njihova povezljivost .......................................................................... 32

5.4 Razvoj pripomočkov in njihova povezljivost ................................................................... 43

5.5 Povezljivost med portleti in pripomočki .......................................................................... 47

5.6 Analiza povezljivosti portalnih komponent ..................................................................... 53

6 SKLEP ........................................................................................................... 58

LITERATURA ...................................................................................................... 59

vii

KAZALO SLIK

Slika 2.1: Magični kvadrant poslovnih portalov za leto 2015 [19]. .......................... 8

Slika 5.1: Osnovna stran spletnega vmesnika storitve Bitbucket. ......................... 29

Slika 5.2: Povezava zahteve z neko spremembo preko komentarja. ................... 30

Slika 5.3: Diagram primerov uporabe portalne aplikacije. .................................... 31

Slika 5.4: Integrirano razvojno okolje Eclipse z vtičnikom Liferay IDE. ................. 33

Slika 5.5: Portalna aplikacija, sestavljena iz portletov. ......................................... 35

Slika 5.6: Urejevalnik pripomočkov OpenSocial. .................................................. 43

Slika 5.7: Portalna aplikacija, sestavljena iz pripomočkov. ................................... 45

KAZALO TABEL

Tabela 4.1: Povzetek matrike združljivosti za portal Liferay EE [13]. ................... 23

Tabela 5.1: Uporaba vzorca MVC pri razvoju portletne aplikacije. ....................... 34

Tabela 5.2: Koraki potrebni za implementacije posamezne povezljivosti. ............ 54

Tabela 5.3: Tehnologije na katerih slonijo mehanizmi za povezljivost. ................. 55

Tabela 5.4: Zmožnosti, ki jih omogočajo posamezni mehanizmi. ......................... 56

viii

IZSEKI PROGRAMSKE KODE

Koda 3.1: Vmesnik Portlet [10]. ............................................................................ 13

Koda 3.2: XML dokument, ki definira pripomoček OpenSocial [11]. ..................... 19

Koda 5.1: Metoda za izbiro mehanizma za povezljivost portletov. ....................... 34

Koda 5.2: Nastavitev javne portletne seje v liferay-portlet.xml. ............................ 36

Koda 5.3: Izsek iz akcijske metode za nastavitev atributa portletne seje. ............ 36

Koda 5.4: Izsek iz izrisovalne metode za pridobitev atributa portletne seje. ......... 37

Koda 5.5: Definicija javnega parametra in njegova podpora v portletih. ............... 38

Koda 5.6: Izsek iz akcijske metode za nastavitev javnega parametra. ................. 38

Koda 5.7: Izsek iz izrisovalne metode za dostop do javnega parametra. ............. 39

Koda 5.8: Definicija dogodka in podpora pošiljanju in prejemanju v portletih. ...... 40

Koda 5.9: Izsek iz akcijske metode za pošiljanje dogodka. .................................. 40

Koda 5.10: Dogodkovna metoda za poslušanje podprtega dogodka. .................. 41

Koda 5.11: Izsek Liferay povezljivosti za pošiljanje sporočil. ................................ 42

Koda 5.12: Izsek Liferay povezljivosti za prejemanje sporočil. ............................. 42

Koda 5.13: Definicija izdajatelja za mehanizem objavi – naroči. .......................... 46

Koda 5.14: Izsek objave sporočila v tematiko mehanizma objavi – naroči. .......... 46

Koda 5.15: Definicija naročnika za mehanizem objavi – naroči. ........................... 47

Koda 5.16: Izsek naročila na tematiko iz mehanizma objavi – naroči. .................. 47

Koda 5.17: Izsek objave sporočil iz portleta v tematiko pripomočkov. .................. 48

Koda 5.18: Izsek naročila na tematiko pripomočkov iz portleta. ........................... 49

Koda 5.19: Implementacija sporočilnega strežnika Faye. .................................... 51

Koda 5.20: Izsek objave sporočila v sporočilni strežnik Faye. .............................. 51

Koda 5.21: Izsek naročila na tematiko v sporočilnem strežniku Faye .................. 52

Koda 5.22: Izsek shranjevanja sporočila v lokalno shrambo brskalnika. .............. 53

Koda 5.23: Izsek branja sporočila iz lokalne shrambe brskalnika. ........................ 53

ix

UPORABLJENE KRATICE

XML – Extensible Markup Language

HTML – Hyper Text Markup Language

XHTML – Extensible Hypertext Markup Language

CSS – Cascading Style Sheet

JSON – JavaScript Object Notation

AJAX – Asynchronous JavaScript and XML

JSP – JavaServer Pages

API – Application Programming Interface

MVC – Model View Controller

IDE – Integrated Development Environment

SDK – Software Development Kit

URL – Uniform Resource Locator

JRE – Java Runtime Environment

Java EE – Java Platform Enterprise Edition

Analiza povezljivosti portalnih komponent na platformi Liferay

1

1 UVOD

Živimo v hitro spreminjajočem se poslovnem okolju, kjer je učinkovita raba informacij in

tehnologij, ki te informacije zagotavljajo, nujna za doseganje konkurenčnosti. V takem

okolju morajo podjetja, bolj kot kdajkoli prej, zagotoviti prave informacije ob pravem času

ter te dostaviti pravim ljudem v takšni obliki, da so ti sposobni sprejemati prave odločitve.

Vendar ta naloga ni enostavna, saj so te informacije zakopane v različnih informacijskih

virih, do katerih podjetja dostopajo z uporabo različnih, med seboj pogosto nezdružljivih,

tehnologij. Znotraj podjetij zato prihaja do zastojev, saj se vse preveč časa uporabi za

iskanje informacij namesto za izvajanje danih nalog.

V praksi so se kot rešitev temu izzivu uveljavili poslovni portali kot posebna oblika portalov

znotraj podjetja. Eden izmed glavnih vzrokov za njihovo uporabo je sposobnost integrirati

in povezati obstoječe sisteme ter jih na enem mestu v enotni in prilagojeni obliki ponuditi

uporabnikom. Integracijo omogočajo z uporabo samostojnih portalnih komponent.

Portalne komponente portali uporabljajo kot vtične komponente uporabniškega vmesnika,

ki zagotavljajo storitve ali informacije integriranih sistemov. Portali portalne komponente

združujejo v portalne strani. Portalne strani lahko uporabnik z dodajanjem, prilagajanjem

ali odstranjevanjem portalnih komponent prilagaja svojim delovnim navadam in potrebam.

Portalne komponente se v portalu izvajajo neodvisno ena od druge, zato se običajno

komponente ne odzivajo na spremembe, ki se zgodijo na drugih komponentah na portalni

strani. Čeprav naj bi portalne strani predstavljale sklop logično povezanih portalnih

komponent, imajo uporabniki portala vseeno občutek, da uporabljajo različne

»nepovezane« aplikacije. Za izboljšanje uporabniške izkušnje je potrebno omogočiti

povezljivost portalnih komponent. Portalne komponente je potrebno povezati, tako da

lahko te med seboj komunicirajo oz. izmenjujejo podatke. Povezane portalne komponente

dajejo uporabniku portala občutek, da uporablja samo eno in ne več različnih aplikacij. Pri

tem ne obstaja neka univerzalna rešitev, ampak različne portalne komponente in portali

uporabljajo različne mehanizme, da zagotovijo medsebojno povezavo portalnih

komponent. Zato je zagotavljanje povezljivosti med portalnimi komponentami relativno

zahtevna naloga, še posebej, če je cilj doseči povezljivost med portalnimi komponentami,

ki uporabljajo različne tehnologije.


2

Namen diplomske naloge je analizirati povezljivost portalnih komponent. Cilj je spoznati

različne tehnologije portalnih komponent in mehanizme, ki jih te komponente uporabljajo

za medsebojno povezovanje. Konkretno bo v diplomskem delu raziskana povezljivost

portalnih komponent, ki so skladne s tehnologijo Java portletov (angl. Portlets) in

družbenih pripomočkov (angl. OpenSocial Gadgets). Cilj je ti tehnologiji uporabiti za razvoj

portalnih komponent in preizkus na portalnem ogrodju Liferay. Zanimalo nas je, kakšni

mehanizmi se uporabljajo za povezljivost portalnih komponent. Uporabljene mehanizme

smo analizirali iz vidika razvoja, njihovih zmožnosti, uporabljenih tehnologij in uporabniške

izkušnje v okviru portala.

V drugem poglavju bomo najprej predstavili zgodovino portalov, jih poizkušali klasificirati

in definirati njihove lastnosti. Analizirali bomo tudi trg komercialnih in odprtokodnih

portalnih strežnikov.

V tretjem poglavju bomo opisali portalne komponente, ki jih bomo uporabili za razvoj

portalne aplikacije. Opisali bomo portlete in pripomočke OpenSocial, pri tem pa bomo

posebno pozornost posvetili njihovi povezljivosti.

Četrto poglavje je namenjeno predstavitvi poslovnega portala Liferay. Opisali bomo

glavne lastnosti in funkcionalnosti ter dodatne možnosti, ki jih portal Liferay ponuja za

povezljivost portalnih komponent.

V petem poglavju predstavimo portalno aplikacijo in funkcionalnost, na kateri bomo

analizirali povezljivost portalnih komponent. Razvili bomo portalno aplikacijo, sestavljeno

iz portletov in pripomočkov, na podlagi katere bomo naredili analizo povezljivosti med

portleti in pripomočki. Na koncu bomo primerjali analizirane mehanizme za povezljivost

portalnih komponent in izbrali najbolj primernega za povezljivost različnih portalnih

komponent v okviru portala Liferay.


3

2 PORTALI

Iz vidika informacijske tehnologije se pojem »portal« prvič pojavi konec devetdesetih let

prejšnjega stoletja [7]. Prvotno se je portal omenjal izključno v povezavi s spletnimi

iskalniki (npr. Yahoo!, Altavista), katerih osnovni namen je bil zagotoviti navigacijo do

informacij, razpršenih po svetovnem spletu. Spletni iskalniki so poleg osnovne storitve

iskanja kmalu zagotavljali dodatne storitve, kot so komuniciranje, virtualne skupnosti,

poosebljeno iskanje (npr. My Yahoo!, iGoogle) in dostop do specializiranih in komercialnih

vsebin. Ta koncept spletnega iskalnika danes imenujemo spletni portal [2]. Portali pa niso

ostali samo v domeni interneta, ampak so se uveljavili tudi v okviru podjetij, kjer jih

imenujemo poslovni portali (angl. Enterprise Portals).

Prva definicija portalov sega v leto 1998, ko sta Shilakes in Tyleman iz podjetja Merrill

Lynch prva predstavila koncept poslovnega portala kot [27]: »Informacijski portal podjetja

je programska rešitev, ki omogoča podjetju, da odklene notranje in zunanje shranjene

informacije in nudi uporabnikom enotno pot do poosebljenih informacij, ki jih potrebujejo

za sprejemanje poslovnih odločitev.«

Čeprav osnovna definicija še vedno drži, se portali kot koncept in tehnologija nenehno

razvijajo in spreminjajo. Zato so se skozi čas razvili različni tipi portalov z različnimi

funkcionalnostmi, vlogami in storitvami; vsak prilagojen določenim zahtevam.

2.1 Klasifikacija portalov

Portali so nameščeni v različnih okoljih. Zato lahko razlikujemo različne tipe portalov. V

literaturi najdemo različne klasifikacije portalov. Ker ni splošne klasifikacije portalov,

mnogo avtorjev predlaga široko klasifikacijo na podlagi specializacije. Ločimo horizontalne

in vertikalne portale [7][30]:

• Horizontalni portali: nudijo različne storitve in vsebine iz različnih področij.

Namenjeni so širokemu krogu uporabnikov, zato njihova ponudba sledi splošnim

interesom. Primer takšnega portala je My Yahoo!, ki nudi široko ponudbo

informacij, ki pokrivajo različne tematike (novice, šport, gospodarstvo itd.).

• Vertikalni portali: imenujemo jih tudi »vortali«. So specializirani za določeno

področje in ponujajo podrobno vsebino določene branže (finance, trgovanje,


4

računalništvo itd). Namenjeni so ozki skupini uporabnikov oz. skupnosti, ki jih

zanima določeno področje. Primer vertikalnega portala je eBay, ki pokriva

področje trgovanja in je specializiran za spletno dražbo in nakupovanje.

Podobno široko delitev predlagajo Gurzki, Hinderer in Eberhard, ki razlikujejo med

spletnimi in poslovnimi portali [30]:

• Spletni portali: predstavljajo vstopno točko do svetovnega spleta. Glavna

značilnost spletnih portalov je njihova odprtost, saj lahko njihove storitve uporablja

vsakdo.

• Poslovni portali: so namenjeni zaprti skupini uporabnikov, ki jih zanimajo vsebine

določenega podjetja. Poleg vertikalno ponujenih informacij, poslovni portali

ponujajo tudi številne storitve, povezane s poslovanjem podjetja, ki so

horizontalne narave.

Poslovne portale lahko naprej delimo na podlagi ciljne skupine uporabnikov, ki jih

naslavljajo. Razlikujemo med potrošniškimi, partnerskimi in poslovnimi portali,

namenjenim zaposlenim [30].

• Potrošniški portali (angl. Business to Customer, B2C): njihov namen je

posredovati kupcem informacije o produktih in storitvah, na podlagi katerih se ti

odločajo oziroma nakupujejo. Ideja teh portalov je privabiti, zbirati informacije o

kupcih in njihovih potrebah, obveščati o novostih itd.

• Partnerski portali (angl. Business to Business, B2B): so namenjeni izmenjavi

informacij in sklepanju poslov med podjetji (npr. dobavitelji, razvijalci, poslovnimi

partnerji itd.). Ideja teh portalov je direktno povezana s pojmom elektronsko

poslovanje (angl. eBusiness), zato ima v teh portalih varnost pomembno vlogo.

• Poslovni portali, namenjeni zaposlenim (angl. Business to Employee, B2E): so

jedro intraneta. Zaposlenim znotraj organizacije zagotavljajo dostop do poslovnih

informacij, aplikacij, znanj, izboljšujejo poslovne procese in povezave med

zaposlenimi. Namen teh portalov je izboljšati učinkovitost zaposlenim in

posledično same organizacije.

Poslovne portale lahko na podlagi funkcionalnosti, ki jih zagotavljajo, delimo, na

informacijske, aplikacijske in portale znanja [30]:

• Poslovni informacijski portali (angl. Enterpris Information Portal, EIP): predstavljajo

enotno vstopno točko do informacij, ki so pomembne za posameznika in podjetje.


5

Na osnovi poosebljenega dostopa omogočajo dostavo informacij, ki jih zaposleni

potrebujejo pri vsakodnevnih opravilih. Namen informacijskih portalov je prihraniti

čas, ki ga zaposleni potrebujejo pri iskanju relevantnih informacij, saj so

informacije dostopne na enem mestu – portalu.

• Poslovni aplikacijski portali (angl. Enterpris Application Portals, EAP): so portali,

katerih glavna lastnost je integracija aplikacij in poslovnih sistemov v enoten

vmesnik, ki preko različnih tehnologij in točno definiranih vmesnikov dostopa do

zunanjih informacij. Naloga portala je, da centralizira dostop do aplikacij in nudi

enoten pogled na različne aplikacije, ki jih združuje. Ključni koncept aplikacijskih

portalov je integracija poslovnih aplikacij (angl. Enterprise Application Integration,

EAI), to pomeni, da lahko integrirajo obstoječe aplikacije, ki so zgrajene okrog

različnih tehnologij.

• Poslovni portali znanja (angl. Enterprise Knowledge Portals, EKP): so portali, na

katere so vplivali cilji upravljanja znanja. So ozko specializirani za posamezno

področje in zato namenjeni samo določenim uporabnikom. Podpirajo

posameznike in skupine pri aktivnostih, ki so potrebne pri reševanju problemov,

tako da jim zagotovijo dostop do znanja in hkrati možnosti za njegovo izmenjavo.

Osnovni namen portalov znanja je sposobnost zbiranja, upravljanja in deljenja

znanja med zaposlene, tako da zagotavlja okolja, ki omogoča ustvarjanje znanja v

organizaciji.

V praksi tipičen poslovni portal vključuje elemente vseh tipov portalov [30]. Kot platforma

se portali nenehno razvijajo in pridobivajo vedno nove funkcionalnosti, zato je meja med

posameznimi tipi portalov vedno bolj zabrisana. Poslovni portali tako pridobivajo širino, saj

lahko pokrivajo različna tehnična, organizacijska in poslovna področja znotraj in zunaj

podjetja.

2.2 Lastnosti portalov

Poslovni portali zagotavljajo širok nabor funkcionalnosti. Nabor funkcionalnosti je

sestavljen iz »standardnih« oz. osnovnih funkcionalnosti, ki so bolj ali manj skupne vsem

portalom, in funkcionalnosti, ki so specifične za okolje, v katerem je portal implementiran.

V nadaljevanju so predstavljene funkcionalnosti, ki so skupne večini portalov [8] [7]:


6

• Enotna prijava: omogoča uporabnikom, da z enkratno avtentikacijo v portal

pridobijo avtorizacijo do aplikacij in storitev znotraj portala, glede na dodeljeno

vlogo.

• Poosebitev: omogoča uporabnikom portala, da prilagodijo prikaz vsebine na

portalni strani glede na svoje osebne potrebe in vloge. Skladno z vlogami in

pravicami, mehanizmi za poosebitev omogočajo uporabnikom prejemanje in

upravljanje specifičnih vsebin v smislu kreiranja lastnih zavihkov, prilagajanje

vsebine ter dodajanje novih portletov iz repozitorija obstoječih portletov.

• Taksonomija: ali kategorizacija zagotavlja obvladovanje in razumevanje vsebine

portala ter zajema kategorije, specifične za organizacijo. Uporabniku omogoča

hiter in enostaven način dostopa do želenih vsebin z vsebinskimi kategorijami, ki

so izključujoče, razumljive in nedvoumne z vidika končnega uporabnika.

Mehanizmi za definiranje taksonomije omogočajo definiranje strukture, kamor se

razvršča vsebina na podlagi pravil in metapodatkov.

• Predstavitev: zagotavlja spletni uporabniški vmesnik, ki je sestavljen iz množice

portletov, samostojnih komponent, ki uporabnikom omogoča prikaz vsebin in

funkcionalnosti v različnih oblikah in na različnih napravah.

• Upravljanje vsebine: vključuje izdelavo, urejanje, objavo in odstranjevanje

poljubnih vsebin ter njihov nadzor v okviru portala.

• Iskanje: je osnovna funkcionalnost portalov, ki omogoča uporabnikom, da

učinkovito najdejo informacije v podjetju. Portal je zasnovan tako, da pridobiva

informacije iz virov, ki se lahko nahajajo v različnih oblikah ali lokacijah. Neodvisno

od virov portal omogoča uporabnikom enotno iskanje, ki je lahko prilagojeno

njihovim vlogam in poosebitvenim referencam.

• Sodelovanje in komunikacija: se lahko izvaja preko različnih orodij, kot so forumi,

wikiji, elektronska pošta, aplikacije za takojšnje sporočanje, izmenjava datotek,

video konference itd. Preko teh orodij poteka sodelovanje med posamezniki,

opravljanje timskega dela in oblikovanje navideznih skupnosti. Takšna izmenjava

informacij lahko poteka na sinhron ali asinhron način.

• Integracija: omogoča povezavo z obstoječimi poslovnimi informacijskimi viri, kot

so podatkovne baze, poslovni sistemi, ki se nahajajo na različnih lokacijah v

podjetju. Portal mora omogočati različne integracijske mehanizme za povezavo s

temi informacijskimi viri.


7

• Administracija: omogoča dostop do podpornih sistemom portala in spreminjanje

njihovih nastavitev ter zajema aktivnosti, povezane z vzdrževanjem portalnega

sistema in funkcionalnostjo poosebitve.

• Varnost: se odraža v nadzoru na način, kdo je v portal prijavljen in na podlagi tega

omogoča dostop do ustreznih virov in funkcionalnosti portala. Portali so integriran;

z različnimi varnostnimi mehanizmi, ki na podlagi enotne prijave uporabniku

omogočijo dostop do virov in funkcionalnosti portala, pri tem pa je pomembno tudi

zagotavljanje varnega prenosa podatkov z različnimi varnostnimi mehanizmi, kot

so šifriranje, digitalni podpisi, certifikati itd.

2.3 Trg poslovnih portalov

Trg poslovnih portalov je od svojega nastanka, konec devetdesetih let, pa do danes prešel

skozi številna obdobja razvoja [19]. Rezultat teh obdobij se danes odraža v relativno

stabilnem trgu poslovnih portalov, ki ga obvladujejo maloštevilni veliki ponudniki

programske opreme s svojimi portalnimi rešitvami. Z vzponom odprte kode1 so se na trgu

poslovnih portalov uveljavile tudi odprtokodne portalne rešitve. Odprtokodni portali

predstavljajo alternativo komercialnim portalom, ki jih ponujajo veliki ponudniki

programske opreme, v nasprotju s slednjimi njihov poslovni model ne temelji na trženju

oz. licenciranju portalnega produkta, ampak na trženju storitev, ki so povezane z njim [32].

V podjetju Gartner, ki se ukvarja z raziskavami in svetovanji, vsako leto raziščejo stanje

na trgu poslovnih portalov, ki ga predstavijo v magičnem kvadrantu za horizontalne

portalne produkte2. Magični kvadrant za leto 2015, na sliki 2.1, prikazuje, da so veliki

ponudniki programske opreme (Microsoft, IBM, Oracle in SAP) tudi vodilni ponudniki

poslovnih portalov z izjemo odprtokodnega portala Liferay [19].

1 Odprta koda (angl. Open Source): je zelo splošen pojem, ki pomeni, da je s programsko opremo

na voljo tudi izvorna koda, kot ga definira iniciativa »Open Source Initiative« 2 Magični kvadrant za horizontalne portalne produkte (angl. Magic Quadrant for Horizontal Portal

Product): prikazuje dvodimenzionalno matriko trga poslovnih portalov, ki ocenjuje ponudnike portalov glede na njihovo dovršenost vizije in sposobnost, da jo izvedejo.


8

Slika 2.1: Magični kvadrant poslovnih portalov za leto 2015 [19].

2.3.1 Komercialni portali

Številni ponudniki programske opreme imajo na voljo svoje komercialne portalne rešitve.

Za podjetja so ti portali zanimivi iz vidika integracije, stabilnosti in zagotavljanja podpore

ter manj iz finančnega vidika. Komercialni portali so zgrajeni okrog tehnologij, ki

omogočajo enostavno in celovito integracijo s produkti določenega ponudnika, zato je

zagotovljena visoka stopnja stabilnosti in podpore za te produkte. Iz finančnega vidika ti

portali zahtevajo velik finančni vložek v smislu visokih licenčnin. Največja prednost

komercialnih portalov, enostavna in celovita integracija, je tudi njihova največja slabost,

saj so podjetja, ki nabavijo tak produkt, v veliki meri vezana na produkte določenega

ponudnika programske opreme. Zato je pomembno, da komercialni portali nudijo podporo

odprtim standardom, ki lahko zagotovijo integracijo s produkti ostalih ponudnikov [32].

V magičnem kvadrantu prevladujejo uveljavljene komercialne portalne rešitve velikih

ponudnikov programske opreme, med njimi lahko izpostavimo rešitvi podjetja Microsoft in

IBM [19].


9

SharePoint: je komercialna spletna platforma podjetja Microsoft, ki jo organizacije

uporabljajo za gradnjo portalnih rešitev. Poleg osnovnih portalnih funkcionalnosti je glavna

značilnost okolja SharePoint, da v zaključeno celoto združuje upravljanje vsebin in

dokumentov s sodelovanjem, socialnim mreženjem in poslovnim sporočanjem. Posledično

zagotavlja tesno integracijo z ostalimi produkti v portfelju ponudnika, kot so pisarniška

orodja Office, poštni strežnik Exchange in strežnik za komunikacijo in sodelovanje Lync.

SharePoint je zgrajen okrog Microsoftovih tehnologij, zato za svoje delovanje potrebuje

platformo Windows Server, spletni strežnik IIS in podatkovno bazo SQL Server [19]. Svoje

zmožnostmi lahko SharePoint razširi z dodajanjem komponent Web Part in spletnih

aplikacij, imenovanih Apps. Za razvoj obojih se uporablja integrirano razvojno orodje

Visual Studio. Apps za SharePoint so na voljo tudi preko storitve Office Store, ki omogoča

njihovo objavo, nakup in namestitev. Microstoft za SharePoint zahteva licenciranje

strežnika kot tudi uporabnikov in naprav, ki dostopajo do njega [31].

WebSphere Portal: je portalna rešitev podjetja IBM, ki omogoča podjetjem gradnjo

zanesljivih in prilagodljivih poslovnih portalov, osnovanih na platformi Java. Portal je del

programske platforme WebSphere. Poleg standardnih funkcionalnosti, kot so iskanje,

sodelovanje, upravljanje vsebin in dokumentov ipd., portalu WebSphere platforma

zagotavlja celo vrsto tehnologij, ki omogočajo portalu integracijo z aplikacijami in

storitvami. Zgrajen je na odprtih standardih, kar portalu omogoča uporabo in gradnjo na

obstoječi informacijski infrastrukturi. Svoje funkcionalnosti lahko portal razširi z

vključevanjem portletov, pripomočkov in lastnih gradnikov. Za razvoj portletov in

prilagajanje portala se uporablja integrirano razvojno okolje Rational Application

Developer, ki je osnovano na odprtokodnem ogrodju Eclipse. Na voljo je tudi storitev

Business Solutions Catalog, ki omogoča dostop do portletov, ki zagotavljajo integrirajo s

poslovnimi rešitvami različnih dobaviteljev programske opreme. IBM omogoča licenciranje

WebSphere portala glede na število uporabnikov ali procesorskih enot [9].

2.3.2 Odprtokodni portali

Z uveljavljanjem odprte kode v poslovnih okoljih so odprtokodni poslovni portali postali

sprejemljiva alternativa komercialnim poslovnim portalom. Odprtokodni poslovni portali so

za podjetja zanimivi iz finančnega in tehnološkega vidika. Iz finančnega vidika zato, ker

sam odprtokodni portal predstavlja zanemarljivi strošek v primerjavi s komercialnim


10

portalom. Ponudniki odprtokodnih portalov svojih prihodkov ne ustvarjajo s trženjem

portalnega produkta, ampak s ponujanjem storitev, ki se oblikujejo okoli samega

portalnega produkta (npr. podpora, svetovanja in razširitve ali pa to podporo zagotavlja

skupnost uporabnikov), zato odprtokodni portali niso nujno zastonj, saj morajo podjetja

poleg cene samega portala posebej upoštevati stroške razvoja, podpore in vzdrževanja

takega produkta. Tehnološki vidik predstavlja fleksibilnost pri izbiri infrastrukture (strojna

oprema, operacijski sistem, aplikacijski strežnik, podatkovna baza), ki jo portal potrebuje

za svoje delovanje, in skladnost s standardi, ki omogočajo integracijo s standardiziranimi

storitvami. Slabost odprtokodnih poslovnih portalov predstavlja podpora integraciji s

komercialnimi produkti, zlasti ker ti uporabljajo lastniške programske vmesnike in

mehanizme za povezovanje [32].

V magičnem kvadrantu je prisotna tudi odprtokodna portalna rešitev podjetja Liferay v

vlogi vodilnega ponudnika [19].

Liferay Portal: je odprtokodni poslovni portal zasnovan na Java platformi in distribuiran

pod odprtokodno GNU Lesser General Public License (LGPL)3 licenco ali alternativno

komercialno licenco. Liferay Portal je sestavljen iz portala, sistema za upravljanje vsebin

in dokumentov ter storitev, ki omogočajo sodelovanje in socialno mreženje. Deluje na

različnih odprtokodnih in komercialnih aplikacijskih strežnikih, podatkovnih bazah in

operacijskih sistemih. Portal je zgrajen na različnih preizkušenih odprtokodnih

tehnologijah in standardih, ki omogočajo enostavno integracijo z obstoječimi aplikacijami

in sistemi. Svoje osnovne funkcionalnosti lahko portal razširi z dodajanjem portletov in

pripomočkov. Za razvoj lastnih portletov in prilagoditev portala se lahko uporabi lastno

integrirano razvojno okolje Liferay Developer Studio ali katerokoli drugo orodje za razvoj

standardnih portletov (npr. Eclipse in Netbeans). Portleti in prilagoditve portala so na voljo

tudi v Liferay tržnici (angl. Liferay Marketplace), ki zagotavlja centralno mesto za deljenje,

brskanje in nalaganje različnih portalnih razširitev, ki omogočajo dodatne funkcionalnosti

[12].

Na trgu najdemo poslovne portale, zgrajene v različnih tehnologijah, kot so Java, .Net ali z

uporabo različnih skriptnih jezikov (npr. PHP, JavaScript idr.). Med vodilnimi poslovnimi

portali prevladujejo portali, osnovani na javanski tehnologiji. Razlog za njihovo razširjenost

3 GNU Lesser General Public License (LGPL): je licence za prosto programje, ki dovoljuje

vključevanje tako licencirane programske opreme v prosto in lastniško programsko opremo.


11

gre iskati v zrelosti Java tehnologije, katera se odraža v obliki portletne specifikacije, ki

natančno definira Java portlete kot komponente Java portalov. Po drugi strani so svojo

mesto na portalnem trgu našli tudi odprtokodni portali. Sprejetje odprte kode v podjetjih je

spodbudilo razvoj inovativnih produktov s poudarkom na prilagodljivosti, uvajanju novih

tehnologij in standardov. Odprtokodni portali so postali bolj ali manj funkcionalno

primerljivi s komercialnim, vendar so se sposobni hitreje odzvati na nove zahteve trga v

primerjavi z komercialnimi portali.


12

3 PORTALNE KOMPONENTE

Poslovni portali lahko v portalno stran vključijo različne portalne komponente. Portal

Liferay podpira uporabo Java portletov in OpenSocial pripomočkov. Čeprav se omenjeni

portalni komponenti iz uporabniškega vidika ne razlikujeta, sta tehnološko gledano precej

različni. V nadaljevanju bomo podrobneje predstavili omenjeni portalni komponenti.

3.1 Portleti

Portlet je spletna aplikacija, ki zagotavlja del vsebine (informacije ali storitve), ki se vključi

kot del portalne strani. Z njim upravlja portletni vsebnik, ki skrbi za obdelavo zahtev in

generiranje dinamične vsebine. Portlete uporabljajo portali kot vtične komponente

uporabniškega vmesnika, ki zagotavljajo predstavitveni sloj informacijskega sistema.

Vsebina, ki jo generira portlet, se imenuje fragment. Fragment je del opisnega jezika (npr.

HTML, XHTML), ki skupaj z drugimi fragmenti, navadno so to fragmenti drugih portletov,

sestavlja portalno stran [10].

Portalni standardi zagotavljajo interoperabilnost in prenosljivost portletov med združljivimi

portalnimi strežniki. Ker so portleti neodvisne in ponovno uporabne vtične komponente, se

lahko ponovno uporabijo na različnih okoljih, platformah in strežnikih. Standarda, ki

specificirata portlete, sta [26]:

• JSR 168: je portletna specifikacija 1.0, ki zagotavlja interoperabilnost med portleti

in portali. Specifikacija definira povezavo med portletnim vsebnikom, portleti in

programskimi vmesniki, ki naslavljajo poosebitev, predstavitev in varnost.

• JSR 286: je portletna specifikacija 2.0, ki je nastala kot rezultat ugotovljenih

pomanjkljivosti portletne specifikacije 1.0. Specifikacija specificira nove

funkcionalnosti kot so: povezljivost med portleti, uporaba dinamično generiranih

virov idr. Poleg tega ostaja portletna specifikacija 2.0 binarno združljiva z 1.0.

Portletna specifikacija je bila razvita v okviru Java Community Process (JCP). V ekspertni

skupini, ki je odgovorna za razvoj specifikacije, je večina vodilnih podjetij komercialnih in

odprtokodnih portalov. Trenutno poteka razvoj portletne specifikacije 3.0, ki se razvija pod

imenom JSR 362.


13

Življenjski cikel portleta

Upravljanje portleta poteka skozi življenjski cikel portleta, ki definira faze nalaganja

portleta, kreiranja njegove instance, inicializacije, obdelave zahtevkov in njegove

odstranitve iz uporabe ob koncu življenjskega cikla [10].

Življenjski cikel portleta je izražen skozi metode init, processAction, render in destroy

vmesnika Portlet (koda 3.1).

public abstract interface Portlet {

public abstract void init(PortletConfig paramPortletConfig) throws PortletException;

public abstract void processAction(ActionRequest paramActionRequest,

ActionResponse paramActionResponse) throws PortletException, IOException;

public abstract void render(RenderRequest paramRenderRequest,

RenderResponse paramRenderResponse) throws PortletException, IOException;

public abstract void destroy();

}

Koda 3.1: Vmesnik Portlet [10].

Portletni vsebnik upravlja življenjski cikel portleta, tako da kliče ustrezne metode vmesnika

Portlet. Življenjski cikel portleta je sestavljen iz naslednjih korakov [10]:

Življenjski cikel portleta nastopi, ko portletni vsebnik naloži in kreira instanco

portleta. To se lahko zgodi ob zagonu portletne aplikacije ali pa se zgodi z

zamikom šele takrat, ko portletni vsebnik ugotovi, da je portlet potreben za

obdelavo zahtevka.

Ko je instanca portleta naložena, mora vsebnik portlet inicializirati, šele takrat

lahko od njega zahteva obdelavo zahtevkov. Vsebnik portlet inicializira z enkratnim

klicem metode init. V tej portlet poskrbi za inicializacijo časovno ali drugače

zahtevnih opravil (npr. povezave do zalednih virov) in izvedbo t. i. enkratnih

aktivnosti, ki jih je potrebno v življenjskem ciklu portleta izvesti samo enkrat.

Po uspešni inicializaciji instance portleta lahko portletni vsebnik od portleta

zahteva obdelavo zahtevkov odjemalcev. Vmesnik Portlet s processAction in

render definira dve osnovni metodi, namenjeni obdelavi zahtevkov. Poleg


14

osnovnih metod sta na voljo še dve dodatni metodi življenjskega cikla portleta:

metoda za obdelavo dogodkov processEvent in metoda streženje virov

serveResource.

o V primeru, ko portletni vsebnik kliče metodo processAction, je zahtevek

obravnavan kot akcijski zahtevek (angl. ActionRequest). Na podlagi

parametrov akcijskega zahtevka lahko portlet spremeni svoje stanje.

Sprememba stanja povzroči sprememba vsebine, ki jo ponuja portlet. Iz

tega razloga portalni strežnik preko zahteve za izrisovanje (angl.

RenderRequest) posodobi vsa portalna okna na portalni strani. Portletni

vsebnik na podlagi zahteve za izrisovanje kliče metodo render nad vsemi

portleti, razen tistimi, ki so predpomnjeni, in zbere njihove fragmente.

Portalni strežnik nato združi fragmente portletov v portalno stran.

o Zahteva za izrisovanje lahko nastopi tudi brez predhodnega akcijskega

zahtevka (npr. ponovni prikaz portalne strani). Ko portletni vsebnik

posreduje zahtevo za izrisovanje določenemu portletu, ta tipično generira

fragment na podlagi trenutnega stanja. V sklopu zahteve za izrisovanje

portlet ne more spreminjati svojega stanja, to lahko stori le v sklopu

akcijskega zahtevka.

o Portletni vsebnik kliče metodo processEvent, ko pride do medportletne

komunikacije na osnovi dogodkov. Ko se obdelava dogodka zaključi, se

sproži zahteva za izrisovanje.

o Ko portletni vsebnik kliče metodo serveResource, se portletu omogoči

generiranje vsebine na osnovi trenutnega stanja. Portletni vsebnik ima

vlogo posrednika, saj ne sme spreminjati vsebine, ki jo vrne portlet. Klic te

metode se uporablja za generiranje vsebine, kot so JSON, XML ali v

primeru uporabe tehnologije AJAX.

Ko portletni vsebnik presodi, da določeni portlet ni več potreben, ga odstrani iz

uporabe, tako da kliče metodo destroy. Metoda poskrbi za sprostitev virov, ki jih je

zasedal portlet tekom svojega življenjskega cikla. Po klicu metode destroy mora

vsebnik poskrbeti, da ob morebitnem novem zahtevku ustvari nov primerek

portleta.

Portletni način (angl. Portlet Mode)

Način portleta definira funkcijo, ki jo portlet opravlja. Portleti namreč opravljajo različna

opravila in generirajo različno vsebino glede na funkcijo, ki jo v tistem trenutku opravljajo.


15

Način portleta predlaga portletu, kakšno opravilo naj izvaja in kakšno vsebino naj

generira. Portletna specifikacija definira tri načine portleta, ki jih mora podpreti vsak portal

[10][26]:

Pogled (angl. View): je osnovni način, v katerem portlet generira vsebino, ki

odraža trenutno stanje portleta.

Urejanje (angl. Edit): je način delovanja, ki uporabnikom omogoča prilagajanje

obnašanja portleta.

Pomoč (angl. Help): je način delovanja, ki zagotavlja pomoč pri uporabi portleta.

Vsak portlet mora podpreti najmanj način Pogled, medtem ko sta načina Urejanje in

Pomoč opcijska. Poleg omenjenih načinov lahko ponudniki portalov definirajo svoje

portletne načine.

Stanje okna (angl. Windows State)

Portalni strežnik za vsak portlet na portalni strani generira okno. Stanje okna je pokazatelj,

ki določa, koliko prostora na portalni strani bo dodeljeno vsebini, ki jo generira portlet.

Portlet lahko to informacijo uporabi, da prilagodi količino prikazanih informacij. Portlet

lahko stanje okna spremeni v sklopu akcijskega zahtevka. Portletna specifikacija definira

tri stanja okna [10][26]:

Normalno (angl. Normal): je privzeto stanje okna, ki omogoča, da si portlet

portalno stran deli z drugimi portleti.

Razprto (angl. Maximized): je stanje okna, v katerem portlet zaseda celotno

portalno stran.

Skrčeno (angl. Minimized): je stanje okna, v katerem portlet prikazuje minimalno

vsebino ali pa je celo brez nje.

Poleg omenjenih stanj lahko ponudniki portalov definirajo svoja stanja okna.

Trajno in začasno shranjevanje uporabniški podatkov

Portletna specifikacija definira različne metode za hranjenje uporabniških podatkov, bodisi

trajno ali začasno za čas trajanja uporabniške seje.

Portlet lahko uporabniško specifične podatke trajno hrani v objektu PortletPreferences.

Podatki v objektu so dostopni za branje ali pisanje v sklopu akcijskega zahtevka in branje

v sklopu zahteve za izrisovanje. Objekt hrani podatke v parih, ki so sestavljeni iz


16

vrednosti, ki so lahko niz ali polje nizov in povezani s ključem. Privzete vrednosti parov so

lahko predhodno specificirane v namestitvenem deskriptorju portleta [10][26].

Za začasno hranjenje podatkov, v okviru uporabniške seje, portletna specifikacija definira

vmesnik PortletSession. V sejo portlet shrani podatke, tako da ga objekt, ki nosi podatke,

poveže z atributom seje preko imena. Vmesnik definira dva obsega, kamor lahko portleti

shranjujejo atribute, in sicer aplikacijski in portletni obseg. Omenjena obsega sta na voljo

kot konstanti APPLICATION_SCOPE in PORTLET_SCOPE vmesnika PortletSession.

Atributi v aplikacijskem obsegu so na voljo vsem portletom znotraj portletne aplikacije,

medtem ko so atributi v portletnem obsegu na voljo samo portletu, ki jih je shranil [10][26].

Pakiranje in namestitev portletov

Pakiranje in namestitev portletne aplikacije je specificirano kot del standardnega arhiva

spletne aplikacije WAR (angl. Web Application Archive), ki vsebuje vse vire, portlete in

namestitvena deskriptorja, pakirana v eni datoteki. Takšno pakiranje poleg standardnega

namestitvenega deskriptorja web.xml, ki specificira spletne vire, vsebuje tudi dodatni

namestitveni deskriptor portlet.xml, ki specificira vse portlete in z njimi povezane

nastavitve. Posledica dveh namestitvenih deskriptorjev je namestitev portletne aplikacije v

dveh korakih, ki zajema namestitev spletne aplikacije v aplikacijski strežnik in namestitev

portletov v portalni strežnik [10].

3.1.1 Povezljivost portletov

Portleti so samostojne komponente na portalni strani. Da bi portlete na portalni strani

povezali v povezano aplikacijo, potrebujemo način, da zagotovimo povezljivost med

portleti. Portletna specifikacija omogoča povezljivost portletov preko treh mehanizmov:

portletne seje, javnih parametrov in portletnih dogodkov [23].

Portletna seja (angl Portlet Session)

Povezljivost med portleti lahko dosežemo z uporabo mehanizma za začasno shranjevanje

uporabniških podatkov. Vsak portlet ima namreč svojo portletno sejo in atributi v portletni

seji se privzeto ne delijo z drugimi portleti. Povezljivost med portleti z uporabo portletne

seje dosežemo s spremembo obsega portletne seje iz privzetega portletnega na

aplikacijski obseg. S spremembo obsega portletne seje na aplikacijski obseg dosežemo


17

deljenje portletne seje med portleti znotraj iste portletne aplikacije. Pri tem nastavljanje in

pridobivanje atributov portletne seje, razen specificiranje aplikacijskega obsega, ostaja

enako [23].

Javni parametri (angl. Public Render Parameters)

Javni parametri omogočajo dostop do istih parametrov iz različnih portletov. Javne

parametre portleti definirajo v portletnem deskriptorju (portlet.xml), tako da jih v sklopu

portletne aplikacije z elementom public-render-parameter definirajo, medtem ko v sklopu

portleta lahko vsak portlet z elementom supportlet-render-parameter določi, katere

definirane javne parametre bo delil [10][5][23]. Portleti javne parametre nastavljajo v

portletnem odgovoru preko metode setRenderParameter in pridobivajo portletni zahtevi

preko metode getParameter.

Portletni dogodki (angl. Portlet Eventa)

Portletni dogodki omogočajo, da portleti po eni strani dogodke prejemajo in po drugi strani

le-te pošiljajo drugim portletom na portalni strani. V ta namen portletna specifikacija 2.0

definira novo t. i. dogodkovno fazo življenjskega cikla portleta, ki je realizirana z

implementacijo metode processEvent vmesnika PortletEvent. Metoda processEvent

obdeluje vhodne dogodke in je v življenjskem ciklu umeščena med metodama

processAction in render. Portlet lahko ustvari dogodke z uporabo metode setEvent

vmesnika EventRespone, ki se lahko kliče v sklopu metode processAction in

processEvent. Če želi portlet prejemati dogodke, mora v sklopu metode processEvent

klicati metodo getEvent vmesnika EventRequest. Portlet dogodke definira v portletnem

deskriptorju (portlet.xml) v okviru portletne aplikacije z elementom event-definition,

medtem ko v sklopu vsakega portleta z elementom supported-publishig-events določi,

katere dogodke pošilja oz. z elementom supported-processing-events, katere dogodke

želi prejemati. Vsebina, ki jo lahko nosi dogodek, mora biti definirana z JAXB (angl. Java

Architecture for XML Binding). Portletni dogodki so šibko sklopljeni in portal ima nalogo

posrednika, da dogodke razdeli med portlete, ki dogodke želijo prejeti [10][5][23].

3.2 Pripomočki OpenSocial

Pripomočki OpenSocial so »majhne« vtične spletne komponente, ki so osnovane na

tehnologijah HTML, CSS in JavaScript. Razvijalcem omogočajo enostaven razvoj

uporabnih spletnih aplikacij, ki brez sprememb delujejo kjerkoli na spletu. Definirani so z


18

uporabo deklarativne XML sintakse, ki jo obdela strežnik pripomočkov OpenSocial v

takšno obliko, ki se lahko vključi v različne kontekste, kot recimo: samostojne spletne

strani, spletne aplikacije ali celo druge pripomočke. Kontekst, v katerega je vključen

pripomoček, se imenuje vsebnik. Vsebnik je zadolžen za upravljanje z videzom in

krmiljenjem pripomočka kot tudi za podporo različnim funkcionalnostim v imenu

pripomočka. Pripomoček je lahko preprosti gradnik, ponovno uporabna komponenta ali

kompleksna aplikacija, sposobna uporabiti ali komunicirati z drugimi pripomočki [1].

OpenSocial pripomočke definira odprtokodna specifikacija OpenSocial. Specifikacija

poleg pripomočkov definira skupek programskih vmesnikov za dostop in delo z

družbenimi podatki ter vsebnik, ki zagotavlja pripomočkom izvajalno okolje, dostop do

skupnih programskih vmesnikov in upravlja z varnostjo dostopa do podatkov. Programski

vmesniki definirajo, kako dostopati do informacij o ljudeh, njihovih povezavah in aktivnosti.

Vmesniki so na voljo pripomočkom preko skupka JavaScript in vmesnikov REST. Pri tem

aplikacije OpenSocial lahko prevzamejo obliko pripomočkov, ki so lahko vključeni v vsak

vsebnik, skladen s specifikacijo OpenSocial. Na ta način pripomočki in programski

vmesniki OpenSocial skupaj zagotavljajo programski model za gradnjo standardnih

družbenih aplikacij [3].

OpenSocial specifikacija je nastala leta 2007 na pobudo podjetja Google. V ta namen je

podjetje Google podarilo tehnologijo pripomočkov (Google Gadget-API), na katerih temelji

OpenSocial, odprtokodni skupnosti. OpenSocial zato ne prestavlja nove tehnologije,

ampak nadaljnji razvoj obstoječih tehnologij. Za razvoj specifikacije je bila ustanovljena

fundacija OpenSocial. Fundacija je specifikacijo razvila do različice 2.5.1, ki je tudi zadnja

stabilna različica in na voljo javnosti od leta 2013. Leta 2015 je nadaljnji razvoj

specifikacije prešel pod okrilje delovne skupine W3C Social Web [21].

Čeprav je prvotni namen specifikacije OpenSocial standardizacija aplikacij v potrošniških

socialnih omrežjih, med drugim OpenSocial implementira družbeni omrežji LinkedIn in

MySpace, se je uveljavila predvsem v poslovnem svetu [22]. Ponudniki programske

opreme uporabljajo infrastrukturo, ki temelji na specifikaciji OpenSocial kot način, s

katerim preko standardiziranih pripomočkov razširjajo svoje produkte, jim dodajajo nove

družbene sposobnosti in izboljšujejo interoperabilnost med svojim portfeljem in portfeljem

drugih podjetij, ki ponujajo poslovne rešitve [3].

Zgradba pripomočka OpenSocial

Pripomoček OpenSocial je definiran kot XML dokument. Pripomoček je v XML dokumentu

definiran s korenskim elementom Module, ki vsebuje tri osnovne elemente: ModulePrefs,

19

UserPref in Content [11]. Koda 3.2 prikazuje osnovno zgradbo XML dokumenta, ki definira

pripomoček.

<?xml version="1.0" encoding="UTF-8"?>

<Module>

<ModulePrefs [...] />

[...]

<ModulePrefs>

<UserPref [...] />

[...]

</UserPref>

<Content type="html|url">

<![CDATA[



]]>

</Content>

</Module>

Koda 3.2: XML dokument, ki definira pripomoček OpenSocial [11].

Osnovni elementi pripomočka definirajo naslednja tri področja [3][11][6]:

Nastavitve pripomočka: definira element ModulePrefs, v katerem so definirani

metapodatki pripomočka, kot so naslov, avtor, velikost pripomočka, dodatne

funkcionalnosti in pravila za obdelavo. To so osnovne informacije, ki jih definira

razvijalec pripomočka in jih uporabnik pripomočka ne more spreminjati.

Uporabniške nastavitve: so definirane z enim ali več elementom UserPref, v

katerih so definirane nastavitve, ki jih lahko uporabnik neposredno spreminja.

Uporabniške nastavitve so med izvajanjem pripomočka samodejno pretvorjene v

uporabniški vmesnik, preko katerega uporabnik nastavitve prilagaja. Razvijalec

ima do uporabniških nastavitev dostop preko aplikacijskega programskega

vmesnika pripomočkov.

Vsebina pripomočka: definira enega ali več elementov Content, znotraj katerih je

implementiran uporabniški vmesnik in poslovna logika pripomočka. Vsebina je

lahko na voljo na nekem naslovu URL ali kot vsebina HTML, CSS in JavaScript, ki

je zajeta znotraj sekcije CDATA[[...]].


20

Aplikacijski programski vmesnik OpenSocial pripomočkov

Aplikacijski programski vmesnik pripomočkov OpenSocial lahko razdelimo na dva dela [6]:

osnovne funkcionalnosti in

specifične funkcionalnosti.

Osnovne funkcionalnosti zagotavlja vsak vsebnik pripomočkov, ki je skladen s

specifikacijo pripomočkov OpenSocial. To pomen, da razvijalcem ni potrebno eksplicitno

zahtevati teh programskih vmesnikov, ampak so vedno vključeni v pripomoček. Osnovne

funkcionalnosti Gadget-API zagotavljajo naslednji objekti [3][6][1]:

gadgets.io: omogoča dostop do oddaljenih virov,

gadgets.json: zagotavlja operacije za pretvorbo v objekte JSON in iz njih,

gadgets.util: zagotavlja uporabne funkcionalnosti za splošno rabo,

gadgets.prefs: zagotavlja dostop do uporabniških informacij vključno z

informacijami o jeziku in državi.

Drugi del so aplikacijski programski vmesniki specifičnih funkcionalnosti pripomočkov. Te

funkcionalnosti mora razvijalec eksplicitno vključiti v nastavitvah pripomočka

(ModulePrefs) z uporabo elementa Optional, če lahko pripomoček deluje brez te

funkcionalnosti, ali Require, če je funkcionalnost potrebna za samo delovanje pripomočka.

Od vsebnika pripomočkov se zahteva, da podpre čim več specifičnih funkcionalnosti.

Nekatere izmed teh specifičnih funkcionalnosti so [3][6][1]:

views: upravljanje z različnimi pogledi glede na situacijo,

dynamic-height: prilagajanje velikosti okna pripomočka glede na vsebino,

minimessage: ustvarjanje sporočil znotraj pripomočka,

pubsub-2: podpora povezljivosti med pripomočki itd.

3.2.1 Povezljivost OpenSocial pripomočkov

Povezljivost pripomočkov v OpenSocial poteka preko mehanizma objavi – naroči (angl.

Publish-Subscribe). Objavi – naroči omogoča šibko sklopljeno asinhrono komunikacijo

med pripomočki preko dostave sporočil, ki so objavljene pod določeno tematiko (angl.

Topic) [3]. Mehanizem je definiran kot vzorec na naslednji način:

Vzorec objavi – naroči je sporočilni vzorec, kjer pošiljatelji sporočil, ki se imenujejo

izdajatelji, ne pošiljajo sporočila neposredno k določenemu prejemniku, ki ga imenujemo


21

naročnik, ampak objavljena sporočila opredelijo v razrede, ne da bi pri tem poznali

naročnike oz. če sploh naročnik obstaja. Podobno naročniki izrazijo interes za enega ali

več razredov in pri tem prejemajo samo sporočila, ki jih zanimajo, ne da bi pri tem poznali

izdajatelje oz. če sploh izdajatelj obstaja [24].

Mehanizem objavi – naroči, uporabljen v pripomočkih OpenSocial, temelji na specifikaciji

OpenAjax Hub 2.0 (OA Hub). Ključna funkcionalnost OA Hub-a je sporočilno središče, ki

gostiteljski aplikaciji omogoča, da izolira nezaupanja vredne komponente v varne

peskovnike. Upravljano vozlišče preusmeri vso komunikacijo med komponentami skozi

upravitelja varnosti gostiteljske aplikacije, ki dovoli ali prepreči vsako zahtevo po objavi ali

naročilu. Specifikacija pripomočkov OpenSocial dodatno razširja aplikacijski programski

vmesnik OA Hub z dogodkovnim vozliščem za upravljanje objav in naročil dogodkov na

odjemalcih [20].

Mehanizem objavi – naroči je specifična funkcionalnost pripomočkov, zato jo je potrebno

posebej vključiti v pripomočke. Funkcionalnost se vključi v nastavitve pripomočka kot

obvezna funkcionalnost pubsub-2. Znotraj vključene funkcionalnosti v razdelek topics

definiramo tematike, na katere pripomoček objavlja oz. na katere se naroča. Pri tem se

lahko ob naročilu na tematiko uporabljajo posebni znaki (za zamenjavo enega znaka »*«

oz. več znakov »**«), s katerimi naročnik dodatno filtrira tematike, na katere se naroča.

Pripomoček, ki definira tematiko za objavo sporočila, objavi sporočilo z uporabo metode

publish. Metoda prejme dva parametra, in sicer ime tematike in sporočilo, ki mora biti

objekt JSON. Pri tem objavljena sporočila so anonimna, zato ne moremo identificirati

pripomočka, ki je sporočilo objavil.

Za prejem sporočil se pripomoček naroči na eno ali več tematik z uporabo metode

subscribe. Metoda prejme dva parametra, in sicer ime tematike, na katero se pripomoček

naroča, in povratno funkcijo, katero pokliče objavi – naroči upravljano vozlišča ob prejemu

sporočila.

Pripomoček se lahko naroči na več tematik, zato metoda subscribe vrne identifikator, s

katerim je enolično določena naročnina na neko tematiko. Kadar se želi pripomoček

odjaviti od neke naročnine, pokliče metodo unsubscribe, pri čemer se kot parameter

uporabi identifikator, ki je bil prejet ob naročilu na tematiko [3].


22

4 POSLOVNI PORTAL LIFERAY

Portal Liferay spada med vodilne poslovne portale na trgu glede na Gartnerjev magični

kvadrant poslovnih portalov (slika 2.1). Kot edini neodvisen portalni produkt se razlikuje od

drugih vodilnih poslovnih portalov na trgu. Medtem ko slednji gradijo okrog tehnologij in

programske opreme, ki je v portfelju posameznega ponudnika programske opreme, je

portal Liferay predvsem rezultat uporabe uveljavljenih standardov, tehnologij in

sodelovanja z odprtokodno skupnostjo.

Portal Liferay je Java EE portal, ki je nastal v okviru odprtokodnega projekta. Prvotni

namen projekta je bil neprofitnim organizacijam in majhnim podjetjem zagotoviti portalno

platformo, ki ne zahteva velikih vlaganj v programsko in strojno opremo, ampak lahko

izkoristi že obstoječo, pogosto manj zmogljivo infrastrukturo. Poleg tega razvijalcem

omogoča enostavno uporabo različnih razvojnih pristopov, pri čemer ti ne potrebujejo

nekih specifičnih orodij, razen tistih, ki so že v samem naboru orodij Java razvijalca.

Zaradi filozofije odprte kode je portal Liferay veliko bolj fleksibilen v primerjavi s

komercialno konkurenco, saj je veliko manjši, sistemsko manj zahteven in preprostejši za

konfiguriranje, saj si kot odprtokodni portal ne more privoščiti, da bi bil prevelik, sistemsko

potraten in zahteven za razvijalce [25]. Takšna filozofija pa ni zanimiva samo za

neprofitne organizacije in majhna podjetja, ampak tudi za velika podjetja, ki potrebujejo

fleksibilnost, ki je ostali vodilni komercialni poslovni portali ne omogočajo.

Zahteve neprofitnih in majhnih organizacij ter velikih podjetij se razlikujejo, zato je portal

Liferay na voljo v dveh izdajah [16]:

Liferay Portal Community Edition (CE) in

Liferay Portal Enterprise Edition (EE).

CE je izdaja portala Liferay, ki je na voljo brezplačno pod odprtokodno licenco LGPL. V

ozadju odprtokodnega projekta Liferay stoji skupnost uporabnikov, ki redno objavlja nove

različice izdaje CE, v katerih se nenehno uvajajo in izpopolnjujejo funkcionalnost, ter skrbi

za podporo uporabnikom portala [25][16].

EE je izdaja portala Liferay, ki je preizkušena v produkcijskih okoljih in kot taka namenjena

večjim podjetjem, ki potrebujejo preizkušeno portalno rešitev. Na voljo je pod komercialno


23

licenco, ki ponuja podporo, izobraževanje in posodobitve, ki odpravljajo napake,

povečujejo stabilnost, zmogljivost in varnost EE portala [25][16].

Vodilni komercialni poslovni portali so osnovani okrog produktov določenega ponudnika

programske opreme, zato so njihovi namestitveni scenariji v veliki meri odvisni od teh

produktov. Portal Liferay je neodvisen poslovni portal in kot tak zavezan k temu, da

podpre čim več namestitvenih scenarijev. Kot portal, ki je osnovan na platformi Java EE,

je združljiv z vsemi pomembnimi operacijskimi sistemi, aplikacijskimi strežniki in

podatkovnimi bazami. Pri tem je vseeno, ali je namestitveni scenarij realiziran v fizičnem

ali virtualnem okolju oz. privatnem ali javnem oblaku. V tabeli 4.1 so našteti uradno podprti

operacijski sistemi, aplikacijski strežniki, podatkovne baze in namestitve v virtualizirano

okolje [13].

Tabela 4.1: Povzetek matrike združljivosti za portal Liferay EE [13].

Operacijski sistem Aplikacijski strežnik Podatkovna baza JDK Storitve v oblaku

Linux Tomcat DB2 IBM JDK AWS

Unix Resin MySQL Oracle JDK Azure

Windows Server GlassFish Oracle JRockit JDK VMware

JBoss AS & EAS PostgreSQL Xen

Weblogic SQL Server

WebSphere Sybase ASE

Portal Liferay je Java EE portal, zato je njegovo ogrodje sestavljeno iz portalnega

strežnika in portletnega vsebnika. Portletni vsebnik v okviru portala nudi izvajalno okolje

portletom, ki so skladni s portletno specifikacijo JSR 168 in JSR 286. Poleg portletnega

vsebnika je v ogrodje portala integriran vsebnik pripomočkov OpenSocial, ki nudi izvajalno

okolje za pripomočke, ki so skladni s specifikacijo OpenSocial 2.0. Portalni strežnik

predstavlja jedro portalnega ogrodja. V tem jedru so uporabljene številne tehnologije, s

pomočjo katerih portal nudi različne storitve. Te tehnologije vključujejo Spring, Hibernate

in EJB, s pomočjo katerih so implementirane portalne storitve in storitve, potrebne za

dostop do podatkovnih virov. Poleg tega je znotraj samega portalnega ogrodja podprto

izvajanje različnih skriptnih jezikov, kot so PHP, Python in Ruby [17].

Portal Liferay zagotavlja mehanizme, ki omogočajo prilagajanje, razširitev in razvoj

funkcionalnosti portala. V ta namen je na voljo standardno razvojno okolje (angl. Software

Development Kit, SDK) – Liferay Plugin SDK. SDK lahko uporabimo samostojno, preko


24

ukazne vrstice, ali ga z Liferay IDE vtičnikom vključimo v integrirano razvojno okolje

Eclipse. SDK je namenjen razvoju vtičnikov za portal, ki so lahko [33][25]:

Portleti (angl. Portlets): Podprt je razvoj portletov, ki so skladni s portletno

specifikacijo JSR 168 in JSR 286.

Teme (angl. Themes): So namenjene prilagajanju grafičnega videza portalne

strani.

Predloge razporeditev (angl. Layout Templates): So način, s katerim se definira

razporeditev portletov na portalni strani.

Kavlji (angl. Hooks): Omogočajo prilagajanje osnovnih funkcionalnosti portala, ne

da bi pri tem posegali v izvorno kodo portala.

Del SDK je tudi orodje Liferay Service Builder, ki se uporablja za razvoj storitev znotraj

portala Liferay, pri čemer so te implementirane z uporabo ogrodij Hibernate in Spring [18].

Storitve, ki so zgrajene s tem orodjem, so integrirane v portal in dostopne na različne

načine, lokalno preko klica Java metod ali oddaljeno z uporabo spletnih storitev [15].

Vse omenjene sposobnosti in storitve, ki jih zagotavlja portal Liferay, se odražajo v

funkcionalnostih portala. Te funkcionalnosti so:

Enotna prijava: Portal ponuja prilagodljivo enotno prijavo, ki jo lahko integriramo s

CAS, z OpenSSO, LDAP (Active Directory, OpenLDAP, Apache DS), NTLM idr.,

kakor tudi z zunanjimi decentraliziranimi rešitvami, ki implementirajo OpenID (npr.

Yahoo). Če določena rešitev za enotno prijavo ni podprta, jo lahko podpremo tudi

z lastno implementacijo.

Poosebitev: Uporabniki portala lahko prilagajajo portalne strani in njihovo vsebino

oz. portlete glede na svoje potrebe in želje. Te strani so lahko javne ali privatne, pri

čemer nivo poosebitve določa administrator portala, tako da nadzira dodajanje,

odstranjevanje, prilagajanje vsebine in portletov glede na vlogo uporabnika v

portalu.

Upravljanje vsebin: Del portala je lasten sistem za upravljanje vsebin, s katerim

lahko upravljamo spletne vsebine in dokumente. Poleg standardnih

funkcionalnosti, kot so dodajanje, spreminjanje in odstranjevanje vsebine, portal

Liferay omogoča tudi upravljanje z različicami in objavo vsebin na podlagi

delovnega toka. Sistem za upravljanje vsebin je skladen z JSR 170, zato lahko za

shranjevane vsebine uporabimo poljuben repozitorij, skladen s to specifikacijo

(npr. Jackrabbit, Magnolia ali Alfresco).


25

Taksonomija: Portal omogoča uporabo enotne taksonomije na nivoju portala, s

čimer je poenostavljena organizacija, iskanje in navigacija po različni vsebini, kot

so strani wiki, blogi, spletna vsebina ipd. Taksonomijo lahko vnaprej definira

administrator kot sklop hierarhično urejenih kategorij, ali pa so to oznake, ki jih

uporabniki dodajajo sproti.

Iskanje: Privzeto je na voljo odprtokodna implementacija iskalnika Lucene, ki je

razširljiva z zmogljivejšimi zunanjimi iskalniki. Iskanje poteka s pomočjo iskalnega

portleta, ki ga lahko vključimo na poljubno portalno stran. Iskalni portlet omogoča

iskanje v globino skozi različne tipe vsebin, oznak in kategorij kakor tudi uporabo

logičnih operatorjev, s čimer natančno omejimo iskanje.

Komunikacija in sodelovanje: Orodja spleta 2.0., kot so blogi, wikiji, forumi in

neposredno sporočanje, so integralni del portala. Ta orodja so integrirana s

pomembnimi funkcionalnostmi portala, kot so recimo imenik uporabnikov, iskalnik

in taksonomija. Orodja spleta 2.0. poleg komunikacije in sodelovanja omogočajo

tudi socializacijo med uporabniki, tako da omogočajo gradnjo družbenih mrež, v

katerih lahko uporabniki izmenjujejo, uporabljajo in ustvarjajo nove ideje in znanje.

Predstavitev: Za predstavitev vsebine in funkcionalnosti portal uporablja portlete in

pripomočke. Portal nudi podporo portletom, ki so skladni s portletno specifikacijo,

medtem ko morajo biti pripomočki skladni s specifikacijo OpenSocial.

Administracija: Osrednjo točko administracije predstavlja nadzorna plošča.

Nadzorna plošča združuje različna administracijska orodja, ki so logično združena

v štiri področja:

o Uporabniki: zajema administracijo uporabnikov, uporabniških skupin, vlog

ter z njimi povezanih dovoljenj.

o Strani: se nanašajo na gradnjo in upravljanje zbirk spletnih strani (npr.

intranet, ekstranet) ter objavo vsebin in aplikacij na njih.

o Aplikacije: zajemajo razširitve portala (portlete, teme, prepisane

funkcionalnosti portala ipd.) in omogoča njihovo namestitev in upravljanje

bodisi lokalno ali iz tržnice Liferay.

o Konfiguracija: združuje nastavitve portala, administracijo strežnika in

upravljanje instanc portala.

Varnost: Varnost portal zagotavlja z uporabo enkripcijskih tehnologij, kot so DES,

MD5 in RSA. Ponuja prilagodljivo enotno prijavo, ki lahko integrira različne

avtentikacijske mehanizme. Poleg tega zagotavlja robustno upravljanje


26

uporabnikov in varnostne funkcionalnosti, kot granulirano dodeljevanje dostopa,

politiko gesel in spremljanje dejavnosti prijavljenih uporabnikov.

Integracija: Portal Liferay je odprta platforma, ki ima izpostavljen aplikacijski

programski vmesnik, dostopen preko klicev Java metod in spletnih storitev.

Osnovana je okrog standardnih integracijskih tehnologij, kot so standardni Java

portleti, OpenSocial pripomočki, Java sistem za upravljanje z vsebino, spletne

storitve idr. Zaradi odprtosti in sledenja standardov lahko portal integriramo s

katerokoli odprtokodno in komercialno aplikacijo, ki ponuja podporo preko nekega

storitvenega sloja ali programskega aplikacijskega vmesnika. Poleg tega lahko v

tržnici Liferay poiščemo vtičnike, ki zagotavljajo integracijo z različnimi

aplikacijami.

Poleg standardnih funkcionalnosti so na voljo tudi funkcionalnosti, ki so specifične za

Liferay portal, kot npr. [14]:

Tržnica Liferay (angl. Liferay Marketplace): Podjetja nenehno iščejo načine, da bi

izboljšala svoje obstoječe portalne platforme, medtem ko razvijalci in ponudniki

programske opreme iščejo načine, da bi dosegli to tržišče. Portal Liferay pri tem

kot vzvod uporablja koncept tržnice, kjer se srečuje povpraševanje podjetij ter

ponudba razvijalcev in ponudnikov razširitev za portal Liferay. Tržnica Liferay je v

osnovi repozitorij za aplikacije, ki so združljive s portalno platformo Liferay. Ta

repozitorij omogoča objavo, upravljanje, iskanje, nakup in prenos (brezplačnih in

plačljivih) aplikacij.

Podpora mobilnim napravam: Ločljivost zaslona in način uporabe mobilnih in

namiznih naprav se razlikujeta, zato se mora prikaz portalnih strani prilagoditi

glede na značilnosti zaslona. Portal Liferay administratorjem portala omogoča, da

v samem portalu preverijo prikaz vsake portalne strani, portletov in pripomočkov

na različno velikih zaslonih. Poleg tega portal vključuje pravila, ki omogočajo

najbolj optimalen prikaz za določeno družino mobilnih naprav.

Peskovnik (angl. Sandbox): V večjih namestitvenih okoljih je nesprejemljivo, da bi

nestabilna aplikacija vplivala na stabilnost portala. Portal Liferay zato uvaja

koncept peskovnika, ki omogoča, da se izbrana aplikacija izvaja v svojem Java

navideznem stroju in s tem ne vpliva na stabilnost samega portala.


27

4.1 Podpora povezljivosti portalnih komponent

Portal Liferay kot vtične portalne komponente uporablja standardne portlete in

pripomočke. Zato portal že v samem jedru nudi podporo standardnim mehanizmom za

povezljivost portletov in pripomočkov. Portal dodatno razširja standardne mehanizme za

povezljivost portletov, ki smo jih predstavili v poglavju 3.1.1, tako da ti ne omogočajo

samo povezljivosti med portleti na trenutni portalni strani, ampak tudi med portleti na

različnih portalnih straneh in portletnih aplikacijah. Portal povezljivost med portleti razširja

na naslednji način:

portletna seja: z nastavitvijo elementa private-session-attributes v liferay

portletnem deskriptorju (liferay-portlet.xml) za posamezni portlet se onemogoči

privatna seja v okviru portletne aplikacije, tako da je ta na voljo drugim portalnim

aplikacijam,

javni parametri: z nastavitvijo lastnosti portlet.public.render.parameter.distribution

na vrednost layout-set v nastavitvah portala (portal-ext.properties) se omogoči

deljenje parametrov med portalnimi stranmi,

portletni dogodki: z nastavitvijo lastnosti portlet.event.distribution na vrednost

layout-set v nastavitvah portala (portal-ext.properties) se omogoči pošiljanje in

prejemanje dogodkov na različnih portalnih straneh.

Poleg razširitve obstoječih standardnih mehanizmov portal Liferay zagotavlja tudi lasten

mehanizem za povezljivost portletov na strani odjemalca – Liferay Client-Side IPC.

Mehanizem Liferay za povezljivost portletov na strani odjemalca je osnovan kot sistem

objavi – naroči in ne omogoča samo povezljivost med portleti, ampak to povezljivost

razširja na pripomočke in obratno, tako da izkorišča standardno povezljivost pripomočkov,

predstavljeno v poglavju 3.2.1.


28

5 PRAKTIČNI PRIKAZ PORTALA S POVEZANIMI KOMPONENTAMI

V prvem delu diplomske naloge smo pridobili teoretično znanje o portalnih komponentah

(portletih in pripomočkih), ki jih lahko vključimo v portal Liferay. To znanje bomo uporabili

pri razvoju portalne aplikacije, sestavljene iz portletov in pripomočkov. Razvoj bo obsegal

izdelavo dveh funkcionalno identičnih, vendar tehnološko različnih portalnih aplikacij, ki jih

bomo vključili v portal. Portal Liferay bo služil kot peskovnik, s pomočjo katerega bomo

preizkusili različne mehanizme za povezljivost portalnih komponent.

V nadaljevanju bomo opisali portalno aplikacijo, definirali njene zahteve in pričakovano

delovanje. Na podlagi zahtev portalne aplikacije bomo razvili portlete in pripomočke,

vključno z mehanizmi za povezljivost portalnih komponent, s katerimi bomo realizirali

portalno aplikacijo in jih analizirali. Na koncu bo sledila primerjalna analiza mehanizmov

za povezljivosti portalnih komponent.

5.1 Opis portalne aplikacije

V tem poglavju bomo predstavili storitev Bitbucket. Na podlagi izbrane funkcionalnosti

storitve bomo zajeli zahteve za portalno aplikacijo in opisali njeno delovanje.

5.1.1 Storitev Bitbucket

Bitbucket je spletna storitev v oblaku za gostovanje projektov, ki uporablja distribuiran

sistem za nadzor različic izvorne kode Mercurial4 ali Git5. Storitev je brezplačna za

nekomercialno uporabo in privatno uporabo oz. plačljiva za komercialno uporabo v

primeru večjega števila uporabnikov. Bitbucket svojim uporabnikom poleg standardnih

funkcionalnosti sistema za nadzor različic, kot je izdelava novih vej (angl. Branching),

združevanj (angl. Merging) in vejitve (angl. Forking), daje na voljo tudi funkcionalnosti

4 Mercurial: je distribuiran sistem za nadzor različic izvorne kode, namenjen razvoju programske

opreme. Mercurial je odprtokodni sistem na voljo pod licenco GNU GPL v2. 5 Git: je distribuiran sistem za nadzor različic izvorne kode namenjen razvoju programske opreme

in drugim opravilom za nadzor različic. Git je odprtokodni sistem na voljo pod licenco GNU GPL v2.


29

sistema wiki, namenjenega obvladovanju dokumentacije, in sistema za upravljanje zahtev,

kjer se zahtevajo nove funkcionalnosti, poročajo hrošči ali druga projektna opravila v

okviru repozitorija. Bitbucket je storitev, ki jo nudi podjetje Atlassian in omogoča

integracijo z drugimi storitvami v oblaku omenjenega podjetja, kot sta npr. Jira in

Confluence. Na sliki 5.1 je prikazan spletni vmesnik storitve Bitbucket s standardnimi

funkcionalnostmi.

Slika 5.1: Osnovna stran spletnega vmesnika storitve Bitbucket.

Funkcionalnost storitve Bitbucket je na voljo preko javno dostopnega aplikacijskega

programskega vmesnika – Bitbucket Cloud API. Ta je osnovan na uporabi odprtih

standardov z namenom poenostaviti integracijo z drugimi aplikacijami. Z Bitbucket Cloud

API se lahko uporabnik prijavi v storitev Bitbucket in dovoli neki aplikaciji, da dostopa do

virov v njegovem imenu. Avtorizirana aplikacija lahko nato preko aplikacijskega

programskega vmesnika dostopa in upravlja z viri, kot so:

uporabniki: upravljanje z informacijami, povezanimi z določenim uporabniškim

računom, in

repozitoriji: upravljanje z viri repozitorija, kot so spremembe (angl. hainsets),

dokumentacija wiki in upravljanje z zahtevami.


30

Za dostop do privatnih podatkov iz storitve Bitbucket se mora uporabnik, ki zahteva

podatke preko aplikacijskega programskega vmesnika, avtenticirati z računom Bitbucket,

pri čemer se za avtorizacijo uporablja mehanizem OAuth6.

5.1.2 Zahteve portalne aplikacije

Zahteve portalne aplikacije smo določili na podlagi funkcionalnosti, ki jih omogoča storitev

Bitbucket. Odločili smo se, da bomo s portletno aplikacijo implementirali funkcionalnost, ki

omogoča, da se v komentarju neke spremembe kode (angl. Chainsets) sklicujemo na

zahtevo (novo funkcionalnost, hrošče ali projektna opravila v okviru repozitorija). V praksi

to pomeni, da je sprememba povezana z zahtevo, kot je prikazano na sliki 5.2.

Slika 5.2: Povezava zahteve z neko spremembo preko komentarja.

Zahteve portalne aplikacije, ki realizira zgoraj omenjeno funkcionalnost storitve Bitbucket,

smo zajeli s pomočjo UML diagrama primerov uporabe (angl. Use Case Diagram).

Diagram primerov uporabe je diagram, s katerim so prikazane funkcionalnosti, ki jih mora

sistem nuditi. Osnovna gradnika diagrama sta akter in primer uporabe. Akter predstavlja

vlogo posameznika v sistemu, ki želi doseči neki poslovni cilj z uporabo primera uporabe,

ki opisuje scenarij za dosego tega cilja. Povezava med njima je definirana kot asociacija.

6 OAuth (angl. Open Authentication): je odprtokodni standard za avtoriziranje aplikacij, da

dostopajo do podatkov v imenu uporabnika.


31

Z diagramom primerov uporabe na sliki 5.3 smo zajeli funkcionalne zahteve portalne

aplikacije, ki smo jo razvili v praktičnem primeru.

Slika 5.3: Diagram primerov uporabe portalne aplikacije.

5.1.3 Opis delovanja portalne aplikacije

Portalna aplikacija je sestavljena iz dveh portalnih komponent (realiziranih kot portletov ali

pripomočkov). Prva komponenta, ki jo bomo poimenovali Commits, prikazuje seznam

sprememb izvorne kode v izbranem repozitoriju, medtem ko druga komponenta, ki jo

bomo poimenovali Issues, prikazuje seznam zahtev oz. določeno zahtevo.

Pred samo uporabo portalnih komponent Commits in Issues mora portalni uporabnik v

nastavitvah portalne komponente izbrati želeni repozitorij in se avtorizirati s storitvijo

Bitbucket. Ko je uporabnik portala avtoriziran, lahko na portalnih komponentah pregleduje

seznam sprememb in zahtev za izbrani repozitorij. V seznamu sprememb, ki ga pridobi

komponenta Commits, so poleg splošnih informacij o spremembah tudi povezave na

zahteve, s katerimi so spremembe povezane. Uporabnik na komponenti Commits izbere

povezano zahtevo, pred tem mora izbrati mehanizem za povezljivost portalnih

komponent, s čimer se informacija o zahtevi posreduje na komponento Issues, ki pridobi

podrobnosti o zahtevi in te prikaže uporabniku.


32

5.2 Opis atributov analize

Mehanizmi za povezljivost portalnih komponent se lahko med seboj precej razlikujejo. Da

bi dobili boljši vpogled v njihove lastnosti, smo izbrali atribute, na podlagi katerih bomo

analizirali mehanizme za povezljivost portalnih komponent.

Implementacija: Iz vidika razvijalca nas zanima postopek, ki je potreben za

implementacijo določenega mehanizma v portalne komponente.

Uporabljene tehnologije: Zanima nas, katere so osnovne tehnologije, na katerih

temelji mehanizem za povezljivost.

Zmožnosti povezljivosti: Mehanizme za povezljivost portalnih komponent je možno

uporabiti v različnih scenarijih, pri tem želimo identificirati scenarije uporabe.

Uporabniška izkušnja: Analizirati želimo občutek in kako ta vpliva na uporabniško

izkušnjo, ki ga ima uporabnik takoj po uporabi določenega mehanizma za

povezljivost portalnih komponent. Pri tem se bomo opirali na subjektivna opažanja

uporabnika portalne aplikacije, ki je lahko pozitivno ali negativno.

5.3 Razvoj portletov in njihova povezljivost

5.3.1 Vzpostavitev razvojnega okolja

Za razvoj portletov smo uporabili Liferay IDE. Liferay IDE je vtičnik, ki smo ga namestili v

integrirano razvojno okolje Eclipse, s čimer smo pridobili orodja za razvoj standardnih

portletov in specifičnih funkcionalnosti Liferay. Za delovanje vtičnika Liferay IDE smo še

konfigurirali povezavo z obstoječim portalom Liferay, ki ga potrebujemo kot izvajalno

okolje za izvajanje in razhroščevanje ter ga povezali z razvojnim orodjem Liferay Plugin

SDK, ki v ozadju skrbi za upravljanje s projekti Liferay. Na sliki 5.4 je prikazano integrirano

razvojno orodje Eclipse z nameščenim vtičnikom Liferay IDE.


33

Slika 5.4: Integrirano razvojno okolje Eclipse z vtičnikom Liferay IDE.

5.3.2 Razvoj portletov

Razvoj portletov smo začeli z ustvarjanjem novega projekta Liferay za vtičnike (angl.

Liferay Plugin Project) v integriranem razvojnem okolju Liferay. S tem projektom smo

vzpostavili projektno strukturo portletne aplikacije. V portletni aplikaciji smo ustvarili dva

portleta: Commits in Issues. Prvi implementira prikaz sprememb v repozitoriju, medtem ko

drugi predstavlja implementacijo prikaza zahtev oz. podrobnosti določene zahteve. Vtičnik

Liferay IDE je pri tem poskrbel, da sta se portleta pravilo umestila v strukturo portletne

aplikacije, da so se ustvarile vse potrebne datoteke in posodobili namestitveni deskriptorji,

v skladu s portletno specifikacijo 2.0.

Oba portleta smo razvili v skladu z arhitekturnim vzorcem model nadzornik pogled (MVC),

s katerim smo predstavitveno logiko ločili od poslovne logike in samih podatkov, kot je

prikazano v tabeli 5.1.


34

Tabela 5.1: Uporaba vzorca MVC pri razvoju portletne aplikacije.

Commits Issues

Nadzornik CommitsPortlet.java IssuesPortlet.java

Model Commits.java,

BitbucketToolbox.java

Issues.java, Issue.java,

BitbucketToolbox.java

Pogled View.jsp, Edit.jsp View.jsp, Edit.jsp

Vlogo nadzornika v portletni aplikaciji imata glavna razreda portleta, to sta

CommitsPortlet.java in IssuesPortlet.java. Razreda razširjata abstraktni razred

GenericPortlet, ki zagotavlja privzeto implementacijo vmesnika Portlet. Preko

implementacije metod, ki jih zagotavlja GenericPortlet, portletna razreda skrbita za

obnašanje posameznega portleta, tj. obdelavo zahtev za prikaz sprememb ali zahtev iz

repozitorija, določanje pogleda za prikaz in upravljanje z nastavitvami portleta. Nadzornik

portleta Commits implementira tudi akcijsko metodo processIssues, v kateri preko

izbranega mehanizma za povezljivost pošljemo informacije o izbrani zahtevi (koda 5.1).

@ProcessAction(name="processIssues")

public void processIssues(ActionRequest actionRequest, ActionResponse actionResponse)

throws IOException, PortletException {

// izbran mehanizem za povezljivost

String ipc = actionRequest.getParameter(Params.IPC_METHOD);

// izbrana zahteva

String issueId = actionRequest.getParameter(Params.ISSUE_ID);

if(ipc.equals(Params.PORTLET_SESSION)){

... // implementacija povezljivosti s portletno sejo

}

if(ipc.equals(Params.PUBLIC_RENDER_PARAMETER)){

... // implementacija povezljivosti z javnim parametrom

}

if(ipc.equals(Params.PORTLET_EVENT)){

... // implementacija povezljivosti s portletnim dogodkom

}

}

Koda 5.1: Metoda za izbiro mehanizma za povezljivost portletov.


35

Vlogo modela v portletni aplikaciji imajo razredi, preko katerih portleta dostopata do

podatkov in te preko krmilnika pošiljata na pogled. V ta namen smo razvili pomožni razred

BitbucketClientToolbox, ki omogoča avtorizacijo preko mehanizma OAuth in dostop do

podatkov preko aplikacijskega programskega vmesnika Bitbucket Cloud API. Portlet se

preko razreda BitbucketClientToolbox avtorizira s storitvijo Bitbucket in pridobi podatke v

obliki dokumenta JSON, ki ga pretvori v ustrezen objekt in vrne nadzornemu razredu.

Pogled je v portletu določen s portlenim načinom. Podprli smo portletni način pogled

(view.jsp), ki skrbi za prikaz sprememb ali zahtev oz. podrobnosti določene zahteve iz

repozitorija in portletni način urejanje (edit.jsp), preko katerega nastavimo podatke,

potrebne za avtorizacijo s storitvijo Bitbucket, in izbiro mehanizma za povezljivost s

portalnimi komponentami.

5.3.3 Povezljivost med portleti

V tem poglavju bomo v portletih implementirali in analizirali povezljivost med portleti.

Povezljivost med portleti bo analizirana na podlagi razvite portalne aplikacije (slika 5.5),

katere delovanje je bilo opisano v poglavju 5.1.3.

Slika 5.5: Portalna aplikacija, sestavljena iz portletov.


36

Portletna seja

Portletna seja je standardni portletni mehanizem za shranjevanje začasnih podatkov.

Vsak portlet na portalni strani ima svojo portletno sejo in podatki iz sej niso deljeni z

ostalimi portleti. Če želimo, da je portletna seja uporabna kot mehanizem za povezljivost

portletov, moramo omogočiti deljenje podatkov med portletnimi sejami portletov.

Povezljivosti med portleti z uporabo portletne seje smo implementirali v sledečih korakih:

Nastavitev javne portletne seje v portalu Liferay: smo eksplicitno definirali z

uporabo elementa private-session-attributes v portletnem dekriptorju Liferay

(liferay-portlet.xml) (koda 5.2). Z omenjeno nastavitvijo smo dosegli, da je portletna

seja tega portleta dostopna tudi drugim portletom.

<portlet>

...

<private-session-attributes>false</private-session-attributes>

...

</portlet>

Koda 5.2: Nastavitev javne portletne seje v liferay-portlet.xml.

Nastavitev atributa portletne seje: smo implementirali v akcijski metodi portleta

Commits. Portletno sejo smo pridobili preko akcijske zahteve. Za nastavitev

atributa portletne seje smo uporabili metodo setAttribute. V metodo setAttribute

smo kot argument podali ime atributa »org.bitbucket.issue«, njegovo vrednost v

obliki objekta razreda Issue in določili uporabo javne portletne seje z uporabo

konstante APPLICATION_SCOPE vmesnik PortletSession (koda 5.3).

Issue issue = new Issue();

issue.setId(Integer.parseInt(issueId));

PortletSession pSession = actionRequest.getPortletSession();

pSession.setAttribute("org.bitbucket.issue", issue, PortletSession.APPLICATION_SCOPE);

Koda 5.3: Izsek iz akcijske metode za nastavitev atributa portletne seje.

Pridobivanje atributa portletne seje: smo implementirali v metodi doView portleta

Issues, ki se proži ob vsakem izrisu portleta. Portletno sejo smo pridobili preko


37

izrisovalne zahteve. Za pridobitev želenega atributa iz portletne seje smo uporabili

metodo getAttribute. V metodo getAttribute smo kot argument podali ime atributa

»org.bitbucket.issue«, ki smo ga nastavili v portletu Commits in določili uporabo

javne portletne seje preko konstanteAPPLICATION_SCOPE vmesnika

PortletSession (koda 5.4).

PortletSession pSession = actionRequest.getPortletSession();

Issue issue = (Issue) pSession.getAttribute("org.bitbucket.issue",

PortletSession.APPLICATION_SCOPE);

Koda 5.4: Izsek iz izrisovalne metode za pridobitev atributa portletne seje.

Portletna seja je osnovana na tehnologiji Java EE. Zmožnost portletne seje je povezljivost

portletov, ki se nahajajo na isti ali drugi portalni strani. Ker portalna seja sloni na Java EE

tehnologiji, se mora ob vsaki uporabi zgoditi ponovni izris portalne strani, zato je

uporabniška izkušnja negativna.

Javni parametri

Javni parametri so eden izmed standardnih načinov, ki jih definira portletna specifikacija

2.0 za doseganje povezljivosti med portleti na portalni strani. Omogočajo povezljivost med

portleti na osnovi portletnih parametrov, ki so vidni vsem portletom na portalni strani.

Javne parametre v portletih omogočimo, tako da jih v portletnem deskriptorju portleta

definiramo in nato implementiramo shranjevanje podatkov v portletu »pošiljatelju« oz.

pridobivanje podatkov v portletu »prejemniku«.

Definicija javnega parametra: se opravi v portletnem deskriptorju. Javni parameter

smo definirali v sklopu portletne aplikacije z enoličnim identifikatorjem »issueId« v

imenskem področju »http://org.bitbucket«. V sklopu vsakega portleta smo

portletnem deskriptorju z elementom supported-public-render-parameter določili

podporo pošiljanju in prejemanju tega parametra (koda 5.5).


38

<portlet-app>

<portlet>

<portlet-name>Commits</portlet-name>

...

<supported-public-render-parameter>issueId</supported-public-render-parameter>

</portlet>

<portlet>

<portlet-name>Issues</portlet-name>

...

<supported-public-render-parameter>issueId</supported-public-render-parameter>

</portlet>

<public-render-parameter>

<identifier>issueId</identifier>

<qname xmlns:x="org.bitbucket">x:paramIssueId</qname>

</public-render-parameter>

</portlet-app>

Koda 5.5: Definicija javnega parametra in njegova podpora v portletih.

Pošiljatelj: je portlet Commits, ki je odgovoren za shranjevanje podatkov v javni

parameter. Shranjevanje podatkov v javni parameter »issueId« smo implementirali

v sklopu akcijske metode, v kateri pridobimo izbrano zahtevo, ki jo je na portletu

izbral uporabnik. V akcijski metodi smo preko akcijskega odgovora nastavili javni

parameter z uporabo metode setRenderParameter (koda 5.6). V metodi smo kot

argumenta uporabili identifikator »issueId« in informacijo o izbrani zahtevi v obliki

niza znakov.

actionResponse.setRenderParameter("issueId", issueId);

Koda 5.6: Izsek iz akcijske metode za nastavitev javnega parametra.

Prejemnik: je portlet Issues, ki je odgovoren za pridobivanje podatkov, ki jih je v

javni parameter shranil pošiljatelj. Pridobivanje podatkov iz javnega parametra

»issueId« smo implementirali v sklopu izrisovalne metode doView. V izrisovalni

metodi smo preko izrisovalne zahteve pridobili podatke iz parametra preko metode

getParameter (koda 5.7), tako da smo kot argument uporabili identifikator javnega

parametra »issueId«.


39

String issueId = renderRequest.getParameter("issueId");

Koda 5.7: Izsek iz izrisovalne metode za dostop do javnega parametra.

Razširitev Liferay: omogoča, da javni parametri niso vidni samo portletom na

portalni strani, kjer se nahaja pošiljatelj, ampak tudi portletom na drugih portalnih

straneh. To funkcionalnost smo omogočili v nastavitveni datoteki portala Liferay

(portal-ext.properties), tako da smo nastavili parameter

portlet.public.render.parameter.distribution na vrednost »layout-set«.

Javni parametri so osnovani na tehnologiji Java EE. Zmožnost javnih parametrov je

povezljivost portletov, ki so na isti portalni strani. V portalu Liferay imamo možnost, da

razširimo javne parametre, tako da so ti dosegljivi tudi portletom na drugih portalnih

straneh. Ker javni parametri slonijo na Java EE tehnologiji, se mora ob vsaki uporabi

zgoditi ponovni izris portalne strani, zato je uporabniška izkušnja negativna.

Portletni dogodki

Portletni dogodki so drugi standardni način, ki jih definira portletna specifikacija 2.0 za

doseganje povezljivosti med portleti na portalni strani. Portletni dogodki predstavljajo

napreden način povezljivost med portleti.

Portletne dogodke v portletih omogočimo z njihovo definicijo v portletenem deskriptorju

portleta in implementacijo v portletu »pošiljatelju«, ki dogodke proži, ter portletu

»poslušalcu«, ki se odzove na proženje dogodkov.

Definicija portletnega dogodka: je izvedena v portletnem deskriptorju (portlet.xml).

Portletni dogodek smo definirali v okviru portletne aplikacije, tako da smo v

imenskem področju »org.bitbucket« določili identifikator »issue« in vsebino

dogodka kot objekt razreda Issue. Poleg tega smo morali v vsakem portletu

definirati podporo dogodkom, in sicer z elementom supported-publishing-event

podporo pošiljanje in z elementom supported-processing-event podporo obdelavi

dogodkov (koda 5.8).


40

<portlet-app>

<portlet>

<portlet-name>Commits</portlet-name>

...

<supported-publishing-event>

<qname xmlns:x="org.bitbucket">x:issue</qname>

</supported-publishing-event>

</portlet>

<portlet>

<portlet-name>Issues</portlet-name>

...

<supported-processing-event >

<qname xmlns:x="org.bitbucket ">x:issue</qname>

</supported-processing-event >

</portlet>

<event-definition>

<qname xmlns:x="org.bitbucket">x:issue</qname>

<value-type>org.bitbucket.api.mapping.Issue</value-type>

</event-definition>

</portlet-app>

Koda 5.8: Definicija dogodka in podpora pošiljanju in prejemanju v portletih.

Pošiljatelj: je v okviru razvite portletne aplikacije portlet Commits, ki je odgovoren

za proženje dogodkov. Pošiljanje dogodkov smo implementirali v akcijski metodi. V

akcijski metodi smo preko akcijskega odgovora nastavili dogodek »issue« s

pomočjo metode setEvent. V metodi smo kot argument uporabili kvalificirano ime,

ki je sestavljeno iz imenskega področja in identifikatorja dogodka, ter objekt tipa

Issues, ki smo ga ustvarili na podlagi izbrane zahteve (koda 5.9).

Issue issue = new Issue();

issue.setId(Integer.parseInt(issueId));

javax.xml.namespace.QName qName = new QName("org.bitbucker.issue", "issue", "x");

actionResponse.setEvent(qName, issue);

Koda 5.9: Izsek iz akcijske metode za pošiljanje dogodka.


41

Poslušalec: je v okviru razvite portletne aplikacije portlet Issues, ki se odziva na

proženje dogodkov. Da smo se sposobni odzvati na proženje podprtih dogodkov,

smo metodo, v kateri obdelujemo dogodke, označili z @processEvent in opremili z

atributom, ki na podlagi imenskega področja in identifikatorja dogodka registrira

metodo samo za izbrani dogodek, s čimer smo ustvarili dogodkovno metodo. V

dogodkovni metodi smo implementirali pridobivanje dogodkov, tako da smo nad

dogodkovno zahtevo klicali metodo getEvent. Same podatke smo iz dogodka

pridobili s pomočjo metode getValue (koda 5.10).

@ProcessEvent(qname = "{org.bitbucket}issue")

public void processIssue(EventRequest eventRequest, EventResponse eventResponse)

throws javax.portlet.PortletException, java.io.IOException {

…

Event event = eventRequest.getEvent();

Issue issue = (Issue) event.getValue();

…

}

Koda 5.10: Dogodkovna metoda za poslušanje podprtega dogodka.

Razširitev Liferay: ne omogoča samo uporabe dogodkov na isti portalni strani, kjer

se nahaja portlet pošiljatelj, ampak so dogodki na voljo tudi portletom, ki se

nahajajo na drugih portalnih straneh. To funkcionalnost smo omogočili v

nastavitveni datoteki portala Liferay (portal-ext.properties) z nastavitvijo parametra

portlet.event.distribution na vrednost »layout-set«.

Portletni dogodki so osnovani na tehnologiji Java EE. Zmožnost portletnih dogodkov je

povezljivost portletov, ki se nahajajo na isti portletni strani. V portalu Liferay imamo

možnost, da razširimo portletne dogodke, tako da so ti dosegljivi tudi portletom na drugih

portalnih straneh. Posebnost portletnih dogodkov je veriženje dogodkov, to pomeni, da

dogodek lahko proži tudi druge dogodke. Ker portletni dogodki slonijo na Java EE

tehnologiji, se mora ob vsaki uporabi zgoditi ponovni izris portalne strani, zato je

uporabniška izkušnja negativna.

42

Mehanizem Liferay za povezljivost portletov na strani odjemalca

Implementacije povezljivosti med portleti z uporabo Liferay povezljivost portletov na strani

odjemalca je sestavljeno iz implementacije »Izdajatelja« in »Naročnika«:

Izdajatelj: je implementiran v portletnem načinu pogled (view.jsp) portleta Commits

z uporabo JavaScript funkcije Liferay.fire, v kateri smo implementirali pošiljanje

sporočil. Funkcija kot parameter prejme dogodek, katerega proži, in podatke za

pošiljanje. Ime dogodka smo definirali kot »org.bitbucket.issue«, medtem ko so

poslani podatki v obliki objekta JSON (koda 5.11).

function sendIssue(issueId){

var issue = {

issueId : issueId

};

Liferay.fire("org.bitbucket.issue", issue);

}

Koda 5.11: Izsek Liferay povezljivosti za pošiljanje sporočil.

Naročnik: je implementiran v portletnem načinu pogled (view.jsp) portleta Issues z

uporabo JavaScript funkcije Liferay.on, ki implementira obdelavo prejetih

dogodkov. V funkciji smo kot parameter uporabili ime dogodka, ki smo ga definirali

v pošiljatelju in funkcijo, v kateri obdelamo podatke, ki so bili poslani z dogodkom

(koda 5.12).

Liferay.on('org.bitbucket.issue', function(issue) {

var issueId = issue.issueId;



);

Koda 5.12: Izsek Liferay povezljivosti za prejemanje sporočil.

Mehanizem Liferay za povezljivost portletov na strani odjemalca je osnovan na tehnologiji

AJAX. Zmožnost mehanizma je povezljivost portletov, ki se nahajajo na isti portletni strani.

Ker mehanizem Liferay za povezljivost portletov na strani odjemalca sloni na tehnologiji

AJAX, se portalna stran ob uporabi ne osveži, zato je uporabniška izkušnja pozitivna.


43

5.4 Razvoj pripomočkov in njihova povezljivost

5.4.1 Vzpostavitev razvojnega okolja

Za razvoj pripomočkov v portalu Liferay ne potrebujemo dodatnih razvojnih orodij. Kot del

integracije specifikacije OpenSocial je v portal vključen urejevalnik pripomočkov

OpenSocial (angl. OpenSocial Gadget Editor). Urejevalnik pripomočkov je kompletno

razvojno okolje za razvoj pripomočkov in omogoča označevanje sintakse, predogled

razvitih pripomočkov ter objavljanje in odstranjevanje pripomočkov v repozitoriju

ripomočkov, ki ga zagotavlja portal. Na sliki 5.6 je prikazan urejevalnik pripomočkov

OpenSocial.

Slika 5.6: Urejevalnik pripomočkov OpenSocial.

5.4.2 Razvoj pripomočkov

Razvoj pripomočkov smo začeli z izdelavo dveh pripomočkov, CommitsGadget in

IssuesGadget, v urejevalniku pripomočkov OpenSocial. Ta pripomočka smo kot XML

dokumenta objavili v repozitorij pripomočkov, ki ga zagotavlja portal Liferay, da sta ta na

voljo za prikaz na portalni strani.


44

Sam razvoj pripomočkov smo razdelili na dva dela. Prvi del skrbi za prikazovanje

podatkov, medtem ko je drugi del odgovoren za dostop do podatkov, nastavljanje in

poslušanje sprememb na pripomočku. Za prikaz podatkov smo ustvarili različne razdelke

za prikaz podatkov v jeziku HTML, ki se ustrezno skrijejo oz. prikažejo in napolnijo s

podatki. Za dostop do podatkov, nastavljanje in poslušanje sprememb na pripomočku

skrbi del, ki uporablja funkcionalnosti pripomočkov preko skriptnega jezika JavaScript.

Ko vsebnik pripomočkov naloži katerega izmed pripomočkov, CommitsGadget ali

IssuesGadget, se najprej iz uporabniških nastavitev pripomočka pridobijo podatki o

repozitoriju, iz katerega želimo pridobivati podatke. Pridobljeni podatki o repozitoriju se

uporabijo za avtentikacijo pripomočka s storitvijo Bitbucket. Če je avtentikacija uspešna,

se sproži klic storitve, ki pridobi podatke v obliki dokumenta JSON. Iz dokumenta JSON

se s pomočjo programskega vmesnika, ki ga zagotavlja pripomoček za delo z viri JSON,

pridobijo podatki in se s pomočjo skriptnega jezika JavaScript vključijo v ustrezen HTML

razdelek pripomočka.

5.4.3 Povezljivost med pripomočki

Standardno povezljivost med pripomočki zagotavlja mehanizem objavi – naroči [1].

Povezljivost med pripomočki bo analizirana na podlagi razvite portalne aplikacije (slika

5.7), katere delovanje je bilo podrobneje opisano v poglavju 5.1.3


45

Slika 5.7: Portalna aplikacija, sestavljena iz pripomočkov.

Mehanizem objavi – naroči za povezljivost pripomočkov

Implementacija povezljivosti med pripomočki z uporabo mehanizma objavi – naroči je

sestavljena iz definicij sporočila, imenovanega »tematika« in implementacije »izdajatelja«

in »naročnika«.

Izdajatelj: je v pripomočku CommitsGadget definiran v elementu ModulePref kot

obvezna funkcionalnost skupaj z definicijo tematike »org.bitbucket.issue«, v katero

pripomoček objavlja sporočila (koda 5.13). Objavo tematike smo implementirali

znotraj elementa Content. Ko uporabnik portala izbere zahtevo, se proži funkcija

JavaScript, v kateri smo implementirali objavo sporočila z uporabo funkcije

gadgets.Hub.publish. V funkcijo gadgets.Hub.publish smo v tematiko

»org.bitbucket.issue« objavili informacijo o zahtevi v obliki objekta JSON (koda

5.14).


46

<Require feature="pubsub-2">

<Param name="topics">

<![CDATA[

<Topic title="Issue" name="org.bitbucket.issue" publish="true">

</Topic>

]]>

</Param>

</Require>

Koda 5.13: Definicija izdajatelja za mehanizem objavi – naroči.

function publishIssue(issueId){

var issue = {

issueId : issueId

};

gadgets.Hub.publish("org.bitbucket.issue", issue);

}

Koda 5.14: Izsek objave sporočila v tematiko mehanizma objavi – naroči.

Naročnik: je v pripomočku IssuesGadget definiran v elementu ModulePref kot

obvezna funkcionalnost skupaj z definicijo tematike »org.bitbucket.issue«, na

katero je pripomoček naročen (koda 5.15). Naročilo na tematiko smo

implementirali znotraj elementa Content, v katerem se pripomoček preko funkcije

gadgets.HubSettings.onConnect najprej poveže na sporočilno središče. Ko se je

pripomoček povezal s sporočilnim središčem, smo ga preko funkcije

gadgets.Hub.subscribe naročili na tematiko »org.bitbucket.issue« in definirali

povratno funkcijo, ki se kliče ob objavi sporočila ter poskrbi, da se pridobijo

informacije o zahtevi (koda 5.16).


47

<Require feature="pubsub-2">

<Param name="topics">

<![CDATA[

<Topic title="Issue" name="org.bitbucket.issue" subscribe="true">

</Topic>

]]>

</Param>

</Require>

Koda 5.15: Definicija naročnika za mehanizem objavi – naroči.

gadgets.HubSettings.onConnect = function(hub, suc, err) {

subscriptionId = gadgets.Hub.subscribe("org.bitbucket.issue", callback);

}

function callback(topic, issue, subscriberData) {

getIssue(issue.issueId);

}

Koda 5.16: Izsek naročila na tematiko iz mehanizma objavi – naroči.

Mehanizem objavi – naroči za povezljivost pripomočkov sloni na tehnologiji AJAX.

Povezljivost mehanizem omogoča le na portalni strani, kjer se nahajajo vsi pripomočki.

Ker mehanizem objavi – naroči za povezljivost pripomočkov uporablja tehnologijo AJAX,

se portalna stran ob njegovi uporabi ne osveži, zato je uporabniška izkušnja pozitivna.

5.5 Povezljivost med portleti in pripomočki

V tem poglavju bomo analizirali povezljivost med portleti in pripomočki. Čeprav se

omenjeni komponenti iz uporabniškega vidika ne razlikujeta, sta tehnološko gledano

precej različni. Portleti so strežniške komponente, ki za svoje delovanje potrebujejo

portletni vsebnik, medtem ko so pripomočki komponente na strani uporabnika, za katere

skrbi vsebnik pripomočkov.


48

5.5.1 Uporaba mehanizma Liferay za povezljivost portletov na strani odjemalca

Kljub vsem tehnološkim razlikam med portleti in pripomočki obe portalni komponenti

uporabljata mehanizma objavi – naroči za povezljivost na strani odjemalca. Mehanizem

Liferay za povezljivost portletov na strani odjemalca izkorišča to podobnost in svojo

funkcionalnost razširja na mehanizem objavi – naroči, ki ga uporabljajo pripomočki.

Implementacija povezljivosti med portleti in pripomočki zahteva uporabo obeh omenjenih

mehanizmov. Medtem ko na strani pripomočkov uporaba mehanizma ostane enaka,

moramo na strani portletov pri objavi in naročilu na tematiko uporabiti predpono

»gadget:«. Povezljivost med portletom »izdajateljem« in pripomočkom »naročnikom« smo

v portalni aplikaciji implementirali na naslednji način:

Izdajatelj: je v portletu Commits definiran v portletnem načinu pogled, ki ga

zagotavlja JavaServer stran view.jsp. Objavo sporočila v tematiko

»gadget:org.bitbucket.issue« smo implementirali z uporabo JavaScript funkcije

Liferay.fire, v kateri smo informacije o zahtevi objavili v tematiko

»gadget:org.bitbucket.issue« (koda 5.17). S predpono »:gadget« smo objavo

izvedli v mehanizem objavi – naroči, ki ga uporabljajo pripomočki, zato so

sporočila v objavljeni tematiki na voljo tudi pripomočkom.

function publishIssue(issueId){

var issue = {

issueId : issueId

};

Liferay.fire("gadget:org.bitbucket.issue", issue);

}

Koda 5.17: Izsek objave sporočil iz portleta v tematiko pripomočkov.

Naročnik: je v pripomočku IssuesGadget za sporočila, ki jih v tematiko objavlja

portlet, definiran enako, kot če bi sporočila objavljal pripomoček. Razlika je edino v

tem, da v pripomočku definiramo (koda 5.15) in se naročamo (koda 5.16) na

tematiko portleta Commits brez predpone »gadget:«, torej »org.bitbucket.issue«.

Povezljivost med pripomočkom »izdajateljem« in portletom »naročnikom« smo v portalni

aplikaciji implementirali na podoben način:

49

Izdajatelj: je v pripomočku CommitsGadget za portlete definiran enako, kot če bi

sporočilo v tematiko objavljal za pripomočke. V pripomočku smo definirali tematiko

(koda 5.13) in objavo (koda 5.14) sporočila enako, kot če bi implementirali

povezljivost s pripomočkom.

Naročnik: je v portletu Issues definiran v portletnem načinu pogled, ki ga

zagotavlja JavaServer stran view.jsp. Naročilo na tematiko smo implementirali z

uporabo funkcije Liferay.on, v kateri smo se naročili na tematiko

»gadget:org.bitbucket.issue« (koda 5.18). Pri tem smo s predpono »gadget:«

nakazali, da se naročamo na tematiko, ki je objavljena v mehanizmu objavi –

naroči, ki ga uporabljajo pripomočki. Ko pripomoček objavi sporočilo v tematiko, se

kliče funkcija Liferay.on, v kateri poskrbimo za pridobitev in prikaz podrobnosti o

zahtevi.

Liferay.on('org.bitbucket.issue', function(issue) {

var issueId = issue.issueId;



);

Koda 5.18: Izsek naročila na tematiko pripomočkov iz portleta.

5.5.2 Uporaba mehanizmov za povezljivost spletnih komponent

Standardni komunikacijski mehanizmi, ki omogočajo povezljivost portalnih komponent,

portlet in pripomoček, naslavljajo le istovrstne komponente. Portal Liferay je zaobšel te

omejitve z uporabo lastnega komunikacijskega mehanizma na strani odjemalca.

Posledično smo želeli nadgraditi povezljivost portalnih komponent z mehanizmom, ki bo:

omogočal povezljivost med enakimi portalnimi komponentami (npr. portlet – portlet

in pripomoček – pripomoček)

omogočal povezljivost med različnimi portalnimi komponentami (npr. portlet –

pripomoček in obratno),

povezljivost preko različnih portalnih strani ter bo

enostaven za uporabo in

neodvisen od portalne rešitve.


50

Pri iskanju primernih mehanizmov za povezljivost, ki bi zadostili zgornjim zahtevam, smo

naleteli na sporočilni sistem Faye in JavaScript knjižnico, ki za komunikacijo uporablja

lokalno shrambo brskalnika.

Mehanizem Liferay za povezljivost portletov na strani odjemalca je osnovan na tehnologiji

AJAX. Povezljivost mehanizem omogoča med portleti in pripomočki, vendar le na portalni

strani, kjer se nahajajo oboji. Ker mehanizem objavi – naroči za povezljivost pripomočkov

uporablja tehnologijo AJAX, se portalna stran ob njegovi uporab ne osveži, zato je

uporabniška izkušnja pozitivna.

Sporočilni sistem Faye

Faye je odprtokodni sporočilni sistem objavi – naroči, ki temelji na protokolu Bayeux7.

Sestavljen je iz sporočilnega strežnika, ki je na voljo za Node.js8 in Ruby, ter odjemalcev

za uporabo na strežnikih in spletnih brskalnikih. Sporočila, ki so poslana preko

sporočilnega strežnika Faye, so lahko katerikoli JavaScript objekt, ki ga je mogoče

serializirati v JSON [4].

Sporočilni sistem Faye se razlikuje od mehanizmov, ki smo jih predstavili doslej. Slednji

so del samega portala, medtem ko je Faye zunanji sporočilni sistem in ga sestavljajo

sporočilni strežnik ter odjemalci. Implementacija sporočilnega sistema Faye za

povezljivost portalnih komponent zato obsega vzpostavitev sporočilnega strežnika in

implementacijo »izdajatelja« in »naročnika« sporočil.

Sporočilni strežnik: evidentira, kateri odjemalec je naročen na katero tematiko in

usmerja sporočila med odjemalce. Zato smo najprej vzpostavili sporočilni strežnik.

Ker smo uporabili Node.js implementacijo sporočilnega strežnika, smo namestili

tudi izvajalno okolje Node.js, ki je potrebno za izvajanje sporočilnega strežnika. Za

delovanje sporočilnega strežnika smo na razredu NodeAdapter definirali priklopno

točko (angl. Mount), ki določa pot, na kateri je sporočilni strežnik dosegljiv, in

časovno omejitev (angl. Timeout), ki definira najdaljše trajanje povezave. Celotno

implementacijo sporočilnega strežnika Faye prikazuje koda 5.19.

7 Bayeux: je protokol za pošiljanje asinhronih sporočil (navadno preko spletnega protokola http ali

WebSocket) z nizko latenco med spletnim strežnikom in spletnim odjemalcem [28]. 8 Node.js: je asinhrono JavaScript izvajalno okolje, razvito za gradnjo razširljivih omrežnih aplikacij.


51

var http = require('http'),

faye = require('faye');

var server = http.createServer(),

bayeux = new faye.NodeAdapter({mount: '/faye', timeout: 45});

bayeux.attach(server);

server.listen(8000);

Koda 5.19: Implementacija sporočilnega strežnika Faye.

Vsaka portalna komponenta, ki želi uporabljati storitve sporočilnega strežnika Faye, mora

uporabiti spletni odjemalec Faye. Za izdelavo odjemalca je potrebno v portalno

komponento najprej vključiti knjižnico JavaScript, ki je na voljo na naslovu Faye strežnika.

Odjemalec izdelamo tako, da kot argument podamo naslov sporočilnega strežnika, ki

vključuje priklopno točko, s čimer se povežemo na sporočilni strežnik.

Izdajatelja: ki sta lahko portlet Commits ali pripomoček CommitsGadget, smo

implementirali z uporabo funkcije publish odjemalca Faye. V funkcijo smo kot

argument definirali tematiko »/org/bitbucket/issue«, na katero bo odjemalec

objavljal sporočila v obliki objekta JSON. Koda 5.20 prikazuje implementacije

izdajatelja in objave sporočila v portletu ali pripomočku.

function publishIssueFaye(issueId){

var issue = {

issueId : issueId

};

var client = new Faye.Client('http://workstation:8000/faye');

client.publish('/org/bitbucket/issue', issue);

}

Koda 5.20: Izsek objave sporočila v sporočilni strežnik Faye.

Naročnika: ki sta lahko portlet Commits ali pripomoček CommitsGadget, smo v

implementirali z uporabo funkcije subscribe odjemalca Faye. V funkciji smo kot

argument podali tematiko »/org/bitbucket/issue«, na katero se odjemalec naroča,

in funkcijo, iz katere pridobi sporočilo v obliki objekta JSON. Funkcija subscribe se


52

kliče, ko izdajatelj objavi sporočilo v tematiki, na katero je naročen odjemalec.

Koda 5.21 prikazuje implementacijo naročnika v portletu ali pripomočku.

var subscriptionId = client.subscribe('/org/bitbucket/issue', function(issue) {

getIssue(issue.issueId)

});

Koda 5.21: Izsek naročila na tematiko v sporočilnem strežniku Faye

Sporočilni sistem Faye je sestavljen iz sporočilnega strežnika in spletnih odjemalcev.

Medtem ko je sporočilni strežnik osnovan na tehnologiji Node.js (JavaScript na strani

strežnika), so odjemalci osnovani na tehnologiji AJAX. Zmožnosti, ki jih omogoča Faye, so

povezljivost portletov in pripomočkov, ki se nahajajo na istih ali različnih portalnih straneh

oz. v drugem zavihku ali celo oknu brskalnika. Ker odjemalci Faye slonijo na tehnologiji

AJAX, se portalna stran ob njihovi uporab ne osveži, zato je uporabniška izkušnja

pozitivna.

Uporaba mosta lokalne shrambe brskalnika

Most lokalne shrambe brskalnika je na voljo kot knjižnica JavaScript, ki za komunikacijo

med portalnimi komponentami uporablja lokalno shrambo9 brskalnika [29]. Knjižnica

standardno funkcionalnost lokalne shrambe brskalnika razširja na mehanizem objavi –

naroči.

Implementacija mosta lokalne shrambe obsega implementacijo »izdajatelja« in

»naročnika« sporočil. Pred samo implementacijo moramo v portalne komponente vključiti

knjižnico lsbridge, ki implementira most lokalne shrambe brskalnika.

Izdajatelja: sta lahko portlet Commits in pripomoček CommitsGadget.

Implementirali smo ga z uporabo funkcije send knjižnice lsbridge. V funkcijo smo

kot parameter definirali tematiko »/org/bitbucket/issue«, na katero se objavljajo

sporočila v obliki JSON objekta (koda 5.22).

9 Lokalna shramba (angl. Local storage): omogoča spletnim aplikacijam lokalno shranjevanje

podatkov znotraj uporabnikovega brskalnika.


53

function publishIssueLsbridge(issueId){

var issue = {

issueId : issueId

};

lsbridge.send('/org/bitbucket/issue', issue);

}

Koda 5.22: Izsek shranjevanja sporočila v lokalno shrambo brskalnika.

Naročnika: sta lahko portlet Commits in pripomoček CommitsGadget.

Implementirali smo ga z uporabo funkcije subscribe knjižnice lsbridge. V funkcijo

smo kot argument podali tematiko »/org/bitbucket/issue«, na katero se odjemalec

naroča, in funkcijo, iz katere pridobi sporočilo v obliki objekta JSON. Funkcija se

kliče, ko pride do objave sporočila na naročeni tematiki (koda 5.23).

lsbridge.subscribe('/org/bitbucket/issue', function(issue) {

getIssue(issue.issueId);

});

Koda 5.23: Izsek branja sporočila iz lokalne shrambe brskalnika.

Most lokalne shrambe brskalnika sloni na tehnologiji JavaScript. Zmožnosti, ki jih

omogoča most lokalne shrambe brskalnika, je povezljivost portletov in pripomočkov, ki se

nahajajo na istih ali različnih portalnih straneh oz. v drugem zavihku brskalnika. Ker

odjemalci Faye slonijo na tehnologiji AJAX, se portalna stran ob njihovi uporabi ne osveži,

zato je uporabniška izkušnja pozitivna.

5.6 Analiza povezljivosti portalnih komponent

V tem poglavju bomo naredili primerjalno analizo mehanizmov za povezljivost portalnih

komponent. Vsak mehanizem za povezljivost ima svoje prednosti in slabosti, ki jih bomo v

nadaljevanju poskusili identificirati in na podlagi tega izbrati najbolj primernega za

povezljivost portletov in pripomočkov v poslovnem portalu Liferay.

Mehanizmi za povezljivost portalnih komponent so različno zahtevni za implementacijo.

Zahtevnost implementacije mehanizma smo ocenili glede na število osnovnih korakov, ki

so potrebni za implementacijo. Pri tem smo izhajali, da sta za dosego povezljivosti


54

potrebna vsaj dva koraka, in sicer implementacija pošiljatelja in prejemnika sporočil. Vsak

dodatni korak, ki je potreben za implementacijo, pomeni dodatno zahtevnost. V tabeli 5.2

so prikazani koraki potrebni za implementacijo posameznega mehanizma za povezljivost.

Tabela 5.2: Koraki potrebni za implementacije posamezne povezljivosti.

Imple

menta

cija

pošilj

ate

lja in p

reje

mnik

a

Definic

ija s

poro

čila

Imple

menta

cija

do

godkovn

e m

eto

de

Vzposta

vitev s

poro

čiln

ega s

trežnik

a

Lifera

y r

azšir

itev o

sn

ovne f

unkcio

naln

osti

Portletna seja

Javni parametri

Portletni dogodki

Liferay povezljivost portletov na strani odjemalca

Mehanizem objavi-naroči za povezljivost pripomočkov


Most lokalne shrambe brskalnika

Iz tabele 5.2 je razvidno, da je glede na število potrebnih korakov najbolj zahtevna

implementacija portletnih dogodkov. Pri implementaciji portletnih dogodkov je poleg

pošiljatelja in prejemnika dogodkov potrebno definirati še sporočilo in implementirati

dogodkovno metodo na strani prejemnika. Najmanj korakov je potrebnih, če povezljivost

implementiramo z mehanizmom Liferay za povezljivost portletov na strani odjemalca ali

uporabo mosta lokalne shrambe brskalnika.

Tehnologije, na katerih je osnovana posamezna povezljivost portalnih komponent, so

prikazane v tabeli 5.3. Iz tabele lahko razberemo, da med analiziranimi mehanizmi za

povezljivost portalnih komponent prevladuje tehnologija AJAX, ki zagotavlja povezljivost


55

na strani odjemalcev za portlete in pripomočke, medtem ko se tehnologija Java uporablja

izključno za povezljivost med portleti na strani strežnika.

Tabela 5.3: Tehnologije na katerih slonijo mehanizmi za povezljivost.

Mehanizmi za povezljivost portalnih komponent so bili razviti z različnim namenom in z

uporabo različnih tehnologij, zato imajo različne zmožnosti povezljivosti. Njihovo zmožnost

smo analizirali z različnimi scenariji, tako da smo analizirali povezljivost istovrstnih in

različnih portalnih komponent, ki se nahajajo na isti portalni strani, različni portalni strani

ali v drugem zavihku brskalnika. Tabela 5.4 prikazuje zmožnosti, ki jih omogočajo

posamezni mehanizmi.

Java E

E

AJA

X

Java

Script n

a s

tra

ni odje

malc

a

JavaS

cript n

a s

tra

ni str

ežn

ika

Portletna seja

Javni parametri

Portletni dogodki

Liferay povezljivost portletov na strani odjemalca

Mehanizem objavi-naroči za povezljivost pripomočkov


Most lokalne shrambe brskalnika


56

Tabela 5.4: Zmožnosti, ki jih omogočajo posamezni mehanizmi.

Port

let (n

a isti port

aln

i str

ani)

Port

let (n

a d

rug

i p

ort

aln

i str

ani)

Port

let (v

dru

gem

zavih

ku b

rskaln

ika)

Prip

om

oček (

na isti p

ort

aln

i str

ani)

Prip

om

oček (

na d

rugi port

aln

i str

ani)

Prip

om

oček (

v d

rugem

zavih

ku)

Portletna seja Portlet

Javni parametri Portlet

Portletni dogodki Portlet

Povezljivost med portleti na strani odjemalca Liferay Portlet

Sporočilni sistem Faye Portlet

Most lokalne shrambe brskalnika Portlet

Mehanizem objavi-naroči za povezljivost pripomočkov Pripomoček

Sporočilni sistem Faye Pripomoček

Most lokalne shrambe brskalnika Pripomoček

Iz tabele 5.4 je razvidno, da sporočilni sistem Faye in most lokalne shrambe brskalnika

omogočata povezljivost različnih portalnih komponent ne glede na to, ali se komponente

nahajajo na isti ali drugi portalni strani oz. na drugem zavihku brskalnika. Poleg omenjenih

dveh mehanizmov povezljivost med različnimi portalnimi komponentami omogoča le še

mehanizem Liferay za povezljivost med portleti na strani odjemalca, vendar le, ko se

portalne komponente nahajajo na isti portalni strani. Preostali »standardni« mehanizmi za

povezljivost portalnih komponent omogočajo le povezljivost med istovrstnimi portalnimi

komponentami.

Uporabniška izkušnja povezljivosti portalnih komponent je bila ocenjena na podlagi

subjektivnega vidika. Zanimalo nas je, ali uporaba mehanizma vpliva na uporabniško

izkušnjo pozitivno ali negativno. Uporabniško izkušnjo lahko povežemo s tehnologijo, na

kateri je določena povezljivost osnovana (tabela 5.3). Medtem ko Java tehnologija na


57

strežniški strani deluje na uporabniško izkušnjo predvsem negativno, to pomeni, da se ob

vsaki uporabi mehanizma osveži portalna stran, ker se ponovno izrišejo vse portalne

komponente, delujeta tehnologiji AJAX in JavaScript pozitivno, saj se portalna stran

posodobi na nivoju portalne komponente, zato ni potrebe, da bi se osvežila celotna

portalna stran.

Izbira določenega mehanizma za povezljivost portalnih komponent je pogojena s tem, ali

želimo povezati istovrstne ali različne portalne komponente. Če se odločamo za

povezljivost istovrstnih komponent, menimo, da se moramo zaradi skladnosti s

standardom odločiti za eno izmed standardnih povezljivosti.

Če potrebujemo povezljivost med različnimi komponentami, se ne moremo ozirati na

standardne mehanizme za povezljivost. Prav tako niso primerni zunanji mehanizmi in tisti,

ki prvotno niso namenjeni povezljivosti portalnih komponent. Za povezljivost različnih

portalnih komponent znotraj portala Liferay je po naši oceni zato najbolj primeren

mehanizem Liferay za povezljivost portletov na strani odjemalcev. Izbrali smo ga, ker je

preprost za implementacijo, pri čemer omogoča povezljivost med portleti in pripomočki.

Ker je osnovan na tehnologiji AJAX, je uporabniška izkušnja ob njegovi uporabi pozitivna,

saj se portalna stran ob njegovi uporabi ne osveži.


58

6 SKLEP

Poslovni portali integrirajo različne storitve in sisteme v samostojne portalne komponente,

ki jih vključijo v portalne strani. S povezovanjem samostojnih portalnih komponent lahko

ustvarimo sestavljene aplikacije, ki uporabnikom omogočajo bolj učinkovito opravljanje

opravil.

V diplomski nalogi smo analizirali mehanizme za povezljivosti portalnih komponent na

poslovnem portalu Liferay. Povezljivost smo preizkusili na dveh tehnološko različnih

portalnih komponentah, in sicer Java portletih, ki so strežniška tehnologija, in pripomočkih

OpenSocial, ki so tehnologija na strani odjemalcev. Analizirali smo povezljivost

mehanizmov med istovrstnimi in različnimi portalnimi komponentami. Pri tem smo

ugotovili, da uporaba različnih tehnologij in standardov omejuje izbiro mehanizma za

povezljivost portalnih komponent. Posledično zaradi tehnološke različnosti, standardi

portalnih komponent, kot sta portletna specifikacija in specifikacija pripomočkov

OpenSocial, naslavljajo samo povezljivost istovrstnih komponent. Vseeno menimo, da

moramo v primeru povezovanja istovrstnih portalnih komponent uporabiti enega izmed

standardnih mehanizmov za povezljivost.

Večji izziv predstavlja povezljivost portalnih komponent, ki slonijo na različnih

tehnologijah. Ugotovili smo, da se v takšnih primerih ne moremo ozirati na standardne

mehanizme za povezljivost, ampak moramo uporabiti prilagojeno rešitev, ki najbolj

ustreza našim zahtevam. Povezljivost med portleti in pripomočki in obratno smo dosegli z

uporabo mehanizmov, ki zagotavljajo povezljivost portalnih komponent na strani

odjemalca. Ocenili smo, da je za povezljivost portletov in pripomočkov v portalu Liferay

najbolj primeren mehanizem Liferay za povezljivost portletov na strani odjemalcev.

Diplomsko nalogo lahko sklenemo z ugotovitvijo, da je izbira mehanizma za povezljivost

portalnih komponent v prvi vrsti odvisna od tega, ali želimo povezovati istovrstne ali

različne portalne komponente. Kadar se odločamo za povezovanje različnih portalnih

komponent, uporabimo mehanizem za povezavo, ki ga zagotavlja portal. Če takšen

mehanizem v okviru portala ni na voljo, uporabimo rešitve, ki jih zagotavljajo tretji

ponudniki.


59

LITERATURA

[1] Core Gadget Specification 2.5.1, OpenSocial Foundation, 2013. Dostopno na:

http://opensocial.github.io/spec/trunk/Core-Gadget.xml [25.8.2016].

[2] Dias, C. Corporate Portals: a literature review of a new concept in Information

Managment, International Journal of Information Managmen 21 , (2001), 4, str. 269-287.

[3] Enterprise OpenSocial Whitepaper, OpenSocial.org., 2009. Dostopno na:

http://archive.is/Ts81o#selection-823.224-825.1 [22.7.2016].

[4] Faye: Simple pub/sub messaging for the web, 2016. Dostopno na:

https://faye.jcoglan.com/ [25.8.2016].

[5] Gothe, D. Understanding the Java Portlet Specification 2.0 (JSR 286). Oracle

Technology Network for Java Developers, 2010. Dostopno na:

http://www.oracle.com/technetwork/java/jsr286-141866.html [25.8.2016].

[6] Grewe, L. OpenSocial network programming. Indianapolis, IN: Wiley, 2009.

[7] Grossmann, M., Koschek, H. Unternehmensportale: Grundlagen, Architekturen,

Technologien. Berlin: Springer, 2005.

[8] Heričko, M., Jurič, B. M., Beloglavec, S., Šumak B. Do pravega portala s pravim

portalnim strežnikom, Portorož: Konferenca SIOUG, 2003.

[9] IBM WebSphere Portal and Web Content Manager Version 8.5, IBM Corporation,

2015. Dostopno na: https://public.dhe.ibm.com/common/ssi/ecm/ws/en/wsl14018usen

/WSL14018USEN.PDF [8.9.2015].

[10] JSR 286: Portlet Specification. Java(TM) Portlet Specification, version 2.0. Java

Community Process, 2008. Dostopno na: http://www.jcp.org/en/jsr/detail?id=286

[25.8.2016].

[11] LeBlanc, J. Programming social applications. Sebastopol, CA: O’Reilly, 2011.


60

[12] Liferay Portal 6.2 : Portlet and feature overview, Liferay, Inc., 2014. Dostopno na:

https://web.liferay.com/documents/14/40343f15-532d-47c2-b29c-7f645c9ac0f3 [9.8.2016].

[13] Liferay Portal 6.2 EE Compatibility Matrix, Liferay Inc , 2016. Dostopno na:

https://web.liferay.com/documents/14/21598941/Liferay+Portal+6.2+EE+Compatibility+Ma

trix.pdf [25.8.2016].

[14] Liferay Portal 6.2 Enterprise Edition: Portlet and feature overview, Liferay Inc., 2013

Dostopno na: https://www.liferay.com/documents/ [25.8.2016].

[15] Liferay Portal 6.2, Liferay Inc, 2015. Dostopno na:

https://www.liferay.com/documentation/liferay-portal/6.2 [21.8.2016].

[16] Liferay Portal, Liferay, Inc. 2015. Dostopno na:

http://www.liferay.com/products/liferay-portal [21.8.2016].

[17] Logical Architecture, Liferay Wiki, 2012, Dostopno na:

http://www.liferay.com/community/wiki/-/wiki/1071674/Logical+Architecture [21.8.2016]..

[18] Meera, P. Liferay Theoretical Architecture/Liferay Layered Architecture, Liferay

Savvy, 2014. Dostopno na: http://www.liferaysavvy.com/2014/11/liferay-theoretical-

architecture.html [21.8.2016].

[19] Murphy, J., Phifer, G., Tay, G., Revang, M. Magic Quadrant for Horizontal Portals,

Gartner, Inc., 2015. Dostopno na: https://www.gartner.com/doc/reprints?id=1-

2N57U9O&ct=150915&st=sb [25.8.2016].

[20] OpenAjax Hub 2.0 Specification, OpenAjax Alliance, 2011. Dostopno na:

http://www.openajax.org/member/wiki/OpenAjax_Hub_2.0_Specification [12.8.2016]

[21] OpenSocial Foundation Moves Standards Work to W3C Social Web Activity, W3C,

2014. Dostopno na: https://www.w3.org/blog/2014/12/opensocial-foundation-moves-

standards-work-to-w3c-social-web-activity/ [22.7.2016].

[22] OpenSocial, Wikipedia, the free encyclopedia, 2016. Dostopno na:

https://en.wikipedia.org/wiki/OpenSocia l [22.7.2016].


61

[23] Prince, M. Liferay Inter Portlet Communication (IPC), Technical Blogs, 2015.

Dostopno na: https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-inter-portlet-

communicp [25.8.2016].

[24] Publish–subscribe Pattern. Wikipedia, the free encyclopedia, 2016. Dostopno na:

https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern [22.7.2016].

[25] Sezov, R. Liferay in Action: The Official Guide to Liferay Portal Development. Shelter

Island, NY: Manning, 2012.

[26] Shailesh Shivakumar, K. A complete guide to portals and user experience platforms,

Boca Raton:Taylor & Francis Group, 2016.

[27] Shilakes, C., Tylman, J. Enterprise Information Portals, NY:Merrill Lynch Inc, 1998.

[28] The CometD Reference Book – 3.0.9, 2016. Dostopno na:

https://docs.cometd.org/current/reference/index.html#_bayeux [25.8.2016]

[29] Tsonev, K., Using Local Storage as a communication channel, 2015. Dostopno na:

http://krasimirtsonev.com/blog/article/Using-Local-Storage-as-a-communication-channel

[21.8.2016].

[30] Wang, J., Encyclopedia Of Data Warehousing And Mining, Hershey,PA:Idea Group

Publishing, 2005.

[31] What’s new for developers in SharePoint 2013, Microsoft, 2015. Dostopno na:

https://msdn.microsoft.com/en-us/library/jj163091.aspx [25.8.2016].

[32] White, C. The Role of Open Source in Enterprise Portals, 2005, Dostopno na:

http://www.b-eye-network.com/view/1016 [25.8.2016].

[33] Xinsheng, C., Jonas, X. Y. Liferay 6.2 User Interface Development. Birmingham :

Packt Publishing, 2013.

ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY · Analiza povezljivosti portalnih...

Documents

Transcript of ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY · Analiza povezljivosti portalnih...