Most recent edit on 2007-11-12 15:38:49 by WebMaster
Additions:
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 2 Retningslinier vedrørende integrationsformen IFrame m/ SSO
Bilag 3 Retningslinier vedrørende integrationsformen WSRP
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive håndteret af de enkelte portalservices eller tværgående løsninger (fx E&S’ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLA’er for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLA’er. Følgende emner vil indgå i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (”oppe”), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
Deletions:
ouacelt
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 2 Retningslinier vedrørende integrationsformen IFrame m/ SSO
Bilag 3 Retningslinier vedrørende integrationsformen WSRP
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive hÃ¥ndteret af de enkelte portalservices eller tværgÃ¥ende løsninger (fx E&Sâ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLAâer for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLAâer. Følgende emner vil indgÃ¥ i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (âoppeâ), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
Edited on 2007-11-12 05:00:36 by CvichIcvia
Additions:
ouacelt
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 2 Retningslinier vedrørende integrationsformen IFrame m/ SSO
Bilag 3 Retningslinier vedrørende integrationsformen WSRP
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive hÃ¥ndteret af de enkelte portalservices eller tværgÃ¥ende løsninger (fx E&Sâ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLAâer for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLAâer. Følgende emner vil indgÃ¥ i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (âoppeâ), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
Deletions:
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 2 Retningslinier vedrørende integrationsformen IFrame m/ SSO
Bilag 3 Retningslinier vedrørende integrationsformen WSRP
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive håndteret af de enkelte portalservices eller tværgående løsninger (fx E&S’ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLA’er for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLA’er. Følgende emner vil indgå i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (”oppe”), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
Oldest known version of this page was edited on 2007-09-02 05:44:07 by KristianHjortMadsen []
Page view:
Den Offentlige Integrationsmodel, OIM Version 0.5
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
Sikkerhed
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive håndteret af de enkelte portalservices eller tværgående løsninger (fx E&S’ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
Autorisation til dele af funktionaliteten og/eller dataudsnit i en portalservice
Visuelt design og navigation
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
Portalkontekst
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
SLA skabelon
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLA’er for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLA’er. Følgende emner vil indgå i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Planlagt nedetid / servicevinduer.
Angivelse af tidsintervaller hvor planlagt nedetid kan forekomme, omfanget af planlagt nedetid og varsler i forbindelse med planlagt nedetid.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (”oppe”), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
