Teknisk Proof of Concept for Den fællesoffentlige integrationsmodel for borgerportalen og virksomhedsportalen

Offentlig Erfaringsrapport

Generelle erfaringer og anbefalinger

Standarder og produktunderstøttelse

Der findes veldefinerede standarder til at foretage udvikling ud fra. Det være sig JSR168 til portlets, WSRP1.0 til Remote Portlets og SAML til Single Sign-on i linking scenarier. Der findes desuden produktunderstøttelse af disse standarder på nuværende tidspunkt.

Dog er det således, at man typisk skal anvende en af de nyere versioner af leverandørernes produkter, for at arbejde med disse standarder (se mere under hver enkelt integrationsform og vær opmærksom på at det vil være forskelle fra leverandør til leverandør). Samtidigt skal man være opmærksom på, at der ikke er mange i Danmark, der har erfaringer med at arbejde med disse standarder.

Udvikling i et distribueret miljø

Selv hvor standarder er på plads og hvor interoperabilitet umiddelbart ikke giver udfordringer er der altid udfordringer i et distribueret miljø.




Særligt i forhold til test er det en udfordring at hver myndighed ikke kan forventes at have adgang til samme produkter og produktversioner som de skal integrere op mod. Selv om standarden ligger fast kan det have interesse at et bestemt produkt i rette version og med en bestemt konfigurering er til rådighed. Det var været en udfordring gennem hele PoC projektet at sikre gensidig adgang til test. Bemærk at der er tale om miljøer, der ikke er at sidestille med alm. testmiljøer, da der er behov for ”adgang udefra”.




Det må forventes at der implementeres formelle afprøvningsprocedurer, der skal gennemføres før nye services kommer på portalerne. Der kan dog være behov for mere uformel test undervejs i serviceproviders udviklingsforløb. Flere deltagere i PoC har udtrykt ønske om testmiljøer, der kontinuerligt er til rådighed – også lang tid før lancering af nye services.

Design retningslinier og visuel integration

En række integrationsformer giver i sig selv nogle begrænsninger og muligheder i forhold til at styre layout og kan i mere eller mindre grad understøtte en visuel integration. Der er dog nogle generelle overvejelser der går igen – uanset integrationsform.



Eksempelvis er der behov for enighed om hvilke HTML version, der tillades lige som man skal have procedurer, der sikrer at W3C standarderne overholdes af alle – hvis brugeren skal stå med en brugeroplevelse af, at portalen samlet set overholder disse standarder. På samme måde kan der for bestemte integrationsformer være behov for yderligere compliance test (specielt portlets - JSR/WSRP).

I sidste ende er det design som serviceprovider implementerer det mest afgørende for den endelige brugeroplevelse. Derfor er der behov for, at services, der ønskes tæt integreret til portalen, overholder nogle designretningslinier og ikke mindst er designet med tanke på at skulle vises på en portal (kan vises med begrænset plads og gerne være fleksibel).

Link eller iFrame m/Single Sing-on (SSO)

Integrationsformen link m/Single Sign-on handler basalt set ikke om at kunne link’e, da der absolut intet nyt og uafprøvet er i denne integrationsform. Det er basal HTML og link/anchor (<A href=”…”>link text</A>). Udfordringen ligger i at man overfører information om, at brugeren er logget ind én gang - og attributter, der fortæller, hvem brugeren er. Det sker med brug af SAML 2.0 standarden.

Links og iFrame giver teknisk set samme udfordringer og er derfor behandlet under ét.

Scenariet er følgende:

1. Borgeren kommer til én portal
2. Borgeren anvender en ressource/service, der kræver login
3. Login sker via fælles logintjeneste – en såkaldt Identity Provider (IdP)
4. Borgeren vises den ønskede (adgangsbegrænsede) side på portalen
5. Borgeren klikker på link til en anden portal (hos anden organisation)
6. Siden på den ”anden portal” vises uden yderligere login

Integrationsformen og standarder

Link m/SSO er baseret på standarden SAML 2.0. SAML 2.0 er en ”approved” OASIS standard og en ”anbefalet” standard i OIO kataloget.

Der er den udfordringer i forhold til valg af standarder, at profilering af SAML i forhold til browser SSO er relativ klar, mens der ikke er en SAML profil for, hvordan SSO etableres på Portlet og web service baserede services og hele vejen ned til back end systemer hos myndigheden.

PoC har kun afprøvet SAML 2.0 i forhold til browser SSO scenarier.

Produktunderstøttelse og interoperabilitet

Der findes i dag produktunderstøttelse for standarden og både consumer og serviceprovider siden af integrationen er baseret på standardprodukter fra deres leverandører (hhv. Oracle og IBM). Bemærk at Microsoft endnu ikke understøtter SAML 2.0 (kun SAML 1.0) men forventes at understøtte SAML 2.0 tokens fremover.

SAML 2.0 og uddelegeret SSO er ikke noget portalprodukterne understøtter ”out of the box”. Der kræves installation af ekstra komponenter eller ligefrem selvstændige produkter. Disse produkter kræver typisk licenser, der medfører omkostninger af ikke uvæsentligt størrelse1.

Yderligere var erfaringen i PoC forløbet, at det var nødvendigt med en række opgraderinger og patches på Oracle portalen, som ligger til grund for Borger.dk, for at forskellige versioner spillede korrekt sammen. Det vil være et typisk forløb, der kan forventes, fordi der er tale om relative nye standarder og ny teknologi.




Generelt spiller SSO baseret på SAML fint på tværs af platforme. SAML er en XML standard som ikke kræver brug af bestemte platforme eller portalløsninger.

Der er dog konstateret mindre udfordringer med interoperabilitet i forbindelse med etablering af det trustede miljø mellem Identity Provider og serviceproviders. Udveksling og indlæsning af XML konfigurations-filer var ikke helt så smertefri, som man kunne håbe, men det var dog absolut muligt at opsætte et trusted miljø mellem produkter fra forskellige leverandører.

Der har ligeledes været udfordringer med visse browser versioner (versioner af Internet Explorer) undervejs i afprøvningen. Der er ingen klare konklusioner, men det forventes ikke at have direkte relation til de afprøvede standarder og produkter og dermed være hindrende for at opbygge en stabil løsning baseret herpå.

Samlet set efterlades der et indtryk af standarder og teknologi, der kan bringes til at virke og tale sammen på tværs af leverandører allerede i dag. Man behøver således ikke vente på produktunderstøttelsen. Man kan dog forvente flere udfordringer i dag end med mere modne standarder og etablerede produkter. Det må forventes, at der sker en læring efterhånden som flere og flere bevæger sig over på disse teknologier, hvorfor man kan forvente kortere tid til udvikling og integration som tiden går i perioden 2008-2010.

Mulighed for styring af brugergrænsefladen

Grundlæggende er der tale om at man oplever en helt ny struktur, ny navigation, nyt layout mv. med tydelig afsenderskift, når man anvender integrationsformen link m/SSO. Det er dog noget man kan forsøge at omgå med forskellige teknikker.

Teknisk set er det muligt at anvende SSO i forbindelse med såvel links som iFrames. Det er dermed et forretningsmæssigt valg om man ønsker at ”link’e ud af portalen” eller indlejre HTML sider i en portalside via iFrame.

På samme måde skal der træffes et valg i forhold til, om man ønsker at tilpasse link’et og frame’et indhold mest muligt til portalen og give et sammenhængende visuelt udtryk eller om man man faktisk ønsker at give et tydeligt signal om, at der er tale om en ny afsender og at brugeren befinder sig i en anden kontekst end selve portalen.

Når man link’er vil man typisk åbne et nyt vindue og det er – som nævnt ovenfor - et politisk valg, om man ønsker at lade siden åbne ”as is” eller om man vil forsøge at efterligne portalens udseende. Det samme gør sig i princippet gældende med iFrame, men her vil det være mere oplagt, at man anvender en teknik til at tilpasse layout, da man mht. navigation mv. fortsat er i portalens miljø (men dog har indlæst en HTML side fra en serviceprovider og viser denne indlejret).




Hvis man ønsker at give en ensartet visuel oplevelse, kan man benytte en teknik, hvor serviceprovider på baggrund af hvem referer (den der linkes fra) er pålægger en bestemt style, således at farver, skriftyper mv. tilpasses og ligner den portal man er linket fra. Det er absolut teknisk muligt og er en teknik, der blandt andet anvendes i KMDs webløsninger på det nuværende borger.dk, jf. evt. KMD MitBudget case’en:
http://budgetmodul.netborger.dk/budget/default.aspx?p=bs∞
http://budgetmodul.netborger.dk/budget/default.aspx?p=aarhus∞

En lignende teknik findes i standardportaler som IBMs WebSphere Portal, hvor de temaer og præsentationstemplates, der anvende,s kan styres af hvor http forespørgslen kommer fra (en bestemt kommune, borger.dk eller en anden kendt portal), hvilken browser (eller mobil enhed) osv. PoC har ikke forsøgt at afdække andre portalprodukters (Oracle, BEA, Microsoft mv.) tilbud på dette område.

Det betyder at kontrol over style ligger hos serviceprovider og at denne dels skal designe efter at kunne anvende forskellige stylesheets og dels skal vedligeholde et antal forskellige stylesheets (ét for hver consumer der måtte have ønske om selv at kunne bestemme over det grafiske snit).




Det er uproblematisk at lade portalen styrer, hvor meget plads der afsættes til iFrames. Resultatet kan dog blive en mindre god brugeroplevelse, hvor der kommer scroll bars i begge retninger. Det valgte design er derfor – som altid – væsentligt for slutbrugeroplevelsen.

Mulighed for interaktion med andre services

Når man anvender links bevæger brugeren sig over i en helt ny kontekst og det giver derfor ikke mening at diskuterer samspillet med andre services på portalen.

iFrames giver umiddelbart ingen mulighed for inter-frame eller frame-portlet kommunikation og giver dermed de samme begrænsninger som WSRP 1.0. Work-arounds kan tænkes men er ikke forsøgt i PoC.

Når en iFrame udgør en del af en portalside, vil handlinger i andre services typisk betyde, at iFrame’en genindlæses og returnerer til startsiden. Resultatet vil afhænge af, hvordan løsningen er opbygget hos serviceprovider, men simpel navigation i iFrame-vinduet huskes ikke.




Udover ovennævnte udfordring kan iFrames ganske let anvendes til at sammensætte indhold fra flere leverandører.




Denne integrationsform giver ingen begrænsninger i forhold til kald af bagvedliggende services. Eftersom servicen fortsat afvikles hos serviceprovider som altid, er der fuld adgang til web service kald, brug af back end legacy og læsning fra databaser mv.

Integrationsformen har i denne sammenhæng den fordel at myndigheden som er serviceprovider, har sikkerhed for hvem slutbrugeren er og dermed kan stille følsomme data fra back end systemer til rådighed uden at skulle indgå særlige aftaler om trust med portalejeren (udover hvad SSO setup’et med en fælles logintjeneste kræver).

Performance og driftsmæssig tilgængelighed

Performance ved links er som udgangspunkt uændret, da drift sker hos serviceprovider på samme vis som før integrationen. Der vil være et mindre overhead i forbindelse med re-directs og check af autentificering i SSO scenariet, men det opvejes så rigeligt af, at brugeren sparer tiden til selv at logge ind. Det samme gør sig gældende ved iFrame ved den lille tilføjelse at svartiden set med brugerøjne naturligvis afhænger af, at begge servere (portal der frame’er og serviceprovider med selve servicen) svarer hurtigt.

Såvel link som iFrame har et klart snit i forhold til hvor kode afvikles og hvem der har det driftsmæssige ansvar. Der sker ikke implementering på portalen, som kan give anledning til et uklart billede af, hvor ansvaret ligger i tilfælde af fejl og nedbrud.




Der vil i SSO tjenester opstå en væsentlig driftsmæssig afhængighed af logintjenesten (Identity provider). Når logintjenesten er nede vil integrationsformen resulterer i synlige fejl for brugeren. Man kan dog rent teknisk forestille sig flere alternative logintjenester, der giver adgang til samme service hos myndigheden og evt. portalerne. Om det i praksis bliver tilfældet er et politisk valg.




Opsummering: Fordele og ulemper ved denne integrationsform

Fordele +	Ulemper -
Links og iFrame er en oplagt og simpel måde at genbruge eksisterende web løsninger uden meget omskrivning (om nogen overhovedet) Serviceprovider pålægges umiddelbart ingen restriktioner i brugerdialogen og kan råde over hele browservinduet ved links (og næsten ved en stor frame) Platformsuafhængighed. Der linkes jo bare mellem løsninger Der er et klart snit mellem consumer og serviceprovider i forhold til ansvar for udvikling og drift Et klart scenarie for hvordan myndigheden har sikkerhed for, hvem følsomme data udleveres til (slutbrugeren)	Services optræder ikke som integrerede på portalen (jf. ønske om borgernes fælles indgang) Styling kræver work arounds og koordinering med serviceprovider SAML 2.0 og brug af Identity provider er ikke velafprøvet teknologi (få erfaringer med produkterne og meget få i Danmark har i praksis arbejdet med standarderne) Microsoft understøtter endnu ikke SAML 2.0 SAML og fælles logintjenester kræver typisk anskaffelse af nye produkter som påfører serviceprovider nogle omkostninger

Remote Portlet – WSRP

Remote Portlets giver mulighed for at portlets vises ét sted, men udvikles og driftes et andet (deraf ”remote”). Integrationen er underliggende baseret på Web service kald.

Integrationsformen og standarder

Remote Portlets er baseret på WSRP 1.0 standarden. WSRP har været en approved standard siden 2003. WSRP 2.0 er på vej, men er endnu ikke klar og der er ingen produktunderstøttelse. Remote Portlets bør derfor for nuværende baseres på WSRP version 1.0.

Der er ingen profil for SAML understøttelse sammen med WSRP og integrationsformen er afprøvet uden sikkerhed. Der kan konstrueres taktiske sikkerhedsløsninger med brug af kendt teknologi for Web Service sikkerhed – eksempelvis med brug af SSL (som OWSA Model T). Dette er dog ikke afprøvet.

Produktunderstøttelse og interoperabilitet

WSRP er understøttet af en række leverandører. I PoC er dette afprøvet på IBM WebSphere portalen og Oracle Portal samt på Microsoft .NET platformen med brug af en 3. parts komponent (NetUnity).

Produktunderstøttelsen er således tilstede i dag, men man skal forvente at det i nogle tilfælde kan være nødvendigt at opgraderer eksisterende løsninger, som måtte kører på ældre portalplatforme.




Interoperabilitet mellem de forskellige leverandører har ikke givet mange problemer. Der er konstateret forskelle i tolkning Window state (nærmere bestemt ”maximize”) mellem IBM og Oracle, således at den ene portal viser en portlet med maksimal bredde (IBM) mens den anden åbner et nyt vindue (Oracle).

Der er desuden lidt forskel og ikke umiddelbart fuld understøttelse (default styles der kan vælges og konfigureres med peg-og-klik) af de portlet-relaterede HTML classes som WSRP specifikationen angiver (til style brug). Muligheden for styling er dog understøttet og overholdelse af WSRP specifikationen er det rigtige udgangspunkt for at opnå interoperabilitet. Der vil dog blive behov for at udvide aftale om classes og styles ud over hvad specifikationen håndterer.




Microsoft kan consume WSRP portlets i Sharepoint, men dette er ikke afprøvet. Microsoft har ikke selv en provider understøttelse i deres produkter og WSRP må fortsat forventes at være lettest med en java platform. NetUnity komponenten har dog vist at det er muligt via 3. parts komponenter at udstille .NET løsninger som WSRP uden nogen væsentlige interoperabilitets problemer.

Mulighed for styring af brugergrænsefladen

Remote Portlets er som andre portlets afgrænsede og konfigurerbare web komponenter, som i sin natur er tænkt til visuel integration. Portlets vises som én del af en samlet portalside. Det er portalejeren, der bestemmer placering og størrelse, men serviceproviders design er afgørende for om resultatet er brugbart.

Selvom portlets afvikles hos serviceprovider er det muligt at lade portalejeren bestemme layoutet via styling. WSRP portlets har en række standard class names2, som portalen kan forvente at kunne bestemme style for. Se nedenfor eksempel på, hvordan samme portlet vises med to forskellige styles og dermed tilpasses hhv. et borgerportalslayout og et erhvervsportalslayout – uden at serviceprovider har rettet noget som helst:

Figur 2: Mit Budget med borger-style


Figur 3: Mit budget med erhvervs-style


Såfremt serviceprovider og consumer begge overholder standard navngivningen er det relativ banalt at lade en portlet style’e efter portalens ønske.




Det er uproblematisk at tilpasse Portlets i størrelse og dermed lade portalejeren styre sammensætningen af skærmbilledet. Vær dog opmærksom på, at serviceproviderens valg af design om brug af eksempelvis store grafiske elementer er afgørende for, om resultater bliver som man kunne ønske sig, hvis man ændre på den plads, der afsættes til en portlet.

Mulighed for interaktion med andre services

Remote Portlets kan sammensættes med – og sameksistere med - andre portlets uden problemer. Det er afprøvet og de enkelte portlets holder fortsat deres tilstand, når man foretager handlinger i de øvrige. Det er dog afgørende at man overholder specifikationen retningslinier for navngivning, så der ikke opstår overlap mellem navne, der skal være unikke.




Problemstilllingen skyldes at portalen sammensætter dokumentet inden det sendes til browseren. Det er en anden teknik end ved iFrames, der opfattes som selvstændige HTML dokumenter som brugerens browser henter og selv sætter sammen.




Der er ikke i WSRP 1.0 understøttelse af kommunikation mellem portlets. Dvs. at man kan – som nævnt ovenfor – uproblematisk sammensætte et skærmbillede af flere portlets fra forskellige myndigheder, men man kan ikke lade handlinger i én af disse påvirke, hvad der sker i en af de andre. Det forventes dog at bliver understøttet i version 2.0. Det svarer altså til begrænsningerne i iFrames, men giver ikke de samme muligheder som JSR168 portlets.

Remote portlets giver ingen begrænsninger i forhold til kald af underliggende services, eftersom portleten stadig kører hos serviceprovider. Alle kald til back end og træk på legacy er altså uændret. Dette er en væsentlig forskel i forhold til traditionelle (JSR168) portlets, som installeres på portalen.

Performance og driftsmæssig tilgængelighed

Brugen af remote portlets giver et rent snit i forhold til ansvaret for udvikling og drift, eftersom portlets fortsat driftsmæssigt befinder sig hos serviceprovider. Det er en klar forsimpling i forhold til at en myndighed skal have kode installeret på portalen, hvor der kan opstå kompabilitetsproblemer og forretningsmæssigt være problemer med at placerer et ansvar for evt. problemer. Det betyder dog at afhængigheden af netværket og båndbredde er stigende (i forhold til installerede portlets).

WSRP portlets kaldes over en Web Service. Det giver et overhead dels pga. at kaldet sker over netværk til en anden myndighed og dels fordi web services er baseret på XML og SOAP. Det er dog konstateret at portalsider med WSRP portlets er i stand til at svare pænt under 1 sekund. Samtidigt er der uden egentligt load test konstateret at flere remote portlets på samme side med flere samtidige kald øger denne svartid. Der er ikke gennemført egentlig load test i PoC og hardware er ikke skaleret efter at skulle performe, men det er stadig en indikation af, at performance skal have opmærksomhed ved valg af denne integrationsform.

Øvrige erfaringer

WSRP specifikationen indeholder nogle user attributes (name, e-mail, phone mv.) som kan bruges til at give information om slutbrugeren. Det er ikke den bruger serviceprovider taler sammen med i sikkerhedsmæssig forstand (det er typisk en systembruger). Disse attributter kan dog i sammenhæng med en sikker forbindelse mellem serverne anvendes til at overføre eksempelvis et CPR nummer og dermed kombineret med den sikre linie og en aftale om hvordan portalen skal sikre autenticitet af brugeren i forhold til CPR anvendes til at hente personaliserede og evt. følsomme oplysninger fra serviceprovider.

Det må ikke forveksles med den sikkerhedsløsning hvor SAML tokens giver sikker identifikation af slutbrugeren. I ovennævnte scenarie taler system-system sammen og udveksler blot nogle attributter. Serviceprovider har intet bevis for at slutbrugeren faktisk er autentificeret og af hvem.

Opsummering: Fordele og ulemper ved denne integrationsform

Fordele +	Ulemper -
Giver en tæt visual integration med mulighed for at lave portalsider bestående af services fra forskellige myndigheder på en måde så de fremstår sammenhængende Remote Portlets giver et klart snit mellem portal og den ansvarlige myndighed som selv har såvel udvikling som drift af servicen, der blot vises på portalen Platformsuafhængighed. Da WSRP er baseret på Web Services er der platformsuafhængighed og i praksis har det vist sig relativt let at arbejde på tværs af produkter fra forskellige leverandører Det er sikkerhedsmæssigt at foretrække at brugerens browser kommunikerer med én portal, frem for som ved iFrame med en række web servere Services, der har behov for kald af back end systemer, giver ingen problemer, da de ikke skal installeres på portalen og dermed stille krav om at der fra portalen åbnes op for diverse (nye) integrationer	En SSO løsning med samspil mellem WSRP og SAML er ikke klar. Sikkerhedsløsningen skal derfor baseres på en taktisk løsning, indtil en profil for SAML for web services er på plads. WSRP 1.0 understøtter ikke inter-portlet kommunikation. Det forventes dog at komme i version 2.0 Standarden er relativ ny og fortsat under udvikling. Der kan være relativt omfattende omskrivning af legacy applikationers front end pga. form elementers navngivning, brug af javascript samt brug og eks. cookies

Composite Application - JSR168 potlets

Portlets baseret på JSR168 er afgrænsede web komponenter som afvikles i portalens run time miljø. Portlets kan anvendes både til simple og til sammensatte applikationer.

Integrationsformen og standarder

Portlets er baseret på JSR168 standarden. Der er tale om en moden standard fra 2003, der beskriver hvordan man i java koder en portlet. JSR168 er ikke en del af J2EE. Der er en ny version af JSR på vej, men den er endnu ikke klar og produktunderstøttet.

Microsoft har deres eget bud på en konfigurerbar web komponent; web part og understøtter ikke JSR168.

Før JSR168 havde en række java leverandører hver deres bud på portlets. For interoperabiliteten er det afgørende, om man holder sig indenfor standarden.

Produktunderstøttelse og interoperabilitet

JSR168 er understøttet af en række leverandører i Java verdenen. Bemærk dog at JSR168 er en java standard og som sådan ikke understøttet af Microsoft (og flere andre). Microsofts analoge teknologi er web parts. I PoC konstateredes det, at Oracle Portal har implementeret JSR168 understøttelse ved at indpakke og afvikle disse som WSRP.

JSR168 kan udvikles på én platform og herefter afvikles på én anden (java) platform. Interoperabilitet er meget lige til så længe portlets er meget simple. En hello world portlet tager ganske kort tid at flytte over på en anden java platform. Når man kommer nærmere virkelighedsnære og mere komplekse løsninger var det dog knap så trivielt at installerer på ny platform. Det skyldes ikke standarden og understøttelsen af denne i sig selv, men at portlets installeres på portalen og dermed bliver afhængig af portalens run time miljøer og den infrastruktur som hele platformen tilbyder.

Det kan give problemer, selv hvor begge platforme har implementeret understøttelse af en standard, der anvendes, eller begge faktisk tilbyder en bestemt infrastrukturkomponent som et web service runtime miljø, fordi der er tale om forskellige implementeringer og en JSR168 portlet kan være udviklet på en måde, der binder den tæt til den enkelte implementering.




Ligesom mange andre Java applikationer kan en JSR168 portlet anvendes divere java biblioteker, til at løse specielle opgaver i applikationen. Hvis disse biblioteker ikke er understøttet i portal platfomen, skal de pakkes ind i deployment filen, som indeholder JSR168 portleten. Derved bliver de også tilgængelige, på consumer portalen. Det er almindelig ”god praksis”, men udfordringen er at finde den rette balance så hver portal ikke medtager unødvendigt mange bibliotekter og ignorerer at portalen allerede understøtter meget af den infrastruktur, den måtte have behov for. Der vil blive behov for retningslinier og aftaler.

Mulighed for styring af brugergrænsefladen

Portlets er afgrænsede og konfigurerbare web komponenter som i sin natur er tænkt til visuel integration. Portlets vises som én del af en samlet portalside. Det er portalejeren, der bestemmer placering og størrelse, men serviceproviders design er afgørende for om resultatet er brugbart.

Da portlets afvikles på portalen er det muligt at lade portalejeren bestemme layoutet via styling. JSR168 portlets har en række standard class names3, som portalen kan forvente at kunne bestemme style for. Se eksempel under Remote Portlets, der har samme mulighed.




Såfremt serviceprovider og consumer begge overholder standard navngivningen er det relativ banalt at lade en portlet style’e efter portalens ønske.

Det er uproblematisk at tilpasse Portlets i størrelse og dermed lade portalejeren styre sammensætningen af skærmbilledet. Vær dog opmærksom på, at serviceproviderens valg af design om brug af eksempelvis store grafiske elementer er afgørende for, om resultater bliver som man kunne ønske sig, hvis man ændre på den plads, der afsættes til en portlet.

Mulighed for interaktion med andre services

Portlets giver i modsætning til 1. generation af Remote Portlets mulighed for inter-portal kommunikation. Portlet-interaktion er dog ikke afprøvet i PoC, men portlets er velafprøvede i en række andre sammenhænge.

Portlets kan uproblematisk sameksisterer med andre portlets (og hver for sig ”holde tilstand”), når blot der overholdes nogle retningslinier for navngivning. Portlets og Remote Portlets kan tillige sameksisterer. Der er ikke konstateret nogen problemer i denne sammenhæng under PoC.

Såfremt Portlets anvender back end systemer eller har behov for at hente data fra en database eller lignende opstår der et noget mere kompliceret billede. Idet portlets er installeret på portalen, betyder det, at enten skal der også installeres databaser mv. på portalen eller disse portlets skal have lov til (eks. via JDBC) kunne kalde en database over netværk. På samme måde kan der være behov for at kalde andre services via web services eller andre metoder. Det betyder, at der i realiteten åbnes op for helt andre integrationsformer, som giver et langt mere kompliceret billede af, hvad der ligger på portal og hos myndighed og hvordan samspillet er herimellem.





Såfremt man måtte fravige princippet om en tynd portal og samtidigt etablerer en offentlig Serviceorientereret Infrastruktur med Web Service kataloger, offentlige service-busser mv. tegner der sig et mere positivt billede af at anvende JSR168 portlets, som installeres på portalen og udnytter en sådan offentlig service infrastruktur.

Performance og driftsmæssig tilgængelighed

Grundlæggende er der tale om et mindre ”rent snit” mellem serviceprovider og portal, idet JSR portlets installeres på portalen. Der er altså tale om at man udvikler kode ét sted og installerer et andet. Der er tillige tale om, at driften ligger på portalen, mens myndigheden bag fortsat må have det forretningsmæssige ansvar.

Rent performancemæssigt vil JSR portlets forventes at være bedre end Remote Portlets, eftersom der er tale om installeret kode og ikke et web service kald over netværk. Det er dog afgørende at der ikke blot flyttes netværkskald til et andet lag (hvis den installerede portlet herefter kalder services ”hjemme hos myndigheden” over netværk). Desuden spares SOAP/XML overhead’et også.

Øvrige erfaringer

Oracle Portal understøtter JSR168 via en WSRP indpakning. Det betyder at JSR168 portlets må forventes afviklet så WSRP begrænsningerne/ulemperne også er gældende for JSR på netop denne platform!

Opsummering: Fordele og ulemper ved denne integrationsform

Fordele +	Ulemper -
Giver en tæt visual integration med mulighed for at lave portalsider bestående af services fra forskellige myndigheder på en måde så de fremstår sammenhængende Der er rigere mulighed for at opbygge sammenhængende applikationer og der er mulighed for inter-portlet integration (i modsætning til WSRP) Performance er bedre end for Remote Portlets (under forudsætning af at man ikke flytter en række netværkskald fordi portleten er afhængig af andre services)	Ikke platformsuafhængighed. JSR portlets er kun en java standard. Det er ikke en platformsuafhængig standard som også Microsoft og andre understøtter Portlets skal installeres på portalen og kan give udfordringer med at arbejde på tværs af platforme, fordi de er udviklet et sted og afhænger af den infrastruktur der var tilstede under udvikling Kald af back end og legacy er problematisk, fordi der skal åbnes op fra portalen En SSO løsning baseret på SAML omfatter ikke kald af back end systemer (hvor disse måtte have behov for at kende slutbrugeren)

Noter

1 Der findes open source implementeringer, men disse er ikke afprøvet i PoC sammenhæng.
2 I HTML kan angives en attribut class som er bestemmende for hvilken style et HTML element vises med (Eks.: <div class=”portlet-font” …>abc</div>)
3 I HTML kan angives en attribut class som er bestemmende for hvilken style et HTML element vises med (Eks.: <div class=”portlet-font” …>abc</div>)