Den Fællesoffentlige Integrationsmodel for Borgerportalen og Virksomhedsportalen

StartSide :: Integrationsmodellen :: Afprøvninger :: Ressourcer :: Kontakt :: Login/Registrering

Bilag B Kommende integrationsformer


Dette bilag beskriver integrationsformer, som potentielt kan indgå som anbefalet i en senere version af integrationsmodellen. Der vil løbende blive opsamlet information om potentielle integrationsformer, eksempelvis via oim.modernisering.dk eller portalejernes fortsatte arbejde med at udvikle de to portaler. En potentiel integrationsform skal som udgangspunkt være i overensstemmelse med integrationsmodellens generelle principper (se afsnit 2.3) for at blive taget op til overvejelse. Der er således tale om integrationsformer, som ikke umiddelbart skal anvendes af serviceudbyderne.

Integrationsformen WSRP indgår i denne kategori i den aktuelle version af integrationsmodellen, idet der har været arbejdet med at udarbejde retningslinier for WSRP. Disse retningslinier inkluderes i dette bilag til orientering, men ikke til anvendelse ved integration af portalservices i en af de to portaler på nuværende tidspunkt

Analyser udarbejdet undervejs af IT- og Telestyrelsen har afdækket tekniske problemstillinger i forbindelse med implementering af Single Sign On. Der er på nuværende tidspunkt ikke en løsning herpå, som gør det forsvarligt at anbefale integrationsformen til generel anvendelse. At finde en løsning på disse problemstillinger vil indgå i det fortsatte arbejde med integrationsmodellen, herunder et kommende Proof of Concept projekt.


B.1 Retningslinier for integrationsformen WSRP (kommende)

Web Service Remote Portlets (WSRP) er en platformuafhængig teknologi til at stille portalservices fra et it-system (hos serviceudbyderen), til rådighed på en portal via web service mekanismer. Integrationsmodellen definerer retningslinier for brugen af WSRP på portalen, der supplerer og præciserer specifikationerne for standarden [WSRP10] og [WSRP20].

WSRP findes i skrivende stund i to versioner, 1.0 og 2.0 og Integrationsmodellen er gældende for begge. WSRP 2.0 specifikationen er dog ikke for nuværende endeligt godkendt af OASIS, og en serviceudbyder må derfor ikke antage at portalen understøtter denne teknologi. Hvis en serviceudbyder finder det nødvendigt at anvende WSRP 2.0, skal det aftales med den specifikke portal, hvor vidt dette er muligt og hvordan.

Hvor intet andet er anført kan det antages at en retningslinje gælder for både WSRP 1.0 og 2.0.

I dette bilag anvendes termen ”portlet” specifikt om WSRP-baserede portalservices.

En portal kan specificere yderligere retningslinjer, der supplerer integrationsmodellens anvisninger og som i givet fald skal overholdes.

B.1.1 Integration af portalservice i portalen


B.1.1.1 Registrering af portalservice


Beskrivelse

Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol

Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.

Tips og begrænsninger

Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.

Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:

**Oplysning** **Anvendelse**
Servicenavn Navn på portalservice
Ejer Navn på den organisation der ejer servicen
Kontaktinfo Kontaktinformation til den organisation der ejer servicen
Beskrivelse Tekstuel beskrivelse
Aktiv status Indikation af om portalservicen er aktiv/inaktiv
Præsentationsnavn Til titel, overskrift, lister osv.
Kort præsentationsnavn Til alternativ tekst, bla.
Kort beskrivende tekst Til præsentation af søgeresultater
Afsender logo Til illustration af afsenderen i forbindelse med præsentation af servicen
Afsender navn Til alternativ tekst i forbindelse med logo
Type Typen af service: webside, pdf, doc, etc.
Integrationsmetode Link, iFrame, WSRP
Emnetype Præsentation og søgning af service ud fra type
Emnekategori Præsentation og søgning af service ud fra kategori
Liste af emneord Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki
Stikord Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.
URL URL til portalservicen
Alternativ URL Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.
Fejlside URL URL til fejlside, hvis portalservicen ikke er tilgængelig
Side titel Titel på side hvor portalservicen indgår
Dynamiske parametre Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk
Brugergruppe Adgangskrav - udtrykt i en rolle-klassifikation styret af portalen


Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

En WSRP baseret portalservice definerer sin snitflade via en WSDL, der bl.a. indeholder operationer til at hente metadata om de portlets der er tilgængelige. Den centrale struktur til dette er ServiceDescription, som portalen kan hente via GetServiceDescription operationen.

For at kunne installere en WSRP portlet skal en portal udstyres med (i hvert fald) følgende tekniske information:


Portalen kan derpå gennem kald til ServiceDescription interfacet få fat i information om de portlets der udstilles hos serviceudbyderen.

Retningslinier

  1. Portalservicen skal tilmeldes til en portal, førend den bliver tilgængelig.
  2. Portalservicen skal stille en URL til rådighed for portalen, på hvilken WSRP operationer kan kaldes.
  3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
  4. Logo skal have en fast størrelse.

Referencer



B.1.1.2 Interaktion med portalen


Beskrivelse

En portalservice der er integreret ind i portalen via WSRP vil optræde i portalen i følgende situationer:


I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:


En portalservice, der bliver integreret via WSRP er ikke direkte i interaktion med portalindholdet på resten af siden. Dette betyder i praksis at portalen som udgangspunkt ikke indstiller det øvrige indhold på siden efter hvad der vises i portalservicens område af siden.

Hvis portalservicen ønsker et sådan sammenspil, kan måden at facilitere dette på være, at portalservicen initierer at hele portalsiden reloades gennem brug af alias samt ekstra parametre som hovedvindue og portalservice kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.

Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicen:

 Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En WSRP portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP.

Retningslinier

  1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer.
  2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
  3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
  4. Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside.
  5. Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
  6. Links til sites udenfor portalen skal åbnes i et nyt vindue.
  7. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS

Referencer



B.1.2 Visuel Integration


B.1.2.1 Applets


Beskrivelse

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.

Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.

Tips og begrænsninger

WSRP portlets kan ikke garanteres en fast bredde og højde, men udelukkende modtage ”hints” om hvor stor den plads de har til rådighed er. Da en applet netop har en fast højde og bredde, kan dette give udfordringer i forhold til brugeroplevelsen.

Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.

Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalen som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.

Retningslinier

  1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
  2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
  3. Java Applets skal kunne afvikles på JDK 1.4.
  4. Shockwave Flash Applets skal kunne afvikles på version 8.

Referencer



B.1.2.2 Cookies


Beskrivelse

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.

Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.

Tips og begrænsninger

En WSRP portalservice kommunikerer aldrig direkte med slutbrugeren, idet al markup medieres via portalen. Portalen kan have en session med serviceudbyderen og brugerens browser kan have en session med portalen.

Det betyder at evt. cookies der leveres tilbage til portalen fra serviceudbyderen sammen med portlet markup eksplicit håndteres af portalen: det er portalens ansvar at associere disse cookies med den aktuelle bruger og sørge for at sende dem med til serviceudbyderen næste gang brugeren forårsager en portletinteraktion. Dette muliggør at en serviceudbyder alligevel kan udnytte cookies til at håndtere f.eks. load balancing uagtet at de aldrig kommer helt ud til browseren

I WSRP leveres serviceudbyderens cookies aldrig helt ud til brugerens browser. Rationalet bag denne beslutning er at cookies altid er associerede med et domæne og at browseren kun vil benytte cookies der kommer fra det domæne den kommunikerer med, dvs. portalens.

Hvis cookies fra en serviceudbyder skulle helt ud til browseren ville en portalserver skulle genskrive domænet for cookies, hvilket potentielt ville kunne føre til kollisioner mellem forskellige serviceudbydere. Denne mulighed er derfor fravalgt i specifikationen. Figuren nedenfor illustrerer hvilke cookies der kan sendes mellem hvilke parter.

Cookies

Der findes to slags cookies: persistente og transiente. Persistente cookies lagres normalt på brugerens harddisk i browserens cookie-cache og disse er udstyret med en udløbsdato. Så længe cookien er indenfor sidste udløbsdato vil browseren medsende den i alle kald til det domæne cookien vedrører. Transiente cookies lever kun så længe browseren er åbnet og gemmes ikke på brugerens disk.

WSRP specifikationen adresserer ikke eksplicit persistente og transiente cookies, så det kan ikke generelt antages at portalen vil gemme cookies længere end portletternes levetid. Det anbefales derfor serviceudbydere ikke at designe portalservices så der kræves persistente cookies.

Retningslinier

  1. Cookies kan anvendes efter behov med de begrænsninger der ligger i WSRP specifikationen.
  2. Persistente cookies bør ikke anvendes.

Eksempler

Eksemplet nedenfor viser lidt af en HTTP header sendt fra server til klient. Headeren indeholder en cookie ”landekode” med værdi ”dk”, som er gyldig for ”/”, dvs. hele sitet. Cookien har ikke nogen ”expires” værdi og er derfor transient.

Content-type: text/html
Set-Cookie: landekode=dk; path=/;


Referencer



B.1.2.3 Fejlmeddelelser og fejlhåndtering


Beskrivelse

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.

Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til portalservicer, etc.

Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalsiden, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.

Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.

Tips og begrænsninger

Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.

Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.

Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.

Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalen udnytter denne klasse i sammenhæng med andre visuelle retningslinier til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.

Retningslinier

  1. Serviceudbydere skal fange applikationsfejl og vise fejltekster.
  2. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
  3. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
  4. Fejltekster skal overholde portalens styling guidelines fra designguiden vedr. præsentation af fejl.
  5. Portalen skal håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

Referencer



B.1.2.4 Globalisering: Internationalisering og Lokalisering


Beskrivelse

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikre at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.

En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger

Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.

Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

Retningslinier

  1. Serviceudbydere kan udvikle portletter med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet.
  2. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

Referencer



B.1.2.5 Hjælpetekster – online hjælp


Beskrivelse

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.

Tips og begrænsninger

Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges. Hvis en portalservice stiller hjælpefunktionalitet til rådighed, benyttes portalens styling relateret til hjælpetekster og designmanualen følges i relation til udformning og navigation.

Vejledningen skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales af hjælpeteksten giver så præcis information i brugskonteksten som muligt.

WSRP specifikationen giver mulighed for at en portlet kan køre i ”wsrp:help” modus. Denne modus giver mulighed for at portletten selv kan præsentere en hjælpetekst efter eget behov. WSRP portlets skal benytte denne mekanisme til at give en hjælpevejledning.

En portlet kan tilbyde kontekstsensitiv information, så brugeren får oplysninger om det indhold, der netop nu vises på skærmen.

Retningslinier

  1. Serviceudbyderen bør implementere hjælpesider.
  2. Serviceudbyderen skal overholde portalens designguidelines for hjælpetekster.
  3. Hvis serviceudbyderen implementerer hjælpesider skal disse kunne aktiveres via ”wsrp:help” mode.
  4. Hjælpetekster skal som minimum beskrive portlettens formål og give en kort introduktion til dens virkemåde.
  5. Hjælpetekster bør tilbyde kontekstsensitiv information.
  6. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

Referencer


B.1.2.6 Informative meddelelser


Beskrivelse

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.

Tips og begrænsninger

Hvis en WSRP baseret portalservice har brug for at vise en informativ tekst til slutbrugeren, er det portalservicen selv der danner markup. Integrationsmodellen definerer i [OIMCSS] CSS klasser til brug ved rendering af informativ tekst, som bruges i disse situationer efter portalens designguidelines.

Retningslinier

  1. Serviceudbyders portlets skal selv rendere informative meddelelser som WSRP markup
  2. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
  3. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

Referencer



B.1.2.7 Javascript


Beskrivelse

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.

Tips og begrænsninger

I Javascript indtræder alle variable og funktioner i samme globale namespace. Det betyder, at Javascript fra en portlet kan komme i konflikt med en anden portlets kode. Denne problemstilling kan undgås ved at sikre, at alle variable og funktioner i det globale scope præfikses med et namespace. WSRP tillader enten at tildelingen af et unikt namespace sker på portalen eller hos serviceudbyderen.

Hvis namespace tildelingen sker på portalen, præfikser serviceudbyderen variable og funktioner med ”WSRP_rewrite_” og portalen vil så erstatte alle forekomster af denne tekst med et unikt namespace præfiks (se eksempel). Alternativt kan serviceudbyderen selv hente namespace præfiks fra RuntimeContext elementet og generere unikt scriptkode.

En række 3.parts biblioteker giver mulighed for at implementere avanceret funktionalitet som f.eks. Asynchronous Java and XML (AJAX), hvor browserklienten henter XML data i baggrunden og dynamisk opdaterer grænsefladen. Grundet problemerne med scope af variable og funktioner vil 3.parts biblioteker være lige så udsatte for konflikter som anden Javascript kode og igen kan problemet potentielt afhjælpes med namespacing. Dette vil dog forudsætte at man ændrer i bibliotekets kode.

Når Javascript inlines i et element er det ikke nødvendigt at sætte et namespace præfiks på koden, idet scope ikke rækker ud over elementet (se eksempel).

Hvis en portlet har brug for at hente ressourcedata som billeder, XML, film, etc. ud på browseren benyttes såkaldte ressource-URL’er. En sådan URL linker stadig til portalen, som viderestiller kaldet til serviceudbyderen, men portalen vil – i modsætning til når der hentes markup fra portletten – returnere de modtagne data direkte tilbage til browseren. WSRP 1.0 understøtter ikke direkte AJAX kommunikation, men en løsning kan implementeres ved at anvende ressource-URL’er.

Retningslinier

  1. Serviceudbyder kan bruge direkte inlinet Javascript f.eks. i event handlers uden at præfikse med et namespace.
  2. Alle variable og funktioner i Javascript skal præfikses med et unikt namespace, som tildeles af portalen.
  3. Præfiks med namespace kan ske på portalen eller hos serviceudbyderen.
  4. En portlet må ikke introducere javascript i body onload-handleren
  5. Brug af eksterne biblioteker skal aftales med portalejeren.

Eksempler

Inlinet Javascript på et billedes ”onload” handler 

<img src=”..” onload=”javascript:alert(’billede loadet’)” />


I eksemplet nedenfor vises indlejret Javascriptkode, hvor lokale variable og metoder er præfiksede med WSRP_rewrite_, der sørger for at portalen gør koden unik inden det når brugerens browser:

<script language="javascript">
  WSRP_rewrite_text = "test";

  function WSRP_rewrite_test() {
	alert(WSRP_rewrite_text);
  }
</script>
<img onClick="javascript:WSRP_rewrite_test()" src="myimage.jpg"/>


Referencer



B.1.2.8 Links


Beskrivelse

Portalservices kan anvende links til forskellige former for navigation:


Tips og begrænsninger

Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen, så længe alias ikke slettes og stadig har samme logiske indhold.

Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.

Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame og WSRP) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

Serviceudbyderen har ansvaret for at sikre, at links til andre portalsider og eksterne websites er valide.

Portletspecifikationerne (se [WSRP10] og [WSRP20], begge afsnit 10.2) definerer to alternative mekanismer for hvordan portlets kan angive links til indhold i portalen. I den ene variant skriver serviceudbyderne alle links med teksten ”wsrp_rewrite” foran (se eksempel) og lader portalen erstatte teksten med et link tilbage til portalen, der så igen stiller videre til den rigtige portlet. I den anden variant skriver producenten selv den fulde URL baseret på skabeloner (”templates”) den har modtaget fra portalen i et WSRP kald. Begge modeller er tilladt i WSRP og ligeledes i Integrationsmodellen.

Retningslinier

  1. Alle links til portalservicen selv skal benytte WSRPs mekanismer ”wsrp_rewrite” eller ”templates”.
  2. Links til andre sider på portalen skal benytte portalens alias mekanisme hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.

Eksempler

Link til samme portlet, renderet med wsrp_rewrite, der beder portalen om at gentegne portletten men nu i ”help” mode.

<a href=”wsrp_rewrite?wsrp-urlType=render&wsrp-mode=help&wsrp- 
windowState=maximized/wsrp_rewrite”>Hjælp</a>


Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_top”>


Eksempler på alias links

http://portal.dk/alias?alias=forside
http://portal.dk/alias?alias=myndighedsoversigt
http://portal.dk/alias?alias=avanceret_søgning
http://portal.dk/alias?alias=vejviser
http://portal.dk/artikel?id=123123
http://portal.dk/service?id=4719


Referencer



B.1.2.9 Markup


Beskrivelse

En serviceudbyder kan potentielt levere mange forskellige typer af markup, HTML, XHTML, WML, etc. tilbage til portalen og i forskellige versioner.

Integrationsmodellen behandler udelukkende HTML og XHTML, men udelukker ikke at brugen af andre markuptyper kan aftales med portalejeren i et konkret brugsscenario f.eks. til særlige sider der skal kunne vises på andre terminaltyper.

Tips og begrænsninger

Portalen anvender selv HTML version 4.01 og da WSRP portlets indlejres i portalens markup inden det sendes til serviceudbyderen, er det derfor det format som indhold skal leveres i.

Browsere blev fra starten designet til at være optimistiske i fortolkningen af den markup der blev leveret fra et website og forsøge at vise HTML uanset om der manglede et eller flere påkrævede elementer. De fleste browsere vil f.eks. kunne vise en side, der ikke har et <BODY> element eller mangler et slut </UL> tag uden problemer. Desværre er der også tilfælde, hvor en browser ikke let kan gætte rigtigt, f.eks. hvis der mangler en slutangivelse af et link </A>, for hvor stopper linket så? Det er derfor et krav at HTML er wellformed (så vidt det er muligt).

Det bemærkes, at WSRP specifikationen udpeger visse HTML elementer som ugyldige i portlet markup, herunder <BODY>, <HTML> og <HEAD>. Kravet om at overholde specifikationerne gælder således fraregnet disse undtagelser.

Retningslinier

  1. En serviceudbyder kan bruge HTML uden aftale med portalen.
  2. En serviceudbyder må ikke som udgangspunkt bruge andre markup typer f.eks. WML eller XHTML. Undtagelser kan aftales med portalen, hvis indhold skal leveres til andre terminaltyper.
  3. HTML må ikke indeholde tags, som er ulovlige ifølge WSRP specifikationerne.

Eksempler

Valid HTML

<html><body><img src=”image”><br></body></html>


Referencer


B.1.2.10 Navigation og dialogforløb


Beskrivelse

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.

Tips og begrænsninger

Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).

Navigation indenfor en WSRP portalservice, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.

Retningslinier

  1. Navigation indenfor en WSRP portalservice skal ske i rammerne af en specifik portalside, der fastholdes
  2. Dialogforløb i en WSRP portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades.

Referencer



B.1.2.11 Styling


Beskrivelse

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.

Tips og begrænsninger

WSRP definerer et sæt style sheet klasser og angiver hvordan de skal bruges i portlet layouts. Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen, som findes i et separat dokument (se [OIMCSS]).

Integrationsmodellens style sheet klasser i [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.

Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.

Style sheets i eksterne filer refereres via elementet <LINK>, der ifølge HTML specifikationen udelukkende må forekomme i <HEAD> elementer. Tilsvarende kan style sheets indlejres i HTML via <STYLE> elementet, igen placeret i headeren. WSRP portlets har imidlertid ikke mulighed for umiddelbart at påvirke headeren af den HTML side i hvilken de optræder. Hvis en portlet derfor har brug for andre styles end de prædefinerede, skal disse - i modsætning til gængs HTML praksis – inlines direkte i markup (se eksempel).

Retningslinier

  1. Integrationsmodellens style sheet klasserne skal anvendes til styling.
  2. Portalens design guidelines for hvordan style sheet klasserne fortolkes skal anvendes
  3. Serviceudbyder kan bruge egne style sheets efter aftale med portalejeren.
  4. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.
  5. Serviceudbyderes egne styles skal indlejres direkte i markup og kan ikke linkes eksternt fra.

Eksempler

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<div class="portlet-font">Vigtig information</div>


Inlining af egen style i HTML

<p style="background: blue; color: white;">Hvid på blå baggrund</p>


Referencer


B.1.2.12 Søgning


Beskrivelse

Der er 3 primære navigationsveje til en portalservice via portalen:

  1. Links i redaktionelt indhold.
  2. Dynamisk liste af portalservices angivet på en konkret portalside.
  3. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

Tips og begrænsninger

Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.

Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.

I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.

Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.

Retningslinier

  1. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

Referencer



B.1.2.13 Tegnsæt


Beskrivelse

Portalens markup overholder et givet tegnsæt, som fortolkes af browseren. Det er vigtigt at samme tegnsæt benyttes af portalservices for at sikre, at alle tegn vises korrekt for brugeren.
Tips og begrænsninger

WSRP specifikationen tillader både 8-bit (UTF-8) og 16-bit (UTF-16) Unicode tegnsæt til at kode tekst i, men portalen standardiserer på UTF-8 der allerede i dag anvendes af portalen.

Retningslinier

  1. Al markup skal leveres i UTF-8

Referencer



B.1.2.14 Tilgængelighed


Beskrivelse

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke blev forudset på det tidspunkt websitet blev designet. I alle tilfælde vil et omhyggeligt og hensigtsmæssigt design kunne gøre websitet tilgængeligt.

Tips og begrænsninger

IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).

WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.

En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

Retningslinier

  1. Portalservices bør levere markup på WAI niveau AA.

Eksempler

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:

<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">


Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:

<OBJECT classid="java:Counter.class" width="200" height="200">
  Java Applet, der viser antal udfyldte formularer …
</OBJECT>


Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.


Referencer



B.1.2.15 Upload og download af indhold


Beskrivelse

En serviceudbyder kan have behov for at afspille film eller lyd for brugeren, modtage filer via upload eller tillade download af dokumenter og lignende.

Tips og begrænsninger

Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.

En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

I et WSRP scenarium kræves der anvendelse af ressource-URL’er for at sikre at portalen stiller videre til den ønskede information.

Retningslinier

  1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
  2. Serviceudbyder skal selv lagre indhold til upload.
  3. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
  4. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

Referencer



B.1.3 Portlet Integration


B.1.3.1 Interportlet kommunikation


Beskrivelse

En portalside kan bestå af flere portletter, der potentielt udstilles af forskellige serviceudbydere. Til tider vil en sides portlets logisk udstille relateret funktionalitet og brugeren vil forvente en vis koordinering imellem portletterne.

En portal kunne f.eks. udstille en portlet til valg af region og en serviceudbyder kunne samtidig udstille en portlet, der viser ventetider på hospitaler i forskellige regioner. Når der vælges en ny region i den ene portlet vil brugeren forvente at ventetidsportletten tilsvarende vil skifte og vise information for den valgte region.

Dette kræver kommunikation mellem portlets.

Tips og begrænsninger

WSRP 1.0 giver ingen mekanismer til interportletkommunikation og udveksling af tilstand fra en portlet til en anden i kontekst af portalen (consumer side IPC). Når der er behov for aggregerede portalservices, koordineres disse af en serviceudbyder, hvis portlet så udstiller data fra flere myndigheder. Koordineringen sker med andre ord hos serviceudbyderen, ikke på portalen.

WSRP 1.0 giver mulighed for at et antal portlets kan grupperes vha. et correlation-id. Ved installation i portalen sættes dette id på de relevante portletter af portalens administrator efter serviceudbyderens anvisninger, og portalen vil så derpå medsende id’et ved hvert kald. På denne måde kan en serviceudbyder holde tilstanden på tværs af et sæt portletter i egen applikation. Denne mekanisme kendes også som ”producer side IPC”.

WSRP 2.0 udvider WSRP 1.0 ved at introducere hændelser, som tillader portlets i samme vindue at sende beskeder til hinanden på tværs af serviceudbydere. Specifikationen benytter samtidig denne mekanisme til at kommunikere tilstand mellem portlets.

Imidlertid kræver en sådan kommunikation at portletterne har samme forståelse af hvilke hændelser der kan forekomme – de skal være enige om navne og indhold i de events, der kan forekomme. WSRP 2.0 definerer kun 2 standard hændelser (se [WSRP20] sektion 6.11) som er helt generelle.

Når WSRP 2.0 bliver produktionsmoden kan der vise sig behov for at definere hændelser, som er specifikke for offentlig portalintegration i Danmark. Det er dog i skrivende stund uklart hvor vidt dette bliver relevant og integrationsmodellen definerer derfor ikke nogen ekstra hændelser.

Retningslinier

  1. WSRP 1.0 portlets kan indgå i producer-side IPC vha. correlation-id.
  2. WSRP 2.0 portlets kan indgå i både producer-side IPC og consumer-side IPC på tværs af serviceudbydere.

Referencer


B.1.4 Sikkerhed

WSRP specifikationen giver ingen retningslinjer for hvordan brugeridentitet flyttes mellem portal og serviceudbyder, men henviser til standardiseringsarbejdet omkring WS-Security og SAML. I en rapport fra IT- og Telestyrelsen [WSRPSEC] gennemgås en række mulige løsninger på udfordringen, men rapporten peger ikke på en klar kandidat til en taktisk profil, der med sikkerhed vil kunne implementeres bredt.

WSRP kan derfor ikke anvendes i et SSO scenarium og kan udelukkende benyttes til services, der ikke kræver sikkerhed. Er der behov for autentifikation, autorisation, mm. henvises til integrationsformerne Link og iFrame.

Der er en kommentar til denne side. [Vis kommentar]

Sidehistorik :: 2007-11-12 04:05:00 XML :: Ejer: KristianHjortMadsen :: Søg:
Valid XHTML 1.0 Transitional∞ :: Valid CSS∞ :: Powered by Wikka Wakka Wiki 1.1.6.3∞
Page was generated in 0.0707 seconds