ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY

Transcription

1 Fakulteta za elektrotehniko, računalništvo in informatiko Smetanova ulica Maribor, Slovenija Marko Haložan ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY Diplomsko delo Maribor, avgust 2016

2 ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY Diplomsko delo Študent: Študijski program: Smer: Mentor: Lektorica: Marko Haložan Univerzitetni študijski program Računalništvo in informatika Informatika red. prof. dr. Marjan Heričko Mateja Rogan i

3 ii

4 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. iii

5 ANALIZA POVEZLJIVOSTI PORTALNIH KOMPONENT NA PLATFORMI LIFERAY Ključne besede: informacijski sistemi, portali, portleti, OpenSocial pripomočki, portalni strežnik Liferay UDK: (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. iv

6 INTEROPERABILITY ANALYSIS OF LIFERAY PORTLETS Key words: information systems, portals, portlets, OpenSocial gadgets, portal server Liferay UDK: (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. v

7 KAZALO 1 UVOD PORTALI Klasifikacija portalov Lastnosti portalov Trg poslovnih portalov PORTALNE KOMPONENTE Portleti Pripomočki OpenSocial POSLOVNI PORTAL LIFERAY Podpora povezljivosti portalnih komponent PRAKTIČNI PRIKAZ PORTALA S POVEZANIMI KOMPONENTAMI Opis portalne aplikacije Opis atributov analize Razvoj portletov in njihova povezljivost Razvoj pripomočkov in njihova povezljivost Povezljivost med portleti in pripomočki Analiza povezljivosti portalnih komponent SKLEP LITERATURA vi

8 KAZALO SLIK Slika 2.1: Magični kvadrant poslovnih portalov za leto 2015 [19] Slika 5.1: Osnovna stran spletnega vmesnika storitve Bitbucket Slika 5.2: Povezava zahteve z neko spremembo preko komentarja Slika 5.3: Diagram primerov uporabe portalne aplikacije Slika 5.4: Integrirano razvojno okolje Eclipse z vtičnikom Liferay IDE Slika 5.5: Portalna aplikacija, sestavljena iz portletov Slika 5.6: Urejevalnik pripomočkov OpenSocial Slika 5.7: Portalna aplikacija, sestavljena iz pripomočkov KAZALO TABEL Tabela 4.1: Povzetek matrike združljivosti za portal Liferay EE [13] Tabela 5.1: Uporaba vzorca MVC pri razvoju portletne aplikacije Tabela 5.2: Koraki potrebni za implementacije posamezne povezljivosti Tabela 5.3: Tehnologije na katerih slonijo mehanizmi za povezljivost Tabela 5.4: Zmožnosti, ki jih omogočajo posamezni mehanizmi vii

9 IZSEKI PROGRAMSKE KODE Koda 3.1: Vmesnik Portlet [10] Koda 3.2: XML dokument, ki definira pripomoček OpenSocial [11] Koda 5.1: Metoda za izbiro mehanizma za povezljivost portletov Koda 5.2: Nastavitev javne portletne seje v liferay-portlet.xml Koda 5.3: Izsek iz akcijske metode za nastavitev atributa portletne seje Koda 5.4: Izsek iz izrisovalne metode za pridobitev atributa portletne seje Koda 5.5: Definicija javnega parametra in njegova podpora v portletih Koda 5.6: Izsek iz akcijske metode za nastavitev javnega parametra Koda 5.7: Izsek iz izrisovalne metode za dostop do javnega parametra Koda 5.8: Definicija dogodka in podpora pošiljanju in prejemanju v portletih Koda 5.9: Izsek iz akcijske metode za pošiljanje dogodka Koda 5.10: Dogodkovna metoda za poslušanje podprtega dogodka Koda 5.11: Izsek Liferay povezljivosti za pošiljanje sporočil Koda 5.12: Izsek Liferay povezljivosti za prejemanje sporočil Koda 5.13: Definicija izdajatelja za mehanizem objavi naroči Koda 5.14: Izsek objave sporočila v tematiko mehanizma objavi naroči Koda 5.15: Definicija naročnika za mehanizem objavi naroči Koda 5.16: Izsek naročila na tematiko iz mehanizma objavi naroči Koda 5.17: Izsek objave sporočil iz portleta v tematiko pripomočkov Koda 5.18: Izsek naročila na tematiko pripomočkov iz portleta Koda 5.19: Implementacija sporočilnega strežnika Faye Koda 5.20: Izsek objave sporočila v sporočilni strežnik Faye Koda 5.21: Izsek naročila na tematiko v sporočilnem strežniku Faye Koda 5.22: Izsek shranjevanja sporočila v lokalno shrambo brskalnika Koda 5.23: Izsek branja sporočila iz lokalne shrambe brskalnika viii

10 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 ix

11 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. 1

12 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. 2

13 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, 3

14 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. 4

15 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]: 5

16 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. 6

17 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 kode 1 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 produkte 2. 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. 7

18 Slika 2.1: Magični kvadrant poslovnih portalov za leto 2015 [19] 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]. 8

19 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] 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 9

20 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. 10

21 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. 11

22 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

23 Ž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 13

24 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. 14

25 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 15

26 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] 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 16

27 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 17

28 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 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, 18

29 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[ <!-- vsebina pripomočka --> ]]> </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[[...]]. 19

30 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 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 20

31 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]. 21

32 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 22

33 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 WebSphere SQL Server 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 23

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

35 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 25

36 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. 26

37 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

38 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 Storitev Bitbucket Bitbucket je spletna storitev v oblaku za gostovanje projektov, ki uporablja distribuiran sistem za nadzor različic izvorne kode Mercurial 4 ali Git 5. 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. 28

39 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. 29

40 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 OAuth 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. 30

41 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 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. 31

42 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 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. 32

43 Slika 5.4: Integrirano razvojno okolje Eclipse z vtičnikom Liferay IDE 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

44 Tabela 5.1: Uporaba vzorca MVC pri razvoju portletne aplikacije. Commits Issues Nadzornik CommitsPortlet.java IssuesPortlet.java Model Commits.java, Issues.java, Issue.java, BitbucketToolbox.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 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. 34

45 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 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 Slika 5.5: Portalna aplikacija, sestavljena iz portletov. 35

46 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 36

47 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» 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). 37

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

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

50 <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. 40

51 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 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 = "{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. 41

52 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; <!--posodobitev portleta z informacijo o prejeti zahtevi --> ); 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. 42

53 5.4 Razvoj pripomočkov in njihova povezljivost 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 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. 43

54 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 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

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