Proof of Concept Web-tjenester (web services) i en tjenesteorientert arkitektur Understøttelse av "Fullverdig elektronisk verdikjede"

Transkript

1 Opprettet Saksnr. BKSAK Revidert: Saksbehandler: Steinar Carlsen Ansvarlig: Kjetil Århus - Leder Portalorganisasjon Delarkiv: Proof of Concept Web-tjenester (web services) i en tjenesteorientert arkitektur Understøttelse av "Fullverdig elektronisk verdikjede"

2 Endringslogg: Versjon Dato Endret av Berørte deler Kort beskrivelse av endring Steinar Carlsen Hele Opprettet dokument Steinar Carlsen Struktur Utarbeidet plan og disposisjon - avklart struktur for dokument Steinar Carlsen Hele Lagt til prosessbeskrivelse og interaksjonsdesign Steinar Carlsen Hele Lagt til tekniske beskrivelser Steinar Carlsen Hele Revidert hele dokumentet Steinar Carlsen Hele Mindre justeringer og klargjøring for revidering Kjetil Århus Hele Revidert Hele Versjon 1.0 godkjent Referanser: 01: Forprosjekt og prosjektrapport "Felles Arkitektur i Kommunal Sektor (FAKS) Side 2

3 Innholdsfortegnelse 1. INNLEDNING HENSIKTEN MED DOKUMENTET MÅLGRUPPER FOR DOKUMENTET BAKGRUNN FOR PROOF OF CONCEPT FUNKSJONELLE EGENSKAPER FULLVERDIG ELEKTRONISK VERDIKJEDE FOR INNBYGGERE, ORGANISASJONER OG NÆRINGSLIV BRUKSTILFELLE BRUKERDIALOG ELEKTRONISK VERDIKJEDE TEKNISK LØSNING REFERANSEARKITEKTUR - TJENESTEORIENTERT ARKITEKTUR BERGEN KOMMUNE OBJEKT/INFORMASJONSMODELL UTVIKLING AV WEB- OG INTEGRASJONSTJENESTER I EN TJENESTEORIENTERT ARKITEKTUR Definisjoner Tjenestebuss Bruken av web-tjenester i konseptet "fullverdig elektronisk verdikjede" Personservice Eiendomsserivce UTVIKLING OG DRIFT AV WEB- OG INTEGRASJONSTJENESTER Organisasjon Utviklings- test og produksjonsmiljø Videreutvikling og forvaltning av den tjenesteorienterte arkitekturen... 8 Side 3

4 1. Innledning 1.1 Hensikten med dokumentet Dette dokumentet beskriver hvordan web-tjenester (web services) er tatt i bruk i en tjenesteorientert arkitektur i Bergen kommune. I dokumentet er det tatt utgangspunkt i konseptet for "fullverdig elektronisk verdikjede for innbyggere" i Bergen kommune, der skjemaløsning er en sentral komponent i tillegg til den tjenesteorienterte arkitekturen. Dokumentet konkretiserer hvordan krav og behov identifisert i øvrige delprosjekter i Bergen kommunes Portalutviklingsprogram knyttet til "fullverdig elektronisk verdikjede" er realisert. Dokumentet skal bidra til å skape en felles forståelse av hvordan web- og integrasjonstjenester realiseres i en tjenesteorientert arkitektur i et samspill med andre komponenter. Eksempler på øvrige komponenter er: Påloggingsløsning (autentisering) med MinID Skjemaløsning Bergen kommune (Sem & Stenersen) Innbyggerportal Bergen kommune (Oracle Portal) Fagsystem - i dette dokumentet saks- og arkivsystemet (Doculive). Dokumentet inkludert eksempler på det arkitektur- og utviklingsrammeverket Bergen kommune benytter for sin tjenesteorienterte arkitektur. 1.2 Målgrupper for dokumentet Målgrupper for dokumentet er både de som har/beskriver de funksjonelle behovene i en organisasjon og de som skal utvikle løsninger i en tjenesteorientert arkitektur. Dokumentet kan også være nyttig å lese for interessenter i organisasjoner og prosjekter som ønsker nærmere informasjon om løsninger i en tjenesteorientert arkitektur. 1.3 Bakgrunn for Proof of Concept Som en del av forprosjekt for Felles Arkitektur i Kommunal Sektor (FAKS) ble det besluttet at det skulle utarbeides et Proof of Concept for en eller flere av web-tjenestene som er i produksjon i Bergen kommune. Hensikten er å dokumentere hvordan slike web-tjenester utvikles og benyttes i en tjenesteorientert arkitektur. Dokumentet beskriver ikke komponentene i den tjenesteorienterte arkitekturen da denne er beskrevet i egen analyse som del av forprosjekt Felles Arkitektur Kommunal Sektor (heretter i dette dokumentet benevnt FAKS-rapporten). Det er flere web-tjenester som inngår i konseptet som er beskrevet i dette dokumentet, men følgende to tjenester vil være mer detaljert beskrevet: Personservice Eiendomsservice Tjenestene er i produksjon og finnes på Side 4

5 2. Funksjonelle egenskaper 2.1 Fullverdig elektronisk verdikjede for innbyggere, organisasjoner og næringsliv Bergen kommune skal tilby fullverdige elektroniske tjenester og prosesser fra konsument (innbygger/organisasjoner/næringsliv) til saksbehandler (kommunal forvaltning) og beslutningstagere (kommunale og politiske beslutningstagere). De fleste prosesser som utføres i kommunen kan forankres mot et tjenestetilbud til enten konsumenter eller ansatte. Prosessene skal i mest mulig grad automatiseres og binde sammen de forskjellige rollene i kommunens tjenestetilbud. Skissen under illustrerer hvordan virksomhetsprosesser som understøtter elektroniske tjenester "flyter" horisontalt gjennom organisasjonen (byrådsavdelingene). Prosessene kan typisk ha behov for informasjon fra flere fagsystemer, og eventuelt også fra eksterne systemer/tjenester. Kompleksiteten i dette skjules i en integrasjonsarkitektur (tjenesteorientert). Prosessene kan involvere både konsumenter (innbyggere/næringsliv/lag/organisasjoner), saksbehandlere, beslutningstagere (både kommunale og politiske) og ansatte. Brukergrensesnittene (presentasjon) for prosessene kan være både Portal, Intranett og fagsystemer. Gevinster som søkes oppnådd er: Forenklet tilgang til kommunens tjenestetilbud (elektroniske tjenester, 24/7) Effektivisering i forvaltning og bruk av prosesser og fagsystemer Utnytte synergier på tvers av fagsystemer og redusere totalomfang av systemer (effektivisere anskaffelser og drift) Bedre datakvalitet og sikkerhet i fagsystemer. Side 5

6 For Bergen kommune som organisasjon vil en automatisering gi mulighet for bedre og raskere saksbehandling. Bedre saksbehandling kan realiseres ved at den kvalitet som blir levert fra skjema vil bli bedre ved at pre-utfylling og drop-down menyer siker riktig format og innhold på informasjonsfelter. I tillegg vil integrasjoner med BKSAK og fagsystemer frigjøre tid som i dag medgår til manuelt å flytte informasjon fra blant annet skjema inn i de respektive systemer. Ny tjenesteorientert arkitektur vil også gi bedre sikkerhet for de integrasjoner som blir utviklet og satt i produksjon, i tillegg vil det bli bedre mulighet for overvåking av de prosesser og tjenester som benytter den tjenesteorienterte arkitekturen. Arkitekturen gir videre mulighet for bedre samhandling med andre tjenesteleverandører, for eksempel andre kommuner eller offentlige etater. Samspillet skal tilstrebes ved at for eksempel felles tjenester i det offentlige Norge gjøres tilgjengelig eller integreres med kommunens egne tjenester (og vica versa). 2.2 Brukstilfelle Følgende brukstilfelle ligger til grunn for å vise stegene i "Fullverdig elektronisk verdikjede": En innbygger i Bergen kommune ønsker å søke om fartsdempende tiltak i sitt nærområde. Innbygger finner ønsket tjeneste (tjenestebeskrivelse) i tjenestekatalogen i innbyggerportalen. Bruker finner lenke til "Søknad om fartsdempende tiltak" i tjenestebeskrivelsen, og blir deretter bedt om å logge inn i Portal. Etter pålogging blir bruker bedt om å fylle inn skjema, for deretter å bli "loset" videre gjennom prosessen. 2.3 Brukerdialog elektronisk verdikjede Etterfølgende skjermbilder viser brukerdialog for ovennevnte brukstilfelle. Hvert skjermbilde/ brukerdialog er nummerert (figur x), slik at det senere i dokumentet (teknisk beskrivelse) er henvist til skjermbilder for å forklare hvordan web-tjenestene i den tjenesteorientert arkitekturen benyttes (og hvilke resultater de gir). Figur 1:Overordnet skisse for sammenheng konsument, pålogging, presentasjonslag og knytning til fagsystemer og eventuelt eksterne tjenester 1) 1) Utvikling av integrasjon og påloggingsmekanisme med AltInn er startet men ikke ferdigstilt. Side 6

7 Figur 2:Bruker velger aktuelt skjema fra tjenestebeskrivelse i Portalløsning - i dette tilfellet skjema for søknad om "fartsdempende tiltak". Figur 3: Bruker møter orientering om personvern før skjemaet åpnes Side 7

8 Figur 4: Ikke innlogget bruker må logge inn med MinID: fødselsnummer og passord (innlogget bruker kommer til første side i skjema) Figur 5: Bruker benytter engangskode enten fra SMS eller fra tilsendte PIN-koder Side 8

9 Figur 6: Personalia i skjema vil bli pre-utfylt med data fra Bergen kommunes Master Data Management system (henter data bl.a. fra Folkeregisteret/Postens adresseregister 2 ) Opplysninger om eiendommer blir pre-utfylt basert på data fra Matrikkelsystemet. 2) Pt kun bosatte i Bergen kommune ihht Folkeregisteret. Figur 7: Skjema kan lagres før innsending Side 9

10 Figur 8: Logg inn på DinSide for å finne ikke innsendt ( mellomlagret ) skjema Figur 9: Fyll inn resterende opplysninger send inn (eventuelt med utskrift før innsending) Side 10

11 Figur 10: Innsendt skjema overføres umiddelbart til DinSide og kan leses/skrives ut. Kvittering sendes til bruker som e-post dersom bruker har oppgitt e-postadresse i skjema Figur 11: Kopi av skjemaet (pdf) kan skrives ut Side 11

12 Figur 12: Arkivopplysninger (tittel, søker, adresse mv) eksporteres automatisk til BKSAK (Doculive) (pt ikke eksport av fagspesifikke data) Figur 13: Sak opprettet i BKSAK blir tilgjengelig i DinSide i Portal påfølgende dag under Samlet oversikt Side 12

13 Figur 14: Melding om at nytt dokument i sak er tilgjengelig i Meldingsboks (norge.no) sendes pr SMS/epost parallelt med at dokumentet blir tilgjengelig i DinSide 3 ref. figur 15 3) Se figur 17 for andre måter å varsle/sende dokument Figur 15: Velg ønsket melding og dokumentdetaljer vil vises. Pt kun varsel om nytt dokument på MinSide (norge.no). Ny funksjonalitet gir mulighet til å åpne dokumentet i meldingsboksen eller følge lenke til sak i DinSide (Portal Bergen kommune). Side 13

14 Figur 16: Følg lenke i meldingsboks (pkt 14) eller klikk på sak under Samlet oversikt (pkt 12) - åpner saken med dokumenter som kan leses/skrives ut Figur 17: Dokumenter i saken kan åpnes og skrives ut Side 14

15 Figur 18: Kontrollrutine for å sikre at bruker enten leser melding i meldingsboksen eller mottar dokumentet i posten Som fagsystem i Bergen kommune ønsker "jeg" å kunne sende svarbrev til en innbygger elektronisk. Dersom innbyggeren ikke leser svarbrevet innen syv dager, skal brevet skrives ut på papir automatisk. Deretter må noen postlegge brevet. Mål: - redusere kostnader ved å sende færre dokumenter i posten - øke bruken av portalløsningen - lette saksbehandlers arbeid ved at han ikke trenger å ta hensyn til om bruker har registrert seg hos norge.no eller ikke - håndtere 7-dagersregelen automatisk 1. Avsendersystemet sender en pdf, en meldingstekst, innbyggerens postadresse og fødselsnummer til systemet 2. Systemet lagrer pdf på disk 3. Systemet sender meldingsteksten til innbyggerens meldingsboks MinSide (norge.no) med lenke for nedlasting av dokumentet 4. Brukeren leser meldingen 5. Brukeren åpner lenken 6. Systemet streamer pdf til brukerens nettleser 7. Systemet noterer at meldingen er lest 8. Systemet sletter pdf etter en måned Unntak (referanse til ovennevnte punkter): 3a. Brukeren har ikke meldingsboks hos MinSide (norge.no), men har oppgitt e- postadresse (I) Systemet sender meldingsteksten til innbyggerens e-postadresse i MinSide (norge.no) med lenke for nedlasting av dokumentet (II) Fortsett fra 4 3b. Brukeren har ikke meldingsboks hos MinSide (norge.no), og har ikke oppgitt e-postadresse (I) Systemet skriver ut meldingen på brevpapir og konvolutterer (II) Systemet noterer at meldingen er skrevet ut (III) Fortsett fra 8 5. Brukeren åpner ikke lenken innen 7 dager (I) Systemet skriver ut meldingen på brevpapir og konvolutterer (II) Systemet noterer at meldingen er skrevet ut (III) Fortsett fra 8 7. Avsendersystemet er BKSAK (I) Systemet produserer et kvitteringsdokument som inneholder tidspunkt brukeren leste dokumentet (II) Systemet arkiverer kvitteringsdokumentet som ny journalpost på saken i BKSAK Side 15

16 Figur 19: Saken knyttes til evt sakgangsmal sikrer korrekt fremgangsmåte og dokumentasjon (illustrasjonsbilde) Figur 20: Dokumenter i saken utarbeides i fagsystem og merkes for å gjøres tilgjengelige i DinSide (portal) og meldingsboks (norge.no) (ref figur 13,14, 15) Side 16

17 Figur 21: Bruker kan legge kommentarer direkte på sak (ref figur 15) ved hjelp av skjema med preutfylt saksnummer og tittel. Kommentaren vises som inngående dokument i saken. Side 17

18 3. Teknisk løsning Den tekniske løsningen for "fullverdig digital verdikjede" for innbyggere er logisk delt inn i følgende hoveddeler: 1. Samhandling Portal Bergen kommune, MinId (pålogging norge.no), løsning for tjenesteorientert arkitektur og skjemaløsning (Sem & Stenersen) 2. Preutfylling og drop-down menyer av skjema 3. Automatisert overføring av skjema til fagsystemer (i dette dokumentet BKSAK) og/eller saksbehandler 4. Kvittering til postkasse minside (norge.no) og til bruker (e-post) 5. Samhandling norge.no - lenketjeneste og meldingstjeneste. For å beskrive de elementer som er viktig i forhold til Proof of Consept vil de videre tekniske beskrivelsene være konsentrert rundt den tjenesteorientert arkitekturen og beskrivelse av to av de sentrale web-tjenestene som understøtter den "fullverdige digitale verdikjeden". Som en del av anskaffelsen av en tjenesteorientert arkitektur ønsket Bergen kommune støtte til innføring av arkitekturen og komponentene. Referansearkitekturen som er beskrevet i punkt 3.1 er derfor fremkommet som en del av et innøringsprosjekt i samarbeid med leverandør (Integrate AS). Komponentene som er valgt for å understøtte denne arkitekturen er beskrevet som del av analysen i Felles Arkitektur i Kommunal Sektor (FAKS). Disse komponentene vil derfor ikke være nærmere beskrevet i dette dokumentet. Det er også viktig å bemerke seg at de web-tjenester som er beskrevet i dette dokumentet ikke krever alle de komponenter som Bergen kommune har anskaffet. Muligheten for å innføre en tjenesteorientert arkitektur med færre komponenter er beskrevet som skalerbarhet i FAKS rapporten. De tekniske beskrivelsene i dette dokumentet har ikke som målsetting å beskrive alle forhold knyttet til utvikling av web-tjenester og bruk av en tjenesteorientert arkitektur, men peke på sentrale områder i arkitekturen og hvordan to typiske web-tjenester er utviklet og hvordan de benyttes. 3.1 Referansearkitektur - tjenesteorientert arkitektur Bergen kommune Arkitekturmodeller har tradisjonelt forsøkt å lagdele modellene, for eksempel ved å skille fysisk datamodell, funksjonalitet og brukergrensesnitt. Å introdusere en tjenestebuss og tjenester kan ved første øyekast se ut til å introdusere en flatere struktur. Likevel, selv om tjenestebussen innføres for å rute kommunikasjon mellom forskjellige systemer, og teknisk sett kan la alle prate med alle, så er en slik ustrukturert kommunikasjon vanligvis ikke en god ide. Figuren nedenfor viser en lagdelt referansearkitektur for en SOA løsning. Nederst på figuren finner vi systemene som tilbyr (tilbyder/provider) funksjonalitet og informasjon, mens vi øverst på figuren finner systemene som bruker (konsument) denne funksjonaliteten eller informasjonen. Merk at figuren viser arkitekturlag, noe som innebærer at hvert lag i sin implementering kan være ytterligere lagdelt.

19 Enterprise Application Architecture: I det nederste laget finner vi alle grunnsystemene til en organisasjon. Disse systemene må tilby grunntjenester for de overliggende lagene enten direkte fra grunnsystemet eller ved hjelp av adaptere hvis grunnsystemet ikke kan endres. Systemene i dette laget kalles derfor tilbydere (providers). Eksempler på tjenester fra dette laget er uthenting eller oppdatering av informasjon fra et system, f.eks hent adresse eller oppdater adresse for en person i system x. Integration Architecture: Integrasjonslaget tilbyr forretningstjenester uavhengig av grensene mellom underliggende systemer. Tjenestene på dette laget er typisk kortvarige (synkrone). Eksempler på tjenester fra dette laget er uthenting eller oppdatering av informasjon på tvers av underliggende systemer, f.eks endre adresse for en person pga. flytting. Integrasjonslaget vil så påta seg ansvaret for å oppdatere adressen i alle underliggende tjenester vha. tjenester fra laget under. Process Architecture: Prosesslaget tilbyr tjenester som går hånd i hånd med prosessene til en organisasjon. Tjenestene på dette laget er typisk langvarige (asynkrone). Eksempler på tjenester på dette laget kan være søknadsprosesser fra innsending av søknad til godkjenning, eller bestillings- og leveranseprosesser. Delivery Architecture: I det øverste laget finner vi systemene som opptrer som konsumenter (consumers) av tjenestene i lagene under. Typiske eksempler på systemer i dette laget er portaler og andre brukergrensesnitt. Merk at et system som både tilbyr grunntjenester og bruker grunntjenester fra andre vil opptre i både det nederste og øverste laget som henholdsvis tilbyder (provider) og konsument (consumer). I tillegg de horisontale lagene beskrevet over, finnes det problemstillinger som ikke kan isoleres til et horisontalt lag, disse problemstillingene er illustrert ved hjelp av vertikale lag: Side 19

20 Information Architecture: Grunnsystemene i en stor organisasjon har oftest svært forskjellige datamodeller, det samme vil gjelde for potensielle konsumenter av tjenester fra grunnsystemene. Å endre datamodellene for disse systemene slik at de samsvarer med hverandre er oftest umulig. I de midterste lagene derimot er vi helt avhengig av å ha en felles objektmodell: En slik felles objektmodell muliggjør informasjonsflyt mellom tilbydere og konsumenter av tjenester uavhengig av hvilken datamodell tilbyderen og konsumenten benytter internt. Konvertering til og fra den felles objektmodellen vil typisk bli gjort av tjenestebussen. Hvis nye systemer utvikles i Enterprise Application eller Delivery Application laget bør den interne datamodellen til systemet legges så tett opp til den felles objektmodellen som mulig. Security Architecture: En felles sikkerhetsarkitektur må sikre at kun autoriserte konsumenter får tilgang til tjenester og at tjenestene kun kan brukes på data sluttbrukeren skal ha tilgang til. Hvis sluttbrukeren f. eks er utenfor organisasjonen vil det typisk bety at han skal ha tilgang til data om seg selv. Governance Architecture: Løsningen må ha en felles styringsmodell. Styringsmodellen må blant anmnet ha regler for hvordan endringer i tjenester eller i den felles objektmodellen skal utføres. Typisk vil man innføre versjonering av tjenester og felles objektmodell, der de n-siste versjonene støttes, slik at brukerne av tjenestene vil ha tid til å tilpasse seg endringer. 3.2 Objekt/informasjonsmodell Viktigheten av en objekt- /informasjonsmodell er beskrevet i FAKS rapporten. Overordnet designmål i Bergen kommune er å ha en stabil felles objektmodell, da modellen er utgangspunkt for alle tjenestene i den tjenesteorienterte arkitekturen. Følgende er en del av arkitekturprinsippene i Bergen kommune: Felles objektmodell må utvikles inkrementelt, slik at man utvikler objekt modellen synkront med de områdene man tar i bruk den tjenesteorienterte arkitekturen. Felles objektmodell må vedlikeholdes manuelt: o XSDL brukes som filformat, XMLSPY brukes som verktøy for redigering og Subversion brukes for versjonskontroll. Antall versjoner som støttes av løsningen må begrenses. Etter hvert som nye versjoner av objektmodellen innføres må den eldste støttede versjonen fases ut. Mapping mellom felles objektmodell og applikasjonsspesifikk objektmodell gjøres i tjenestebussen (Mule). For å sikre løs kobling må 1-1 mapping gjøres i de tilfellene der felles objektmodell og applikasjonsspesifikk objektmodell er like. 3.3 Utvikling av web- og integrasjonstjenester i en tjenesteorientert arkitektur Som en del av innføringsprosjektet for den tjenesteorienterte arkitekturen ble det i tillegg til rammeverk ("best practice") for arkitektur og arkitekturprinsipper også etablert et rammeverk for utvikling av tjenester. Rammeverket består av følgende hoveddeler: Utviklingsprinsipper Utviklingssystemer Navnestandarder Rammeverket har som hensikt å sørge for en ensartet utvikling som følger de etablerte arkitekturprinsippene, og som skal sikre at alle som utvikler web-tjenester for Bergen kommune følger de samme maler og prinsipper. Side 20

21 For å vise hvordan en spesifikk tjeneste er utviklet er web-tjenestene "Personservice" og "Eiendomsservice" vist i sin helhet i WSDL format i kapittel og under. Eksempler på andre web-tjenester som er i produksjon som del av Bergen kommunes innbyggerportal: OrgEnhetService Tilbyr data om organisasjonsenheter i Bergen kommune fra Master Data Management systemet (MDM). SakService Tilbyr saksbehandlingsdata fra saks- og arkivsystemet (BKSak) og MDM. ParkeringsService Gir tilgang til kundeforhold hos Bergen Parkering og informasjon om ledige plasser i parkeringshus. ProfilService Web-tjeneste for portalen som gir oversikt over en portalbrukers kundeforhold til Bergen kommune. SkjemaService Tilbyr tjenester for å behandle skjemaer. Eksempel kan være søknadsskjemaer fra innbyggere. Tjenesteidentifisering og tjenesteutvikling pågår kontinuerlig i Bergen kommune, både som del av Portalutviklingsprogrammet, men også ift integrasjoner med og mellom fagsystemer Definisjoner For å bedre å sikre forståelsen av web-tjenestene har vi lagt følgende definisjoner til grunn (kilde; Wikipedia): Web Services: En web service er definert av World Wide Web Consortium (WC3)som et software system som er designet for å støtte maskin til maskin interaksjon/kommunikasjon over et nettverk. En web service er en protokoll for utveksling av XML-baserte meldinger i et datanettverk. SOAP (Service Oriented Architecture Protocol) danner grunnlaget for en webservice. Vanligvis brukes HTTP/HTTPS for å overføre meldinger. WSDL: Web Services Description Language (WSDL) er et markeringsspråk for å beskrive Web Services (elektroniske tjenester over World Wide Web). Hensikten er å ha en velkjent (standard) måte for å etablere dialog mellom kunder og tilbydere av elektroniske tjenester. WSDL lar en tilbyder angi hvilke tjenester den har å velge mellom, og (for hver slik tjeneste), hvilke protokoller som kan brukes for å styre dialogen mot kunden, samt hvilket format som kan brukes i samtalen. Språket er utviklet av den frittstående organisasjonen W3C. Den opprinnelige formulering (versjon 1.0) kom i 2000, mens man i dag finner en revidert og utvidet beskrivelse (versjon 2.0). Der beskrives protokollene SOAP og HTTP, samt dialogformattering i henhold til metaspråket XML. SOAP: SOAP er en (plattformuavhengig) protokoll for utveksling av XML-baserte meldinger i datanettverk. SOAP danner grunnlaget for Web Services (elektroniske tjenester over World Wide Web). Vanligvis brukes HTTP/HTTPS til å overføre meldingene. Opprinnelig var navnet en forkortelse for Simple Object Access Protocol, senere Service Oriented Architecture Protocol. Side 21

22 HTTP: HTTP (Hypertext Transfer Protocol) er protokollen som primært benyttes på Verdensveven for å utveksle informasjon. HTTP er en forespørsel/respons protokoll mellom klienter og tjenere. En HTTP klient slik som en nettleser oppretter typisk en TCP forbindelse over IP-protokollen til en spesiell port (typisk port 80) på en annen vert. En HTTP tjener lytter på den porten og venter på at klienten skal sende en forespørselstreng, slik som «GET / HTTP/1.1» (som vil resultere i at tjeneren sender standardsida fra en vevtjener). Etter Forespørselstrengen kan en MIME melding følge, som har et hode som inneholder et antall parametre som beskriver ulike aspekter av forespørselen og en valgfri kropp som kan inneholde vilkårlige data. Når en tjener mottar en forespørselstreng (og muligens en melding) så sender tjeneren tilbake en responsstreng som for eksempel «200 OK», og ei melding der kroppen kan være fila som ble forespurt, en feilmelding eller annen informasjon. HTTP er forskjellig fra andre TCP-baserte protokoller slik som FTP på den måten at forbindelser vanligvis terminieres så snart en bestemt forespørsel (eller en serie med relaterte forespørsler) har blitt fullført. Denne teknikken gjør HTTP velegnet for Verdensveven der sider ofte lenkes til sider på andre tjenere. Det finnes også en sikker variant av HTTP som kalles HTTPS som kan bruke hvilken som helst krypteringsmetode så lenge den er forstått av begge sider av forbindelsen. Lokasjoner til HTTP (og HTTPS) sider oppgis som URLer (Uniform Resource Locators). Denne adresseringsmåten ble lagd for lenking i HTML-dokumenter Tjenestebuss Den viktigste komponenten som må forefinnes i en tjenesteorientert arkitektur er tjenestebussen (også benevnt ESB - Enterprise Serivce Bus). I Bergen kommune har vi valgt å benytte en tjenestebuss fra Mule. Tjenestebussen vil "samhandle" mellom de forskjellige lagene i arkitekturen og opptre som meglingsmann (mediator) mellom lagene. Tjenstebussens ansvarsområde kan enklest beskrives vha. VETRO-patternet: Validate - Validere innkommende meldinger. Enrich - Berike meldinger med informasjon som sender ikke har, men som mottaker trenger. Transform - Omforme meldingen fra det formatet sender tilbyr til det formatet mottaker trenger. Route - Rute meldingen fra sender til mottaker. Operate - Sikre at ønsket handling blir utført av mottaker, inkludert feilhåndtering og overvåking. Mule vil derfor benyttes for å konvertere (omforme og berike) innholdet i meldinger mellom den felles objektmodellen som benyttes av de midtre lagene og de system spesifikke objektmodellene som benyttes av de ytre lagene i løsningen. Side 22

23 3.3.3 Bruken av web-tjenester i konseptet "fullverdig elektronisk verdikjede" Web-tjenestene som beskrevet i avsnittene under benyttes blant annet til følgende formål: Personservice: Henter personinformasjon om pålogget bruker fra Bergen kommunes Master Data Management (MDM) system og presenterer dette i skjermbilder i Portal og i skjema som pre-utfylt data. Følgende skjermdialoger (referanser til figurer i kapittel 2) viser informasjon fra denne web-tjenesten: o Figur 6 - pre-utfylt personinformasjon i skjema Web-tjenesten henter informasjon fra MDM systemet og viser dette som pre-utfylt informasjon i felter i skjema o Figur 8 - personinformasjon (navn, adresse og fødselsdato) vises som topptekst i skjermbilde i Portal når bruker er pålogget. Eiendomsservice: Henter eiendomsinformasjon fra Bergen kommunes MDM system og presenterer dette i skjermbilder i Portal og i skjema som pre-utfylt data. Følgende skjermdialoger (referanser til figurer i kapittel 2) viser informasjon fra denne web-tjenesten: o Figur 6 - pre-utfylt eiendomsinformasjon i skjema Web-tjenesten henter informasjon fra MDM systemet og viser dette som pre-utfylt informasjon i felter i skjema o Figur 6 - informasjon i drop down menyer. Web-tjenesten henter informasjon fra MDM systemet og viser tilgjengelige (gyldige) gateadresser i Bergen kommune. o Figur 8/11 - lenke på venstre side <Mine eiendommer> gir oversikt over alle eiendommer pålogget bruker er hjemmelshaver for i Bergen kommune. Avsnittene under viser de komplette WSDL filene for ovennevnte web-tjenester. De er kun ment som eksempler for de med kunnskap om hvordan slike tjenester utvikles. Side 23

24 3.3.4 Personservice PersonService WSDL: <?xml version='1.0' encoding='utf-8'?><wsdl:definitions name="personservice" targetnamespace=" xmlns:ns1=" xmlns:soap=" xmlns:tns=" xmlns:wsdl=" xmlns:xsd=" <wsdl:types> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns=" xmlns:xs=" <xs:complextype name="usercontext"> <xs:element name="userid" type="xs:string" /> <xs:element name="onbehalfofid" nillable="true" type="xs:string" /> <xs:element name="appid" type="xs:string" /> <xs:element name="transactionid" nillable="true" type="xs:string" /> </xs:schema> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns:ns1=" xmlns:tns=" xmlns:xs=" <xs:import namespace=" /> <xs:complextype name="innbygger"> <xs:element name="person" type="ns1:person" /> <xs:element name="boligadresse" type="tns:boligadresse" /> <xs:element name="postadresse" type="tns:postadresse" /> <xs:element name="familienr" type="xs:string" /> <xs:element name="kjønn" type="tns:kjønn" /> <xs:complextype name="boligadresse"> <xs:element name="gateadresse" type="xs:string" /> <xs:element name="postnr_sted" type="ns1:postadministrativeområder" /> <xs:complextype name="postadresse"> <xs:element name="adresse1" type="xs:string" /> <xs:element name="adresse2" type="xs:string" /> <xs:element name="adresse3" type="xs:string" /> <xs:element name="landkode" type="xs:string" /> <xs:simpletype name="kjønn"> <xs:restriction base="xs:string"> <xs:enumeration value="m" /> <xs:enumeration value="k" /> </xs:restriction> </xs:simpletype> </xs:schema> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns:tns=" xmlns:xs=" <xs:complextype name="person"> <xs:element minoccurs="0" name="id" type="tns:personidentifikator" /> <xs:element minoccurs="0" name="personnavn" type="tns:personnavn" /> <xs:element minoccurs="0" name="fødselsdato" type="tns:dato" /> <xs:complextype name="personidentifikator"> <xs:element minoccurs="0" name="fødselsnummer" type="xs:string" /> <xs:element minoccurs="0" name="dnummer" type="xs:string" /> <xs:element minoccurs="0" name="dufnummer" type="xs:string" /> <xs:complextype name="personnavn"> Side 24