Veiledning for utvikling. Bruk av BKWSDL

Transkript

1 BÆRUM KOMMUNE BK BEDRIFTER DATA Veiledning for utvikling og Bruk av BKWSDL Versjon: 1.0 Dato Side 1 av 36

2 Innholdsfortegnelse Innholdsfortegnelse... 2 Innledning... 3 Målgruppe... 3 Målsetning... 4 Hva er BKWSDL... 5 Arkitekturelementer... 5 Kontraktsbaserte tjenester... 6 InfoStrukturBiblioteket... 7 Retningslinjer for BKWSDL... 8 Generelle regler [BKWSR-1] Bruk av WS-I Basic Profile [BKWSR-2] Bruk av document-literal [BKWSR-3] Bruk av godkjente BKXML typer [BKWSR-4] Bruk av elementreferanser [BKWSR-5] Bruk av request-response [BKWSR-6] Bruk av fault [BKWSR-7] Bruk av protokoller [BKWSD-1] Dokumentasjon Navngivningsregler [BKWSN-1] Bruk av BKXML navngivningsregler [BKWSN-2] Bruk av namespace i WSDL [BKWSN-3] Namespace navngiving for teknikk i WSDL [BKWSN-4] Navngiving av WSDL filer [BKWSN-5] Navngiving av tjenester <service> [BKWSN-6] Navngiving av operasjoner <operation> [BKWSN-7] Navngiving av meldinger <message> [BKWSN-8] Navngiving og oppbygging av meldingsinnhold [BKWSN-9] Navngiving av porttyper <porttype> [BKWSN-10] Navngiving av bindinger <binding> [BKWSN-11] Navngiving av soapaction [BKWSN-12] Navngiving av port elementet <port> Hvordan utvikles en BKWSDL Fremgangsmåte for utvikling av BKWSDL Eksempel Trinn 1: Modellering av datadefinisjoner Trinn 2: Modellering av meldingsdefinisjoner Trinn 3: Modellering av grensesnitt Trinn 4: Generere kodemal Ofte stilte spørsmål FAQ Sjekkliste Begrepsdefinisjoner Appendiks A Eksempel på WSDL Side 2 av 36

3 Innledning Dette dokumentet inneholder en beskrivelse av BKWSDL samt veiledning i hvordan en BKWSDL skal bygges opp og benyttes. BKWSDL er en sammenstilling av BK (Bærum Kommune) og WSDL (Web Service Description Language). Formålet for BKWSDL er å fremme Web Service interoperabilitet i Bærum kommune og å standardisere måten å lage BKWSDL-dokumenter på. Denne Veiledning skal medvirke til ovenstående ved å gjøre det lettere og mer oversiktlig for tjenestebrukere å benytte, og for tjenestetilbydere å utvikle BKWSDL-dokumenter. Denne Veiledningen fokuserer entydig på utviklingen og bruken av WSDL dokumenter i en BK-kontekst og er ikke en introduksjon til WSDL eller andre XML relaterte teknologier eller standarder. Veiledningen er basert på anbefalingene fra WS-I Basic Profile Version 1.1 med enkelte innstramninger. WS-I Basic Profile 1.1 er basert på WSDL 1.1. Målgruppe Målgruppene for denne Veiledningen er de virksomhetene, som har behov for: 1) Å utvikle Web Services på oppdrag fra Bærum kommune, eller som skal brukes av Bærum kommune. 2) Å benytte allerede utviklede og tilgjengelige Web Services i Bærum kommune. Virksomhetene er i denne forbindelse offentlige myndigheter og private virksomheter og deres leverandører av it-løsninger. Figur 1 - Roller relatert til WSDL-bruk 1304 Side 3 av 36

4 Målsetning Målsetningen for denne Veiledningen er: Å fremme utviklingen av interoperatible webservices. Å standardisere bruken av WDSL i Bærum kommunes regi. Å forenkle prosessen med å finne fram til eksisterende WSDL-definisjoner, og bruken av disse i Bærum kommunes regi Å forenkle bruken av BKXML i arbeidet med WSDL Det forutsettes, at man i forkant av utviklingen av et BKWSDL-dokument har identifisert tjenesten, dens operasjoner, og funnet relevante datastrukturer til operasjonenes grensesnitt Side 4 av 36

5 Hva er BKWSDL BKWSDL er WSDL-dokumenter som følger retningslinjene beskrevet i dette dokumentet. Retningslinjene for BKWSDL-dokumenter er, som beskrevet i introduksjonen, til for å understøtte Web Service interoperabilitet i Bærum kommune. Retningslinjene skal således være med på å fremme utviklingen WSDL-dokumenter med standard struktur, oppbygning, navnepolitikk og så videre. Arkitekturelementer BKWSDL-dokumentene inngår som et element i BK Web Service Arkitekturen (BKWSA). Figur 2 illustrerer kun utvalgte arkitekturelementer, som inngår i BKWSA. Figur 2 - BKWSA grunnelementer I dette dokument er det fokusert på tre grunnelementer fra BKWSA: En tjenestetilbyder, som enten selv eller gjennom en leverandør har utviklet en eller flere tjenester og fått dem publisert i InfoStrukturBiblioteket (ISB). En tjenestebruker, som finner en relevant tjeneste i tjenestekatalogen med henblikk på å benytte den. Tjenestekatalog, som er representert av InfoStrukturBiblioteket, og inneholder XML datadefinisjoner (XSD er) og web service definisjoner (WSDL-dokumenter). Den BKXML, som utveksles mellom tjenestetilbyder og tjenestebruker, er definert i BKWSDL-dokumentet i form av en eller flere meldingsdefinisjoner (XSD) Side 5 av 36

6 Kontraktsbaserte tjenester En Web Service er beskrevet i en tjenestekontrakt, som utveksles mellom tjenesteleverandøren og de aktuelle tjenestebrukere. Servicekontrakten består av to deler: Den tekniske, en WSDL, som beskriver eksempelvis, hvor en service finnes, hvilke operasjoner den har samt deres input og output. Den juridiske, en Service Level Agreement (SLA), som eksempelvis beskriver tilgjengeligheten for tjenesten, bruksavtale samt kvalitet for tjenesten. Figur 3 nedenfor illustrerer de to delene av kontrakten mellom tjenestetilbyder og tjenestebrukerne. Figur 3 - Tjenestekontrakt for en Web Service Tjenestebruk skjer på grunnlag av kontrakten (både WSDL og SLA). WSDL-dokumentet er en presis beskrivelse av tjenestens grensesnitt, som inneholder definisjoner av dels den informasjonen tjenesten har ansvaret for og manipulerer, dels den oppførsel tjenesten har. WSDL-dokumentet inneholder også en spesifisering av hvor og hvordan tjenesten fysisk skal finnes og benyttes samt eventuelle andre infrastrukturmessige krav. En SLA beskriver de tjenestekvaliteter, som tjenesteleverandøren skal leve opp til, og dermed også hvilke kvaliteter en tjenestebruker kan forvente. Alle aktører er dermed kjent med deres presise forpliktelser når en tjeneste leveres eller benyttes. Dette prinsippet kan være medvirkende til å forbedre kvaliteten på it-løsningene da risikoen for feil og misforståelser blir redusert. I praksis stiller dette relativt store krav til beskrivelse, vedlikehold og versjonskontroll av hele tjenestekontrakten. Dette dokument omhandler kun den del av tjenestekontrakten, som inneholder WSDLdokumentet, det vil si den tekniske delen av kontrakten Side 6 av 36

7 InfoStrukturBiblioteket Tjenestekatalogen er et viktig element i den ovenfor skisserte arkitekturen. For å få brukt eller gjenbrukt de tjenester som utvikles, skal det være lett å publisere og finne tjenester. Bærum kommune er i ferd med å opprette InfoStrukturBiblioteket, en infrastruktur til oppbevaring av BKXML og BKWSDL dokumenter. I infostrukturbiblioteket vil det også bli mulig å finne oppdaterte versjoner av relevant dokumentasjon, slik som dette dokumentet. InfoStrukturBiblioteket vil bli gjort tilgjengelig på i løpet av første halvdel av Inntil videre kan spørsmål rettes til Systemavdelingen i Bærum kommune ved Spesialkonsulent Øystein Aanrud, epost: oystein.aanrud@baerum.kommune.no Side 7 av 36

8 Retningslinjer for BKWSDL En web service består av ett eller flere grensesnitt, som hver kan definere en rekke operasjoner. WSDL-dokumentet beskriver disse grensesnitt. Kommunikasjon med tjenesten foregår med meldinger (messages), som utveksles mellom tjenestetilbyder og tjenestebruker via en spesifikk adresse (URI). Koblingen mellom adressen og grensesnittet (binding) definerer hvilken protokoll som benyttes. For BKWSDL bindinger skal i utgangspunktet HTTP og HTTPS benyttes. Figur 4 illustrerer grafisk et WSDL-dokument. Figur 4 - Grafisk illustrasjon av et WSDL-dokument <!-- definisjon av WSDL struktur --> <definitions xmlns=" <!-- abstrakte definisjoner --> <types>... </types> <message>... </message> <porttype>... </porttype> <!-- konkrete definisjoner --> <binding>... </binding> <service>... </service> </definitions> Figur 5 - Elementer i et WSDL-dokument Figur 5 skisserer elementene i et WSDL-dokument. De fem elementene er ytterligere beskrevet i Tabell 1. Elementnavn Beskrivelse 1304 Side 8 av 36

9 <types> <message> <porttype> <binding> <service> En container for abstrakte datadefinisjoner beskrevet ved hjelp XML schema En definisjon av en abstrakt beskjed, som kan bestå av flere forskjellige datadefinisjoner En abstrakt samling av operasjoner, som støttes av ett eller flere grensesnitt. Operasjoner defineres ved å beskrive forespørselsog svarmeldinger En konkret spesifikasjon av protokoll og dataformat for en bestemt porttype En samling av relaterte grensesnitt, hvor et grensesnitt er definert ved en kombinasjon av en binding og en adresse (URI) Tabell 1 - Elementer i et WSDL-dokument Forbindelsen mellom BKXML og BKWSDL bygges opp i <types> elementet. Her inkluderes (<include>) BKXML-skemaer fra ISB Side 9 av 36

10 Generelle regler BKWSDL-dokumenter skal overordnet følge anbefalingene fra WS-I Basic Profile Version 1.1 1, men for å oppnå den ønskede interoperabilitet i Bærum kommune, er reglene ytterligere tilpasset Bærum kommunes arkitekturprinsipper. Dette er beskrevet nærmere i resten av dette dokumentet. For et eksempel på en korrekt BKWSDL med tilhørende BKXML-skjemaer, se Appendiks A sist i dette dokumentet. [BKWSR-1] Bruk av WS-I Basic Profile 1.1 "En BKWSDL SKAL følge anbefalingene til WS-I Basic Profile 1.1, og skal ikke generere feil når de testes med siste versjon av WS-I WSDL-Analyzer. " Som utgangspunkt for å godkjenne BKWSDL-dokumenter, med tilhørende BKXMLskjemaer benyttes WS-I WSDL Analyzer 2. I tillegg skal alle reglene i beskrevet i Navngiving- og designregler for felles XML-skjema i Bærum kommune (BKNDR 1.0) overholdes. BKWSDL-dokumenter og BKXML-skjemaer skal derfor godkjennes av Bærum kommune ved IKT eller Systemavdelingen før de aksepteres som offisielle, og kan publiseres i InfoStrukturBiblioteket. [BKWSR-2] Bruk av document-literal "En BKWSDL SKAL benytte document-literal binding." For at en message skal kunne valideres utelukkende ved schema-validering, skjerpes R2705 i WS-I Basic Profile fra "MUST be a rpc-literal binding or a document-binding" til "MUST be a document-literal binding". [BKWSR-3] Bruk av godkjente BKXML typer "En BKWSDL SKAL kun benytte typer fra godkjente BKXML-skjema." Datadefinisjoner er XML skjemaer som definerer databærende elementer og deres innbyrdes relasjoner. Datadefinisjoner skal baseres på BKXML standarden. Selv om det allerede finnes en del BKXML-skjemaer, dekker de ennå ikke alle områder og segmenter innenfor alle sektorer i Bærum kommune. Før dette er tilfellet, vil det ikke kunne stilles krav om at samtlige datadefinisjoner skal være BKXML godkjente. Alle XML-skjemadefinisjoner som benyttes i Bærum kommunes SOA infrastruktur skal likevel oppfylle BKXML Navngivingog Designregler 1.0 (BKNDR). Bærum kommune ved IKT eller System avdelingen skal få mulighet til å gjennomgå og kommentere alle XML-skjemadefinisjoner før de tas endelig i bruk. Målet med en slik gjennomgang og godkjenning er at samtlige XML-skjemaer som brukes i Bærum kommune skal forbedres inntil de oppfyller alle BKNDR regler, og krav til gjenbrukbarhet og gjenbruk av allerede eksisterende typer. Oppnås dette, vil de godkjennes som offisielle BKXML-skjemaer, og publiseres i InfoStrukturBiblioteket Side 10 av 36

11 [BKWSR-4] Bruk av elementreferanser "En BKWSDL SKAL i sine message elementer kun ha ett part element. Dette part elementet skal benytte element attributtet og skal referere til et globalt godkjent BKXML-element." Meldingsdefinisjoner (message) beskriver de meldinger som sendes mellom tjenestetilbyder og tjenestebruker. En meldingsdefinisjon er et XML-skjema som samler de datadefinisjonene som bygger opp en konkret melding. Det forventes ikke at meldinger som inngår i et BKWSDL-dokument vil bli gjenbrukt i andre BKWSDL-dokumenter. WSDL-dokumentet og dets meldinger skal likevel publiseres i Bærum kommunes InfoStrukturBibliotek og tjenesten som beskrives av WSDL-dokumentet skal bygges opp med tanke på gjenbruk i andre tjenester og prosesser. Det stilles derfor krav til at også meldingsdefinisjonene skal oppfylle reglene beskrevet i BKNDR. Hele WSDLdokumentet inkludert dets meldingsdefinisjoner skal derfor forelegges Bærum kommunes IKT eller Systemavdeling for godkjenning før det kan tas endelig i bruk. I meldingsdefinisjonen skal det refereres til elementet i det BKXML-skjemaet som beskriver meldingen, ikke til typen som beskriver elementet. [BKWSR-5] Bruk av request-response "En BKWSDL SKAL benytte request-response utveksling." En BKWSDL tilpasset Bærum kommunes SOA infrastruktur skal i sine meldinger inneholde en del faste elementer (beskrevet senere i dette dokumentet) for håndtering av informasjon knyttet til feilsituasjoner og instansidentifikasjon. Alle operasjoner i en BKWSDL skal derfor kunne ta imot, og returnere denne informasjonen, selv om forespørselen eller svaret i seg selv ikke inneholder forretningsdata. [BKWSR-6] Bruk av fault "En BKWSDL SKAL IKKE benytte fault konstruksjonen. Alle feilmeldinger skal fanges opp i tjenesten og returneres som feilmelding i kontekstobjektet for status." Ettersom Bærum kommune har implementert egne rutiner for feilhåndtering (beskrevet senere i dette dokumentet) skal alle feilsituasjoner som oppstår i de enkelte tjenester fanges opp i tjenesten og beskrives i et eget element for statusinformasjon i meldingselementene. En BKWSDL skal derfor ikke benytte fault konstruksjonen som er tilgjengelig i WSDL standarden. Selv om mellomvarelaget i Bærum kommune også fanger opp uforutsette feil i form av exceptions og håndterer disse, skal de enkelte komponenter selv fange opp alle interne feilsituasjoner og beskrive disse i det nevnte statuselementet. [BKWSR-7] Bruk av protokoller "En BKWSDL SKAL definere tjenester som kommuniserer over Soap protokollen." Alle tjenester i Bærum kommunes SOA infrastruktur skal tilby sine tjenester i SOAP (som Web Services) over http og/eller https. Det er tillatt å tilby tjenestene i andre protokoller i tillegg Side 11 av 36

12 [BKWSD-1] Dokumentasjon "Et BKWSDL-dokument skal fylle ut et <documentation> element under sine <service>, <operation> og <message> elementer som til sammen gir en dekkende beskrivelse av tjenestens funksjonalitet." I tillegg til de vanlige dokumentasjonsdokumenter som hører til en leveranse, skal hovedelementene i et BKWSDL-dokument dokumenteres i selve BKWSDL-dokumentet slik at ethvert BKWSDL-dokument inneholder all den informasjon som er nødvendig for å kunne ta i bruk tjenesten og forstå dens funksjonalitet. Navngivningsregler [BKWSN-1] Bruk av BKXML navngivningsregler "En BKWSDL SKAL følge navngivingsreglene for BKXML-skjema der disse gir mening." Overordnet skal BKNDR benyttes i størst mulig grad også for BKWSDL-dokumenter. Eksempelvis skal man benytte entallsform av navn. Unngå bruk av forkortelser og akronymer, bindeord, bruk av norske tegn (æ, ø og å) og andre tegn enn bokstaver og tall. Norsk skal benyttes i navngiving av alle elementer og operasjoner. Det skal ikke benyttes underscore (_), punktum (.) eller bindestrek (-) i oppbygningen av navn- I stedet benyttes UpperCamelCase, det betyr at navnet skal begynne med en stor bokstav, heretter begynner hvert nytt ord med en stor bokstav. Hvis en forkortelse består utelukkende av store bokstaver, som f.eks. SFO, bør det påfølgende ordet starte med en liten bokstav. [BKWSN-2] Bruk av namespace i WSDL "En BKWSDL SKAL i sine namespace termer <bk-inngang>, <bk-område> og <versjon> følge reglene for BKXML-skjema." En BKWSDL skal alltid angi et namespace for alle sine bestanddeler. Navngivingen for termene <bk-inngang>, <bk-område> og <versjon> skal i dette namespace følge reglene [BKNMS-1] til [BKNMS-1d] fra BKNDR angående namespace for typer og elementer i BKXML-skjemaer. Regelen [BKNMS-1e] erstattes for BKWSDL-dokumenter av følgende regel. [BKWSN-3] Namespace navngiving for teknikk i WSDL "En BKWSDL SKAL i sin namespace term <teknikk> ha verdien Xml/Wsdl." For å skille WSDL-dokumenter fra de tilhørende XSD-dokumenter i InfoStrukturBiblioteket, samt å skille klart fra hverandre hvilke typer som beskriver dataobjekter og hvilke som beskriver operasjoner, grensesnitt og tjenester, skal namespace gjenspeile om det tilhører et XSD- eller WSDL-dokument. Et korrekt namespace for et BKWSDL-dokument kan eksempelvis få verdien " [BKWSN-4] Navngiving av WSDL filer "En BKWSDL SKAL navngi sine wsdl fil etter modellen 1304 Side 12 av 36

13 <namespace prefix>+ _ +<tjenestenavn>+ _ +<versjon>+.wsdl." For også å unikt kunne identifisere WSDL-dokumenter utenfor InfoStrukturBiblioteket skal også filnavnet gjenspeile namespace og versjon i tillegg til hvilken tjeneste som er beskrevet. WSDL-dokumentet fra eksemplet med namespace over, som beskriver en tjeneste for innkommende fakturaer kan da få navnet "OkFaIn_InnkommendeFaktura_ wsdl" [BKWSN-5] Navngiving av tjenester <service> "En BKWSDL SKAL navngi sin tjeneste (service) med et begrep som er dekkende for alle dens operasjoner. Et tjenestenavn bør ikke beskrive en handling " En BKWSDL skal beskrive en tjeneste som kan inneholde en eller flere operasjoner. Operasjonene i en tjeneste skal logisk høre sammen innen for et forretningsområde og hvilke data de gir tilgang til eller manipulerer. Tjenesten skal gis et navn som beskriver hva alle operasjonene har til felles, eller hvilke data de gir tilgang til eller manipulerer. Tjenesten selv skal ikke beskrive hvilke handlinger operasjonene tilbyr på de tilhørende dataobjekter. Man bør også unngå ordene Tjeneste og Service i tjenestenavnet. Eksempel på et anbefalt tjenestenavn: <service name= InnkommendeFaktura > Eksempel på et ikke anbefalt tjenestenavn: <service name= HentInnkommendeFakturaTjeneste > [BKWSN-6] Navngiving av operasjoner <operation> "En BKWSDL SKAL navngi sine operasjoner etter HandlingObjekt navngivningsmodellen. Det er ingen faste regler for Handling eller Objekt termene, men Handling termen skal presist gjengi operasjonens oppgave. Objekt termen vil i mange tilfeller være identisk med navnet på selve tjenesten." En operasjon bør navngis etter ObjektHandling navngivingsmodellen. Det er ingen fast definisjon av navngiving for handlinger. En operasjon som returnerer en liste over innkommende fakturaer kan for eksempel navngis: <operation name="hentfaturaliste"> En operasjon som oppdaterer informasjonen om en innkommende faktura kan for eksempel navngis: <operation name="oppdaterfaktura"> [BKWSN-7] Navngiving av meldinger <message> "En BKWSDL SKAL navngi sine meldinger (message) etter modellen <operasjonsnavn>+ In og <operasjonsnavn>+ Out for hhv. Inn og ut parametrene. " I BKWSDL opereres det kun med operasjonstypen Request-Response. Operasjonen vil da motta en forespørsel og skal returnere et svar Side 13 av 36

14 En melding (message) skal navngis etter den operasjon, meldingen benyttes i sammenheng med. I meldingsnavnet skal navnet på operasjonen etterfølges av henholdsvis In eller Out i de respektive meldingene som går inn til, eller kommer ut fra operasjonen. To meldinger som henholdsvis forespør og returnerer en samling av fakturadata, kan eksempelvis navngis slik. Forespørsel: <message name="hentfakturalistein"> Svar: <message name="hentfakturalisteout"> [BKWSN-8] Navngiving og oppbygging av meldingsinnhold "En BKWSDL SKAL i sine meldinger ha nøyaktig ett part element. Dette part elementet skal ha navnet body og skal referere til elementet i et gyldig BKXML-skjema som inneholder korrekte kontekst objekter samt et element som samler alle forretningsdata i inn eller ut parametrene. Nevnte BKXML-skjema skal ha som navn <operasjonsnavn>+ Request for inn parameteren og <operasjonsnavn>+ Response for ut parameteren. De tilsvarende typer skal ha samme navn, men med endelsen Type." I henhold til WS-I anbefalingene og for å oppnå bredest mulig verktøystøtte, anbefales det at hver melding kun inneholder et part element, og at dette part elementet refererer til et gyldig BKXML-skjema element, som vist i eksemplet nedenfor. <message name="hentfakturalistein"> < part name ="body" element=" xsd:hentfakturalisterequest"/> </ message> < message name="hentfakturalisteout"> < part name ="body" element=" xsd:hentfakturalisteresponse"/> </ message> Figur 6 Eksempel på anbefalt oppbygging av meldinger med innhold [BKWSN-9] Navngiving av porttyper <porttype> "En BKWSDL SKAL navngi sine porttype elementer etter navngivningsmodellen <tjenestenavn>+<teknikk>+ PortType. Hvor <teknikk> for eksempel kan være Soap eller HttpGet. Termen for <teknikk> kan utelates hvis tjenesten kun har en porttype." Det anbefales at navngiving av porttype elementet svarer til tjenestenavnet etterfulgt av ordet PortType. Hvis en tjeneste inneholder flere porttyper, skal i tillegg hver porttype kunne identifiseres unikt. Dette gjøres ved å legge inn teknikken som benyttes (for eksempel HttpGet eller HttpPost ) mellom tjenestenavnet og porttype. En porttype for tjenesten InnkommendeFaktura som kommuniserer over Soap bør derfor hete InnkommendeFakturaPortType, eller hvis det også finnes andre porttyper, for eksempel for HttpGet og HttpPost kan den hete InnkommendeFakturaSoapPortType. <porttype name="innkommendefakturasoapporttype"> < operation name=" HentFaturaListe"> < input message=" tns:hentfakturalistein"/> < output message=" tns:hentfakturalisteout"/> </ operation> </ porttype> Figur 7 Eksempel på definisjon av porttype 1304 Side 14 av 36

15 [BKWSN-10] Navngiving av bindinger <binding> "En BKWSDL SKAL navngi sine binding elementer etter navngivningsmodellen <tjenestenavn>+<teknikk>+ Binding. Hvor <teknikk> for eksempel kan være Soap eller HttpPost. Termen for <teknikk> kan utelates hvis tjenesten kun har en binding." Det anbefales at navngiving av binding elementet svarer til tjenestenavnet etterfulgt av ordet Binding. Hvis en tjeneste inneholder flere bindinger, skal i tillegg hver binding kunne identifiseres unikt. Dette gjøres ved å legge inn teknikken som benyttes (for eksempel HttpGet eller HttpPost ) mellom tjenestenavnet og Binding. En binding for servicen InnkommendeFaktura som kommuniserer over Soap bør derfor hete InnkommendeFakturaBinding, eller hvis det også finnes andre bindinger, for eksempel for HttpGet eller HttpPost kan den hete InnkommendeFakturaSoapBinding. [BKWSN-11] Navngiving av soapaction "En BKWSDL SKAL navngi sin SOAP-action etter modellen <namespace>+ / +<tjenestenavn> # +<operasjonsnavn>." En soapaction navngis med en kombinasjon av det namespace som refererer til WSDLdokumentets targetnamespace, navnet på den tjenesten som WSDL-dokumentet beskriver og operasjonsnavnet. Operasjonsnavnet skilles fra resten av navnet med tegnet #. Eksempel på en korrekt navngitt SOAP-action kan være: " #HentFakturaListe" [BKWSN-12] Navngiving av port elementet <port> "En BKWSDL skal i sin service, navngi dens port element likt som den porttype tjenesten implementerer, men endelsen skal være Port istedenfor PortType samt at teknikken som benyttes alltid skal inkluderes i navnet." Port elementet i en tjeneste (service) skal navngis som den porttypen tjenesten implementerer, men med endelsen Port istedenfor PortType, samt at teknikken som benyttes alltid skal være med ( Soap, HttpGet, etc.) Side 15 av 36

16 Hvordan utvikles en BKWSDL Fremstillingen av BKWSDL-dokumenter følger den generelle BK-metoden for utvikling, og bør følge Kontrakt Først utviklingsmetoden (KF-metoden), som beskrives nærmere under. Filosofien bak BK-metoden er blant annet å fremme gjenbruk og deling av datadefinisjoner samt å heve kvaliteten av data. Det skal være mulig å gjenbruke allerede utviklede elementer og typer, for med dette å minske kompleksiteten og antallet elementer og typer. For å utnytte gjenbruksprinsippet er det satt opp en rekke regler for navngiving og design av datadefinisjoner (XSD er), som forenkler at datadefinisjonene kan kombineres og gjenbrukes etter behov (BKXML). Når man ønsker å eksponere funksjonalitet som en Web Service, er det derfor utviklerens ansvar å kombinere sine meldingsdefinisjoner på bakgrunn av tilgjengelige datadefinisjoner, som er publisert i InfoStrukturBiblioteket. Er det bruk for ytterligere datadefinisjoner må disse nødvendigvis utvikles, for så å inkluderes i InfoStrukturBiblioteket for senere gjenbruk. Den beskrevne fremgangsmåten er basert på at data- og meldingsdefinisjoner er på plass, før den endelige tjeneste defineres med grensesnitt og operasjoner. Med dette oppnås muligheten for gjenbruk av allerede utviklede BKXML-skjemaer. Deretter kan koden til den konkrete implementering genereres ut fra WSDL-dokumentet. Fremgangsmåte for utvikling av BKWSDL KF-metoden kan beskrives ved følgende fire trinn: 1. Finne/modellere datadefinisjoner: I dette trinnet defineres hvilke forretningsdata som skal benyttes i tjenesten. Forretningsdata er beskrevet i BKXML-skjemaer. De aktuelle BKXML-skjemaer hentes i InfoStrukturBiblioteket (ISB) eller utvikles i henhold til BKNDR. 2. Modellere meldingsdefinisjoner: Her modelleres de meldingene som skal utveksles mellom tjenestetilbyder og -bruker. Meldingene beskrives i nye BKXML-skjemaer og benytter datadefinisjonene fra trinn 1. I forbindelse med modellering av meldinger skal også de faste elementene for instans- og statusinformasjon legges inn i tillegg til elementene som inneholder forretningsdata. 3. Modellere grensesnittet: I dette trinnet defineres, hvilke operasjoner tjenesten skal tilby. Operasjonene grupperes i grensesnitt. Trinnet avsluttes med å teste det ferdige BKWSDL-dokument opp mot WS-I Basic Profile Version 1.1 med WS-I tools 3. Merk at disse verktøy ikke kan avgjøre om alle profilens retningslinjer for BKWSDL er overholdt. 4. Generere kodemal: Ut fra BKWSDL-dokumentet genereres kodemaler til henholdsvis klient (tjenestebruker) og tjeneste (tjenestetilbyder). 3 Se Side 16 av 36

17 De fire trinnene er illustrert i Figur 8, hvor et antall datadefinisjoner kombineres til meldingsdefinisjoner, som benyttes til grensesnittbeskrivelsen. På bakgrunn av grensesnittbeskrivelsen genereres koden til det aktuelle miljø, hvor Web Servicen implementeres. Figur 8 Skjematisk fremstilling av kontrakt-først fremgangsmåten 1304 Side 17 av 36

18 Eksempel La oss prøve å se på et realistisk eksempel. Eksemplet tar utgangspunkt i en eksisterende tjeneste for å hente ut informasjon om inngående fakturaer til Bærum kommune. Altså fakturaer Bærum kommune skal betale til sine leverandører. Det benyttede eksemplet er vedlagt i sin helhet i appendiks A bakerst i dette dokumentet. Trinn 1: Modellering av datadefinisjoner Datadefinisjonene til denne tjenesten består av en samling BKXML-skjemaer som er utviklet i henhold til reglene for skjemautvikling i BKNDR 1.0. De benyttede skjemaene kan deles opp i : Basale databærende elementer som gjennom en eller flere enkle typer (simpletype) - eventuelt med restriksjoner representerer en enkel type. For eksempel OkFa_FakturaBeloep_ xsd. Sammensatte elementer som kombinerer de basale elementene til kombinasjoner og sekvenser av elementtyper. For eksempel OkFaIn_FakturaStruktur_ xsd. Meldingsdefinisjoner som samler alle data som skal sendes henholdsvis inn til eller ut fra tjenesten. For eksempel OkFaIn_HentFakturaListeRequest_ xsd. Generelt kan man si at mer sammensatte elementtyper, spesielt meldingsdefinisjonene er mer tilbøyelige til å være spesifikke til en gitt tjeneste (f.eks. som et resultat som består av en unik sammensetning av basale typer), mens de basale elementene vil være mer stabile på tvers av tjenester. XML-skjemadefinisjonene skal ikke bygges inn i WSDL-dokumentet, men skal i stedet referere til et gyldig BKXML-skjema gjennom et include-direktiv. XML-skjemadefinisjonene kan ses i sin helhet sammen med BKWSDL-dokumentet i Appendiks A. <types> < xs:schema elementformdefault=" qualified" targetnamespace=" Faktura/Innkommende/Xml/Schema/ "> < xs:include schemalocation="okfain_hentfakturalisteresponse_ xsd"/> < xs:include schemalocation="okfain_hentfakturalisterequest_ xsd"/> </ xs:schema> </ types> Figur 9 Inkludering av BKXML-skjemadefinisjoner 1304 Side 18 av 36

19 Trinn 2: Modellering av meldingsdefinisjoner På dette trinnet defineres en forespørselsmelding og en svarmelding. Innholdet i forespørselsmeldingen er basert på elementet HentFakturaListeRequest, og innholdet i svarmeldingen er basert på elementet HentFakturaListeResponse. Meldingselementene skal i tillegg til å inneholde de forretningsmessige parametrene inn og ut av operasjonen, også inneholde instanselementet MetaDataStruktur og, for svarmeldingen statuselementet ResultatStatusStruktur. Selve meldingsdefinisjonene HentFakturaListeIn og HentFakturaListeOut ligger i selve WSDL-dokumentet. <message name="hentfakturalistein"> < part name ="body" element=" ns:hentfakturalisterequest"/> </ message> < message name=" HentFakturaListeOut"> < part name ="body" element=" ns:hentfakturalisteresponse"/> </ message> Figur 10 - Meldingsdefinisjoner Trinn 3: Modellering av grensesnitt På dette trinnet defineres et grensesnitt som inneholder en operasjon. Operasjonen er definert ved den ovenfor beskrevne forespørsels- og svarmelding. og ser ut som følger: <porttype name="innkommendefakturaporttype"> < operation name=" HentFaturaListe"> < input message=" tns:hentfakturalistein"/> < output message=" tns:hentfakturalisteout"/> </ operation> </ porttype> Figur 11 - Grensesnittsdefinisjon Det resulterende BKWSDL-dokument blir med dette som vist nedenfor: 1304 Side 19 av 36

20 <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns=" xmlns:soap=" xmlns:http=" xmlns:xs=" xmlns:soapenc =" xmlns:mime=" xmlns:tns=" Faktura/Innkommende/Xml/Wsdl/ " xmlns:ns=" Faktura/Innkommende/Xml/Schema/ " xmlns:ns1 =" xmlns:ns2 =" xmlns:ns3 =" targetnamespace=" /Faktura/Innkommende/Xml/Wsdl/ "> < types> < xs:schema elementformdefault=" qualified" targetnamespace=" /Faktura/Innkommende/Xml/Schema/ "> < xs:include schemalocation="okfain_hentfakturalisteresponse_ xsd"/> < xs:include schemalocation="okfain_hentfakturalisterequest_ xsd"/> </ xs:schema> </types> < message name="hentfakturalistein"> < part name=" body" element="ns:hentfakturalisterequest"/> </ message> < message name="hentfakturalisteout"> < part name=" body" element="ns:hentfakturalisteresponse"/> </ message> < porttype name="innkommendefakturasoapporttype"> < operation name=" HentFaturaListe"> < input message="tns:hentfakturalistein"/> < output message=" tns:hentfakturalisteout"/> </ operation> </porttype> < binding name ="InnkommendeFakturaSoapBinding" type="tns:innkommendefakturasoapporttype"> < soap:binding style ="document" transport=" < operation name=" HentFaturaListe"> < soap:operation soapaction=" /Faktura/Innkommende/Xml/Wsdl/ / #HentFakturaListe" style="document"/> < input> < body use="literal"/> </ input> < output> < soap:body use="literal"/> </ output> </ operation> </ binding> < service name="innkommendefaktura"> < port name=" InnkommendeFakturaSoapPort" binding="tns:innkommendefakturasoapbinding"> < soap:address location=" </ port> </ service> </ definitions> Figur 12 Eksempel på BKWSDL-dokument 1304 Side 20 av 36

21 Trinn 4: Generere kodemal Tjenestetilbyder Tjenestetilbyderen implementerer den Web Servicen som er spesifisert av WSDLdokumentet. Det generelle mønsteret for server-side implementeringen av en WSDL-basert Web Service er at det valgte verktøyet med WSDL-dokumentet som input genererer klasser og kildekode for grensesnitt og databindinger i det benyttede programmeringsspråket. Deretter er det opp til utvikleren å skrive serverside kode som kan aktiveres via de genererte grensesnitt. Databindings klassene avspeiler de XSD-typer, som WSDL-dokumentet er basert på og brukes til å representere de overførte meldinger. Tjenestebruker En tjenestebruker vil generelt ved hjelp av det valgte klient-side verktøyet generere stub og databindings klasser og kildekode. Utvikleren kan så benytte disse stubbene til å kalle web servicen Side 21 av 36

22 Ofte stilte spørsmål FAQ Hva er en BKWSDL? BKWSDL er et WSDL-dokument, som følger dette dokuments retningslinjer for hvordan en WSDL skal oppbygges. BKWSDL er basert på Web Service Description Language (WSDL) 1.1 samt WS-I Basic Profile Version 1.1. samt BKXML NDR. Hvorfor BKWSDL? Standard måte å lage WSDL-dokumenter på i Bærum kommune, slik at organisasjoner kun skal forholde seg til en måte å frembringe og benytte WSDL-dokumenter på, med den fordel at alle BK Web Service kan håndteres på samme måte. Hvorfor støttes kun HTTP og HTTPS? BKWSDL er basert på WS-I Basic Profile version 1.1 og peker derfor kun på http og HTTPS. Hva gjør vi med data, som ikke er blitt standardisert ennå? Før alle sektorer av den Bærum kommune er dekket, vil det ikke kunne stilles krav om at samtlige datadefinisjoner skal være BKXML godkjente. Inntil da kan også ikke-godkjente BKXML-skjemaer benyttes. Disse schemaer skal dog som minimum oppfylle BKXML Navngivings- og Designregler 1.0 (BKNDR) og forelegges Bærum kommune ved IKT eller Systemavdelingen for kommentarer/godkjenning. Unntaket fra dette er nasjonalt og internasjonalt standardiserte skjemaer adoptert av BKXML. Er det tatt hensyn til WS-Policy og andre WS-standarder? Der har vært fokus på WSDL, men retningslinjene kan benyttes i forbindelse med andre WS-* standarder. Er WSDL-dokumentet registrert under den stien, som namespace angir? Når Bærum kommunes InfoStrukturBibliotek er oppe, skal alle BKXML-skjemaer og BKWSDL-dokumenter kunne finnes under den stien som dens namespace angir Side 22 av 36

23 Sjekkliste Følgende sjekkliste kan benyttes til å undersøke, om et WSDL-dokument overholder de i dette dokumentet oppstilte BK-retningslinjer. WSDL-dokumentet: skal som utgangspunkt kunne valideres imot WS-I Basic Profil og dermed WSDL 1.1 må kun inneholde document-literal bindinger, dvs. ingen rpc-literal bindinger skal i størst mulig omfang følge NDR har i navnet angitt et prefiks, eksempelvis OkFa, etterfulgt av underscore ( _ ) og tjenestenavnet har et target-namespace, som bygges opp av domene etterfulgt av xml.wsdl og dato benytter utelukkende request-response operasjoner har meldinger som navngis etter den operasjon en aktuell melding benyttes i sammenheng med har operasjoner som navngis etter HandlingObjekt navngivingsmodellen har porttyper som navngis etter tjenesten, men som er unike, hvis der er mer enn én porttype har soapaction som navngis ved namespace etterfulgt av # og operasjonsnavn har et service element, som navngis med tjenestens navn 1304 Side 23 av 36

24 Begrepsdefinisjoner Interoperabilitet, evnen til at to systemer kan utveksle informasjon og bruke den informasjon de har utvekslet. ISB, InfoStrukturBiblioteket er Bærum kommunes register, hvor alle BKXML schemaer skal oppbevares. BK, forkortelse for Bærum kommune BKNDR, Bærum kommunes design og navngivningsregler for XML-skjema og WSDL dokumenter BKWS, er Web Services i BK-kontekst, som de er beskrevet i BKWSA. BKXML, er XML som etterlever reglene for navngiving og design av XML til bruk i det offentlige, som beskrevet i BKXML skjemaregelsamling (BKNDR). BKWSA, BK Web Service Arkitekturen er Bærum kommunes standard for BK Web Service Arkitektur. Det arbeides i denne forbindelsen med å beskrive referansemodeller, som bygger på WS-I profiler, og konkretiserer disse profiler til Bærum kommunes forhold. Tjenestetilbyder, er den aktøren som tilbyr en beskrevet Web Service. Tjenestebruker, er den aktøren som benytter en Web Service. Tjenesteutvikler, er den aktøren som utvikler en Web Service. Det behøves ikke nødvendigvis å være den aktøren som blir tjenestetilbyder. Det kan eksempelvis være en it-leverandør som er utvikler, og en avdeling, som blir tilbyder av tjenesten. WS-I Basic Profil, en spesifikasjon fra Web Services Interoperability industrikonsortiet, som gir veiledning i samspillet mellom Web Service spesifikasjonene slik som SOAP, WSDL og UDDI. WSDL, Web Service Description Language er XML, som beskriver Web Services ved deres operasjoner og adresser Side 24 av 36

25 Appendiks A Eksempel på WSDL <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns=" xmlns:soap=" xmlns:http=" xmlns:xs=" xmlns:soapenc =" xmlns:mime=" xmlns:tns=" Faktura/Innkommende/Xml/Wsdl/ " xmlns:ns=" Faktura/Innkommende/Xml/Schema/ " xmlns:ns1 =" xmlns:ns2 =" xmlns:ns3 =" targetnamespace=" /Faktura/Innkommende/Xml/Wsdl/ "> < types> < xs:schema elementformdefault=" qualified" targetnamespace=" Faktura/Innkommende/Xml/Schema/ "> < xs:include schemalocation="okfain_hentfakturalisteresponse_ xsd"/> < xs:include schemalocation="okfain_hentfakturalisterequest_ xsd"/> </ xs:schema> </types> < message name="hentfakturalistein"> < part name=" body" element="ns:hentfakturalisterequest"/> </ message> < message name="hentfakturalisteout"> < part name=" body" element="ns:hentfakturalisteresponse"/> </ message> < porttype name="innkommendefakturasoapporttype"> < operation name=" HentFaturaListe"> < input message="tns:hentfakturalistein"/> < output message=" tns:hentfakturalisteout"/> </ operation> </porttype> < binding name ="InnkommendeFakturaSoapBinding" type="tns:innkommendefakturasoapporttype"> < soap:binding style ="document" transport=" < operation name=" HentFaturaListe"> < soap:operation soapaction=" Faktura/Innkommende/Xml/Wsdl/ / #HentFakturaListe" style="document"/> < input> < body use="literal"/> </ input> < output> < soap:body use="literal"/> </ output> </ operation> </ binding> < service name="innkommendefaktura"> < port name=" InnkommendeFakturaSoapPort" binding="tns:innkommendefakturasoapbinding"> < soap:address location=" </ port> </ service> </ definitions> OkFaIn_InnkommendeFaktura_ wsdl 1304 Side 25 av 36

26 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Innkommende/Xml/Schema/ " xmlns:ns1=" Metadata/Xml/Schema/ " targetnamespace=" Faktura/Innkommende/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFaIn_HentFakturaListeRequest_ " < import namespace=" Metadata/Xml/Schema/ " schemalocation="tkmd_metadatastruktur_ xsd"/> < include schemalocation="okfain_fakturaansvarligid_ xsd"/> < element name ="HentFakturaListeRequest" type="tns:hentfakturalisterequesttype"/> < complextype name=" HentFakturaListeRequestType"> < sequence> < element ref=" tns:fakturaansvarligid"/> < element ref=" ns1:metadatastruktur" minoccurs=" 0"/> </ sequence> </ complextype> OkFaIn_HentFakturaListeRequest_ xsd 1304 Side 26 av 36

27 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Innkommende/Xml/Schema/ " xmlns:ns1=" Metadata/Xml/Schema/ " xmlns:ns2=" Status/Xml/Schema/ " targetnamespace=" Faktura/Innkommende/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFaIn_HentFakturaListeResponse_ " < include schemalocation="okfain_fakturaliste_ xsd"/> < import namespace=" Metadata/Xml/Schema/ " schemalocation="tkmd_metadatastruktur_ xsd"/> < import namespace=" Status/Xml/Schema/ " schemalocation="tkst_resultatstatusstruktur_ xsd"/> < element name ="HentFakturaListeResponse" type="tns:hentfakturalisteresponsetype"/> < complextype name=" HentFakturaListeResponseType"> < sequence> < element ref=" tns:fakturaliste"/> < element ref=" ns1:metadatastruktur" minoccurs=" 0"/> < element ref=" ns2:resultatstatusstruktur"/> </ sequence> </ complextype> OkFaIn_HentFakturaListeResponse_ xsd 1304 Side 27 av 36

28 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Innkommende/Xml/Schema/ " targetnamespace=" Faktura/Innkommende/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFaIn_FakturaAnsvarligId_ " < element name ="FakturaAnsvarligId" type=" tns:fakturaansvarligidtype"/> < simpletype name="fakturaansvarligidtype"> < restriction base="xs:string"/> </ simpletype> OkFaIn_FakturaAnsvarligId_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Innkommende/Xml/Schema/ " targetnamespace=" Faktura/Innkommende/Xml/Schema/ " elementformdefault="qualified" attributeformdefault="unqualified" version="1.0" id="okfain_fakturaliste_ " < include schemalocation="okfain_fakturastruktur_ xsd"/> < element name ="FakturaListe" type="tns:fakturalistetype"/> < complextype name=" FakturaListeType"> < sequence> < element ref=" tns:fakturastruktur" < minoccurs ="0" maxoccurs="unbounded"/> </ sequence> </ complextype> OkFaIn_FakturaListe_ xsd 1304 Side 28 av 36

29 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Innkommende/Xml/Schema/ " xmlns:ns1=" Faktura/Xml/Schema/ " targetnamespace=" Faktura/Innkommende/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault="unqualified" version ="1.0" id ="OkFaIn_FakturaStruktur_ " < include schemalocation="okfain_fakturaforfallindikator_ xsd"/> < include schemalocation="okfain_leverandoernavn_ xsd"/> < import namespace=" Faktura/Xml/Schema/ " schemalocation="okfa_fakturastrukturelementer_ xsd"/> < element name ="FakturaStruktur" type=" tns:fakturastrukturtype"/> < complextype name=" FakturaStrukturType"> < sequence> < element ref=" ns1:fakturabeloep"/> < element ref=" ns1:fakturaforfalldato"/> < element ref=" tns:fakturaforfallindikator" minoccurs=" 0"/> < element ref=" ns1:fakturanummer"/> < element ref=" ns1:fakturatekst" minoccurs="0"/> < element ref=" tns:leverandoernavn"/> </ sequence> </ complextype> OkFaIn_FakturaStruktur_ xsd 1304 Side 29 av 36

30 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Xml/Schema/ " targetnamespace=" Faktura/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id="okfa_fakturabeloep_ " < element name ="FakturaBeloep" type=" tns:fakturabeloeptype"/> < simpletype name="fakturabeloeptype"> < restriction base="xs:decimal"> < fractiondigits value=" 2"/> < mininclusive value=" 0"/> </ restriction> </ simpletype> OkFa_FakturaBeloep_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" Faktura/Xml/Schema/ " targetnamespace=" Faktura/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFa_FakturaForfallDato_ " < element name ="FakturaForfallDato" type=" tns:fakturaforfalldatotype"/> < simpletype name="fakturaforfalldatotype"> < restriction base="xs:date"/> </ simpletype> OkFa_FakturaForfallDato_ xsd 1304 Side 30 av 36

31 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" F aktura/xml/schema/ " targetnamespace=" Fak tura/xml/schema/ " elementformdefault=" qualified" attributeformdefault="unqualified" version ="1.0" id="okfa_fakturanummer_ " < element name ="FakturaNummer" type=" tns:fakturanummertype"/> < simpletype name="fakturanummertype"> < restriction base="xs:string"/> </ simpletype> OkFa_FakturaNummer_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" F aktura/xml/schema/ " targetnamespace=" Faktura/Xml/Schema/ " elementformdefault=" qualified" attributeformdefault="unqualified" version="1.0" id="okfa_fakturatekst_ " < element name ="FakturaTekst" type="tns:fakturateksttype"/> < simpletype name="fakturateksttype"> < restriction base="xs:string"/> </ simpletype> OkFa_FakturaTekst_ xsd 1304 Side 31 av 36

32 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" F aktura/innkommende/xml/schema/ " targetnamespace=" Fak tura/innkommende/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFaIn_FakturaForfallIndikator_ " < element name ="FakturaForfallIndikator" type="tns:fakturaforfallindikatortype"/> < simpletype name="fakturaforfallindikatortype"> < restriction base="xs:boolean"/> </ simpletype> OkFaIn_FakturaForfallIndikator_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" F aktura/innkommende/xml/schema/ " targetnamespace=" Fak tura/innkommende/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFaIn_LeverandoerNavn_ " < element name ="LeverandoerNavn" type=" tns:leverandoernavntype"/> < simpletype name="leverandoernavntype"> < restriction base="xs:string"/> </ simpletype> OkFaIn_LeverandoerNavn_ xsd 1304 Side 32 av 36

33 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" F aktura/xml/schema/ " targetnamespace=" Fak tura/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="OkFa_FakturaStrukturElementer_ " < include schemalocation="okfa_fakturabeloep_ xsd"/> < include schemalocation="okfa_fakturaforfalldato_ xsd"/> < include schemalocation="okfa_fakturanummer_ xsd"/> < include schemalocation="okfa_fakturatekst_ xsd"/> OkFa_FakturaStrukturElementer_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" S tatus/xml/schema/ " targetnamespace=" Sta tus/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="TkSt_ResultatStatusStruktur_ " < include schemalocation="tkst_statusbeskrivelse_ xsd"/> < include schemalocation="tkst_statuskode_ xsd"/> < include schemalocation="tkst_statuslogid_ xsd"/> < element name ="ResultatStatusStruktur" type="tns:resultatstatusstrukturtype"/> < complextype name=" ResultatStatusStrukturType"> < sequence> < element ref=" tns:statusbeskrivelse" minoccurs="0"/> < element ref=" tns:statuskode"/> < element ref=" tns:statuslogid" minoccurs=" 0"/> </ sequence> </ complextype> TkSt_ResultatStatusStruktur_ xsd 1304 Side 33 av 36

34 <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" S tatus/xml/schema/ " targetnamespace=" Sta tus/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="TkSt_StatusBeskrivelse_ " < element name ="StatusBeskrivelse" type="tns:statusbeskrivelsetype"/> < simpletype name="statusbeskrivelsetype"> < restriction base="xs:string"/> </ simpletype> TkSt_StatusBeskrivelse_ xsd <?xml version="1.0" encoding="utf-8"?> xmlns:tns=" S tatus/xml/schema/ " targetnamespace=" Sta tus/xml/schema/ " elementformdefault=" qualified" attributeformdefault=" unqualified" version ="1.0" id ="TkSt_StatusKode_ " < element name ="StatusKode" type="tns:statuskodetype"/> < simpletype name="statuskodetype"> < restriction base="xs:integer"/> </ simpletype> TkSt_StatusKode_ xsd 1304 Side 34 av 36