OIOWSDL Vejledning for udvikling og anvendelse af OIOWSDL

Transkript

1

2 OIOWSDL Vejledning for udvikling og anvendelse af OIOWSDL Udgivet af: IT- & Telestyrelsen i samarbejde med Devoteam og Trifork IT- & Telestyrelsen Holsteinsgade København Ø Publikationen kan hentes på It- & Telestyrelsens Hjemmeside: ISBN (internet): Tryk: Oplag: ISBN: Telefon: Fax:

3 OIOWSDL Vejledning for udvikling og anvendelse af OIOWSDL IT- & Telestyrelsen august 2007

4 Indhold > Introduktion 6 Målgruppe 6 Mål 6 Hvad er OIOWSDL? 8 Arkitekturelementer 8 Kontraktbaserede services 8 Infostrukturbasen 10 Retningslinier for OIOWSDL 10 [DEF-1] Document literal binding 11 [DEF-2] Krav til datadefinitioner 11 [DEF-3] Krav til message-definitioner 12 [NAV-1] Krav til navngivning af filer, namespaces og elementer 12 [DOK-1] Dokumentation 15 Hvordan fremstilles OIOWSDL? 16 Fremgangsmåde for udvikling af OIOWSDL 16 Eksempel 18 Trin 1: Modellering af datadefinitioner 19 Trin 2: Modellering af beskeddefinitioner 19 Trin 3: Modellering af grænseflade 20 Trin 4: Generér kodeskabelon 21 Hvordan anvendes OIOWSDL? (Værktøjsunderstøttelse) 22 Generelle problemer med imports 23 Løsninger 24 BEA WebLogic Introduktion 25 Klientstubbe 26 Service-skeletons 27 RAD 6.0.0, RAD 6.0.1, RAD Introduktion 28 Klientstubbe 29 Service-skeleton 29 Axis Introduktion 30 Klientstubbe 30 Service-skeleton 31 Axis2 31 Introduktion 31 Klient 31 Service-skeleton 31 Eclipse 32 Introduktion 32 Klientstubbe 32 Service-skeleton 32.NET Introduktion 32 Klientstubbe 33 Service-skeleton 33.Net Introduktion 34

5 Klientstubbe 34 Service-skeleton 35.NET Introduktion 35 Klientstubbe 36 Service-skeleton 37 Ruby 37 Introduktion 37 Klientstubbe 37 Service-skeleton 38 Appendiks: FAQ 39 Appendiks: Referencer 41 Appendiks: Checkliste 42 Appendiks: Begrebsdefinitioner 43 Appendiks: XSD schema er for eksempel 44 DKMA_DosageFormText.xsd 44 DKMA_DrugIdentifier.xsd 45 DKMA_DrugName.xsd 46 DKMA_DrugStrengthText.xsd 47 DKMA_DrugStructure.xsd 48 DKMA_MedicineChestItemChoiceStructure.xs d 49 DKMA_MedicineChestItemDate.xsd 50 DKMA_MedicineChestItemIdentifier.xsd 51 DKMA_MedicineChestItemStructure.xsd 52 DKMA_MedicineChestItemVersionIdentifier.xs d 53 DKMA_MedicineChestRemarkText.xsd 54 DKMA_MedicineChestStructure.xsd 55 DKMA_MedicineChestStructureGet.xsd 56 DKMA_OwnerTypeText.xsd 57 Appendiks: WSDL for eksempel 58 Appendiks: WSDL med indlejrede typer 59

6 Introduktion > Nærværende dokument indeholder en beskrivelse af OIOWSDL samt vejledninger i, hvordan OIOWSDL skal opbygges og anvendes. Denne struktur vil være afspejlet i dokumentets opbygning. OIOWSDL er en sammenstilling af OIO (Offentlig Information Online) og WSDL (Web Service Description Language. Formålet for OIOWSDL er at fremme Web Service interoperabilitet i Det Digitale Danmark og at ensrette måden at lave OIOWSDL-dokumenter på. Denne vejledning skal medvirke til ovenstående ved at gøre det lettere og overskueligt for serviceaftagere at anvende og for serviceudbydere at frembringe OIOWSDL-dokumenter. Denne vejledning fokuserer entydigt på udviklingen og anvendelsen af WSDLdokumenter i en OIO-kontekst og er ikke en introduktion til WSDL eller andre XML relaterede teknologier/standarder. Vejledningen er baseret på reglerne for WS-I Basic Profile Version 1.1 med enkelte skærpelser. WS-I Basic Profile 1.1 er baseret på WSDL 1.1. Målgruppe Målgrupperne for denne vejledning er de virksomheder, der har behov for: 1) At udbyde Web Services for omverdenen - offentlige myndigheder og samarbejdspartnere. 2) At aftage allerede udviklede og tilgængelige Web Services. Virksomhederne er i denne forbindelse offentlige myndigheder og private virksomheder og deres leverandører af it-løsninger. OIOWSDL-dokumenterne er tilgængelige gennem servicekataloget. Servicekataloget indeholder således faciliteter, så serviceudbyderen kan publicere OIOWSDL-dokumenter, og serviceaftageren kan finde OIOWSDLdokumenter. Figur 1 Rollerne relateret til WSDL-brug Mål Målsætningen for denne vejledning er: At fremme udviklingen af interoperable webservices 6

7 At standardisere brugen af WDSL i OIO regi At lette frembringelsen og brugen af WSDL i OIO regi At lette anvendelsen af OIOXML i arbejdet med WSDL Det forudsættes, at man inden udviklingen af et OIOWSDL-dokument har identificeret servicen, dens operationer, og fundet relevante datastrukturer til operationernes snitflader. 7

8 Hvad er OIOWSDL? > OIOWSDL er WSDL-dokumenter, der følger retningslinierne beskrevet i dette dokument. Retningslinierne for OIOWSDL-dokumenter er, som beskrevet i introduktionen, til for at understøtte Web Service interoperabilitet i det Digitale Danmark. Retningslinierne skal således være med til at udvikle WSDLdokumenter med ensartede strukturer opbygninger, navnepolitikker m.v. Arkitekturelementer OIOWSDL-dokumenterne indgår som et element i OIO Web Service Arkitekturen (OWSA), som er skitseret i Fejl! Henvisningskilde ikke fundet. herunder. Figur 2 illustrerer kun udvalgte arkitekturelementer, som indgår OWSA 1. Figur 2 OWSA grundelementer I dette dokument er der fokuseret på de tre grundelementer fra OWSA: En serviceudbyder, som enten selv eller gennem en leverandør har udviklet en eller flere services og fået dem publiceret i Infostrukturbasen (ISB). En serviceaftager, som finder en relevant service i servicekataloget med henblik på at anvende den. Servicekatalog, som indeholder XML datadefinitioner (XSD er) og web service definitioner (WSDL-dokumenter). Det OIOXML, der udveksles mellem serviceudbyder og serviceaftager, er defineret i OIOWSDL-dokumentet i form af en eller flere meddelelsesdefinitioner (XSD). Kontraktbaserede services En Web Service er beskrevet i en servicekontrakt, som udveksles mellem serviceleverandøren og de aktuelle serviceaftagere. Servicekontrakten består af to dele: 1 En mere detaljeret beskrivelse af OWSA og de sikkerhedsmæssige aspekter er beskrevet i ITST s OWSA model Transportbaseret sikkerhed ver. 1.0 publiceret 5. december

9 Den tekniske, en WSDL, som beskriver eksempelvis, hvor en service findes, hvilke operationer den har samt deres input og output. Den juridiske, en Service Level Agreement (SLA), som eksempelvis beskriver tilgængeligheden for servicen, forbrugsaftale samt kvalitet for servicen. Figur 3 herunder illustrerer de to dele af kontrakten mellem serviceudbyder og serviceaftagerne. Figur 3 Servicekontrakt for en Web Service Serviceanvendelse sker på grundlag af kontrakten (både WSDL og SLA). WSDL-dokumentet er en præcis beskrivelse af servicens interfaces, der indeholder en definition af dels den information, servicen har ansvaret for og manipulerer med, dels den adfærd servicen har. WSDL-dokumentet indeholder også en specificering af, hvordan servicen fysisk skal findes og anvendes samt eventuelle andre infrastrukturmæssige krav. SLA en beskriver de servicekvaliteter, som serviceleverandøren skal leve op til, og dermed også hvilke kvaliteter en serviceaftager kan forvente. Alle aktører er dermed bekendt med deres præcise forpligtigelser, når en service leveres eller anvendes. Dette princip kan være medvirkende til at forbedre kvaliteten i it-løsningerne, da risikoen for fejl og misforståelser bliver reduceret. I praksis stiller dette relativt store krav til beskrivelse, vedligeholdelse og versionering af hele servicekontrakten 2. Dette dokument vedrører kun den del af servicekontrakten, der indeholder WSDL-dokumentet, dvs. den tekniske del af kontrakten. 2 Se OIO Standardaftale om web services: 9

10 Infostrukturbasen Servicekataloget er et vigtigt element i den ovenfor skitserede arkitektur. For at få brugt eller genbrugt de services, der udvikles, skal det være let at publicere og finde services. Der findes allerede en velfungerende infrastruktur til opbevaring af OIOXML schemaer - Infostrukturbasen. Grundet den tætte sammenhæng med OIOXML schemaer er Infostrukturbasen et oplagt sted at opbevare og udstille OIOWSDL-dokumenter. Retningslinier for OIOWSDL En web service består af et eller flere interfaces, der hver kan definere en række operationer. WSDL-dokumentet beskriver disse interfaces. Servicen tilgås via beskeder (messages), som udveksles mellem serviceaftager og -udbyder via en specifik adresse (URI). Koblingen mellem adressen og interfacet (binding) definerer hvilken protokol der anvendes. For OIOWSDL bindings kan udelukkende anvendes HTTP og HTTPS. Fejl! Henvisningskilde ikke fundet. illustrerer grafisk et WSDL-dokument. Figur 4 - Grafisk illustration af et WSDL-dokument <!-- definition af WSDL struktur --> <definitions xmlns=" <!-- abstrakte definitioner --> <types>... <message>... <porttype>... <!-- konkrete definitioner --> <binding>... <service>... </definition> Figur 5 - Elementer i et WSDL-dokument 10

11 Figur 5 skitserer elementerne i et WSDL-dokument. De fem elementer er yderligere beskrevet I Tabel 1. Elementnavn Types Message porttype Binding Service Beskrivelse En container for abstrakte datadefinitioner beskrevet ved hjælp XML schema En definition af en abstrakt besked, der kan bestå af flere forskellige datadefinitioner En abstrakt samling af operationer, der supporters af et eller flere interfaces. Operationer defineres ved at beskrive forespørgsels- og svarbeskeder En konkret specifikation af protokol og dataformat for en bestemt porttype En samling af relaterede interfaces, hvor ét interface er defineret ved en kombination af en binding og en adresse (URI) Tabel 1 - Elementer i et WSDL-dokument Forbindelsen mellem OIOXML og OIOWSDL opbygges i <type>-elementet. Her inkluderes (<include>) OIOXML-skemaer fra ISB en i modsætning til servicens egne typer, som oftest indlejres, da de ikke nødvendigvis kan genbruges i andre sammenhænge. OIOWSDL-dokumenter skal overordnet følge reglerne for WS-I Basic Profile Version 1.1 3, men for at opnå den ønskede interoperabilitet i Det Digitale Danmark er reglerne tilpasset OIO-konteksten. Dette er beskrevet i nærværende kapitel. [DEF-1] Document literal binding For at en message kan valideres udelukkende ved schema-validering, skærpes R2705 fra WS-I Basic Profile fra MUST be a rpc-literal binding or a document-binding til MUST be a document-literal binding. [DEF-2] Krav til datadefinitioner Datadefinitioner er XML schemaer, som definerer databærende elementer og deres indbyrdes relationer. Datadefinitioner skal som udgangspunkt baseres på OIOXML standarden. Pt., primo 2007, findes der ca schemaer i ISB en; hvilke kan anvendes til udvikling af OIOWSDL-dokumenter

12 Selvom der allerede findes OIOXML schemaer, dækker de endnu ikke alle områder og segmenter inden for den offentlige sektor. Før dette er tilfældet, vil der ikke kunne stilles krav om, at samtlige datadefinitioner skal være OIOXML godkendte. Indtil da kan også non-oioxml schemaer anvendes. Disse schemaer skal opfylde OIOXML Navngivnings- og Designregler (NDR), men behøver ikke at være godkendte. [DEF-3] Krav til message-definitioner Message-definitioner beskriver de beskeder, der sendes mellem serviceudbyder og serviceaftager. En message-definition er et XML schema, som samler de datadefinitioner, der opbygger en konkret besked. Det forventes, at messages, der indgår i et OIOWSDL-dokument, ikke vil blive genbrugt i andre OIOWSDL-dokumenter. Derfor stilles der ikke krav om, at message-definitioner, der indgår i et OIOWSDL-dokument, skal være OIOgodkendte eller på sigt skal godkendes. [NAV-1] Krav til navngivning af filer, namespaces og elementer Overordnet bør NDR benyttes i størst muligt omfang; eksempelvis entalsform af navne, forkortelser og akronymer, bindeord, anvendelse af tegn i navne, anvendelse af danske tegn (æ, ø, å). Mht. sprogvalg følges NDR, dvs. det valgte sprog (dansk eller engelsk) skal anvendes gennemført, og engelsk foretrækkes. Generelt anbefales det ikke at benytte underscore (_), punktum (.) eller bindestreg (-) i opbygningen af navne, men i stedet at benytte UpperCamelCase. Det betyder, at navnet skal begynde med et stort bogstav, herefter begynder hvert nyt ord med et stort bogstav. Hvis en forkortelse består udelukkende af store bogstaver, som f.eks. DK, bør det efterfølgende ord starte med et lille bogstav. [NAV-1a] Navngivning af OIOWSDL-dokumenter I lighed med NDR for OIOXML anbefales det, at navngive sine OIOWSDLdokumenter som følger: <namespace-prefix med store bogstaver>+ _ +<servicenavn>+.wsdl Et OIOWSDL-dokument indeholdende beskrivelse af en service med navnet MedicineChest med prefix DKMA vil således få navnet DKMA_MedicineChest.wsdl

13 [NAV-1b] Navngivning af OIOWSDL namespace Navngivning af namespaces for OIOWSDL-dokumentet bør følge de generelle OIO retningslinier, som er beskrevet i NDR. Dog er der en ændring i forhold til det anbefalede i NDR, nemlig brug af punktum til adskillelse af visse understrukturer samt dato <domæne> + /xml.wsdl/ + <årstal> +. + <måned> +. + <dag> + / Et namespace for OIOWSDL under dkma.dk domænet kan eksempelvis få namespace <definitions xmlns=" targetnamespace=" xmlns:dkma=" xmlns:xsd=" xmlns:tns=" xmlns:soap=" Figur 6 Eksempel på navngivning af namespace [NAV-1c] Navngivning af <message> Der opereres i OIOWSDL regi med to operationstyper: Request-response operationen kan modtage en forespørgsel og vil returnere et svar. One-way operationen kan modtage en meddelelse, men vil ikke returnere et svar. Request-response typen er dog den mest anvendte. En meddelelse (message) bør navngives efter den operation, meddelelsen anvendes i sammenhæng med. Hvis operationen er en request- eller responseoperation, skal navnet efterfølges af hhv. Request eller Response. Hvis operationen er en one-way operation, navngives meddelelsen udelukkende af operationens navn. For fejl-meddelelser efterfølges navnet af Fault. <operationsnavn> + Request Response Fault To meddelelser, der forespørger hhv. returnerer en samling af medicinoplysninger, kan eksempelvis se ud som følger. Forespørgsel: MedicineChestStructureGetRequest 5 Navngivning af namespace ved brug af punktum mellem xml og wsdl, samt til opdeling af dato følger ikke NRD 3.0, men er en senere anbefaling fra Adam Arndt fra ITST. 13

14 Retursvar: MedicineChestStructureGetResponse <message name="medicinecheststructuregetrequest">... </message> <message name="medicinecheststructuregetresponse">... </message> <message name="medicinecheststructurefault">... </message> Figur 7 Eksempel på navngivning af message elementet Der er ikke set behov for navngivningsregler af message parts. [NAV-1d] Navngivning af <operation> En operation bør navngives efter ObjektHandling navngivningsmodellen. Der er ingen fast definition af navngivning af handlinger. En operation som returnerer en medicinprofil ved en forespørgsel kan eksempelvis navngives: MedicineChestStructureGet En operation som ændrer på en medicinprofils indhold kan eksempelvis navngives: MedicineChestStructureUpdate. <operation name="medicinecheststructureget"> <input name="medicinecheststructuregetrequest" message="tns:medicinecheststructuregetrequest"/> <output name="medicinecheststructuregetresponse" message="tns:medicinecheststructuregetresponse"/> <fault name="medicinecheststructurefault" message="tns:medicinecheststructurefault"/> </operation> Figur 8 Eksempel på navngivning af operation elementet [NAV-1e] Navngivning af <porttype> (interface) Det anbefales at navngivning af porttype elementet svarer til service navnet. For WSDL-dokumenter med flere interfaces kræves dog en unik navngivning af samtlige interfaces. <servicenavn> + <unik identifikation> En porttype for servicen MedicineChest, der kun indeholder én porttype hedder således blot: MedicineChest. <porttype name="medicinechest">... </porttype> Figur 9 Eksempel på navngivning af porttype elementet [NAV-1f] Navngivning af <binding> Det anbefales at navngivning af binding svarer til servicenavnet. Findes der mere end ét binding element i WSDL-dokumentet, kræves dog en unik navngivning af samtlige binding elementer: 14

15 <servicenavn> + <unik identifikation> [NAV-1g] Navngivning af SOAP-actions SOAP-actions navngives efter følgende model: <namespace> + # + <operationsnavn> Hvor namespace refererer til det targetnamespace, der er angivet i WSDLdokumentet. Eksempel på en SOAP-action kan være: <binding name="medicinechestbinding" type="tns:medicinechesttype"> <soap:binding transport=" style="document" /> <operation name="getmedicinecheststructure"> <soap:operation soapation= " style="document" />... </operation> </binding> Figur 10 Eksempel på navngivning af binding elementet [NAV-1h] Navngivning af <service> Det anbefales at benytte et dækkende begreb for navngivning af service elementet, der dækker over servicens operationer. Det frarådes at anvende operationstyper i navnet, eksempelvis medicineget, ligesom det frarådes at anvende ordet service i navngivningen af servicen. Eksempel på det anbefalede: <service name="medicinechest"> Eksempel på ikke anbefalet: <service name="medicinechestgetservice"> <service name="medicinechest">... </service> Figur 11 Eksempel på navngivning af service elementet [DOK-1] Dokumentation Det anbefales, at der tilføjes et <documentation> element til <service>, <operation> og <message> elementerne i WSDL-dokumentet, som tilsammen giver en dækkende beskrivelse af den funktionalitet, som servicen udbyder. 15

16 Hvordan fremstilles OIOWSDL? > Fremstillingen af OIOWSDL filer følger den generelle OIO-tankegang, og bør følge Kontrakt Først udviklingsmetoden (KF-metoden), som beskrives nærmere nedenfor. Filosofien bag OIO er blandt andet at fremme genbrug og deling af datadefinitioner samt at hæve kvaliteten af data. Det skal være muligt at genbruge allerede udviklede elementer for herved at mindske kompleksiteten og antallet af elementer. For at udnytte genbrugsprincippet opstilles der en række regler for navngivning og design af datadefinitionselementer (XSD er) 6, som letter, at datadefinitionselementerne kan kombineres efter behov. Når man ønsker at udstille noget funktionalitet som en Web Service, er det derfor udviklerens ansvar at kombinere sine meddelelsesdefinitioner på baggrund af tilgængelige datadefinitioner, som er udstillet i det fællesoffentlige serviceregister. Er der brug for yderligere datadefinitioner, må disse nødvendigvis udvikles 7. Den beskrevne fremgangsmåde er baseret på, at data- og besked-definitioner er på plads, før den endelige service defineres med interfaces og operationer. Herved opnås muligheden for genbrug af allerede udviklede OIOXML schemaer. Herefter kan koden til den konkrete implementering genereres ud fra WSDL-dokumentet. Fremgangsmåde for udvikling af OIOWSDL KF-metoden kan beskrives ved følgende fire trin: 1. Finde/modellere datadefinitioner: Dette trin definerer, hvilke forretningsdata der skal anvendes i web servicen. Forretningsdata er beskrevet i OIOXML schemaer. De aktuelle OIOXML schemaer hentes eksempelvis i Infostrukturbasen (ISB en). 2. Modellere beskeddefinitioner: Her modelleres de beskeder, der skal udveksles mellem service-aftager og -udbyder. Beskederne beskrives i XML schemaer og anvender datadefinitionerne fra trin 1. I forbindelse med modellering af beskeder skal der også beskrives, hvorledes fejlmeddelelser returneres fra web servicen. Fejl returneres vha. soap fault. 3. Modellere grænsefladen: Dette trin definerer, hvilke operationer web servicen skal tilbyde. Operationerne grupperes i interfaces. Trinet afsluttes eventuelt med at teste den frembragte OIOWSDL-dokument 6 Disse regler findes i ITST s Navngivnings og Design Regler (NDR). 7 Udvikling af datadefinitioner ligger uden for denne vejlednings rammer. Der henvises til ITST s NDR og sektorstandardiseringsarbejde. 16

17 op imod WS-I Basic Profile Version 1.1 med WS-I tools8. Det skal bemærkes, at disse tools ikke kan afgøre, om alle profilens retningslinier er overholdt. 4. Generere kodeskabelon: Ud fra OIOWSDL-dokumentet genereres kodeskabeloner til henholdsvis klient (serviceaftager) og service (serviceudbyder). De fire trin er illustreret i Figur 12, hvor et antal datadefinitioner kombineres til beskeddefinitioner, som anvendes til grænsefladebeskrivelsen. På baggrund af grænsefladebeskrivelsen genereres koden til det aktuelle miljø, hvor Web Servicen implementeres. 8 Se 17

18 Da tadefinitio ner OIOXML Schema OIOXML Schema OIOXML Schema Non OIOXML Schema B eskeddefinitioner XML Schema XML Schema XML Schema G ræ nseflade OIO WSDL K odeskabeloner C# Java Ruby Figur 12 schematisk fremstilling af kontrakt-først fremgangsmåden Eksempel Lad os prøve at se på et realistisk eksempel. I forbindelse med projektet Hjemmesygeplejens adgang til Medicinprofilen under Lægemiddelstyrelsen (se er der udviklet en web service, der tillader registrering af håndkøbsmedicin, der er observeret i medicinskabet hos klienter i forbindelse med besøg fra hjemmeplejen. Dette er tiltænkt som en hjælp til at foregribe evt. interaktion med ordineret medicin. Web servicen gør det muligt at registrere observeret håndkøbsmedicin på klientens CPR-nr. samt at hente tidligere registreringer. Der vises kun operationen til at hente registreringer i det følgende. Det anvendte eksempel er vedlagt i appendiks bagest i dette dokument og kan desuden downloades fra sammen side som nærværende dokument. 18

19 Bemærk at eksemplets schema og WSDL-dokumenter er modificerede i forhold til Medicinprofilens i de tilfælde, hvor der er afvigelser fra nærværende vejledning. Dette er en konsekvens af, at Medicinprofilen er lavet før nærværende vejledning Trin 1: Modellering af datadefinitioner XML schema til web servicen består af en blanding af et antal nyudviklede, NDR kompatible schema er samt et enkelt schema fra OIO kerne-klassen (CPR-nr.). De anvendte schema er kan generelt deles op i: Basale databærende elementer, der via en eller flere simple typer - evt. med restriktioner - repræsenterer en enkelt type, f.eks. DKMA_DosageFormText.xsd (Appendiks: XSD schema er for eksempel). Sammensatte elementer, der kombinerer de basale elementer til kombinationer og sekvenser af elementtyper, f.eks. DKMA_DrugStructure.xsd (Appendiks: XSD schema er for eksempel) Generelt kan man sige, at mere sammensatte elementtyper er mere tilbøjelige til at være specifikke til en given webservice (f.eks. som et resultat, der består af en unik sammensætning af basale typer), mens de basale elementer vil være mere stabile på tværs af webservices. Det kan derfor give god mening at indlejre de mest sammensatte elementer i selve WSDL-dokumentet i stedet for at lave selvstændige XSD schema er på alle niveauer. Schemadefinitionerne er dog ikke indlejret i det WSDL-dokument, der vises her (se afsnittet nedenfor), men er i stedet refereret via et include- eller import-direktiv. Schema-definitionerne kan ses i deres helhed i Appendiks 9. Trin 2: Modellering af beskeddefinitioner I dette trin defineres en requestbesked, en responsebesked samt et fault detail element. Request-beskeden er baseret på elementtypen MedicineChestStructureGet (se Appendiks: XSD schema er for eksempel) og response-beskeden er defineret via elementypen MedicineChestStructure (se Appendiks: XSD schema er for eksempel). Fault-beskeden er defineret via elementtypen MedicineChestFault, hvis definition er indlejret i WSDLdokumentet. Beskeddefinitionerne kan findes i WSDL-dokumentet som de 3 <message> elementer, med name = hhv. "MedicineChestStructureGetRequest", "MedicineChestStructureGetResponse" samt "MedicineChestStructureFault". 19

20 Trin 3: Modellering af grænseflade I dette trin defineres et interface rummende en operation. Operationen er defineret ved den ovenfor beskrevne requestbesked, responsebesked samt fault detail elementet, og ser ud som følger: <operation name="medicinecheststructureget"> <input name="medicinecheststructuregetrequest" message="tns:medicinecheststructuregetrequest" /> <output name="medicinecheststructuregetresponse" message="tns:medicinecheststructuregetresponse" /> <fault name="fault" message="tns:medicinecheststructurefault" /> </operation> Det resulterende OIOWSDL-dokument bliver hermed som vist nedenfor: <?xml version="1.0" encoding="utf-8"?> <definitions xmlns=" targetnamespace=" xmlns:xsd=" xmlns:tns=" xmlns:soap=" <types> <xsd:schema elementformdefault="qualified" targetnamespace=" rep.oio.dk/dkma.dk/homecare/xml.schema/ "> <xsd:include schemalocation="../xsd/dkma_medicinecheststructureget.xsd"/> <xsd:include schemalocation="../xsd/dkma_medicinecheststructure.xsd"/> <xsd:element name="medicinecheststructurefault" type="xsd:string"/> </xsd:schema> </types> <message name="medicinecheststructuregetrequest"> <part name="cpr" element="tns:medicinecheststructureget"/> </message> <message name="medicinecheststructuregetresponse"> <part name="arg2" element="tns:medicinecheststructure"/> </message> <message name="medicinecheststructurefault"> <part name="fault" element="tns:medicinecheststructurefault"/> </message> <porttype name="medicinechest"> <operation name="medicinecheststructureget"> <input name="medicinecheststructuregetrequest" message="tns:medicinecheststructuregetrequest"/> <output name="medicinecheststructuregetresponse" message="tns:medicinecheststructuregetresponse"/> <fault name="medicinecheststructurefault" message="tns:medicinecheststructurefault"/> </operation> </porttype> (fortsættes på næste side) 20

21 <binding name="medicinechest" type="tns:medicinechest"> <soap:binding transport= style="document"/> <operation name="medicinecheststructureget"> <soap:operation soapaction= " rep.oio.dk/dkma.dk/homecare/xml.schema/ /#medicinechestget" style="document"/> <input name="medicinecheststructuregetrequest" > <soap:body use="literal"/> </input> <output name="medicinecheststructuregetresponse"> <soap:body use="literal"/> </output> <fault name="medicinecheststructurefault"> <soap:fault name="medicinecheststructurefault" use="literal"/> </fault> </operation> </binding> <service name="medicinechest"> <documentation>wsdl file for MedicineChest</documentation> <port name="medicinechest" binding="tns:medicinechest"> <soap:address location= " </port> </service> Trin 4: Generér kodeskabelon Service udbyder Service udbyderen implementerer den Web Service, som er specificeret af WSDL-dokumentet. Det generelle mønster for server-side implementeringen af en WSDL baseret Web Service er, at det valgte værktøj med WSDLdokumentet som input genererer skeleton og data-binding klasser/kode i det anvendte programmeringssprog. Derefter er det op til udvikleren at skrive serverside kode, der kan aktiveres via de genererede skeletons. Data-binding klasserne afspejler de XSD typer, som WSDL-dokumentet er baseret på og bruges til at repræsentere de overførte beskeder. Service aftager En service aftager vil generelt vha. det valgte client-side værktøj generere stub og data-binding klasser/kode. Udvikleren kan så anvende disse stubbe til at kalde web servicen. Det efterfølgende kapitel Hvordan anvendes OIOWSDL? rummer referencer til en række af de mest udbredte udviklingsværktøjer. 21

22 Hvordan anvendes OIOWSDL? (Værktøjsunderstøttelse) > Nærværende afsnit beskriver, hvorledes man på baggrund af et OIOWSDLdokument kan generere kode til klient og server. Det vil sige dels at implementere en web service (service-skeleton), der overholder OIOWSDL beskrivelsen, dels generere kode, der kan kalde web servicen (klientstubbe).. oiowsdl Generering af serviceskabelon/- skeleton til web servicen Generering af proxy klasse til klientapplikation Serviceskabelon Kommunikerer via OIOWSDL interface Proxy klasse De pt. (primo 2007) mest udbredte udviklingsværktøjer er blevet undersøgt for at se, hvordan de håndterer OIOWSDL-dokumenter, udviklet efter kontraktførst metoden. De undersøgte værktøjer er: BEA WebLogic 9.2 Axis 1.3 og 2 Eclipse 3.2 IBM Rational Application Developer 6.0, og 7.0.Net 1.1, 2.0 og 3.0 Ruby Der er ikke lavet udførlige beskrivelser for, hvordan man laver web services med de enkelte værktøjer. Udgangspunktet har i stedet været, at man følger værktøjets generelle fremgangsmåde for fremstilling af web services, og for hvert værktøj er gennemgået, hvad der dukker op i forbindelse med arbejdet med OIOWSDL-dokumenter. 22

23 Der vil således i den følgende gennemgang i høj grad være links til referencedokumentationen for det enkelte værktøj. I visse tilfælde vil femgangsmåden være at følge værktøjets dokumentation direkte. For hvert værktøj, der bliver gennemgået, følger en generel introduktion og derefter et afsnit for hhv. klientstubbe og service-skeleton. Som eksempel bruges medicinskabet (MedicineChest) omtalt i foregående kapitel. Det forudsættes at WSDL- og XSD-eksemplerne fra medicinskabet er kopieret ud i filer på den lokale disk. I praksis skal XSD-filer til udvikling af WSDLdokumenter hentes i det fælles servicekatalog, men under udviklingsarbejdet vil det ofte være en fordel at have kopier liggende lokalt; ikke mindst hvis man kombinerer XSD erne fra ISB en med egne/nyudviklede XSD er. Generelle problemer med imports Inden vi går i gang, er det vigtigt at identificere en meget udbredt implementations-detalje i værktøjerne. Visse XML-parsere tolker nemlig XSDspecifikationen meget hårdt og giver derfor fejl, når samme namespace importeres flere gange med forskellige schemalocations. Specifikationen siger følgende: "Note: The above is carefully worded so that multiple <import>ing of the same schema document will not constitute a violation of clause 2 of schema Properties Correct ( ), but applications are allowed, indeed encouraged, to avoid <import>ing the same schema document more than once to forestall the necessity of establishing identity component by component. Given that the schemalocation [attribute] is only a hint, it is open to applications to ignore all but the first <import> for a given namespace, regardless of the actual value of schemalocation, but such a strategy risks missing useful information when new schemalocations are offered." Med andre ord betyder det, at parsere der tolker specifikationen efter ovenstående, vil kun hente den først refererede XSD-fil og derefter gå ud fra, at den indeholder den komplette definition af det givne namespace. Denne parsning giver imidlertid problemer i forhold til OIOs NDR-standard, der siger, at et namespace splittes op, så hver type ligger i hver sin fil (afsnit 3.5 i NDR). I tilfælde, hvor der laves import af flere typer fra samme namespace, kan nogle parsere komme med fejl om, at alle andre typer end den første er udefineret. 23

24 Problemet er indtil videre set i Xerces-2 9 / JAXP 1.3 og.net 2.0 (.Net 1.1 har desuden et generelt problem med includes, men dette behandles særskilt i afsnittet vedr..net 1.1). Xerces-2/JAXP 1.3 er standard under Java5 og bruges bl.a. i WebLogic 9 og RAD 7.0. Løsninger Der foreslås to løsninger på problemet: 1. Inlining af typer. Ved trække alle definitioner ind i WSDL-filen, undgås include og import helt, og problemet forsvinder. 2. Generer en ny XSD-fil, der samler de nødvendige typer, som importeres i stedet for de enkelte typer. I vores eksempel kunne den f.eks. se således ud: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" xmlns:common=" rep.oio.dk/dkma.dk/common/xml/xsd/2006/05/11" targetnamespace=" 05/11" elementformdefault="qualified" attributeformdefault="unqualified"> <include schemalocation="dkma_drugidentifier.xsd" /> <include schemalocation="dkma_drugname.xsd" /> <include schemalocation="dkma_dosageformtext.xsd" /> <include schemalocation="dkma_drugstructure.xsd" /> </schema> Den anbefalede løsning er nr. 2, da den beholder opsplitningen og ikke kræver ændringer i eksisterende typer. I henhold hertil anbefales det, at der altid skal laves en XSD-fil, der inkluderer alle typer i et namespace, og som skal gøres tilgængelig sammen med de øvrige typer. Det skal understreges, at baggrunden for disse løsninger udelukkende er for at kunne anvende OIOWSDL ved kodegenerering i visse værktøjer. Det er således det oprindelige/generelle WSDL-dokument, der skal publiceres og ikke de to nævnte løsninger. 9 Xerces har dog følgende mulighed for at omgå problemstillingen med samme namespace på tværs af flere schema-locations: 24

25 BEA WebLogic 9.2 Introduktion Helt generelt genereres klientstubbe og service-skeletons via Ant. I Workshop er der mulighed for at generere samme features, men bruger man de muligheder, benyttes Eclipse WTP-funktionaliteten, der bruger Axis. WebLogic 9.2 har import-begrænsningen omtalt i starten af dette kapitel. Den letteste vej udenom dette er at oprette en ny XSD-fil, DKMA_Common.xsd, der indeholder XML en vist i afsnittet øverst i dette kapitel. Ret DKMA_MedicineChestItemChoiceStructure.xsd og indsæt <import namespace=" " schemalocation="common.xsd" /> i stedet for den eksisterende import Ret DKMA_MedicineChestItemStructure.xsd og gør det samme En anden mulighed er at konfigurere Xerces-2 til at indlæse alle schemalocations ved at sætte en feature på parseren. Hvis sættes til Boolean.TRUE, bruger parseren alle import statements. Problemet her er blot helt generelt, at parseren typisk ikke er tilgængelig, når der genereres stubbe, da den er pakket ind. Det er også muligt at implementere en ny schemafactory, som kan angives med en system property, men dette er også en ret ufleksibel løsning. Her fokuseres på generering af client-stubbe og service-skeletons ved hjælp af Ant, samt efterfølgende import af disse i Workshop. Start evt. med at oprette en ny server under File->New->Server. Brug standardindstillingerne på første side og vælg Next. Brug Configuration Wizard til at oprette et nyt domæne med support for Workshop (Tryk next, vælg Workshop for WebLogic platform, next, indtast nyt password, next, next, next, create, done. Herefter kan det det nye domæne vælges under Domain home. Domænet ligger i $BEA_HOME/user_projects/domains/base_domain. Tryk finish for at oprette serveren. Til classpath tilføjes WEBLOGIC_HOME/server/lib/weblogic.jar og WEBLOGIC_HOME/server/lib/xbean.jar, hvis source importeres i Workspace På runtime kommer der warnings omkring exception-typer, men det har ingen indflydelse på afviklingen, heller ikke i tilfælde hvor der rent faktisk kommer en exception. (Referencedokumentation for web services: og 25

26 Herefter er vi klar til at lave hhv. klient og service. Klientstubbe Opret evt. nyt Java Project i Workspace med de ønskede indstillinger, som beskrevet ovenfor. Først oprettes en build.xml med følgende indhold: <project> <taskdef name="clientgen" classname="weblogic.wsee.tools.anttasks.clientgentask" /> <target name="build-client"> <clientgen wsdl="wsdl/dkma_medicinechest.wsdl" destdir="gen" packagename="com.acme.test"/> </target> </project> Opret et nyt dir, WSDL, og kopier WSDL-filen hertil. Kopier evt. XSD-filer, så de ligger rigtigt i forhold til WSDL-filen. Ret build.xml så WSDL-attributten peger på den rigtige fil og packagename-attributten, så den peger på den pakke, hvor klientstubben skal ligge. Herefter køres $BEA_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh ant build-client Det genererede kode ligger nu i gen-directory et og kan pakkes sammen til en jar-fil med jar cf client.jar -C gen. Herefter kan de genererede stubbe anvendes i Workshop: 1. Refresh projektet 2. Højreklik på gen og vælg Build path->use as source folder 3. Højreklik på projektet og vælg Properties->Java Build Path-> Libraries a. Add Library->Server Runtime->Next->Finish b. Add Variable->WEBLOGIC_HOME->Extend-> server/lib/weblogic.jar c. Add Variable->WEBLOGIC_HOME->Extend-> server/lib/xbean.jar 4. Opret en ny klasse, fx com.acme.test.client med følgende i main - 26

27 metoden: MedicineChest_Impl service = new MedicineChest_Impl(); MedicineChestType port = service.getmedicinechestport(); MedicineChestStructureType type = new MedicineChestStructureType(); type.setpersoncivilregistrationidentifier(" "); MedicineChestStructureType medicinecheststructure = port.getmedicinecheststructure(type); Service-skeletons Opret nyt projekt, File->New->Project->Web Services->Web Service Project. Brug standardindstillingerne. Fremgangsmåden er den samme som for klientstubbe: Først oprettes en build.xml (eller et nyt target tilføjes til en eksisterende): <project> <taskdef name="wsdlc" classname="weblogic.wsee.tools.anttasks.wsdlctask"/> <target name="generate"> <wsdlc srcwsdl="wsdl/dkma_medicinechest.wsdl" destjwsdir="gen/jws" destimpldir="gen/impl" packagename="com.acme.wsdl" explode="true" /> </target> </project> Opret et nyt dir, WSDL, og kopier WSDL-filen hertil. Kopier evt. XSD-filer, så de ligger rigtigt i forhold til WSDL-filen. Ret build.xml så WSDL-attributten peger på den rigtige fil og packagename-attributten, så den peger på den pakke, hvor klikoden skal ligge. Herefter køres: $BEA_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh ant generate Det genererede kode er delt op i to dele: I gen/jws ligger autogenererede typer, der matcher dem der er defineret i XSD-filerne, og i gen/impl ligger skeletonklassen. I tilfældet med MedicineChest, ligger der en klasse ved navn MedicineChestImpl, der har en tom metode, der kan implementeres. Byg og deployment af en service er gennemgået på og I Workspace kan de genererede klasser nu bruges: 27

28 1. Refresh projektet 2. Tilføj gen/impl og gen/jws til build path som source folders 5. Højreklik på projektet og vælg Properties->Java Build Path- >Libraries og Add Variable->WEBLOGIC_HOME->Extend- >server/lib/xbean.jar 6. Åben typen MedicineChestImpl og implementer forretningslogik for servicen 7. Åben OwnerTypeTextType. Dette er en enumeration-klasse, og deploy vil fejle hvis den ikke får tilføjet en tom constructor. 8. DKMA_MedicineChest.wsdl i gen/jws/wsdls indeholder en tom nameattribut. Slet denne, da der ellers kommer valideringsfejl. 9. Tilføj projektet til WebLogic-serveren: a. Åben Servers-viewet b. Højreklik på BEA WebLogic v9.2 server og vælg Add and remove projects c. Tilføj service-projektet d. Start serveren e. Test servicen. WebLogics admin-interface har testfeature indbygget på -> Deployments->service-> MedicineChest->Testing->Expand MedicineChest->Test client RAD 6.0.0, RAD 6.0.1, RAD 7.0 Introduktion Referencedokumentation for web services: og RAD og RAD 7.0 har import-begrænsningen omtalt i starten af dette kapitel. Den letteste vej udenom dette er at oprette en ny XSD-fil, DKMA_Common.xsd, der indeholder XML en vist i afsnittet øverst i dette kapitel. Ret DKMA_MedicineChestItemChoiceStructure.xsd og indsæt <import namespace=" schemalocation="common.xsd" /> i stedet for den eksisterende import Ret DKMA_MedicineChestItemStructure.xsd og gør det samme RAD har ikke import-begrænsningen. Da JAX-RPC kun definerer optional support for <xsd:choice>, kan RAD ikke generere Java-klasser for dette. Det giver en WSWS2029W warning. (Se - der kræves en custom data binder, eller at <xsd:choice> skrives om til <xsd:sequence> med <xsd:element maxoccurs="1" minoccurs="0">. Sidstnævnte giver dog ikke helt samme semantiske betydning. Afsnit i NDR bemærker i øvrigt, 28

29 at choice kan være et usikkert valg. Start med at konfigurere en server: Højreklik i Servers-viewet og vælg New -> Server og vælg WebSphere 6.1 Server og finish. Ret XSD-filerne som beskrevet ovenfor, så alle typer fra et namespace ligger i samme fil. Klientstubbe For at skabe klientstubben udføres følgende trin: 1. Vælg New->Other->Web Services->Web Service Client 2. Vælg WSDL-filen under Service definition 3. Finish 4. Klienten kan nu bruges på følgende måde: Fejl! URL url = new URL(" MedicineChest service = new MedicineChestLocator().getMedicineChestPort(url); MedicineChestStructureType arg = new MedicineChestStructureType(); arg.setpersoncivilregistrationidentifier(" "); service.medicinecheststructureget(arg); Service-skeleton 1. Opret et nyt Dynamic Web Project med standardindstillinger 2. Kopier WSDL - og XSD-filer ind i det nye projekt 3. Vælg New->Other->Web Services->Web Service 4. Vælg Top down Java bean Web Service under Web service 5. Vælg wsdl-filen under Service definition 6. Finish RAD åbner automatisk Web Services Explorer, der kan bruges til at teste services. - Fold MedicineChest (det markerede element) ud og vælg medicinecheststructureget - Indtast en tekst på 10 tegn i tekstfeltet og tryk Go - Web Services Explorer kan åbnes ved at finde den lokale wsdlfil (WebContent/WEB-INF/wsdl/DKMA_MedicineChest.wsdl), højreklikke på den og vælge Web Services->Test with Web Services Explorer. Åben typen MedicineChestImpl og implementer forretningskoden. Deploy til serveren (hvis det er nødvendigt) ved at højreklikke på serveren i Servers-viewet og vælge Publish. 29

30 Axis 1.3 Introduktion Generering af både klientstubbe og service-skeleton følger referencedokumentationen for WSDL-drevet udvikling: Bemærk, at ved arrays indeholder det genererede xml <Item> tags i stedet for f.eks. <MedicineChestItemStructure>. Hvis man eksempelvis erklærer følgende type: <complextype name="pharmacycollectiontype"> <sequence> <element ref="pharmacystructure" minoccurs="0" maxoccurs="unbounded"/> </sequence> </complextype> <element name="pharmacystructure" type="common:pharmacystructuretype"/> <complextype name="pharmacystructuretype"> <sequence>... </sequence> </complextype> medfører det, at Axis serialiserer arrayelementerne med elementnavnet item i stedet for PharmacyStructure som XSD'en foreskriver. Dette optræder kun ved arrays, dvs. ved maxoccurs > 1. Dette er ikke et problem, hvis både servicen og klienten er udviklet i Axis, men det er det, hvis klienten eksempelvis er.net. For at opnå den fornødne interoperabilitet kan man derfor i stedet inline definitionen som følger: <complextype name="pharmacycollectiontype"> <sequence> <element name="pharmacystructure" type="common:pharmacystructuretype" minoccurs="0" maxoccurs="unbounded"/> </sequence> </complextype> Dette medfører dog, at OIOs standarder ikke overholdes! Problemet er rettet i Axis Klientstubbe Anvend WSDL-to-Java-tool et i klassen org.apache.axis.wsdl.wsdl2java: 30

31 java org.apache.axis.wsdl.wsdl2java DKMA_MedicineChest.wsdl (Bemærk, at der findes også Ant-targets og et par shell scripts, som udfører kommandoen). Dette skaber alle klient-stubbene, som bliver lagt i et directory, som afspejler target-namespace fra WSDL-filen; dvs. i dette tilfælde bliver de lagt under dk/dkma/homecare. Service-skeleton Akkurat som ved klient-stub-generering, anvendes WSDL2Java til at generere service-skeleton med; denne gang blot med et par server side options: % java org.apache.axis.wsdl.wsdl2java --server-side --skeletondeploy true DKMA_MedicineChest.wsdl Dette genererer faktisk også klient-stubbene, men derudover også skeletonklasserne til server side implementationen. Axis2 Introduktion Både klient-stubbe og service-skeletons genereres som beskrevet i referencedokumentationen: Klient-stubbe: Service-skeletons: Axis2 lider af samme problematik omkring <item> som Axis1. Problemet er rettet i Axis Klient Stubbene genereres kort og godt med wsdl2java kommandoen: %AXIS2_HOME%\bin\wsdl2java -uri DKMA_MedicineChest.wsdl -p <package> s hvor - p angiver package for de genererede stubbe - s angiver synkron/blokerende kald. Service-skeleton Skeletonklasserne genereres med wsdl2java kommandoen med lidt ekstra options: 31

32 %AXIS2_HOME%\bin\wsdl2java -uri DKMA_MedicineVhest.wsdl -p <package> -o <directory> -s -ss sd - hvor - p angiver package for de genererede klasser - -o angiver directory for de genererede packages - -s angiver synkron/blokerende opførsel - -ss angiver, at det er serverside generering - -sd angiver, at services.xml service-descriptoren skal skabes. Eclipse Introduktion Understøttelse for web services i Eclipse kommer via Web Tools Project et (WTP), som kan findes på WTP bruger Axis 1.3 til at generere kode; se afsnit vedr. problemer med arrays. Klientstubbe Genereringen af klient-stubbene følger vejledningen her: rviceclient/webserviceclient.html. Service-skeleton På serversiden følges denne vejledning/tutorial til at implementere en serviceskeleton : /TopDownWebService/TopDownWebService.html.NET 1.1 Introduktion Klientstubbe og service-skeletons bygges ved hjælp af wsdl.exe. Referencedokumentation for wsdl.exe: Overvej evt. at bruge WSCF fra t.html 32

33 I.Net 1.1 virker det helt generelt ikke at bruge include i en XSD-fil. I stedet skal alle typer indlejres. Dette er omtalt meget udførligt her: Et andet work-around er at kopiere wsdl.exe fra en Mono-installation under f.eks. Linux; den har ikke samme problem. WSDL-filen med indlejrede definitioner er vist i appendiks 11. Bemærk, at med discover-tool et, disco.exe, kan alle typerne downloades til den lokale disk. disco.exe tager den komplette url til wsdl-filen som argument, evt. angivet som UNC-sti (\\<server>\<share>). Dvs. i vores tilfælde kunne kommandoen se ud som følger: disco.exe c:\dkma-eksempel\wsdl\dkma_medicinechest.wsdl Klientstubbe For at anvende de lokale kopier af XSD erne i stedet for at hente dem i ISB en (dette vil ofte være en fordel i udviklingsfasen), skal hele listen af importerede (ikke de inkluderede, som er blevet lavet om til indlejrede) XSD er angives på kommandolinien. I vores eksempel har vi indlejret hele striben af XSD er, så den komplette kommando-linie er dermed reduceret til: wsdl.exe DKMA_MedicineChest.wsdl Dette vil skabe filen MedicineChest.cs med metoden: public MedicineChestItemStructureType[] MedicineChestStructureGet(...) Service-skeleton Generereingen af service-skeleton er helt parallel med genereringen af klientstubbene, blot skal /server optionen med til kommandoen: wsdl.exe /server DKMA_MedicineChest.wsdl - hvilket genererer filen med service-skeleton, den abstrakte klasse, MedicineChest.cs 33

34 .Net 2.0 Introduktion Som på.net 1.1, bygges klientstubbe og service-skeletons ved hjælp af wsdl.exe. Referencedokumentation for wsdl.exe: Overvej evt. at bruge WSCF fra t.html Include-problematikken fra.net 1.1, er rettet i.net 2.0, men.net 2.0 har import-problematikken omtalt i starten af dette kapitel. Det kommer dog kun til udtryk som en advarsel og ikke en egentlig fejl. Advarslen siger (også på en dansk installation): Warning: Schema could not be validated. Class generation may fail or may produce incorrect results. De genererede klassefiler er dog fejlfri. Bemærk, at med discover-tool et, disco.exe, kan alle typerne downloades til den lokale disk. disco.exe tager den komplette url til wsdl-filen som argument, evt. angivet som UNC-sti (\\<server>\<share>). Dvs. i vores tilfælde set kommandoen ud som følger: disco.exe c:\dkma-eksempel\wsdl\dkma_medicinechest.wsdl Klientstubbe For at anvende de lokale kopier af XSD erne i stedet for at hente dem i ISB en, skal hele listen af både inkluderede og importerede XSD er angives på kommandolinien. Eventuelt indlejrede typer skal ikke angives på kommandolinien. Da XSD-filerne i eksemplet refereres relativt som../dkma_xxx.xsd forventes det, at der eksisterer to directories kaldet xsd og wsdl, og at hhv. alle XSD-filerne og WSDL-filen ligger i de to respektive directories. Den følgende kommando udføres fra xsd-directoriet og vil generere sourcefilen til klienten: 34

35 wsdl.exe..\wsdl\dkma_medicinechest.wsdl DKMA_DosageFormText.xsd DKMA_DrugIdentifier.xsd DKMA_DrugName.xsd DKMA_DrugStrengthText.xsd DKMA_DrugStructure.xsd DKMA_MedicineChestStructureGet.xsd DKMA_MedicineChestItemChoiceStructure.xsd DKMA_MedicineChestItemDate.xsd DKMA_MedicineChestItemIdentifier.xsd DKMA_MedicineChestItemStructure.xsd DKMA_MedicineChestItemVersionIdentifier.xsd DKMA_MedicineChestStructure.xsd DKMA_OwnerTypeText.xsd CPR_PersonCivilRegistrationIdentifier.xsd Dette vil skabe MedicineChest.cs (Bemærk, at CPR_PersonCivilRegistrationIdentifier.xsd er downloadet til den lokale disk og derfor er med på kommandolinien). Service-skeleton Generereingen af service-skeleton er helt parallel med genereringen af klientstubbene, blot skal /serverinterface optionen med til kommandoen. Bemærk, at på.net 1.1 hedder denne option /server. Dette er depricated på.net 2.0, her hedder den /serverinterface. Hvis man angiver /server på.net 2.0, ignoreres dette, og det er klientdelen, man får skabt! Kommandoen er derfor: wsdl.exe /serverinterface..\wsdl\dkma_medicinechest.wsdl DKMA_DosageFormText.xsd DKMA_DrugIdentifier.xsd DKMA_DrugName.xsd DKMA_DrugStrengthText.xsd DKMA_DrugStructure.xsd DKMA_MedicineChestStructureGet.xsd DKMA_MedicineChestItemChoiceStructure.xsd DKMA_MedicineChestItemDate.xsd DKMA_MedicineChestItemIdentifier.xsd DKMA_MedicineChestItemStructure.xsd DKMA_MedicineChestItemVersionIdentifier.xsd DKMA_MedicineChestStructure.xsd DKMA_OwnerTypeText.xsd CPR_PersonCivilRegistrationIdentifier.xsd Dette skaber den abstrakte klasse til implementationen af web servicen, MedicineChest.cs.NET 3.0 Introduktion.NET Framework version 3.0 indeholder Windows Communication Framework (WCF). WCF rummer sit eget program til kodegenerering ud fra en 35