Rapport Widgets, Gadgets en Portaltechnologie
advertisement
indi-2009-11-012 Rapport Widgets, Gadgets en Portaltechnologie Project Projectjaar Projectmanager Auteur(s) Opleverdatum Versie : : : : : : SURFworks / Proof of Concept Collaboration Infrastructure 2009 Frank Pinxt Wouter Meijers, Paul van Dijk, Niels van Dijk 30 oktober 2009 1.0 Samenvatting Met de Proof of Concept Collaboration Infrastructure, waar dit rapport deel van uit maakt, wil SURFnet een samenwerkingsomgeving realiseren die zich onderscheidt van andere alternatieven doordat er gebruik gemaakt wordt van open standaarden en waarbij federatieve ontsluiting een voorwaarde is voor koppelen van diensten. Om tot een keuze te komen voor de toe te passen technologie voor de gebruikersinterface is er in het project onderzoek gedaan naar Widget- en Portaltechnologie. Het rapport beschrijft de verschillende technologieën en geeft een advies voor het vervolg van het project Voor deze publicatie geldt de Creative Commons Licentie “Attribution-Noncommercial-Share Alike 3.0 Netherlands”. Meer informatie over deze licentie is te vinden op http://creativecommons.org/licenses/by-nc-sa/3.0/nl/ Colofon Programmalijn Onderdeel Activiteit Deliverable Toegangsrechten Externe partij : : : : : : Proof of Concept Collaboration Infrastructure 5.2 Rapport Widget en portaltechnologie publiek Everett Dit project is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website (www.surf.nl). 4 dingen die je moet weten over het Rapport Widgets, Gadgets en Portaltechnologie Context Het rapport maakt deel uit van de Proof of Concept Collaboration Infrastucture. In deze Proof of Concept worden technologieën beproefd die in de toekomst mogelijk gebruikt kunnen worden bij de ontwikkeling van een nieuwe SURFnet samenwerkingsomgeving. Wat is het? Het rapport beschrijft verschillende technologieën die beschikbaar zijn op het gebied van gebruikersinterfaces en geeft een advies voor de toe te passen technologie in een nieuwe samenwerkingsomgeving. Voor wie is het? Het rapport is in eerste instantie bedoeld voor de projectgroep en de stuurgroep van het project Collaboration Infrastucture. Daarnaast is het rapport geschikt als verdieping voor mensen met een technische achtergrond die geïnteresseerd zijn in het onderwerp. Hoe werkt het? nvt Wat kan je ermee? Achtergrondinformatie op het gebied van Widget, Gadget en Portaltechnologie. Extra (Bijlagen, Thema, Gerelateerde thema’s) Rapport Widgets, Gadgets en Portaltechnologie Inhoud 1 Inleiding 6 2 Web presentatie technologieën 7 2.1 Inleiding 2.2 Web Application Frameworks (WAF) 7 10 2.2.1 Scripting 10 2.2.2 Markup Templates 11 2.2.3 Model-View-Controller Engines 12 2.2.4 Rapid Web Development Frameworks (RWD) 13 2.3 Portalservers 14 2.3.1 GUI ontwikkel functionaliteit 16 2.3.2 Integratie 16 2.3.3 Gebruikersbeheer 18 2.3.4 Portal content management 19 3 Anatomie van een portlet 22 3.1 Portal Pagina 22 3.2 Portlet Window States 23 3.3 Portlet View-Modes 24 3.4 Portlet Lifecycle 25 3.5 Portlet Application 27 3.5.1 Portlet Context 27 3.5.2 Sessies 27 3.5.3 State control; Portlet URL’s 28 3.5.4 Events 28 3.5.5 Publieke renderparameters 29 3.5.6 Resource 30 3.5.7 Filters 31 4 Portal Standaarden 4.1 Java Portlet Specification 32 32 4.1.1 JSR 168 32 4.1.2 JSR 286 32 4.1.3 Samenvatting 32 4.2 4.2.2 Web Services for Remote Portlets (WSRP) Samenvatting 34 39 4.3 Microsoft Sharepoint 40 4.4 Gadgets en Widgets 40 4.4.1 Wat is een Gadget? 40 4.4.2 Gadgets API 41 4.4.3 OpenSocial 42 4.4.4 Gadgets Veiligheid 43 4.4.5 Samenvatting 45 4.5 Gadgets en Portalen combineren 5 Functionele eisen 45 47 5.1 Requirements 47 5.2 Technologiemapping 48 6 Conclusie 49 1 Inleiding SURFnet heeft een missie en een sterke traditie om instellingsoverstijgende samenwerking mogelijk te maken. Met de Proof of Concept Collaboration Infrastructure, waar dit rapport onderdeel van uit maakt, wil SURFnet een samenwerkingsomgeving realiseren die zich onderscheidt van andere alternatieven doordat er gebruik gemaakt wordt van open standaarden en waarbij federatieve ontsluiting een voorwaarde is voor het koppelen van diensten. Omdat innovatie tot de core-business van SURFnet behoort, is het noodzakelijk om een platform te creëren waarop in snel tempo innovatieve ontwikkelingen kunnen worden uitgeprobeerd. Dit betekent ook dat het mogelijk moet worden om bèta functionaliteit in een vroeg stadium op dit platform aan te kunnen bieden, tegelijkertijd betekent dit dat een dergelijk platform niet tegemoet zal komen aan de eisen van Operational Excellence die aan SURFnet diensten gesteld worden. Het platform moet een showcase vormen voor innovatieve samenwerking, federatieve authenticatie en multimedia technologie voor onderzoek en onderwijs. Om tot een keuze te komen voor de toe te passen technologie voor de gebruikersinterface zal er in het project onderzoek gedaan worden naar Widget- en Portaltechnologie. De belangrijkste functionele wens in dit onderzoek is het in samenhang kunnen presenteren van diensten (services) van zowel SURFnet, instellingen als ook diensten van derden. Omdat portal techniek hiervoor de meest geschikte oplossingrichting lijkt, wordt gekeken naar de technologieën die hiervoor beschikbaar zijn en wat de voor en nadelen van de verschillende mogelijkheden zijn. Het Collaboration Infrastructure rapport geeft daarnaast aan dat het een goed idee is om technologie te kiezen die het ook voor derden mogelijk maakt delen hiervan te consumeren, door voor een oplossing op basis van open koppelvlakken te kiezen. In hoofdstuk 1 van dit rapport wordt een overzicht gegeven van de verschillende web presentatie technologieën, vervolgens gaat hoofdtuk 2 dieper in op de anatomie van een portlet. In hoofdstuk 5 worden de verschillende Portal standaarden besproken. De functionele eisen vanuit SURFnet aan een portalomgeving worden in hoofdstuk 6 opgesomd, daarnaast is in hoofdstuk 6 een vergelijking van de verschillende technologieën opgenomen. Het rapport eindigt in hoofdstuk 6 met een conclusie en aanbevelingen voor toepassing bij de inrichting van een SURFnet Collaboration Infrastructure. 6/52 2 Web presentatie technologieën 2.1 Inleiding Web presentatietechnologie is er in vele soorten en maten. Met de opkomst van “web 2.0” is er met name aan de browserkant het nodige aan het veranderen. Was “vroeger” de browser niet meer dan een passieve applicatie voor HTML rendering waarbij de opmaak (pagina inhoud en lay-out) volledig door de server werd bepaald, tegenwoordig is het mogelijk om op basis van verschillende technologieën de browser een meer intelligente en dynamische dialoog met de gebruiker te laten voeren. De focus verschuift hiermee van “server side” opmaak naar “client side” opmaak. Onderstaande figuur toont een generieke architectuur op hoofdlijnen voor web presentatie: Figuur 1: Web presentatie architectuur In deze figuur onderscheiden we een viertal punten waar presentatietechnologie een rol speelt: A. De gebruiker is in het bezit van in toenemende mate intelligente browsers met standaard ondersteuning voor web 2.0 gerelateerde technologie zoals AJAX, Java Plugins, Javascript, Flash, built-in RSS, HTML 5, etc. Document [1, Collaboration Infrastructure] geeft hiervan een redelijk uitgebreide beschrijving, inclusief relevante standaarden. Dit rapport gaat hier verderop nog summier op in, met name waar het de relatie betreft met server-side componenten; 7/52 B. Web Applicatie Frameworks (WAF) werken nauw samen met de web server voor het produceren van web content. Een van de oudste en meest bekende varianten hiervan is het Common Gateway Interface (CGI), dat dateert uit begin van de jaren 90 en het mogelijk maakt om via een API “eigen code” te laten executeren door de Web Server. Het CGI (en al zijn varianten zoals SCGI, FastCGI, Apache Modules, NSAPI, ISAPI) zijn inmiddels volledig uitontwikkelde standaarden die door de meeste web servers in de een of andere vorm worden ondersteund. Web ontwikkelaars gebruiken in de praktijk vrijwel nooit deze “low-level” web server API’s maar maken gebruik van open standaarden die in de loop der tijd bovenop deze CGI API’s zijn ontwikkeld. Voorbeelden hiervan zijn: a. Java Servlet API, (JSP); b. Java Server Faces (JSF); c. Struts; d. Spring; e. Cold Fusion; f. Web Server scripts (PHP, Python, Perl); g. ASP, ASP.Net; h. ... Met de opkomst van de “web 2.0” hype zijn er aan de server kant meer en meer volwaardige applicatie frameworks ontstaan waarmee ontwikkelaars redelijk eenvoudig dynamische web applicaties kunnen ontwikkelen. Voorbeelden hiervan zijn: a. WebObjects (Apple); b. Ruby On Rails; c. OpenACS; d. Apache Tapestry; Naast deze specifiek op software ontwikkeling toegespitste systemen is er tegenwoordig sprake van de opkomst van een groeiende groep content management gebaseerde frameworks met zeer uitgebreide presentatie en distributie faciliteiten. Deze frameworks leunen qua functionaliteit aan tegen portalen, alhoewel ze meestal het gepersonaliseerd aanbieden van content elementen (“portlets”) op basis van gebruikersrollen [nog] niet ondersteunen. De CMS frameworks zijn met name sterk als het gaat om het flexibel ontsluiten van informatiebronnen, het combineren van informatie en het aggregeren ervan. Voorbeelden in deze categorie zijn: a. Drupal; b. Alfresco; c. Acquia (“commerciële versie” van Drupal); d. SpringSource; e. WordPress; f. Joomla!; In het algemeen kunnen WAF’s worden opgesplitst in een viertal categorieën: 1) Scripting; 2) Markup Templates; 8/52 3) Model-View-Controller engines; 4) Rapid Web Development Frameworks; Deze vier categorieën zullen in een volgend hoofdstuk in meer detail worden besproken. C. Portalservers zijn in principe WAF’s van het Model-View-Controller type1. Een Portalserver doet aan content aggregatie en presentatie en doet dat vervolgens ook nog op een gepersonaliseerde wijze. Hiertoe dient de portal te weten wie de gebruiker is, wat de gebruiker mag en wat hij/zij wil. Portalen zullen daarom altijd nauw integreren met een authenticatie en autorisatie oplossing en met een repository voor accountadministratie. Een portal breekt zijn web pagina’s op in “templates” met daarop “regions” (coördinatensystemen op de pagina). Binnen een region kunnen “portlets” worden geplaatst. Elke portlet is verantwoordelijk voor het genereren van HTML “fragmenten”. De portlet wordt daartoe door de portalserver aangeroepen op het moment dat een pagina moet worden opgebouwd. Voor een meer gedetailleerd overzicht van de structuur van een portalpagina, zie hoofdstuk 3. De taak van de portalserver is: a. Bepaal de gebruikersrollen op basis van authenticatiegegevens; b. Bepaal de noodzakelijke pagina instantie op basis van de gebruikersrollen en de door de gebruiker ingevoerde URL; c. Bepaal de lijst met portlets op de pagina op basis van de instantie en de gebruikersrollen; d. Draag elke portlet op om HTML fragmenten te genereren; e. Bouw de complete pagina op, op basis van de template gegevens in combinatie met de gegenereerde HTML van de portlets; f. Lever de gegenereerde pagina af bij de gebruiker; Portalservers maken het mogelijk om een complexe, gepersonaliseerde web site te bouwen met minimale ontwikkelinspanningen (aannemende dat alle noodzakelijke portlets aanwezig zijn). De portal administrator kan in het algemeen via een beheerdersdashboard simpel pagina templates aanmaken, deze koppelen met “thema’s” (die de algemene look-and-feel bepalen) en er portlets op plaatsen door deze uit een lijst te selecteren. Voor elke pagina en portlet wordt tevens aangegeven bij welke gebruikersrol (of rollen) deze horen. Tevens kan worden vastgelegd of en in welke mate, de gebruiker “zijn” portal pagina kan aanpassen. Hoofdstuk 2.3 gaat dieper in op de technologie achter portalservers. D. Alhoewel de bedrijfslogica van een web applicatie in principe geen “eigen” presentatielaag bezit, kan het nodig zijn dat op dit niveau kennis aanwezig is van de gebruiker en het gebruikte presentatiekanaal. Op deze manier kan de applicatielogica op correcte wijze rekening houden met rollen en rechten (wat mag/moet deze specifieke gebruiker te zien krijgen) en met de mogelijkheden van het kanaal (bv. breedband Internet kent veel meer en rijkere presentatietechnieken dan een mobiele telefoon of PDA). Anders dan authenticatie en autorisatiestandaarden zijn voor het doorgeven van kanaaleigenschappen geen marktstandaarden aanwezig. Hiervoor zal zelf een oplossing moeten worden bedacht (bv. door kanaaleigenschappen mee te geven naar de achterliggende applicaties, of door deze beschikbaar te stellen via een 1 Het “Model” is de content en applicatie-informatie die door de portlets worden ontsloten. De “View” wordt gevormd door de pagina templates en portlets en de “Controller” is de Portalserver “engine” waarmee de pagina’s daadwerkelijk worden opgebouwd. 9/52 z.g. “kanaalprofiel” (te vergelijken met een “gebruikersprofiel” maar dan voor de combinatie communicatiekanaal/device/presentatiesoftware). In de praktijk zien we dat de applicaties in het algemeen generieke XML berichten genereren die vervolgens door de presentatielaag (B of C) wordt gerendeerd in een kanaalspecifiek formaat (op basis van de HTTP sessiegegevens). Dit kan inhouden dat voor bv. mobiele techniek er veel informatie uit het XML bericht zal worden genegeerd of op andere manier wordt geïnterpreteerd. De applicaties dienen bij het genereren van de berichten in het algemeen rekening te houden met de gebruikersgegevens. Voor het uitwisselen van deze gebruikersgegevens zijn diverse mogelijkheden, waarbij de eenvoudigste bestaat uit het doorgeven van de gebruikersidentifier. Daarnaast bestaan diverse Web Service standaarden zoals WS-Security en SAML die kunnen worden gebruikt voor het uitwisselen van gebruikerscredentials tussen applicaties en/of services. Figuur 1 toont tevens hoe in het algemeen de beveiliging van web applicaties wordt geregeld. Hiertoe wordt de web server voorzien van een stukje software, het “Policy Enforcement Point” (PEP), waarmee kan worden gecontroleerd of de gebruiker toegang heeft tot de door deze gebruiker gevraagde URL. Hiertoe onderschept de PEP elke URL aanvraag en laat hij hier een “security policy” op los. Dit kan variëren van een eenvoudige lokale gebruikersnaam/wachtwoord check tegen een bestandje met toegestane gebruikers tot een verificatie tegen een separate “Authentication, Authorization & Accounting” (AAA) server met gefedereerde authenticatie en geïntegreerde Identity Management oplossing. Belangrijk om te realiseren is dat de beveiligingsoplossing tegenwoordig in het algemeen onafhankelijk is van de overige technologie componenten. De PEP is een “plugin module” voor de betreffende web server of portalserver en er kan worden gekozen uit meerdere mechanismen. Alle zijn ze in principe transparant voor de presentatieomgeving: uiteindelijk zal er na succesvolle authenticatie sprake zijn van een HTTP sessie waarbinnen de identiteit van de gebruiker beschikbaar is voor componenten die daarin geïnteresseerd zijn. Daadwerkelijke implementatie van security over web servers, portalen, service landschappen en applicaties valt buiten de scope van dit rapport. 2.2 Web Application Frameworks (WAF)2 Zoals in het vorige hoofdstuk is vermeld kunnen we op het gebied van WAF’s onderscheid maken tussen een viertal categorieën: 1) Scripting; 2) Markup Templates; 3) Model-View-Controller engines; 4) Rapid Web Development Frameworks; 2.2.1 Scripting Het “scripten” van web applicaties is nog steeds een van de meest gebruikte technieken voor het ontwikkelen van dynamische web applicaties. Hierbij wordt gebruik gemaakt van een web server “plugin” component waarbinnen programmacode wordt uitgevoerd. Voor het schrijven van de code wordt gebruikgemaakt van een van de vele “script talen” die 2 Bij het uitwerken van dit hoofdstuk is o.m. gebruik gemaakt van het Burton Group rapport “Web Application Frameworks: Evolving to support the Interactive Web”, door Richard Monson-Haefel, Versie 1.0, April 16,2007. 10/52 hier in de afgelopen jaren voor zijn ontwikkeld. De meest populaire smaken zijn PHP, Perl, Python, Ruby en ECMAScript/Javascript. De laatste wordt meestal ingezet voor “browserside” scripting, maar het is ook mogelijk om Javascript aan de server kant uit te laten voeren. Bij “scripting” wordt de source code direct door de web server geïnterpreteerd en uitgevoerd. De huidige stand van techniek is daarbij dusdanig dat vrijwel geen performance bottlenecks meer bestaan. Net als bij Java wordt het script eerst vertaald naar een binaire code die efficiënt kan worden uitgevoerd. Deze “just-in-time” compilatietechniek is onzichtbaar voor de ontwikkelaar en levert flinke performancewinsten op. Script talen, met name de recente zoal Ruby, zijn daarnaast vrijwel net zo krachtig als de “hogere programmeertalen” zoals Java, C/C++ of C#. Het grote voordeel van scripting is dat de talen verregaand zijn uitontwikkeld en er een zeer ruime ondersteuning in de vorm van ontwikkelgereedschappen en componentenbibliotheken voor bestaat. Als nadeel kan worden genoemd dat het bouwen van een complexe web applicatie op basis van scripts toch redelijk veel specialistische kennis vraagt. Vrijwel elk aspect van de applicatie dient zelf te worden uitontwikkeld, hetgeen ontwikkelaars vraagt die goed thuis zijn met de gekozen taal en de daarbij behorende componentenbibliotheken (als gevolg van de grote keuze is dit veelal een kwestie van “bomen en bos”). Voor redelijk “platte” web sites waarbij het gedrag vrijwel onafhankelijk is van de identiteit van de gebruiker is het gebruik van scripts nog steeds een goede optie. 2.2.2 Markup Templates Markup is het gebruikmaken van speciale “tag libraries” waarmee in principe de functionaliteit van de HTML opmaaktaal wordt uitgebreid. Door middel van tags kan je in feite “programmeren in HTML”. De nieuwe tags worden in veel gevallen gebruikt voor het activeren van stukjes script taal. Beide oplossingen liggen dus dicht bij elkaar. Alhoewel de basisgedachte in alle gevallen gelijk is, is de invalshoek een beetje verschillend afhankelijk van de gekozen markup variant. Zo maakt bv. ColdFusion gebruik van een combinatie van standaard HTML met specifieke tags, maakt JSP gebruik van eXtensible HTML (XHTML) waarbinnen een aparte XML namespace wordt gebruikt voor het opnemen van Java code binnen de pagina’s. Tenslotte kent Microsoft met zijn ASP een technologie waarbij in het geheel geen HTML meer gebruikt wordt en de pagina’s in principe XML objecten zijn (Microsoft Extensible Application Markup Language, XAML). In sommige gevallen zijn de tags (de feitelijke markup) en de bijbehorende code (scripts) gescheiden. In andere gevallen zitten beiden in dezelfde pagina. En tenslotte zijn er combinaties mogelijk. Voordeel van Markup templates is de eenvoud en het feit dat er vrijwel niet geprogrammeerd hoeft te worden. Nadeel is dat het mechanisme al snel neigt naar het vermengen van applicatie met presentatie waarmee een onontwarbare kluwen ontstaat van presentatie componenten (HTML) en code (scripts en tags). Markup templates alleen zijn daarom niet aan te raden voor grote, complexe projecten. Het is wel mogelijk om markup templates te gebruiken in combinatie met een model zoals MVC (zie volgende hoofdstuk). In dat geval bevat de HTML alleen de tags en wordt de code door het model afgehandeld. Een aantal voorbeelden van markup: Markup framework: Voor taal: JSP Velocity FreeMarker Smarty Java Java Java PHP 11/52 The Template Toolkit (T2T) Perl SSI ASP ColdFusion 2.2.3 Perl Perl VBScript CFML Model-View-Controller Engines Het Model-View-Controller (MVC) pattern is een veelgebruikte manier om onderscheid te maken tussen bedrijfslogica (het “Model”), de manier waarop deze logica communiceert met eindgebruikers over verschillende presentatiekanalen (de “View”) en de wijze waarop de dialoog met de gebruiker wordt gevoerd in de tijd (de “Controller”). MVC maakt het mogelijk om deze drie aspecten onafhankelijk van elkaar te ontwikkelen en is dan ook de basis voor complexe presentatieomgevingen waarbij complexe functionaliteit moet worden aangeboden aan grote gebruikersgroepen over meerdere kanalen. Modellen hebben in het algemeen de vorm van informatie (bv. een view op data in een database) of ze representeren bedrijfsobjecten met bijbehorende state. Modellen zijn prima te implementeren op basis van services. Views nemen meestal de vorm aan van markup templates, waarbinnen zich properties bevinden die een relatie hebben met properties van modellen. De presentatiecode van een View is verantwoordelijk voor het transformeren van Model data op basis van het markup template. De meest populaire technologie hiervoor is XSL(T). Controllers zorgen voor het toekennen van de juiste View aan het juiste Model op basis van de gebruikersdialoog. Controllers dragen daarnaast ook zorg voor bv. validatie. MVC is een krachtige technologie, maar vereist wel goede basiskennis van de gebruikte frameworks. Implementatie is complex, maar zeer flexibel. De meeste MVC frameworks zijn volwassen en goed uitontwikkeld. Een aantal voorbeelden van populaire MVC engines: MVC framework: Voor taal: Struts Java JSF Java Spring Web MVC Java Apache Tapestry Java Zope Python Php.MVC PHP Catalyst Perl Maypole Perl ASP.Net Microsoft Common Language Runtime (CLR) MVC engines zijn de beste keus voor het ontwikkelen van grotere, complexere web applicaties. De technologie kan ook op kleinere schaal worden ingezet om bv. binnen een portalomgeving de content voor één of meerdere portlets te verzorgen. Veel portal engines bieden dan ook MVC patterns aan als ontwikkelomgeving voor het ontwikkelen van portlets. De Portalservers zelf vormen eveneens een specifieke vorm van MVC engines. In een portal wordt de Controller gevormd door de portalserver zelf. De Views zijn de display elementen die de betreffende portalserver kan aanbieden, zoals bv. Portlets. De applicaties en databronnen die door de portal worden ontsloten vormen het Model. Portalen verdienen door hun complexiteit en gebruik een eigen hoofdstuk. Zie dan ook hoofdstuk 2.3 voor verdere details. 12/52 2.2.4 Rapid Web Development Frameworks (RWD) Het ontstaan van de Ruby scripttaal in combinatie met het Rails ontwikkelplatform leidde tot een geheel nieuwe categorie van MVC engines. Ruby on Rails richt zich vooral op het zeer snel ontwikkelen van data-driven applicaties waarbij uitgegaan wordt van een aantal afwijkende principes. Een belangrijk uitgangspunt is dat slechts minimale configuratie nodig is en dat zoveel mogelijk automatisch wordt gegenereerd (bv. namen van componenten afgeleid van de onderliggende data entiteiten). RWD frameworks genereren grote delen van de applicatie uit de onderliggende database schema’s. Zo worden bedrijfsobjecten waarmee de data kan worden gemanipuleerd afgeleid van de data schema’s. View en Controller objecten worden vervolgens weer afgeleid van deze bedrijfsobjecten. RWD is met name interessant voor generieke, data-gestuurde, applicaties. De krachtige scripttalen en bijbehorende ontwikkelomgevingen leiden snel tot resultaat en vereisen geen diepgaande technische kennis. Kennis van de datamodellen en het oplossingsdomein is uiteraard wel van groot belang. RWD’s zijn relatief jong en de toepassing is redelijk specialistisch. Echter, veel van de huidige web applicaties kunnen op de een of andere manier toch vaak gekarakteriseerd worden als een “data gestuurde” applicatie waarbij informatie uit één of meerdere databases wordt gelezen, gemuteerd en/of aangevuld en vervolgens opgeslagen. Een aantal voorbeelden van populaire RWD’s: RWD: Voor taal: Ruby on Rails Django TurboGears CakePHP Symfonie Trails Java on Sails Groovy on Grails Castle MonoRails Ruby Python Python PHP PHP Java Java Groovy (Java) C# en Mono 13/52 2.3 Portalservers Zoals eerder al aannemelijk is gemaakt, is een portal eigenlijk een vorm van een “Enterprise Model-View-Controller” implementatie zoals hiernaast in de figuur nogmaals wordt getoond. De portalserver vervult hierbij de rol van “Controller” en bepaalt welke informatie wordt getoond afhankelijk van het “klikgedrag” van de gebruiker (menu items, tabbladen of elementen binnen een pagina). Het “Model” omvat het servicelandschap van de organisatie (content en applicatie services) en de pagina’s met de daarop geplaatste functionele componenten, de “portlets”, vormen samen de “View” op dit landschap. Het doel van een portal is om gebruikers toegang te geven tot informatie (in de ruimste zin des woord), op een veilige en Figuur 2: Portal als MVC gepersonaliseerde wijze en via mogelijk verschillende afleverkanalen. Portalen maken dit mogelijk door implementatie van een aantal technologieën: Portalen hebben de identiteit van de gebruiker nodig. Elk portal biedt daartoe authenticatievoorzieningen die deze identiteit vaststellen en vervolgens koppelen aan een verzameling van portal “rollen”. Bij deze rollen horen “rechten”. De identiteit kan worden bepaald op basis van een simpel gebruikersnaam/wachtwoord binnen de portal, maar ook worden gedelegeerd aan een aparte authenticatie service, al dan niet opgenomen binnen een federatieve omgeving. Het is vervolgens de taak van deze externe authenticatie service om bv. de “federatieve identiteit” (waarvan de gebruiker er mogelijk meerdere kan hebben) af te beelden op de “portal identiteit” (waarvan de gebruiker er maximaal één per ingelogde sessie mag hebben); De portal rollen en rechten zijn gekoppeld aan pagina’s maar ook aan elementen op die pagina. Elke pagina wordt specifiek opgebouwd volgens het stramien wat daartoe vooraf door de beheerder(s) is opgesteld. In principe kan elke gebruikersrol zijn gekoppeld aan compleet verschillende paginastructuren met verschillende content; Portalen maken gebruik van “templates” en “skins” (of “themes”) voor constructie van de pagina. De “template” bevat de structuur, de “skin” de stijl (kleuren, fonts). Beiden zijn rol afhankelijk. De beheerder kan nieuwe templates en skins maken zonder daarvoor programmeerkennis nodig te hebben; Portalen maken gebruik van losse componenten, de “portlets”, voor het tonen van content en voeren van gebruikersdialoog. De portal verzorgt zelf de navigatie (op basis van specifieke “navigatie portlets”). Door deze tweedeling hoeft de portlet ontwikkelaar zich niet druk te maken over de pagina waarop de portlet uiteindelijk wordt geplaatst (sterker nog: hij mag daarover geen aannames doen). Portalen kennen dus een strikte scheiding tussen “vorm” en “functie”; 14/52 Portalen maken het mogelijk dat een geauthenticeerde gebruiker zelf zijn eigen pagina’s samenstelt door te kiezen uit een vooraf, op basis van de gebruikersrollen, vastgestelde lijst met portlets. Daarnaast kan de gebruiker eventueel kiezen uit verschillende templates en skins om daarmee de pagina naar eigen wens te kunnen aankleden. Dit staat bekend als “customisation” of “voorkeurinstellingenbeheer”; De beheerder kiest voor een bepaald paginastramien en plaatst vooraf portlets op de pagina’s. Hij kan ervoor kiezen om de gebruiker deze indeling te laten wijzigen, of hij “bevriest” juist bepaalde structuren. Dit op basis van de gebruikersrollen vooraf vastleggen van structuur en content heet ook wel “statische personalisatie”; Geavanceerde portalen maken gebruik van het gebruikersprofiel (verzameling van attributen waarmee de gebruiker op unieke wijze wordt beschreven), in combinatie met content classificatiemodellen en bedrijfsregels om de content die de gebruiker te zien krijgt dynamisch (dus tijdens de sessie) te wijzigen. Dit heet “dynamische personalisatie” en wordt vaak gebruikt bij e-commerce sites om op basis van het koopgedrag van de gebruiker, in combinatie met het koopgedrag van aan hetzelfde kopersprofiel beantwoordende gebruikersgroepen, bepaalde producten extra onder de aandacht te brengen of juist niet [meer] te tonen; De daadwerkelijk aan de gebruiker aangeboden functionaliteit (content, applicaties) wordt geleverd door een mechanisme van “portlets”. Dit zijn “brokjes functionaliteit” die alleen of met groepen op een pagina zijn te plaatsen. De portlet code kan door middel van standaard applicatie-interfaces zoals gedefinieerd door de JSR-168 en JSR-286 standaarden, communiceren met de portalserver. De portalserver heeft totaal geen invloed op de wijze waarop de portlet aan zijn informatie komt en hoe dit wordt vertaald naar HTML. Er zijn in principe slechts twee “contracten” tussen de portalserver en de portlet: o Actie – de gebruiker heeft op een URL geklikt (bv. button of hyperlink) die is gekoppeld aan de portlet. Het is nu de taak van de portlet om zijn “state” bij te werken. Als voorbeeld valt te noemen het klikken op een “submit” knop op een door de gebruiker ingevuld formulier. De portlet ontvangt dit formulier via de portal interface en verwerkt de inhoud. Dit kan resulteren in een nieuw formulier (bv. “volgende pagina”) of bv. een fout op het bestaande formulier (velden niet goed ingevuld). Hoe het formulier wordt gevalideerd en welke [externe] informatiebronnen de portlet hiervoor gebruikt is “onzichtbaar” voor de portalserver; o Render – Per pagina roept de portalserver slechts maximaal één keer een “Actie” aan (er kan tenslotte maar op één link tegelijk worden geklikt). Als deze actie is afgerond wordt voor elke portlet op de pagina het Render contract uitgevoerd. De portlet wordt hiermee “uitgenodigd” om nieuwe HTML code te genereren. De portalserver verzamelt deze HTML code van elke portlet en bouwt daarmee de complete pagina op. Pas als ook de laatste portlet zijn HTML heeft teruggegeven gaat de pagina naar de gebruiker; In de volgende hoofdstukken wordt op de verschillende aspecten van de portalserver nader ingegaan waarbij wordt gewezen op standaarden indien aanwezig. 15/52 2.3.1 GUI ontwikkel functionaliteit Er is niet zoiets als een “standaard GUI functionaliteit” in de gemiddelde portalserver. Echter, de algemene tendens voor het gros van de portalservers is dat pagina templates worden gebouwd volgens de Java Server Pages (JSP’s) standaard. Elke portal heeft zijn eigen administratie interface waarmee de pagina’s “in elkaar worden geklikt”. De pagina fragmenten zijn in het algemeen zelf op te zetten in de vorm van JSP fragmenten. Dit maakt het bv. mogelijk om standaard Javascript op te laten nemen in de door de portal gegenereerde pagina’s. Of, en op welke wijze, een portal een bepaalde ontwikkelfunctionaliteit ondersteunt is zeer portal specifiek. Er zijn op dit gebied geen echte standaarden, anders dan Java, wat de de-facto standaard is voor vrijwel elke portalserver. De pagina bestaat vaak uit een “stramien” (of “template”) met daarbinnen verschillende “zones” (of “gebieden”). Binnen zo’n zone is het vervolgens mogelijk om portlets te plaatsen. Op die manier wordt de pagina interactief opgebouwd door te kiezen uit een palet van aanwezige portlets. Het resultaat is in veel gevallen een JSP pagina. Het mechanisme is altijd “des portalen” waarbij de moderne portalen een schat aan direct plaatsbare componenten bieden. Een goed voorbeeld is het Liferay open source portal (www.liferay.com). Liferay is een compleet ontwikkelraamwerk waarbij gekozen kan worden om in Java te werken (alle gangbare standaarden worden ondersteund) of om portlets te bouwen m.b.v. Ruby, PHP, Python of Groovy. De oudere generatie portalen ondersteunden uitsluitend “server-side” processing, met andere woorden: alle wijzigingen op de pagina werden vanaf de server gerealiseerd d.m.v. complete re-render van de pagina. Tegenwoordig zie je meer en meer ondersteuning van AJAX direct vanuit de portal (een verplichting voor portalen met JSR286 ondersteuning) waardoor een portlet alleen zichzelf kan verversen, zonder dat de rest van de pagina opnieuw hoeft te worden opgebouwd. Zie hoofdstuk 4.1.2 voor meer details inzake JSR-286. 2.3.2 Integratie Portalen bevatten “van zichzelf” in principe geen informatie en integreren dan ook niet met applicaties. De enige integratiekoppelingen zijn die met de security omgevingen waarbij elk portal minimaal LDAP ondersteunt voor opvragen van accountgegevens. Veel portalen hanteren hierbij een eigen LDAP schema (waarbij bestaande schema’s worden uitgebreid of er zelfs een apart schema naast de eventueel bestaande schema’s wordt opgebouwd). Daarnaast is in veel gevallen een relationele database noodzakelijk voor opslag van voorkeuren, templates, sessiegegevens, configuratiegegevens, etc. Integratie met achterliggende informatie is de taak van de portlets. Zeker als deze worden geschreven in Java is een zeer grote variëteit aan componenten, technieken en standaarden beschikbaar. Een algemeen aanvaard principe is om gebruik te maken van een separaat ModelView-Controller model op applicatieniveau voor de bouw van de portlets. Het “Model” is de informatie die door de portlet moet worden ontsloten (bv. de inhoud van een database). De “View” is de logica van de portlet waarmee deze informatie daadwerkelijk wordt getoond aan de gebruiker en de “Controller” kan één van de Figuur 3: MVC model voor portlets 16/52 populaire frameworks zijn zoals Velocity, Spring, Struts, of JSF. Het is aan te raden om de daadwerkelijke portlet implementatie niet “dikker” te maken dan strikt noodzakelijk. Er dient zeker geen bedrijfslogica in de portlet te worden opgenomen. Portlets zijn strikt bedoeld voor de implementatie van gebruikersinteractie en moeten dan ook tot dat doel beperkt blijven. Daadwerkelijke integratie met achterliggende applicaties, processen of informatie wordt dan ook veelal geïmplementeerd door de portlet te koppelen aan web services waarbinnen de bedrijfslogica wordt geïmplementeerd. Uiteraard is dit geen wetmatigheid en dient de implementatie te worden afgestemd op de specifieke situatie. De figuur toont een typische opbouw van een portal “applicatie”, bestaande uit één of meerdere portlets die op basis van een separate presentatielaag de informatie ontsluiten uit een achterliggend service landschap. Hiervoor wordt gebruikgemaakt van een presentatieframework waarmee in feite de gebruikersdialoog wordt bestuurd. De portlets met bijbehorende presentatieservices formen de “View”, het achterliggende service landschap het “Model” en het presentatie framework de “Controller”. 17/52 2.3.3 Gebruikersbeheer Portalservers hebben in het algemeen een eigen gebruikersadministratie. De gebruikersidentifier (naam of anderszins) wordt daarbij gekoppeld aan één of meer rollen en op basis van deze rollen bepaalt de portalserver welke pagina’s en welke componenten op die pagina aan die specifieke gebruiker mogen worden getoond. Rollen komen typisch overeen met groepen in een Directory. Elke portal heeft dan ook de optie om te kunnen koppelen met een LDAP gebruikers directory. Vrijwel alle portalservers bieden de mogelijkheid om de “ingebouwde” beveiliging op basis van een eigen database en een lokale “gebruikersnaam/wachtwoord” policy te vervangen door een Enterprise SSO oplossing. Hiertoe wordt vaak gebruikgemaakt van een “agent” dit binnen de web server wordt geïnstalleerd en die alle binnenkomende URL verzoeken onderschept3. De oranje componenten in nevenstaande figuur tonen de security componenten bij toepassing van Enterprise SSO: Indien de gebruiker een portal pagina opvraagt zal de URL hiervoor in de webserver worden onderschept door de lokale security agent, ook wel genoemd het “Policy Enforcement Point” of PEP. De PEP controleert of deze specifieke gebruiker al bekend is en of de toegangsrechten voor de pagina al eens zijn gecontroleerd. Bij een eerste bezoek zal de gebruiker eerst naar de login pagina worden doorgestuurd. Deze pagina staat in principe niet onder controle van de portalserver, maar Figuur 4: Portalen en authenticatie van de Authenticatie Server (onderdeel van het oranje blok “Authentication, Authorization & Accounting”, ook wel genoemd het “Policy Administration Point” of PAP). De wijze van authenticeren wordt bepaald door de opgevraagde resource (de URL) en kan variëren van eenvoudig met gebruikersnaam / wachtwoord tot geavanceerd met 2-weg certificaten en/of tokens, of door te controleren of de gebruiker binnen een federatieve omgeving al is ingelogd. Uiteindelijk nemen we aan dat de authenticatie succesvol is verlopen en worden de account gegevens gecontroleerd tegen een centrale administratieve voorziening zoals bv. een LDAP Directory. De identiteit van de gebruiker wordt vervolgens doorgegeven aan de portal die deze gebruikt voor het selecteren van de juiste pagina en het eventueel filteren van de portlets op die pagina. Hiertoe maakt de portal gebruik van rollen die aan de identiteit van de gebruiker zijn gekoppeld. Alle portal resources (pagina’s en portlets) zijn eveneens rolgebonden waardoor de portal per individuele gebruiker een eigen pagina kan construeren. 3 Een andere voorkomende optie is het toevoegen van een “security gateway” waarbij de aanvragen naar de web server al voordat ze bij de server komen worden onderschept. De functionele werking is verder gelijk. 18/52 De verantwoordelijkheid van de portalserver beperkt zich tot het selecteren van pagina’s en portlets. Uiteraard is het daarnaast ook van belang dat deze portlets alleen de informatie tonen die voor de betreffende gebruiker relevant is en die de gebruiker mag zien. Het beveiliging van content is de verantwoordelijkheid van de portlet, die dit eventueel kan delegeren naar het achterliggende servicelandschap. Hiertoe kan de portlet de identiteit van de gebruiker afleiden uit de portlet context (de gebruikerssessie die door portal en/of authenticatie voorziening zijn opgezet). Op basis van deze identiteit kan de portlet zijn eigen securitychecks [doen] uitvoeren. Als de portlets communiceren via een service architectuur met een ESB dan is het in veel gevallen mogelijk om de beveiliging “door te trekken” tot op de ESB waarbij de middleware dan automatisch zorgdraagt voor alle toegangscontroles “in naam van de gebruiker”. Om dit te laten werken is het dan wel noodzakelijk dat de gebruikersidentiteit éénduidig is vastgelegd over alle aangesloten systemen. Dit is uiteraard het eenvoudigst indien ook de applicatieomgeving gebruikmaakt van dezelfde PAP voorziening en gebruikersadministratie als de portalserver. Voor een portalserver is de gebruikersidentiteit belangrijk omdat de content daarop wordt afgestemd. In de simpelste vorm alleen de pagina’s en de daarop geplaatste portlets maar in meer complexe omgevingen kan ook gebruik worden gemaakt van andere gebruikersattributen zoals werkgever, universiteit, leeftijd, etc. Op basis van bedrijfsregels in combinatie met gebruikersgegevens is het dan mogelijk om dynamisch content te leveren. Dit noemen we “context-gestuurde personalisatie”. Hiertoe moet de personalisatiecomponent van de portalserver toegang krijgen tot alle relevante gebruikersgegevens. Omdat die niet altijd netjes in één directory zitten is het gebruik van een “gebruikersprofiel service” aan te raden. Deze services zijn trouwens (net zoals context-gestuurde personalisatie) niet standaard, ze zullen altijd op maat moeten worden ontwikkeld. Gebruikersprofiel services zijn goed te realiseren door gebruik te maken van Virtual Directory producten. Een Virtual Directory maakt het mogelijk om “naar de aanvrager toe” een éénduidig LDAP schema te gebruiken, waarbij de onderdelen van dat schema afkomstig kunnen zijn uit verschillende heterogene en mogelijk overlappende bronnen zoals relationele databases, web services of andere LDAP directories. Omdat een Virtual Directory zich gedraagt als een “normale” directory kan hij zondermeer worden ingezet waar ook deze “normale” directory past. 2.3.4 Portal content management Zoals al genoemd in hoofdstuk 2.3.2 beschikt een portal in principe zelf niet over “eigen” data. Alles wat aan de gebruiker wordt getoond is een “portlet” en de implementatie daarvan is buiten scope voor de portal server. Echter, met de opkomst van de JSR-168/286 standaarden en de wijdverbreide support hiervan binnen de portal servers, is er een groeiende verzameling standaard portlets te vinden waarmee snel een functioneel rijke portal is te bouwen. Steeds vaker zie je bv. dat CMS systemen standaard JSR-168 portlets beschikbaar stellen om direct content uit het CMS te tonen. Deze portlets zullen in het algemeen dus wel “CMS-spcifiek” zijn, maar zijn portal onafhankelijk. Daarnaast heeft elke portal server wel een eigen, proprietary, interface voor beheer en presentatie van content, veelal uit een geïntegreerd CMS maar vaak ook in combinatie met separate CMS platformen. De JCR standaard (Java Content Repository) beschrijft een standaard content repository interface voor Java. Het is dus een API (Application Programming Interface) beschrijving en zegt niets over de structuur van de content. Veel [open source] CMS systemen gebruiken deze standaard (bv. Magnolia, eXo JCR, Alfresco, Jeceira en Apache Jackrabbit). Jackrabbit geldt als de “reference implementatie” van JCR. De JCR interface is formeel vastgelegd in de Java JSR-170 standaard. De JCR interface beschouwt een 19/52 repository als een hiërarchische verzameling van abstracte “nodes” waarbij de standaard het mogelijk maakt om deze nodes aan te maken, te lezen, te wijzigen of te verwijderen. Zie de figuur voor het model. Elke node heeft één of meerdere properties die de eigenschappen van die node beschrijven. Doordat het functionele model wordt uitgedrukt in XML elementen is het redelijk eenvoudig om een portlet te bouwen die een JSR170 compliant repository uitvraagt en op basis van XSLT operaties de ontvangen content rendeert naar een presentatievorm naar keuze. Veel portalen ondersteunen JSR-170 tegenwoordig direct vanuit de beheerinterface. Er kunnen dan “on the fly” portlets worden gegenereerd op basis QuickTime™ and a van JSR-170 content queries. De JSR-170 decompressor are needed to see this picture. standaard dateert uit juni 2005 en is inmiddels volwassen. Er bestaan redelijk veel implementaties van. De opvolger, JSR-283, is Figuur 5: JSR-170 functioneel model inmiddels in de maak. Per maart 2009 bestaat hiervan een “proposed final draft”, d.w.z. het finale voorstel voor de standaard. Echter, gezien de recente datum en het feit dat het nog steeds een “draft” is, kan niet verwacht worden dat op korte termijn serieuze implementaties zullen ontstaan. De JSR-283 standaard biedt additionele functionaliteit zoals de ondersteuning van “workspaces” (meerdere groepen nodes met elk een eigen “root”), verbeterd beheer van workspaces, nodes en properties en een verbeterd model voor beheer van toegangsrechten. Alles bij elkaar biedt de JSR-283 standaard betere ondersteuning voor grootschalig Enterprise Content Management. Nog een interessante standaard is JSR-188. Deze standaard (uit eind 2003) is een formele beschrijving van hetgeen ook wel bekend staat als CC/PP (Composite Capability/Preference Profile). Het is een RDF4 (Resource Description Framework) gebaseerd framework voor het beschrijven van de mogelijkheden van user-devices (browsers, PDA’s, smartphones) v.w.b. de ondersteuning van rendering functionaliteit. Kort gezegd kan CC/PP worden gebruikt om aan het portal te vertellen hoe de pagina moet worden opgebouwd op een dusdanige wijze dat deze optimaal is afgestemd op de functionaliteit van het apparaat waarmee de pagina wordt bekeken. In dat licht gezien is dit dus een belangrijke standaard als het gaat om kanaalspecifieke “push” van content naar de gebruiker. JSR-188 gaat er vanuit dat leveranciers “device profiles” beschikbaar stellen (in RDF) waarin de mogelijkheden van het device zijn beschreven. Vervolgens dient op de server een JSR-188 compliant repository beschikbaar te zijn waarin deze profielen worden geadministreerd en ontsloten. Tot slot dienen programmeurs bij het bouwen van hun portlets gebruik te maken van de CC/PP API om op een device-onafhankelijke wijze hun portlets te bouwen. Datzelfde geldt uiteraard ook voor de portal zelf, die uiteindelijk de complete pagina zou moeten construeren op basis van het client device. 4 RDF is een “XML taal” voor het beschrijven van entiteiten en de verbanden tussen entiteiten. Het wordt veel gebruikt voor het beschrijven van content classificatiemodellen en thesauri en is één van de bouwstenen van het “semantisch web”. 20/52 Een afgeleide standaard is User Agent Profile (UAProf) van de Open Mobile Alliance (OMA). Dit is eveneens een CC/PP gebaseerde standaard voor het vastleggen van device profiles voor mobiele apparatuur. Helaas is de JSR-188 standaard niet echt “aangeslagen” in de markt en is de ondersteuning ervan binnen de portal wereld uiterst beperkt. 21/52 3 Anatomie van een portlet Ongeacht de exacte technologie die gebruikt wordt, kennen de verschillende portal technologieën een aantal functionele overeenkomstigheden. Dit hoofdstuk gaat in op deze functionaliteiten aan de hand van de JSR-168/ JSR-286 specificatie. Voor andere portal technologieën zal de terminologie wellicht wat afwijken, maar komt de functionaliteit op hoofdlijnen overeen. 3.1 Portal Pagina Een portal pagina heeft de volgende algemene layout: Figuur 6: Anatomie van een portal pagina Bovenstaande figuur toont een portal pagina met daarop een viertal portlets. Elke portlet wordt getoond binnen een “portlet window”, gegenereerd door de portlet container. De portlet zelf is uitsluitend verantwoordelijk voor het genereren van de “portlet fragment”, dus de content die in het window wordt getoond. De container voegt aan dit fragment eventueel een kader toe Portlet Objects alsmede “versieringen” Portlet Portal Page zoals een titel en Portlet Window 1 Portlet Window 2 verschillende knoppen. De GenericPortlet knoppen kunnen, in PortletPreferences PortletPreferences combinatie met paginacontrol links, worden gebruikt om portlet in- en MyPortlet OtherPortlet uit te klappen en om Portlet Window 3 additionele dialogen te activeren (de zogenaamde PortletPreferences “portlet view-modes”, zie Portlet Window 4 hoofdstuk 3.3). Al deze extra content is ook te onderdrukken, waarmee een portlet een uiterlijk kan krijgen dat uitsluitend wordt bepaald Figuur 7: Portlet windows 22/52 door de door de portlet gegenereerde markup. Een portlet kan meerdere malen voorkomen op dezelfde pagina, waarbij sprake is van een gedeelde portlet instantie maar met unieke Portlet Windows. Een portlet window bevat contextuele informatie die door de portlet container aan de portlet instantie beschikbaar wordt gesteld en die de portlet onder andere dient te gebruiken om voorkeurinstellingen van de gebruiker voor dat specifieke window in op te slaan. Deze contextuele informatie is beschikbaar in de vorm van een “PortletPreferences” object. Op het moment dat de portlet op een pagina wordt geplaatst wordt hieraan door de container automatisch een preferences object toegevoegd, waarbij de default waarden worden opgehaald uit de Portlet Deployment Descriptor. De figuur hierboven toont een tweetal portlet instanties (“objecten”) die beide zijn geassocieerd met twee aparte portlet windows. Portlet “OtherPortlet” bezit twee windows met elk een eigen preferences object terwijl portlet “MyPortlet” twee windows bezit met een gedeeld preferences object. Het beheer van “PortletPreferences” objecten is de verantwoordelijkheid van de container. Voor de portlet instanties zijn deze associaties onzichtbaar. Als een portlet meerdere malen binnen dezelfde pagina wordt gebruikt zal hij door de container ook meerdere malen worden geactiveerd, één maal voor elk portlet window waarmee de portlet is geassocieerd. De portlet instantie kan bij het uitvoeren van een render- of action request (zie hoofdstuk 3.4) het preference object van het huidige window opvragen. Het meerdere malen plaatsen van een portlet op een pagina is in het algemeen alleen dan zinvol als elk portlet window apart geconfigureerd kan worden middels de preferences objecten (gebruikersvoorkeuren). Een voorbeeld hiervan is een nieuws portlet, waarbij de gebruiker via de voorkeurinstellingen per portlet window andere nieuwsbronnen kan selecteren. Om de gebruiker in staat te stellen ook daadwerkelijk zijn voorkeuren aan te geven dient de portlet de “EDIT” view-mode te ondersteunen (zie hoofdstuk 3.3). Het voorbeeld is in ieder geval illustratief voor het tonen van de relatie tussen de verschillende onderdelen (Portlet Object, PortletPreferences Object, Portlet Window en Portal Pagina). Het verdient sterke aanbeveling om portlets altijd af te leiden van de generieke “GenericPortlet” klasse, welke op zijn beurt de portlet interface “Portlet” implementeert. Beide zijn onderdeel van de JSR-168 standaard en beschikbaar in elke compatible portlet container. 3.2 Portlet Window States Een portlet window kan een aantal verschillende “representatievormen” aannemen, genoemd de “window states” van de portlet. De JSR-168 standaard schrijft de volgende drie states voor: 1. NORMAL – het window neemt een hoeveelheid ruimte in beslag die is vastgesteld tijdens opbouw van de pagina. In deze toestand zal de portlet waarschijnlijk de pagina delen met andere portlets. 2. MAXIMIZED – het window is “uitgeklapt” (vergelijk de “maximize” button onder Windows) en neemt maximale ruimte in binnen het gebied op de pagina waarbinnen de portlet is geplaatst. Dit is een hint aan de portlet dat er meer ruimte dan gebruikelijk beschikbaar is voor het renderen van content. 3. MINIMIZED – het window is “ingeklapt” (vergelijk de “minimize” button onder Windows) en neemt minimale ruimte in binnen het gebied op de pagina waarbinnen de portlet is geplaatst. Dit is een hint aan de portlet dat geen, of slechts minimale, output mag worden geproduceerd tijdens een “render” request. 23/52 Naast deze drie voorgedefinieerde window states kan een portlet nog een willekeurig aantal additionele window states ondersteunen. Deze dienen in de Deployment Descriptor van de portlet te worden gespecificeerd. Deze window states moeten dan wel ondersteund worden door de portlet container! Het is dus niet zo dat een portlet states kan “verzinnen” die de container niet kent. Normaalgesproken wordt een portal pagina opgebouwd uit een aantal losse gebieden (“areas”) waarbinnen portlets kunnen worden geplaatst zoals nevenstaande figuur toont. Een portlet mag nooit meer plaats innemen dan “zijn” gebied toelaat. Informatie betreffende de window state kan de portlet ophalen uit de ontvangen PortletRequest objecten (zie hoofdstuk 3.4). Een portlet kan zijn window state wijzigen bij het uitvoeren van een “processAction”. De Figuur 8: Pagina opbouw aangeboden window state moet dan wel geldig zijn voor zowel de portlet en de portlet container. 3.3 Portlet View-Modes Een portlet opereert altijd in één uit “n” zogenaamde “view-modes”. Deze mode bepaalt wat voor soort informatie de portlet aan de gebruiker toont en wat voor dialoog de portlet met de gebruiker voert. Wisseling tussen view-modes wordt gestuurd door de portlet container op basis van “processAction” requests (zie hoofdstuk 3.4). De standaard schrijft minimaal de volgende drie modes voor: 1. VIEW – genereer markup content conform de momentele “state” van de portlet. Dit is de normale operationele mode van elke portlet en de portlet is dan ook verplicht om deze mode te ondersteunen. 2. EDIT – de portlet dient een gebruikersdialoog te executeren waarmee de gebruiker in staat wordt gesteld om het gedrag en de instellingen van de portlet aan te passen aan de wensen en eisen van de gebruiker. Met andere woorden: deze mode implementeert “application customization”. De mode wordt normaalgesproken geactiveerd middels een icoon in de titelbalk van de portlet, of pagina-breed middels activeren dan “pagina-edit” mode. Dit is portlet container afhankelijk. De portlet is niet verplicht om de edit mode te implementeren. 3. HELP- de portlet biedt statische- of context gevoelige help informatie aan. De implementatie is portlet specifiek en de help mode wordt normaalgesproken geactiveerd middels een icoon in de titelbalk van de portlet. De portlet is niet verplicht om de help mode te implementeren. Naast deze drie voorgedefinieerde modes kan een portlet nog een willekeurig aantal additionele modes ondersteunen. Deze dienen in de deployment descriptor van de portlet te worden gespecificeerd. Deze modes moeten dan wel ondersteund worden door de portlet container! Het is dus niet zo dat een portlet modes kan “verzinnen” die de container niet kent. 24/52 3.4 Portlet Lifecycle De lifecycle van een portlet komt tot uiting in een viertal methoden op het Portlet interface. De portlet container zal normaalgesproken precies één portlet instantie creëren per portlet definitie (XML deployment descriptor) en per Java Virtual Machine (JVM). Deze ene instantie zal dus gedeeld worden tussen alle pagina’s en gebruikers, althans voor zover de gebruikersessies door dezelfde JVM worden afgehandeld. De portlet container is vrij om het moment van laden en instantiëren te kiezen. Aangezien het aanroepen van de portlet constructor niet inhoudt dat de portlet al actief is binnen de container, mag de portlet in zijn constructor geen gebruik maken van container resources! Pas na het aanroepen van de “init” methode is de portlet volledig gereed voor afhandelen van requests. 1. init; wordt aangeroepen door de portlet container nadat een nieuwe instantie van de portlet is geïnstantieerd en voordat de instantie requests gaat behandelen. Dit gebeurt in principe éénmalig en dient door de portlet te worden gebruikt voor eenmalige initialisatie. De portlet kan geen gebruik maken van portal resources voordat de “init” methode is uitgevoerd (en kan dat dus wel tijdens uitvoer van “init”). not initialised "init" "processAction" "render" active "destroy" destroyed Figuur 9: Portlet Lifecycle 2. processAction; wordt aangeroepen door de portlet container als gevolg van ontvangst van een action URL met als target de betreffende portlet (zie verder). 3. render; wordt aangeroepen door de portlet container tijdens constructie van een pagina. 4. Destroy; wordt aangeroepen door de portlet container als de portlet instantie niet langer nodig is. De normale lifecycle van een portlet bestaat uit het éénmalig aanroepen van init, (overgang van “not-initialised” naar “active” state), gevolgd door een aantal malen processAction en/of render (voor elke keer dat de pagina waarop de portlet voorkomt wordt opgebouwd, dit is de “active” state). Tot slot wordt destroy aangeroepen voordat de portlet wordt verwijderd (overgang naar “destroyed” state). De portlet kan geen portal resources meer gebruiken nadat de “destroy” methode is aangeroepen en de portlet code kan worden opgeruimd door de garbage collector. Een pagina wordt normaalgesproken opgebouwd als gevolg van ontvangst van een URL door de portlet container. Deze URL kan de vorm hebben van een action URL. In dat geval bevat de URL de identifier voor de portlet die als target dient voor de action. De container dient dan als eerste voor die betreffende portlet de processAction methode aan te roepen en vervolgens te wachten totdat deze methode gereed is. Vervolgens dient de container de render methode aan te roepen voor elke portlet op de pagina. Dit mag sequentieel of parallel (in afzonderlijke threads). Aanname is dat de portal engine dit multi-threaded zal doen. De URL kan de vorm hebben van een render URL. In dat geval is geen portlet specifiek geadresseerd en mag de container voor geen enkele portlet op de pagina de processAction aanroepen. In plaats daarvan worden alleen de render methoden aangeroepen, mogelijk parallel. 25/52 Onderstaande figuur toont de relatie tussen de “processAction” en de “render” methoden: Figuur 10: Pagina opbouw sequence In dit geval wordt de processAction uitgevoerd door Portlet A omdat dat kennelijk de portlet was die als target in de PortletURL was aangegeven. Welke portlet uiteindelijk de processAction methode gaat uitvoeren wordt volledig bepaald door URL parameters en is dus afhankelijk van de URL waarop de gebruiker heeft geklikt. De methode wordt altijd als eerste uitgevoerd voordat de render methode wordt aangeroepen! Merk op dat de processAction method altijd uitgevoerd wordt door de portlet waaruit “geklikt” is. Van deze eigenschap kan gebruik gemaakt worden, maar het is aan te raden om de processAction methode in alle portlets éénduidig te implementeren middels een gedeelde state machine (zie verder). Als een willekeurige portal pagina wordt benaderd doordat de gebruiker “elders” in de portal op een paginalink klikt (een link met algemeen format http://www.myportal.com/portal/myportal/mypage), dan zal de portal deze pagina genereren middels “render” requests naar alle op de pagina aanwezige portlets. Als dit de eerste keer is dat de betreffende portlets worden geactiveerd dan zal de container van elke portlet eerst de “init” methode aanroepen (dit gebeurt dan dus alleen voor de eerste gebruiker die de pagina voor de eerste keer opent, “init” wordt immers slechts één maal in de lifecycle van een portlet aangeroepen). Het is theoretisch ook mogelijk om een pagina te laden middels een “processAction” request, maar het nadeel hiervan is dat deze URL dan één specifieke portlet op één specifieke pagina dient te adresseren (action requests zijn altijd gericht op een portlet). Dit maakt de paginalink gevoelig voor fouten en slecht onderhoudbaar. 26/52 3.5 Portlet Application Portlets die samen voorzien in de implementatie van de gebruikersinterface van één applicatie dienen te worden gecombineerd binnen een Portlet Application. Een Portlet Application is een speciale vorm van een Web Application. Portlet Applications worden beschreven door een [Portlet Application] Deployment Descriptor en bevatten een enkele PortletContext (per Java VM) die door de deelnemende portlets kan worden gebruikt om de applicatie context op te halen en/of te wijzigen. 3.5.1 Portlet Context Elke Portlet Application bezit een PortletContext. Dit is in feite een extensie van de ServletContext, aangezien portlets onderdeel zijn van een web applicatie. Indien de portlet container is gedistribueerd over meerdere JVM’s bezit elke portlet applicatie een PortletContext instance per JVM. PortletContext en ServletContext hebben toegang tot dezelfde resources. De portlet kan zijn PortletContext Figuur 11: Portlet applicatie gebruiken om attributen en settings te delen met andere portlets binnen dezelfde Portlet Application. De PortletContext dient met name te worden gebruikt voor het registreren van attributen/instellingen op applicatie niveau, niet op sessie niveau, hiervoor dient PortletSession (zie hierna). Elke implementatie van zekere omvang zal gebruik maken van meerdere JVM’s. Daarom is de PortletContext dus niet geschikt om dynamische informatie te delen tussen alle portlet instanties van één Portlet Application. Een goede implementatie zal dus gebruik maken van een RDBMS voor opslag van dynamische informatie en zal PortletContext alleen gebruiken voor statische informatie of informatie die alleen relevant is voor objecten binnen dezelfde JVM. De figuur hiernaast toont nogmaals de relatie tussen de componenten. Omdat een Portlet Application dus een variant is van een Web Application, heeft hij ook een Web Application Deployment Descriptor en deze dient dan ook gebruikt te worden voor vastleggen van algemene configuratie informatie voor de applicatie als geheel. 3.5.2 Sessies De portlet container is verantwoordelijk voor het bijhouden van gebruikerssessies. Deze hebben de vorm van een PortletSession object. Binnen deze PortletSession kan een portlet attributen opslaan met als scope de portlet zelf of de applicatie. In het eerste geval zijn opgeslagen attributen alleen beschikbaar voor de betreffende portlet, in het tweede geval zijn ze beschikbaar voor alle portlets binnen dezelfde Portlet Application. Attributen worden opgeslagen met een zelfgekozen naam en kunnen willekeurige objecten zijn. De portal container is verantwoordelijk voor het correct bijhouden van de sessie context. Met name het activeren van de juiste PortletSession voor opvolgende http requests en het “tracken” van sessies is een verantwoordelijkheid van de container. Hier hoeven Portlets dus zelf geen rekening mee te houden. Uitgangspunt is dat alle requests die het gevolg zijn van een specifieke gebruikersactie binnen een bepaalde Portlet, gegarandeerd binnen dezelfde sessie zullen worden afgehandeld. 27/52 Elke Portlet Application heeft één aparte PortletSession per gebruikerssessie. Dus een gebruiker die meerdere malen op het portal is aangelogd zal meerdere PortletSession objecten bezitten. 3.5.3 State control; Portlet URL’s Portlets mogen nooit direct HTML URL’s genereren, aangezien de container zijn eigen URL format kan en mag hanteren. In plaats daarvan dienen portlets gebruik te maken van door de API aangeboden methoden om PortletURL objecten van het juiste type te maken. De URL objecten ondersteunen een aantal methoden om op de juiste wijze key/value tuples aan de URL toe te voegen. URL’s kunnen daarnaast uitsluitend worden gemanipuleerd vanuit de render methode. Dit is conform het model dat de processAction uitsluitend dient om portlet state bij te werken en dat markup alleen wordt gegenereerd vanuit de render methodes. Een processAction wordt normaalgesproken altijd gevolgd door een render op dezelfde portlet (zie ook het sequence diagram in hoofdstuk 3.4). Om de state van een portlet (of groep portlets) te sturen dient de portlet dan ook “Action URL’s” te genereren en deze te koppelen aan knoppen en/of andere navigatiemiddelen die invloed op de state hebben. Als de gebruiker op zo’n URL klikt zal bij het opnieuw opbouwen van de pagina dus altijd eerst processAction worden uitgevoerd op de bij de URL behorende portlet. Deze methode dient op basis van de ontvangen informatie een state-update uit te voeren. Als de methode gereed is zal de portlet container alle render methoden aanroepen om op basis van de nieuwe state de pagina op te bouwen met eventueel nieuwe content. Het is een beperking van de huidige JSR-168 standaard dat een portlet alleen URL’s kan bouwen die reflecteren aan de “eigen” portlet. Het is dus niet mogelijk om te verwijzen naar andere pagina’s binnen de portal. Dit heeft alles te maken met het feit dat een portlet een “op zichzelf” staande entiteit is die geen weet heeft van zijn (portal) context. Alleen op deze wijze is te garanderen dat de portlet werkt in willekeurige portalen en op willekeurige pagina’s! Dit gaat met name een rol spelen bij gebruik van WSRP, waar de portlet op “virtuele” wijze in meerdere portalen kan leven. Verwijzen naar andere pagina’s zal in zo’n geval vreemde zijeffecten op kunnen leveren. Deze beperking is wel iets om bij ontwerp van het portal interactiemodel rekening te houden. 3.5.4 Events De JSR-286 standaard beschrijft een uitgebreid mechanisme waarmee portlets zich kunnen “abonneren” op events, events kunnen ontvangen of events kunnen versturen. Het event framework moet niet worden verward met bv. JMS. Het beperkt zich tot de portal omgeving en er is geen sprake van “guaranteeed delivery” (met andere woorden: events kunnen theoretisch “kwijt raken”). Portlets kunnen zich “abonneren” op specifieke events (XML structuren). Als het juiste event optreedt zal de container vervolgens op de portlet de processEvent methode aanroepen met de eventinformatie als parameter. Events zullen altijd optreden vóór de render fase en de portlet mag tijdens het afhandelen van events (of tijdens de processAction) zelf nieuwe events genereren door de setEvent methode van de portlet container aan te roepen. Deze aanroepen resulteren dan eventueel weer in nieuwe processEvent aanroepen op andere portlets etc. De container zal pas beginnen met de render fase als alle events die tijdens de processAction fase zijn ontstaan zijn afgehandeld. Het JSR-286 event raamwerk biedt uitgebreide mogelijkheden om dynamische interactie tussen portlets en de portlet container te implementeren. De event inhoud kan in principe alles zijn, van simpele naam/waarde paren tot complete Java objecten. 28/52 3.5.5 Publieke renderparameters Ook nieuw in JSR-286 is het gebruik van publieke renderparameters, welke primair bedoeld zijn voor het delen van view-state informatie tussen portlets. Het voordeel van publieke parameters boven events is het vermijden van de overhead van de event functies. Een publieke parameter “zit” op de pagina en kan door elke portlet simpelweg worden uitgelezen. Een mooi voorbeeld is het definiëren van “Postcode” als een publieke parameter. Als de pagina meerdere portlets heeft die allemaal gebruikmaken van postcode (zoals bv. een weer portlet, een landkaart portlet, een restaurant portlet, etc.) zullen alle portlets hun content automatisch aanpassen aan de opgegeven postcode zodra één van deze portlets de postcode aanpast. De portlets hoeven verder geen informatie van- of over elkaar te weten of te delen, anders dan een gemeenschappelijke definitie van de “Postcode” variabele. De portalserver kan publieke parameters coderen binnen de URL van de pagina, waardoor ze automatisch worden meegenomen in bv. bookmark lijsten. Dit is echter implementatie afhankelijk. 29/52 3.5.6 Resource Een JSR-286 portlet kan een nieuwe methode, serveResource, implementeren. Deze methode is qua scope zeer beperkt en laat het bv. niet toe om events te genereren of publieke parameters te wijzigen. Daarnaast is het niet mogelijk om de window state of de view mode aan te passen. Het belangrijkste doel van serveResource is het samenwerken met een browser-side stukje [AJAX] scripting om daarmee dynamisch onderdelen van een HTML pagina aan te passen zonder dat een complete pagina refresh noodzakelijk is. Onderstaande figuur toont hoe dit werkt in relatie met de browser en de portal container: Figuur 12: JSR-286 sequenties De browser stuurt in dit geval een XMLHttpRequest (XHR) naar de portal, bv. vanuit Javascript op de pagina. De portal vertaalt deze request naar een serveResource aanroep op een specifieke portlet. De portlet genereert een HTML fragment en stuurt dit terug naar de container die het op zijn beurt ongewijzigd naar de browser stuurt. Het fragment kan HTML zijn, maar ook XML of een willekeurige andere opmaaktaal. De portal doet in principe niets met het fragment, anders dan het ongewijzigd naar de browser doorsturen. Een voor de hand liggende toepassing is een “adresgenerator” portlet waarbij in de request een postcode wordt gestuurd. De response bevat het complete adres. Op deze wijze ziet een gebruiker na het intypen van zijn/haar postcode automatisch het complete adres worden ingevuld. 30/52 3.5.7 Filters Een portlet filter is een stukje Java code waarmee de inhoud en structuur van request en response objecten naar- en van portlets kan worden “onderschept” en eventueel getransformeerd. Filters kunnen bv. worden gebruikt om additionele informatie in een portlet request te stoppen voordat de portlet wordt aangeroepen, of om informatie in het response object te wijzigen voordat dit door de container verder wordt verwerkt. Filters maken het dus mogelijk om in te grijpen op de manier waarop de container informatie met portlets uitwisselt. Het is mogelijk om meerdere filters te declareren en filters kunnen zelf bepalen of ze al dan niet verwerking overdragen aan het volgende filter in de keten. Een simpele toepassing van een filter is bv. een stukje code waarmee de inhoud van elke request en response wordt gelogd. 31/52 4 Portal Standaarden 4.1 Java Portlet Specification 4.1.1 JSR 168 Vrijwel alle portal implementaties ondersteunen tegenwoordig de Java Portlet Specification, version 1.0. Dit is een implementatie van JSR-168 en beschrijft de interactie tussen de Java code van de portlet en de “portlet container” (m.a.w. de portalserver). Portlets geschreven volgens deze standaard zijn in principe zonder wijziging te deployen in elke container die de standaard ondersteunt. Zoals de naam al impliceert is JSR-168/286 een pure Java standaard. Dit heeft alles te maken met het feit dat de meeste portalservers geschreven zijn in Java of alleen Java portlets ondersteunen. Uitzondering is Microsoft die feitelijk “alle talen zolang het maar geen Java is” ondersteunt in hun Sharepoint server. Microsoft confirmeert zich dan ook niet aan de JSR standaarden. 4.1.2 JSR 286 Sinds juni 2008 is de opvolger van JSR-168 formeel vrijgegeven als standaard. Deze JSR286 standaard biedt een aantal extra’s vergeleken met JSR-168, te weten: Events – een portlet kan events ontvangen van de portlet container en kan events sturen naar de container. Op basis hiervan kunnen portlets informatie uitwisselen met elkaar en/of reageren op veranderingen in de omgeving (bv. het feit dat de gebruiker op een bepaalde link heeft geklikt); Publieke renderparameters – een portlet kan parameters “publiek” verklaren waarmee ze beschikbaar komen voor andere portlets op de pagina. Via deze parameters kunnen portlets dus direct state informatie uitwisselen; Resource – portlets kunnen optreden als “resources” op een pagina en maken het mogelijk om alleen een gedeelte van een pagina aan te passen bv. via AJAX calls; Filters – portlets kunnen dynamisch de request en response dataobjecten manipuleren en transformeren; 4.1.3 Samenvatting De JSR-168 standaard is inmiddels volwassen geworden en is beschikbaar in de meeste, zo niet alle, Java portalservers. De ervaring heeft geleerd dat in het algemeen JSR-168 portlets prima kunnen worden geporteerd tussen verschillende container implementaties. Nadelen zijn er ook: de JSR-168 standaard is uitsluitend gericht op Java en is verder redelijk “kaal”, met name als het gaat om de interactie tussen de portlet en zijn pagina (inclusief andere portlets). Zolang voor een applicatie slechts één of twee onafhankelijke portlets nodig zijn is dit geen groot probleem. Echter, in veel gevallen is er sprake van niet-triviale dialoogfunctionaliteit en dan is vaak behoefte aan een meer geavanceerd protocol. Nu is inter-portlet communicatie in de praktijk voor een enkele applicatie goed op te lossen door gebruik te maken van een set gedeelde presentatie services (een extra service laag, dus). Echter, ook dit is niet altijd toereikend. De JSR-286 standaard is bedoeld als uitbreiding op JSR-168 om juist deze problematiek op te lossen. Helaas ondersteunen veel moderne containers wel JSR-168 maar nog geen JSR-286! Met een beetje extra aandacht kan ook met JSR-168 echter prima worden gewerkt, zelfs als inter-portlet communicatie op een pagina noodzakelijk is. JSR-286 32/52 vinden we momenteel in de “voorop lopende” open-source portalen zoals LifeRay Sun WebSpace (gebaseerd op LifeRay) en eXo. In het geval dat een portalserver de JSR-168/286 standaard ondersteunt verdient het gebruik ervan absoluut de voorkeur boven gebruik maken van de “portal specifieke” API’s. Alhoewel de verleiding vaak groot is om toch maar de container specifieke functionaliteit te gebruiken is dit in de meeste gevallen niet nodig. Toepassen van JSR168/286 garandeert het eenvoudig kunnen migreren van één portal implementatie naar een andere. Vanuit de markt is er altijd al redelijk veel kritiek geweest over de beperkte scope van de portlet API’s en het feit dat het zo lang duurt voordat nieuwe versies van de API beschikbaar komen (versie 1.0 dateert uit 2003, versie 2 is pas in 2008 gekomen). Een veel gehoord punt van kritiek is het ontbreken van toegang tot portal “data”. Echter, in mijn opinie is deze kritiek niet geheel juist: de portlet API specificeert de interactie tussen de portlet en zijn container. De container biedt een run-time omgeving waarmee door portlets gegenereerde markup fragmenten aan elkaar worden “geweven” tot complete pagina’s. Hoe de portlet aan zijn markup fragment komt is niet relevant. Portalen hebben in principe GEEN EIGEN DATA! Alle informatie die door de portal naar de gebruikers wordt ontsloten wordt beschikbaar gesteld door de portlets en niet door de portalserver zelf. Dit houdt uiteraard in dat er wat meer effort door de programmeur moet worden besteed aan het ontsluiten van door de portlet beschikbaar te stellen informatie. Deze informatie valt uiteen in twee delen: 1) sessie-gerelateerde user-interactie informatie (m.a.w. de “portal sessie” inclusief de identiteit van de ingelogde gebruiker). Deze informatie wordt door de container aangeboden; 2) business-gerelateerde informatie, m.a.w. de “toegevoegde waarde” van de portlet zoals bv. e-mail, nieuws, weer, messaging, collaboratie, file access, etc. Etc. Categorie (2) moet door de portlet zelfstandig worden opgelost. De container helpt hierin een beetje met het beschikbaar stellen van context en state. Hoe de portlet het “business deel” oplost is zijn eigen verantwoording. Meer en meer wordt hier gebruik gemaakt van additionele Web Application Frameworks zoals Java Server Faces (JSF), Struts of Spring. Veel portalservers bieden tegenwoordig dan ook naadloze integratie met deze frameworks. De aanbevolen structuur wordt dan als volgt: Hierbij zijn de feitelijke portlets “zo dun mogelijk” en zorgen deze alleen voor state update en rendering van presentatie fragmenten. De feitelijke “business presentatie” logica zit in separate presentatie services die op hun beurt weer gebruik kunnen maken van bedrijfsservices. Figuur 13: Constructie presentatieservices 33/52 Er zijn tegenwoordig nog maar erg weinig Java portalservers die geen ondersteuning bieden voor JSR-168. De meest voor de hand liggende uitzondering is Microsoft Sharepoint, doch dit is geen Java portal. Sharepoint is een .Net implementatie en ondersteunt alle Microsoft programmeertalen. Het aantal “niet-Java” portalservers is verder zeer gering. We komen dan al snel terecht bij specifieke Web Applicatie Frameworks op basis van PHP, Perl, Ruby of andere scripting talen. Deze omgevingen zijn zonder uitzondering specifiek en hebben hun eigen (niet-standaard) programmeeromgevingen. 4.2 Web Services for Remote Portlets (WSRP) Het Web Services for Remote Portlets Consumer Portal (WSRP) protocol is ontwikkeld voor het technologie-neutraal koppelen van presentatie componenten. In het algemeen Pagina Structuur wordt het protocol geïmplementeerd binnen een Enterprise Portal omgeving Local Portlets Remote Portlets waardoor de betreffende portal hetzij (JSR-168) (WSRP ‘stubs’) “eigen” portlets beschikbaar kan stellen WSRP Consumer aan remote portalen (“WSRP Producer”), hetzij gepubliceerde portlets van remote Producer Portal portalen kan weergeven in de lokale paginastructuur (“WSRP Consumer”). WSRP werkt nauw samen met JSR-168. Pagina Structuur (en inmiddels is er een WSRP 2.0 standaard die dan weer gebaseerd is op Private Portlets Public Portlets JSR-286). Alhoewel beide standaarden (JSR-168) (JSR-168) onafhankelijk van elkaar zijn ontwikkeld, zijn er duidelijke overeenkomsten in gebruik. Hierdoor is het eenvoudig om Figuur 14: WSRP Structuur portlets die zijn ontwikkeld conform JSR168 te publiceren middels WSRP. De portlet ontwikkelaar hoeft hier in principe geen rekening mee te houden, de extra functionaliteit wordt volledig geboden door de WSRP interfaces van de betreffende Portlet Container. In de meeste gevallen is het voldoende om in de Deployment Descriptor van de betreffende portlet aan te geven dat de portlet gepubliceerd mag worden middels WSRP. Doordat WSRP is gebaseerd op Web Services en XML, is het protocol neutraal v.w.b. de achterliggende technologie aan beide kanten. Zo biedt Microsoft Sharepoint 2007 standaard functionaliteit voor het “consumeren” van via WSRP aangeboden portlets ondanks dat de portal technlogie compleet verschillend is van de meeste andere, Java gebaseerde, portalservers. Echter het “produceren” van WSRP portlets wordt niet door Microsoft ondersteund. Figuur 14 toont beknopt de relatie tussen producer en consumer. De figuur toont een “producer” portal waarbinnen een aantal portlets tot “publiek” zijn bestempeld (aangegeven in de Deployment Descriptor van de betreffende portlets). Deze portlets zijn vervolgens toegankelijk via het “WSRP Producer” interface van de portal. Een “consumer” portal kan via de “WSRP Consumer” logica de specificaties van de remote portlets opvragen en deze portlets beschikbaar stellen aan de gebruiker als ware het lokale portlets. Merk op dat een portal zowel producer als consumer kan zijn en ook tegelijkertijd. Het gaat dan uiteraard om verschillende portlets (een consumer kan geen portlets die hij 34/52 middels WSRP heeft gegenereerd zelf beschikbaar stellen als producer, immers, deze portlets bestaan niet fysiek binnen de betreffende portal). 4.2.1.1 Overzicht van het Producer interface De WSRP “producer” is de entiteit die een presentatiecomponent beschikbaar stelt aan “derden”. De Producer dient daartoe een aantal Web Service interfaces te leveren, waarvan de volgende twee verplicht zijn: Service Description Interface Door uitvragen van dit interface kan de vragende partij (de “consumer”) achterhalen welke portlets door de betreffende producer worden aangeboden. Dit interface biedt de volgende informatie: 1. De producer “meta-data”. Hiermee worden specifieke producer kenmerken overgebracht aan de consumer. Onderdeel hiervan is bv. of de consumer zich dient te registreren of niet, hoe cookies moeten worden beheerd, of de consumer “URL-rewriting” dient uit te voeren, locale support, etc. 2. De lijst met beschikbare portlets met per portlet de titel, portlet description, ondersteunde window states, view modes, mime-types, etc. Markup Interface Dit interface dient door de consumer te worden gebruikt voor het ophalen van de daadwerkelijk gegenereerde content. Het interface biedt een tweetal methoden die elk een JSR-168 “tegenpool” bezitten met gelijksoortige functionaliteit: Methode “performBlockingInteraction” is de WSRP versie van de JSR-168 “processAction” methode. De consumer roept de methode aan voor het bijwerken van de “state” van de producer portlet, waarbij andere portlets binnen dezelfde pagina niet mogen worden geactiveerd. Methode “getMarkup” is de WSRP versie van de JSR-168 “render” methode. De consumer roept de methode aan voor het daarwerkelijk ophalen van de door de remote portlet gegenereerde markup; dit is in de meeste gevallen een HTML fragment. Vervolgens bestaan er nog twee optionele interfaces: Registration Interface Via dit interface kan een consumer zich direct (in-band) registreren bij een producer en kunnen specifieke kenmerken van de consumer worden doorgegeven aan de producer. De producer kan hiermee rekening houden bij het genereren van content. Er ontstaat in dit geval een “statefull” verbinding tussen consumer en producer. De WSRP standaard gaat niet in detail in op de exacte wijze waarop registratie plaats dient te vinden. Er zijn diverse mogelijkheden, variërend van een simpele aanroep van het Registration Interface (zonder aanvullende kenmerken) tot een complete outof-band registratie procedure met contracten en certificaten. In dit laatste geval zullen specifieke kenmerken moeten worden overgedragen tijdens aanroep van de “register” methode op het Registration Interface. Registratie is vooral bedoeld om een ‘context’ te creëren waarbinnen producer en consumer informatie uitwisselen. Het zou bv. kunnen zijn dat een producer verschillende portlet sets beschikbaar stelt aan verschillende consumers, of dat een consumer specifieke eisen stelt aan de door de producer gegenereerde content. Ook kan een producer bepaalde functionaliteit onthouden aan bepaalde consumers (die mogen bv. een portlet niet verkleinen of vergroten). 35/52 Portlet Management Interface Via dit interface kan de consumer de remote portlets beheren alsof ze onderdeel zijn van het consumer portal. Het gaat hierbij om op afstand aanpassen van portlet properties, het clonen van portlets en het verwijderen van portlets. 4.2.1.2 Markup generatie Het “markup” interface vormt de bron voor de daadwerkelijke portlet content. De consumer zal dit interface gebruiken bij het opbouwen van een lokale pagina waarop “remote” portlets voorkomen. Het interface wordt gebruikt om “user-state” door te geven van consumer naar producer en om “markup” door te geven van producer naar consumer. De volgende methoden zijn beschikbaar op dit interface: a) De “getMarkup” methode wordt gebruikt voor het ophalen van de daadwerlijke portlet markup. Het is in feite de WSRP tegenhanger van de “render” methode van JSR-168; b) Methode “performBlockingInteraction” is de methode die wordt aangeroepen om gebruikersinvoer door te sturen naar de remote portlet waarvoor deze invoer is bedoeld. Het is de tegenhanger van de JSR-168 methode “processAction”; c) De methode “initCookie” wordt gebruikt om de producer in staat te stellen om eventuele cookies te initaliseren en terug te sturen naar de consumer voor gebruik binnen de huidige sessie. Producers kunnen cookies bv. gebruiken voor het expliciet koppelen van sessie state aan bepaalde producer instances (i.g.v. load balancers of producers die binnen een cluster opereren). Verder worden cookies natuurlijk veelvuldig gebruikt om server state vast te leggen binnen de browser. d) Methode “releaseSessions” kan door de consumer worden gebruikt om sessie informatie binnen de producer op te ruimen. Op deze wijze kan de consumer ervoor zorgen dat sessies die binnen de consumer niet langer geldig zijn (bv. na timeout of expliciete logout) ook aan de producer zijde niet langer bestaan. Bij het opbouwen van een pagina met remote portlets volgt de consumer portal exact dezelfde processtappen als JSR-168. Er zijn twee varianten: 1) De pagina wordt opgebouwd zonder dat er sprake is van een “user action”. Dit is bv. het geval indien een portal pagina voor de eerste maal wordt aangeroepen vanuit een andere pagina, of de pagina wordt eenvoudigweg ververst. In dit geval zal de consumer portal voor elke “remote” portlet de methode “getMarkup” aanroepen, mogelijkerwijs vanuit meerdere threads. De ontvangende producer portal zal deze aanroep verwerken en tenslotte de “render” methode aanoepen op de corresponderende “fysieke” portlet. 36/52 2) De pagina wordt opgebouwd als gevolg van een “user action”, m.a.w. de gebruiker klikt op een link die is gekoppeld aan een portlet. Dit kan bv. de “submit” knop zijn van een formulier. Als de “target” van deze actie een “remote” portlet betreft zal de consumer portal als eerste de methode “performBlockingInteraction” aanroepen met als één van de argumenten de verzamelde gebruikersgegevens (formulier velden). De consumer wacht vervolgens op return van deze methode, andere portlets worden dus nog niet verwerkt. De producer portal ontvangt de argumenten en zal tenslotte methode “processAction” op de “fysieke” targer portlet aanroepen. Ook hier zullen andere portlets niet worden geactiveerd. Als deze aanroep is afgerond zal de consumer portal vervolgens “getMarkup” gaan aanroepen van alle “remote” portlets om de actuele content op te halen. Dit sequence diagram toont het complete “two-step process” bij verwerken van gebruikersinvoer. Het diagram toont alleen de “remote” portlets, waarbij we er vanuit gaan dat de producer een tweetal portlets, A en B, beschikbaar heeft gesteld op de pagina waarop de gebruiker de invoer heeft gepleegd. Figuur 15: WSRP Content generatie 4.2.1.2.1 URL’s in markup De markup die door de producer wordt geproduceerd kan uiteraard URL’s bevatten. Aangezien de gebruiker communiceert met de consumer en niet met de producer, dienen deze URL’s uiteindelijk te verwijzen naar de consumer site en niet naar de producer site. WSRP biedt hiervoor een aantal alternatieven, afhankelijk van de bereidwilligheid van de producer portlet om “WSRP aware” URL’s te genereren of niet. In het eenvoudigste geval heeft de feitelijke portlet code van de producer geen weet van het gebruik van WSRP en deze zal dan ook URL’s maken die verwijzen naar producer resources. In dit geval zal de WSRP producer in de gegenereerde markup de URL’s voorzien van “tags” en hij zal de consumer de instructie geven dat alle van een “tag” voorziene URL’s moeten worden aangepast aan de situatie van de consumer. Als parameter aan de tag is de actie meegegeven die de consumer moet uitvoeren indien de gebruiker klikt op de uiteindelijke URL. WRSP kent hiertoe een drietal acties: 1. blockingAction – de URL resulteert in een “state-change” binnen de portlet en zal dus moeten worden uitgevoerd als een sequentie van “performBlockinInteraction” op de betreffende portlet, gevolgd door “getMarkup” voor alle portlets; 2. render – de URL dient te resulteren in het uitvoeren van alleen een “render” op alle portlets; 37/52 3. resource – de URL vormt een verwijzing naar additionele pagina resources zoals plaatjes en/of bestanden; Een alternatief is het gebruik van “URL Templates”. In dit geval stuurt de consumer zijn context naar de producer (in de vorm van één of meer “URL Templates”) als onderdeel van de “performBlockingInteraction” of “getMarkup” aanroep. De producer gebruikt deze context om URL’s te genereren die direct verwijzen naar deze consumer context en dus niet achteraf door de consumer hoeven te worden herschreven. Voordeel is uiteraard dat performance winst kan worden geboekt. Nadeel is dat de producer hiermee afhankelijk wordt van de consumer en geen markup kan cachen voor meerdere consumers. Een portlet die wordt gebruikt binnen een WSRP omgeving en die gebruik maakt van herschrijven van URL’s door de consumer kan uitsluitend URL’s genereren die refereren aan die betreffende portlet. Het is dus expliciet niet mogelijk om pagina URL’s te genereren! Dit is ook logisch, een WSRP portlet wordt immers “op zichzelf” gebruikt, de pagina structuur wordt volledig bepaald door de consumer. Ook URL’s naar andere portlets binnen dezelfde producer is een twijfelachtige zaak. Immers, het is niet zeker dat deze portlets bestaan bij de consumer. 4.2.1.2.2 Cookies In veel gevallen zal een portal gebruik maken van Cookies om state op te kunnen slaan in de browser van de gebruiker. Als de producer behoefte heeft aan het gebruik van Cookies zal hij dit kenbaar maken middels het “requiresInitCookie” element in de response op “getServiceDescription”. De consumer dient in dit geval de markup interface methode “initCookie” aan te roepen waarna de producer één of meerdere Cookies teruggeeft. Deze moeten met elke volgende “markup” of “performBlockingInteraction” worden meegegeven aan de producer. Tijdens de sessie kunnen Cookies ongeldig raken. De producer zal dit kenbaar maken middels “invalidCookie” foutmeldingen. De consumer moet op dat moment opnieuw “initCookie” aanroepen om “verse” Cookies te krijgen. 4.2.1.3 De WSRP 2.0 standaard Sinds april 2008 is de WSRP 2.0 standaard formeel vrijgegeven. WSRP 2.0 biedt aansluiting op de JSR-286 standaard en heeft dan ook ondersteuning voor de typische JSR-286 uitbreidingen: Events – een portlet kan reageren op events die zich in de consumeromgeving hebben voorgedaan. Dit kunnen events zijn van portlets die afkomstig zijn van verschillende producers (een “echt” gedistribueerd event netwerk dus). De functionaliteit komt overeen met het JSR-286 eventmodel; Publieke renderparameters – deze parameters worden in WSRP 2.0 altijd via de URL doorgegeven en zijn beschikbaar voor alle portlets op een consumer pagina, onafhankelijk of dit een lokale portlet is (dus in de context van de consumer) of dat het een via WSRP ontsloten “remote” portlet is; Resource – identiek aan de JSR-286 spcificatie kunnen portlets render “fragmenten” genereren die vanaf de producer, via WSRP, naar de consumer worden geleid en vandaar naar de browser van de gebruiker, zonder dat hiervoor de volledige pagina hoeft te worden gerefreshed; 38/52 Naast deze uitbreidingen biedt WSRP 2.0 tevens nog: Caching – markup fragmenten voor remote portlets worden in de consumer opgeslagen. De cache wordt bijgewerkt conform een “expiration” mechanisme (dus na “x” seconde verversen) of d.m.v. een expliciete validatiecheck bij de producer; Leasing – in de WSRP 1.0 standaard was de verbinding tussen “consumer” en “producer” in principe permanent. De WSRP 2.0 standaard biedt de mogelijkheid om conditioneel een geldigheidsperiode aan de verbinding te koppelen; 4.2.2 Samenvatting De WSRP 1.0 standaard is volwassen en is beschikbaar voor veel uiteenlopende portalservers. Echter, er zijn gevallen waar de portalserver wel het “consumer” interface aanbiedt maar niet het “producer” interface (een goed voorbeeld hiervan is Microsoft Sharepoint 2007). WSRP is het enige alternatief voor het direct koppelen van portalen. Het grote voordelen van WSRP is de mogelijkheid om direct portlets aangeboden door portal A beschikbaar maken via de presentatielaag van portal B. Portal B hoeft deze portlets niet zelf te onderhouden. Daarnaast kunnen gedistibueerde netwerken van portlets worden gebouwd, ongeacht de technologie. Er zijn echter ook een aantal nadelen. Zo is de beveiliging slecht geregeld in de standaard. Omdat WSRP is gebaseerd op web services wordt vaak gesteld dat beveiliging op het service transportniveau moet worden opgelost d.m.v. WS-Security of SAML. In de praktijk bieden maar weinig portalservers deze optie ook aan. De standaard methode is om security te regelen op het consumer portal door toegang tot pagina’s met WSRP portlets te limiteren tot geauthenticeerde gebruikers en om HTTPS / SSL te gebruiken over de verbinding tussen producer en consumer. Performence en complexitied van WSRP is problematisch. De standaard definieert in feite een protocol om gebruikersinterfaces te transporteren over web services. Dit maakt de interactie complex en vrij breekbaar. In veel gevallen is het (in ieder geval architectuur-technisch) netter om de onderliggende functionaliteit beschikbaar te stellen als bedrijfsservice en deze service met een “eigen” portlet van het consumer portal te ontsluiten. De afhankelijkheiden tussen producer en consumer worden beter te beheren en de connectie is bovendien beter de beveiligen. WSRP is verder een vrij complex protocol en levert redelijk veel overhead op. Performance is een issue, zeker als de verbinding tussen producer en consumer via het Internet loopt. Tenslotte wordt de WSRP 2.0 standaard wordt door slechts weinig portalservers ondersteund. 39/52 4.3 Microsoft Sharepoint Microsoft Sharepoint heeft functionaliteit om portal omgevingen aan gebruikers aan te bieden, waarbij zogenaamde ‘webparts’ de rol van de portlet hebben. Deze portals zijn alleen in staat functionaliteit aan te bieden die op de Sharepoint server of farm zelf geïmplementeerd is. Koppeling met andere systemen zal gebouwd/gekocht moeten worden om vervolgens aangeboden te kunnen worden in de portal. Dit lijkt daarmee sterk op wat JSR-168 kan bieden. Sharepoint implementeert, in tegenstelling tot JSR-168, geen open standaard voor de communicatie tussen portal en achterliggende systemen. Sharepoint kan middels WSRP portlets consumeren. 4.4 Gadgets en Widgets Gadgets en Widgets zijn termen die horen bij de “Web 2.0 hype”. Maar wat zijn nu eigenlijk een Gadget en Widgets en wat kan je er mee? 4.4.1 Wat is een Gadget? De term “Gadget” of “Widget” kom je nogal eens tegen binnen de wereld van Web 2.0. De beste definitie van een “Gadget” is: “Een universele, publieke, op basis van een URL toegankelijke service waarmee toegang wordt verkregen tot een applicatie die speciaal is toegesneden om te worden opgenomen binnen de HTML structuur van een web pagina”. Gadgets en Widgets zijn een verschillende naam voor feitelijk hetzelfde ding. Omdat de API specificatie de Gadget API heet, zal in het vervolg de term Gadget worden gehanteerd wanneer we aan deze technologie refereren. Gadgets zijn in principe “browser based”. De logica maakt gebruik van Javascript, eventueel gecombineerd met dynamische content-rendering tools zoals Flash of Microsoft Silverlight. Communicatie met de achterliggende applicatielogica maakt gebruikt van AJAX waardoor het mogelijk wordt om alleen de door de Gadget getoonde content bij te werken waarbij de rest van de pagina niet wijzigt. Gadgets zijn de belangrijkste bouwsteen voor Rich Internet Applications (RIA’s) en voor de creatie van Mashups. Mashups maken het mogelijk om de content van meerdere informatiebronnen aan de browser kant te combineren tot nieuwe functionaliteit, zonder aan de oorspronkelijke bronnen iets te hoeven wijzigen. Uniek aan gadgets, in vergelijking met JSR-168 portlets, is dat ze naast in een browser, ook in toenemende mate rechtstreeks, zonder browser, gebruikt kunnen worden op ‘devices’ zoals mobiel telefoons en smartphones zoals de iPhone en Android. Ook bieden gangbare besturingsystemen zoals Microsoft Vista, MacOS en diverse Linux varianten momenteel reeds de mogelijkheid gadgets rechtstreeks op de desktop weer te geven zonder (zichtbare) tussenkomst van een browser. Er zijn ondertussen zelfs televisie toestellen die zelfstandig gadgets kunnen weergeven5 Net als een portlet kan een Gadget een “window” bezitten met daarop knoppen voor omschakeling tussen verschillende “views” (de meest voor de hand liggende zijn daarbij de “view” mode waarbij de daadwerkelijke functionaliteit van de Gadget wordt getoond en de “customize” mode waarbij de gebruiker de Gadget kan aanpassen aan eigen wensen en voorkeuren. In tegenstelling tot een [JSR-168/286] Java portlet waarbij de code aan de portal-kant wordt uitgevoerd, worden bij de Gadget de meeste operaties uitgevoerd binnen de browser op basis van Javascript bibliotheken. 5 http://connectedtv.yahoo.com/services/tv-widgets 40/52 Gadgets zijn als zodanig “uitgevonden” door Google. De Gadget specificatie maakt tegenwoordig onderdeel uit van de OpenSocial API (waarover later meer). De specificaties zijn te vinden op de site van opensocial.org6. OpenSocial is (nog) geen formele open standaard en Google is nog steeds een van de belangrijkste spelers is bij de doorontwikkeling van de gadgets API. Echter de OpenSocial API wordt beheerd door een stichting – de OpenSocial Foundation - en het proces rondom de doorontwikkeling is transparant en toegankelijk7. 4.4.2 Gadgets API De Gadget specificatie gaat met name over de weergave van gadgets. De gadgets API is gebaseerd op een drietal componenten: 1. De “Gadget Specificatie”, een XML file waarin de kenmerken, content en configuratiegegevens van de Gadget zijn beschreven. Deze file wordt “ergens” op het Internet opgeslagen en is via een URL toegankelijk. De gadget specificatie is zeer eenvoudig. Hieronder een voorbeeld van een eenvoudige gadget. <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Hello World!"> <Require feature="opensocial-0.8" /> </ModulePrefs> <Content type="html"> <![CDATA[ Hello, world! ]]> </Content> </Module> De <Module> sectie geeft aan dat deze xml file een gadget beschrijft. Het onderdeel <ModulePrefs> Heeft metadata over de gadget zoals auteur, licentie, ect. De <Require feature="opensocial0.8" /> beschrijft de afhankelijkheden van de gadget, in dit geval, de OpenSocial API (v0.8), meer hierover in het volgende hoofdstuk. De <Content> sectie beschrijft de content van de gadget. In dit geval zal de inhoud van het type ‘html’ zijn. Andere datatypen zijn mogelijk, maar worden voor OpenSocial containers niet aangeraden. Figuur 16: HelloWorld Gadget in iGoogle 6 http://www.opensocial.org 7 http://wiki.opensocial.org/index.php?title=Specification_Process 41/52 Het <![ CDATA[…]]> blok is de daadwerkelijke inhoud van de gadget. Omdat het hier een html widget betreft, zou dit blok HTML code, CSS stylesheets enJavaScript functies kunnen bevatten. Bovenstaande Gadget leidt in iGoogle tot de weergave zoals getoond in figuur 17 2. De “Gadget Implementatie”, de achterliggende code (server-side, “ergens op het Internet”) die door de browser-kant van de Gadget wordt aangeroepen om daadwerkelijke content te tonen. Theoretisch kan dit leeg zijn of een vast inhoud hebben, zoals bovenstaande boorbeeld. We spreken dan van een “statische” Gadget en die zijn over het algemeen niet bijzonder interessant want redelijk beperkt in functionaliteit; 3. De “Gadget Code”, Javascript, HTML, Flash, etc., code componenten die binnen de browser de Gadget presentatielaag vormen; 4.4.3 OpenSocial De Gadget specificatie maakt onderdeel uit van de ‘OpenSocial’ specificatie. OpenSocial definieert een API waarbij het uitgangspunt een zogenaamde ‘Social Application’ is. Dit soort applicaties draaien om mensen, hun relaties en hun activiteiten. De 0.9 versie 8 van de API die is sinds April 15, 2009 beschikbaar is, implementeert interfaces voor onder andere: Personen en hun eigenschappen Relaties (Vrienden/Groepen) Activiteiten Messaging Gadgets De data uitwisseling van bovenstaande middels Javascript, Rest en SOAP Authenticatie middels OAuth OpenSocial faciliteert in drie onderdelen, zie figuur 17: Figuur 17: OpenSocial componenten 1. 8 OpenSocial applicaties (App) Dit zijn de op gadgets en OpenSocial standaard gebaseerde applicatie die op een http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html 42/52 (web) server geplaatst wordt en bepaalde functionaliteit kunnen uitvoeren. Welke functionaliteit wordt uitgevoerd is volledig afhankelijk van wat de betreffende Gadget implementeert, en dit is niet afhankelijk van de uiteindelijke presentatie van de gadget, noch van de data waarop de Gadget werkt. 2. OpenSocial Container (‘Social Network’) De OpenSocial container implementeert de OpenSocial API en een OpenSocial Data Server in het sociale netwerk. Het is de container die mensen, hun eigenschappen, relaties en activiteiten beschikbaar maakt aan de App’s middels de gestandaardiseerde OpenSocial API. De wijze waarop deze gegevens verzameld worden is aan de container. Vaak zal een container daarom functionaliteit bieden om account, profielen en relaties aan te maken en te beheren. Er zijn een aantal zeer bekende container aanbieders, waarbij die van Google (iGoogle9), MySpace (MySpace Developer10), Yahoo (Yahoo! Application Platform11) en Linkedin (LinkedIn Applications Platform12) wel de bekendste zijn. Ook het Nederlandse Hyves implementeert een OpenSocial container (Hyves Developer Site13). Via deze containers gebruiken maandelijks meer dan 100 miljoen mensen op OpenSocial gebaseerde technologie. De meest containers implementeren momenteel API 0.8.x Naast de vele beschikbare sites die de container als (onderdeel van) een ‘hosted’ dienst aanbieden, zijn er implementaties beschikbaar om zelf een OpenSocial container beschikbaar te stellen. Shindig14 van de Apache Foundation is de Open Source referentie implementatie van de OpenSocial API’s en wordt actief ondersteund door onder andere Google. 3. ‘Sharing and Accessing Social Data‘ Het gecombineerde resultaat van functionaliteit van de App en data van de OpenSocial Container wordt door de container geserveerd aan een eindgebruikersapplicatie. De eindgebruikersapplicatie, vaak een browser, presenteert (rendert) het geheel op basis van de gadget spec. en toon de middels de OpenSocial API vergaarde data. 4.4.4 Gadgets Veiligheid Het open karakter van gadgets brengen ook een aantal uitdagingen met zich mee. Gadget hebben op het gebied van veiligheid niet een erg goede naam. Dit is vooral veroorzaakt doordat in de eerste versies van de spec de veiligheid onderbelicht was. Ondertussen zijn er een aantal significante verbetering aangebracht om de veiligheid van gadgets te verbeteren. Hieronder worden een aantal aandachtspunten opgesomd. In tegenstelling tot portlets dienen gadgets niet zomaar met elkaar te kunnen communiceren. Dit is noodzakelijk om onderlinge beïnvloeding te vermijden. Het hele idee achter een Gadget is het binnen de browser draaien van Javascript, aangeleverd door een stukje software “ergens” op het Internet. De gebruiker kan willekeurige gadgets op een pagina verzamelen en elke Gadget kan in theorie zijn 9 http://www.google.com/ig 10 http://developer.myspace.com/community/ 11 http://developer.yahoo.com/yap/ 12 http://www.linkedin.com/static?key=developers_opensocial 13 http://www.hyves.nl/gapsb 14 http://incubator.apache.org/shindig/ 43/52 gekoppeld aan een andere website. Omdat de ‘bron’ van een gadget overal op internet kan zijn, dienen zowel de container als de gadgets onderling beschermd te worden. De introductie van CAJA 15 16, wat zoveel betekend als kluis of cel introduceert dit soort mogelijkheden binnen OpenSocial containers. Naast het afbeschermen van gadgets wordt ook de interactie tussen gadgets en container gecontroleerd. Caja is nog niet voltooid. Wel is het tegenwoordig een standaard onderdeel van de Shindig referentie applicatie. Beveiliging is binnen gadgets niet expliciet geregeld. Standaard https kan gebruik worden om de communicatie tussen Gadget (web)server en de portal te beveiligen. Authenticeren vanuit een Gadget is moeilijk, zo niet onmogelijk omdat de web browsers over het algemeen niet toestaan dat “vreemde” web sites (referenties vanuit een pagina naar een URL anders dan de pagina URL), security Cookies plaatsen en deze Cookies noodzakelijk zijn voor het vastleggen van login informatie. Als een Gadget in combinatie met een portal wordt gebruikt is dit probleem minder relevant (althans, voor gadgets die gebruik maken van datzelfde portal) omdat de gebruiker op het portal moet inloggen voordat de pagina met de gadgets kan worden aangeboden. In het geval dat zowel de portal als de gadgets voor authenticatie gebruik maken van een federatie zoals de SURFfederatie zijn bovenstaande zaken echter geen probleem. De portal en de gadgets gedragen zich net als ‘normale’ webbased ‘service providers’ en in voorkomende gevallen wordt zelfs Single-Sign-On gerealiseerd tussen de portal en de gadgets. De huidige OpenSocial API implementeert Oauth. Middels OAuth kun je ‘resources’ (foto’s videos, contact lijstjes, etc) die zich op een site bevinden delen met een andere sites, zonder dat je wachtwoorden en gebruikersnaam ook met iedere site moet delen. Gadgets vormen potentieel een groot risico op het gebied van privacy. Omdat gadgets vrijwel per definitie in iemand anders z’n omgeving draaien, vormen ze daarmee een potentieel interessante inspiratiebron voor hackers en phishers. Een Gadget kan ongemerkt worden ingezet om bijvoorbeeld informatie van de gebruiker te verzamelen en door te sturen. Zie bijvoorbeeld het volgende artikel: “Analyst: Beware of the Google gadgets”17 Daarnaast ondersteunt de OpenSocial specificatie een aantal eigenschappen van personen waarvan het dubieus is of je die wel zou moeten willen vrijgeven. Dit varieert van ‘favorite books/food/whatwever’ tot ‘sexual preference’. Het verdient dan ook de aanbeveling in onderwijs of onderzoek context zeer terughoudend te zijn met het aanleveren van dit soort informatie naar de gadgets die in de container gebruikt worden. Er zou bijvoorbeeld gekozen kunnen worden niet meer informatie weg te geven dan reeds door de IdP van de instelling van de gebruiker beschikbaar wordt gemaakt. Gadgets zijn in principe publiek toegankelijk. Zoals voor iedere dienst op internet geld dat ook de servers die gadgets aanleveren goed beveiligd dienen te worden. Daarnaast heeft iedereen toegang heeft tot de Gadget en/of de Gadget code. gadgets die gevoelige informatie manipuleren zijn dus een slecht idee. 15 http://code.google.com/p/google-caja/ 16 http://google-caja-discuss.googlegroups.com/web/caja-spec.pdf 17 http://www.debianhelp.org/node/14120 44/52 4.4.5 Samenvatting Gadgets maken het mogelijk om dynamische pagina’s te bouwen zonder daarvoor kennis te hoeven hebben van code en maken het mogelijk om snel Mashups en Rich Internet Applications (RIA’s) te ontwikkelen. Omdat de “server side” van een Gadget niet afhankelijk is van een specifiek framework kan de Gadget Implementatie worden ontwikkeld met een willekeurig Web Framework. De enige randvoorwaarde is de ondersteuning van HTTP en HTML. Gadgets en OpenSocial zijn zeer open en worden reeds door diverse grote platformen gebruikt en is daarmee bewezen technologie. Het gemak waarmee het mogelijk is functionele componenten (‘Apps’) uit te wisselen tussen OpenSocial compatible portals maat het gebruik van dit soort technologie extra aantrekkelijk. Echter, de OpenSocial API is (nog) geen open standaard. Wel zijn er tekenen die laten zien dat er in die richting wordt bewogen. Om veilig en betrouwbaar met gadgets te kunnen werken verdient het de voorkeur een container omgeving te gebruiken die door een vertrouwde partij beheerd wordt. SURFnet zou hierin prima een centrale rol kunnen spelen voor haar instellingen. Voor een dergelijke container zou SURFnet nauwkeurig moeten afwegen welke onderdelen van OpenSocial API wel en niet geïmplementeerd worden. Daarnaast zou bij het aanspreken van ‘externe’ gadgets de gebruiker expliciet gevraagd moeten worden of hij/zij de attributen die wel door SURFnet geprovisioned worden ook echt beschikbaar wil maken voor de widget. Gebruik van “externe” gadgets dient zorgvuldig te worden overwogen en het verdient aanbeveling gadgets niet te gebruiken voor bewerken van gevoelige informatie. Opnieuw zou SURFnet hier een rol kunnen spelen. Middels de SURFfederatie kunnen instellingen nauwkeurig regelen welke attributen gebruikers wel, en welke niet beschikbaar gemaakt worden richting een container omgeving. Daarnaast zou SURFnet een rol kunnen spelen bij het beoordelen van de betrouwbaarheid van gadgets van derden en/of instellingen. 4.5 Gadgets en Portalen combineren Gadgets laten zich prima combineren met portalen. Veel portal servers bieden ondersteuning op basis van JSR-168/286 portlets die in feite een “placeholder” vormen voor de Gadget code. Ze laten zich op een portal pagina plaatsen zoals elke andere portlet, met het grote verschil dat er in feite een “lege” server-side portlet achter zit. De feitelijke code draait volledig binnen de browser (in combinatie met de Gadget Implementatie die achter de opgegeven URL zit “verstopt”). De figuur toont hoe gadgets samen met een portal gebruikt kunnen worden voor het genereren en tonen van dynamische wijzigende web content: In eerste instantie biedt de portal server het Gadget aan in de vorm van een [JSR-168/286] portlet. Deze portlet genereert de “Browser-kant” van de Gadget in de vorm van Javascript. Voordeel is dat de Gadget op deze manier op een pagina kan worden geplaatst net zoals de “standaard” Java portlets. 45/52 Bij het renderen van de pagina worden de gadgets vertaald naar Javascript “insertions” in de HTML pagina. Ze maken voor hun runtime omgeving gebruik van door Google beschikbaar gestelde Javascript bibliotheken. De Gadget Descriptor beschrijft in principe de functionaliteit en configuratiegegevens van de Gadget. In theorie heb je niet meer nodig dan deze descriptor. De Gadget Browser Code is onderdeel hiervan en bevat de Javascript code waarmee de Gadget binnen de browser wordt geïmplementeerd. Om dynamische gadgets te maken die opereren op externe content (= content beschikbaar “ergens” op het Internet) zal er ook sprake zijn van server-side componenten, in de figuur omschreven met “Gadget Implementatie”. Deze componenten kunnen in elke [web]taal zijn geschreven en worden vanuit de Gadget aangeroepen d.m.v. AJAX calls. Het is deze combinatie van browser-kant logica met server-kans logica die het Gadget concept zo krachtig maken. De figuur toont een aparte server voor de Gadget Implementatie. Dat kan echter ook de portal server zijn. In dat geval kan je een implementatie bouwen waarbij server-side (portlet code) en browser-side (gadgets) samenwerken om volledig dynamische pagina’s te realiseren. Gadgets zijn een krachtige aanvulling op het scala aan portalpagina ontwikkeltools. Onder andere via de Google repository is het mogelijk om te Figuur 18: Relatie Gadgets & Portalen kiezen tussen vele honderden verschillende gadgets die, mits de juiste portal server is gekozen, direct op een pagina zijn te plaatsen, al ware het lokale portlets. 46/52 5 Functionele eisen 5.1 Requirements De functionele eisen zijn aangeleverd door SURFnet op basis van een tweetal interview rondes met afgevaardigden van de afdelingen Community Support en Middleware Services. Naast een overzicht van de functionele eisen voor de portal-technologie is er een lijstje met functionele eisen voor de te realiseren portlet en widget technologie naar voren gekomen. Dit lijst is op de volgende pagina te lezen. De tabel hieronder bevat de geïnventariseerde eisen met betrekking tot portaltechnologie met hun prioriteit: Ident: Eis: MoSCoW: F01 Diensten (services) van zowel SURFnet als instellingsdiensten en diensten van derden moeten door middel van de portaltechnologie zichtbaar gemaakt kunnen worden binnen de portal. M F02 De portaltechnologie moet personalisatie-functionaliteiten beschikbaar maken M F03 Free widget placing: Widgets moeten door de gebruiker vrij gepositioneerd kunnen worden binnen de portal M F04 De portaltechnologie moet generiek herbruikbare widgets kunnen faciliteren M F05 De portaltechnologie moet bewust zijn dat de gebruiker aangemeld is bij de portal** M F06 De portaltechnologie moet informatie (logs) kunnen bijhouden over het gebruik van de portlets en widgets M F07 De portal moet de gebruiker de mogelijkheid bieden de layout van de portal aan te passen M F08 De portaltechnologie moet vertrouwende widgets herkenbaar kunnen maken. Evenzo de niet-vertrouwde widgets. De CI moet daarbij betrouwbaarheid van widgets kunnen checken M F09 De portal moet niet de rechten en rollen van de onderliggende diensten kunnen overschrijven M F10 De portaltechnologie moet de portlets met meerdere identiteiten kunnen consumeren* S F11 De portaltechnologie moet de huidige presentatievorm kunnen opslaan en deelbaar beschikbaar stellen S *: De gebruiker moet gelijktijdig ingelogd kunnen zijn via federatieve inloggegevens en inloggegevens van instellingspecifieke diensten, alsmede diensten (google bijvoorbeeld) van de derden. Hierbij is het van belang dat de inloggegevens van de gebruiker niet doorgespeeld worden naar diensten van niet-federatiefgekoppelde diensten. **: De portaltechnologie moet een intelligente en specifieke profielen-optie faciliteren 47/52 5.2 Technologiemapping Niet elke in hoofdstuk 2 beschreven technologie is even geschikt voor de implementatie van de in hoofdstuk 5 beschreven eisen. De tabel hieronder geeft op basis van een “consumentengids” beoordelingsmethode een overzicht van toepasbaarheid. Hierbij is gebruik gemaakt van de volgende symbolen: “-“ Geen of slechts beperkte support; “+/-“ Support, maar onder condities; “+” Support; Voor alle drie geldt: op en aanmerkingen zijn mogelijk via footnotes. F01 - - +/- +/- ?20 - + + F02 - - +/- - + + + + F03 - - +/- +/- + + + + F04 - - - +/- + + + + F05 - - +/- + + + + + F06 - - +/- + + + + + F07 - - - - + + + + F08 - - +/- +/- + + + + F09 - - +/- +/- + + + + F10 - - +/- +/- + + + + F11 - - +/- +/- + + + + Gadgets & OpenSocial Portal Server (WSRP) Portal Server (JSR 168/286) Portal Server (proprietary) RWD Frameworks19 Eis: MVC Engines18 Markup Templates Scripting Tech: 18 Voor MVC engines geldt dat in principe “alles kan”, je moet het alleen wel zelf bouwen. 19 Voor RWD geldt dat de support sterk afhankelijk is van het type framework. Sommigen zijn beter dan anderen. Kans op maatwerk is zeer groot. 20 Afhankelijk van wat de portals implementeren 48/52 6 Conclusie De belangrijkste functionele wens die ten grondslag ligt aan in dit onderzoek is het in samenhang kunnen presenteren van diensten (services) van zowel SURFnet, instellingen als ook diensten van derden. Omdat portaltechniek hiervoor de meest geschikte oplossingrichting lijkt, is gekeken naar de technologieën die hiervoor beschikbaar zijn en wat de voor- en nadelen van de verschillende technologieën zijn. Het Collaboration Infrastructure21 rapport geeft daarnaast aan dat om het voor derden mogelijk te maken om delen hiervan te consumeren, het verstandig is om te kiezen voor een oplossing op basis van een open koppelvak. Hiernaar wordt door SURFnet in het SURFworks programma in 2009 onderzoek gedaan onder de werknaam “Collaboration Infrastructure”. In het onderzoek is gekeken naar de volgende technologieën: Scripting Markup templates MVC Engines RWD Frameworks Portal Server (proprietary) Portal Server (JSR168/286) Portal Server (WSRP) Gadgets & OpenSocial Het is mogelijk portals te realiseren op basis van een geïntegreerde oplossing, zoals beschreven in het eerste deel van hoofdstuk 2. In dit soort oplossingen is er vaak een sterke koppeling tussen presentatie en functionaliteit, en ontbreekt het aan standaardisering in de interfaces hiertussen. Er dient voor iedere nieuwe service een nieuwe maatwerkkoppeling gerealiseerd te worden met het achterliggend bronsysteem. Naast de diverse Rapid Web Development Frameworks (RWD) die beschreven zijn is ook Microsoft Sharepoint een product dat deze lijn volgt, met dien verstande dat als gevolg van de grootte en functionele rijkdom van dit product, het niet zonder meer op een lijn gezet kan worden met de andere RWD systemen. Juist omdat koppelingen steeds opnieuw aangemaakt moeten worden is een dergelijk systeem niet erg geschikt om als presentatielaag voor een nog onbekend aantal diensten te dienen. Het scheiden van presentatie en functionaliteit, en vervolgens de communicatie tussen die twee lagen standaardiseren, zal het opnemen van services in een portal aanzienlijk vereenvoudigen. Dat is de basis van de JSR-168 portal-standaard. De portal omgeving biedt slechts die functionaliteit die nodig is om weergave van de gebruikersinterface en om een beperkte set interacties af te handelen. Alle andere zaken moeten door een applicatie server ‘achter’ de portal afgehandeld worden. JSR-168 is volledig geaccepteerd binnen alle Java portalproducten, en nauwelijks daarbuiten. JSR-168 gaat voornamelijk over de interoperabiliteit van portletcode in verschillende portalproducten, maar niet over de interoperabiliteit van portlets zelf. Het mixen van services uit verschillende bronnen op presentatieniveau is dan ook iets waar JSR-168 geen handvatten voor biedt. Hierdoor dient alsnog de combinatie en eventuele integratie van de services in achterliggende applicatie server te gebeuren, die vervolgens het resultaat ervan via de protal presenteerd. De opvolger van JSR-168, de JSR-286 standaard, biedt betere mogelijkheden op dit vlak, maar wordt helaas nog weinig geïmplementeerd. 21 Dit rapport is opgesteld in het kader van de technologieverkenning “Collaboration Infrastructure & Federated Collaboratories” dat in de eerste helft van 2009 is opgesteld. Hoewel JSR-168/286 in potentie een goede set standaarden biedt, is het feit dat er eigenlijk alleen op Java goede implementaties bestaan een groot probleem. Microsoft producten implementeren in ieder geval deze standaard niet. Dit maakt gebruik van deze standaarden als basis voor een generieke integratie omgeving zeer lastig. WSRP (Web Services for Remote Portlets) is expliciet bedacht om portlets uit verschillende omgevingen te kunnen mengen in één presentatie omgeving. Hoewel de naam (‘portlets’) nog duidelijk naar de java achtergrond van deze standaard verwijst, is deze standaard een echte interoperabiliteitstandaard en daarmee platformonafhankelijk. Er zijn bijvoorbeeld ook in PHP en ASP/.NET omgevingen implementaties en ook Microsoft Sharepoint is in staat WSRP portlets te consumeren. Er zijn echter wel (aanzienlijke) nadelen met betrekking tot WSRP; zoals de performance en complexiteit en ook de beveiliging behoeft de nodige aandacht. In veel gevallen is het eenvoudiger om de onderliggende functionaliteit beschikbaar te stellen als service en deze met een “eigen” lokale JSR-168 portlet richting de portal te ontsluiten. OpenSocial gadgets introduceren een open, platform onafhankelijk, model voor het presenteren van functionele componenten aan gebruikers. Hiervoor kunnen zowel portals, ‘gewone’ websites als ook ‘devices’ zoals mobiele telefoons gebruikt worden. Het maakt daarnaast in principe niet uit waar de functionaliteit vandaan komt, en het is dus mogelijk in de presentatielaag gadgets uit verschillende bronsystemen te mixen. Verder is de gadgets API relatief licht, en sterk geoptimaliseerd op gebruik in een internetcontext. De combinatie van deze zaken maakt OpenSocial bij uitstek geschikt voor gebruik als standaard voor het leveren van functionaliteit richting een ‘consumer’ zoals bedoeld in de context van de Collaboration Infrastructure. Daarnaast biedt OpenSocial als enige naast een standaard voor het weergegeven van gadgets ook een set gestandaardiseerde data-API’s die met name in ‘sociale’ context waardevol zijn. Zo zijn standaard personen, groepen en hun activiteiten in de API aanwezig. OpenSocial is een vrij nieuwe standaard, maar mede dankzij uitgebreide ondersteuning in de industrie (o.a. Google) wordt hier hard aan (door)ontwikkeld. Verder is het gebruik van de standaard aanzienlijk. Op OpenSocial gebaseerde ‘social networks’ worden dagelijks door tientallen miljoenen mensen gebruikt. Het lijkt er verder op dat de standaard op niet al te lange termijn een echte Open Standaard gaat worden, nu de API is ondergebracht bij een onafhankelijke stichting. OpenSocial kent echter ook een aantal nadelen. Deze liggen vooral op het gebied van privacy en veiligheid. Omdat het relatief eenvoudig is via de OpenSocial API kennis te nemen van eigenschappen van gebruikers, groepen en hun activiteiten, is het verstandig om OpenSocial applicaties alleen te gebruiken indien de container waarin de gadgets draaien te vertrouwen is. Hierin zou SURFnet een faciliterende rol kunnen spelen voor de doelgroep. Ten aanzien van de veiligheid dient bij een mogelijke implementatie aanzienlijke aandacht geschonken te worden aan het afschermen van gadgets om interacties tussen gadgets en de container waar ze binnen draaien en tussen de gadgets onderling te voorkomen. Hiervoor is echter reeds technologie beschikbaar. Wanneer de beschikbare technologieën worden afgezet tegen de doelstellingen van de Collaboration Infrastructure lijkt een omgeving op basis van OpenSocial gadgets het meest geschikt. Geen van de diensten van SURFnet, uitgezonderd SURFmedia, is out-of-the-box in staat zichzelf middels ook maar één van de beschikbare portal technologieën in een portal te representeren. Dit zal naar verwachting ook in hoge mate gelden voor de diensten van onze instellingen en diensten van marktpartijen. De lichtgewicht OpenSocial API is echter relatief eenvoudig en vormt daarmee de kleinste barrière. Daarnaast wordt OpenSocial reeds door grote spelers gebruikt. Hierdoor is er nu al veel functionaliteit beschikbaar en lijkt doorontwikkeling voorlopig gegarandeerd. Het is verder de verwachting dat steeds meer services Gadgets als additionele methodiek gaan aanbieden om de functionaliteiten van de service beschikbaar te maken. 50/52 Om veiligheid en privacy voor de gebruikers te garanderen zou SURFnet een eigen, op OpenSocial gebaseerde portal omgeving moeten aanbieden, waardoor goede controle over deze aspecten mogelijk is. Door de SURFfederatie en groepsrelatie dienst te koppelen aan deze portal kan de SURFnet ‘context’ worden toegevoegd aan de omgeving. Vervolgens kan op relatief eenvoudige, controleerbare, en gestandaardiseerde wijze Gadget functionaliteit van SURFnet, instellingen en mogelijk ook van derden beschikbaar worden gemaakt voor eindgebruikers. 51/52 COLOFON Dit Rapport is opgesteld in opdracht van het SURFworks programma 2009 en maakt deel uit van de Proof of Concept Collaboration Infrastructure. Tekst Wouter Meijers (Everett) Niels van Dijk (SURFnet) Paul van Dijk (SURFnet) Review Remco Poortinga (SURFnet) Paul van Dijk (SURFnet) Floor Jas (SURFnet) © SURFnet bv 2009 52/52
