Basic Profile. SHS Version 2.0 SOAP-based Protocol. Utgåva PA SHS Version 2.0 SOAPbased Protocol Basic Profile 1 (10)

Relevanta dokument
RIVTA Basic Profile 2.1

RIV TA Basic Profile 2.1 med intygspropagering RIV Tekniska Anvisningar

RIV TA Basic Profile 2.1 RIV Tekniska Anvisningar

RIV TA Basic Profile 2.1

RIV TA Domänschema 2.1

RIV TA Domänschema 2.1

RIV Tekniska Anvisningar 2.1

RIV Tekniska Anvisningar Release notes

SHS Version 2.0 SOAP-based Protocol Översikt

RIV Tekniska Anvisningar Basic Profile Valfria tillägg

RIV TA Tjänsteschema 2.1 RIV Tekniska Anvisningar

RIV Tekniska Anvisningar Tjänsteschema

RIV Tekniska Anvisningar Tjänsteschema

Policy för öppen källkod RIV Tekniska Anvisningar

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1

Sammansatt bastjänst för grundläggande uppgifter om företag

Sammansatt bastjänst för engagemang i företag

Sammansatt bastjänst för engagemang i företag

RIV Tekniska Anvisningar Översikt

Hantera informationspaket i system för bevarande

RIV Tekniska Anvisningar Översikt Utgåva E

Serverat och kommunal arkitektur

Sammansatt bastjänst för grundläggande uppgifter om företag

Sammansatt bastjänst för roll i företag

RIV Tekniska Anvisningar Översikt

RIV TA Konfigurationsstyrning 1.0 RIV Tekniska Anvisningar

RIV Tekniska Anvisningar Översikt Utgåva PD

XML-produkter. -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: Version: 1.

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.3

Anvisning för Svensk Livfaktura

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0

Handledning Konfigurationsstyrning tjänstedomäner

Konfigurationsstyrning tjänstedomäner ARK_0007. Version

Heldag om FGS FGS:er och deras tekniska regelverk. Karin Bredenberg, FGS funktionen. Standarder. FGS:er och deras tekniska regelverk 1

Sammansatt bastjänst för grundläggande uppgifter om företag

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0

Delrapport DP3. FGS för paketstruktur för e-arkiv Bilaga 1 METS

Förvaltningsgemensam specifikation för leverans av enstaka publikationer till Kungliga biblioteket (FGS-PUBL)

Dokumentschema förpackning av externa objekt. Version: 1.0 Status: Standard Datum:

Elektronisk tullräkning Sid 1(9) Samverkansspecifikation. Version: 1.0 SAMVERKANSSPECIFIKATION. för. e-tullräkning

E-pliktleverans via RSS-feeds

Webbteknik II. Föreläsning 4. Watching the river flow. John Häggerud, 2011

LEFI Online. Anslutningsinformation

Underlag för godkännande av tjänsteproducent

Version: 2.0 NBS / / AS

Heldag om FGS Att ta fram en FGS. Jan Aspenfjäll. FGS projekt

SOA. Länkar +ll sidor om SOA h3p:// h3p://dsv.su.se/soa/

Version: 2.0 NBS / / AS

DP7 Kompletterande information

Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP)

Kom-och-fika Öppna system & E-tjänster.

Innehåll Introduktion... 3 InteractiveScene.config... 3 Scener <scenes>... 3 Typsnitt <fonts>... 3 Övergångar <transitions>...

Webbtjänster med SOAP, uppbyggnad och implementation

Handledning. Konfigurationsstyrning tjänstedomäner. Version ARK_

EBITS Energibranschens IT-säkerhetsforum

Läs mer om SLL:s Regionala Tjänsteplattform (RTP)

FHIR OCH INTEROPERABILITET I SJUKVÅRDEN OSKAR THUNMAN

Webbtjänster med API er

Vad gör en åsna i vården? Mats Ekhammar

Handledning. Konfigurationsstyrning tjänstedomäner. Version ARK_

Tjänstekontraktsbeskrivning - Terminologitjänsten

Beställning av samverkan över flera tjänsteplattformar

Tjänstespecifik teststrategi. För anslutning till tjänsteplattform för vård- och omsorgsutbud

Kärnfunktionalitet. Middleware. Samverkande system. Service Oriented Architecture. Kommunikationsmekanismer. Tjänsteorienterade arkitekturer

Avisering av förändringar i tjänstekontrakt för Mina Meddelanden

Beställningsstöd för anslutning till NTJP

Utveckling av tjänster

SSEK version 2.0. Säkra webbtjänster för affärskritisk kommunikation

Introduktion till integrering av Schenkers e-tjänster. Version 2.0

RDT Externt Webbtjänst Gränssnitt

Bas - Utvecklingsstöd

Sändning av uppgifter Scheman Makuleringsuppgifter Anläggningsprojekt för ett nationellt inkomstregister

Projektet NCTS (New Computerised Transit System) är ett EU-projekt som utvecklats inom ramen för de verksamheter som organisatoriskt bedrivs av:

Sändning av uppgifter Scheman Meddelanden Anläggningsprojekt för ett nationellt inkomstregister

Arkitektur för Bistånd

Hyperlänkar. I HTML skapar man en hyperlänk med taggen <a> </a>, som är en förkortning av ordet ankare, på (engelska anchor).

Tekniskt ramverk för Svensk e- legitimation

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.

ISO general purpose metric screw threads Selected sizes for screws, bolts and nuts

Dataproduktspecifikation Projektionszoner Sweref 99 Trafikverket. Version 5.0

RDT Externt Webbtjänst Gränssnitt

En snabb titt på XML LEKTION 6

Anvisning Tjänsteplattformen Driftsättning av Virtualiseringsplattformen

Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.

UC API Teknisk referens för UC:s svenska personinformation

Tillämpningsanvisningar

Certifikattjänsten - testbädd. Anläggningsprojekt för ett nationellt inkomstregister

HANDLEDNING TILL TEKNISK BILAGA - TB 2007

Certifikattjänsten Beskrivning av gränssnittet Inkomstregisterenheten

Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg

Retrieve a set of frequently asked questions about digital loans and their answers

Webbtjänster med API er

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer.

Referensarkitektur: T-boken, RIV-TA och tjänstekontrakt Referensimplementationen av T-boken: SKLTP

Förvaltningsgemensam specifikation för leverans av enstaka publikationer till Kungliga biblioteket (FGS-PUBL)

Teknisk guide för brevlådeoperatörer. Annika Melin Version: 1.1

E-legitimationsdagen dag 2. En översikt av eidas-arkitekturen och E-legitimationsnämndens erbjudande

Transkript:

Profile 1 (10) SHS Version 2.0 SOAP-based Protocol Basic Profile Försäkringskassan - Swedish Social Insurance Agency Utgåva PA3 Copyright 2012, 2013 Swedish Social Insurance Agency. All Rights Reserved. SHS Version 2.0 SOAP-based Profile.docx

Profile 2 (10) Utgåvehistorik Utgåva Revision Datum Beskrivning Ändringarna gjorda av PA1 2012-04-10 Skapat dokument med bas i RIV TA BP 2.1 anders.asplund@ca llistaenterprise.se Definitiv revision fastställd av PA2 2012-05-02 Återinfört Uppdrag-Resultat och Informationsspridning anders.asplund@ca llistaenterprise.se 2012-10-12 SHS Version 2.0, efter 1 a remiss PA3 Slutgiltig version SHS 2.0 SHS Version 2.0 SOAP-based Profile.docx

Profile 3 (10) INNEHÅLLSFÖRTECKNING 1. INLEDNING 4 1.1. MÅLGRUPP 4 1.2. SYFTE 4 1.3. TILLGÄNGLIGHET 4 1.4. UPPHOVSMAN 5 1.5. REFERENSER 5 2. BESKRIVNING AV NAMNREGLER 6 3. FÖLJSAMHET MOT EXTERNA REGELVERK 6 REGEL #1, FÖLJSAMHET MOT WS-I-PROFILER 6 4. UNDANTAG FRÅN WS-I BASIC PROFILE 6 REGEL #2, BILAGOR 6 5. DETALJERADE REGLER 6 REGEL #3, NAMNGIVNING AV WSDL-FIL 6 REGEL #4, NAMN PÅ <DEFINITIONS>-ELEMENT 6 REGEL #5, NAMN PÅ TARGET NAMESPACE 6 REGEL #6 DOKUMENTATION AV TJÄNSTEINTERAKTION 7 REGEL #7 KRYPTERING OCH AUTENTISERING 7 REGEL #8 DOCUMENT/LITERAL 7 REGEL #9, NAMN PÅ <PORTTYPE>-ELEMENT 8 REGEL #10, NAMN PÅ <BINDING>-ELEMENT 8 REGEL #11, NAMN PÅ <SERVICE>-ELEMENT 8 REGEL #12, NAMN PÅ <PORT>-ELEMENT 8 REGEL #13, NAMN PÅ <MESSAGE>-ELEMENT 8 REGEL #14, NAMN PÅ <OPERATION>-ELEMENT 8 REGEL #15, VÄRDE FÖR SOAPACTION-ATTRIBUT 9 REGEL #16, TARGETNAMESPACE I SCHEMA:IMPORT 9 REGEL #17, FÖRHÅLLANDET MELLAN PORTTYPE OCH OPERATIONER 9 6. TJÄNSTEKOMPONENTER 9 REGEL #18, WSDL-FIRST 9 REGEL #19, UPPBYGGNAD AV URL FÖR TJÄNSTEPRODUCENT 9 REGEL #20, META-DATA I RUN-TIME 10 SHS Version 2.0 SOAP-based Profile.docx

Profile 4 (10) 1. Inledning Detta dokument beskriver regelverket för SHS Version 2.0 SOAP-based Profile. 1.1. Målgrupp Denna anvisning riktar sig till dem som ska specificera WSDL för en tjänsteinteraktion i enlighet med den tekniska SHSprofil som benämns Basic Profile. Anvisningen innehåller endast regeluppsättningen som definierar profilen. För bakgrund, motiv, krav samt de principer som ligger till grund för utvecklingen av profilen hänvisas till SHS Version 2.0 SOAP-based Protocol Översikt [R2]. 1.2. Syfte Syftet med denna anvisning är att beskriva hur man realiserar utbytet av information mellan två parter på ett interoperabelt sätt baserat på WS-I Basic Profile v1.1 synkrona (Fråga-Svar) tjänsteinteraktioner: Regler och riktlinjer för framtagning av WSDL-filer Baserad på SHS Version 2.0 SOAP-based Protocol Tjänsteschema [R2] Baserad på WS-I Basic Profile v1.1 [R3] och WS-I Simple SOAP Binding Profile v1.0 [R4] Protokollbaserad säkerhet, HTTPS, med användande av ömsesidig autentisering för säker identifiering av sändande tjänstekomponent Riktlinjer för versionshantering av WSDL Exempel på WSDL som följer denna anvisning finns på Försäkringskassans hemsida tillsamman med exempelapplikationer som visar hur konsumenter och producenter kan utvecklas i Java och.net för tjänsteinteraktioner som följer denna profil. 1.3. Tillgänglighet Specifikationerna för SHS Version 2.0 publiceras på Försäkringskassans hemsida www.fk.se. SHS Version 2.0 SOAP-based Profile.docx

Profile 5 (10) 1.4. Upphovsman SHS Version 2.0 SOAP-based Protocol är framtagen av Försäkringskassan och baserad på RIV TA version 2.1 med upphovsman SKL(Sveriges Kommuner och Landsting). 1.5. Referenser Ref Dokument Beskrivning och ev. webbadress Ansvarig [R1] SHS Version 2.0 SOAP-based Protocol Översikt [R2] SHS Version 2.0 SOAP-based Protocol Tjänsteschema Bakgrund, motiv, krav samt de principer som ligger till grund för utvecklingen av denna anvisning. Anvisning för att specificera ett XML-schema (tjänsteschema) för ett tjänstekontrakt. Definierar elementen för WSDL-filens meddelanden. Försäkringskassan Försäkringskassan [R3] WS-I Basic Profile Defines the WS-I Basic Profile 1.1, consisting of a set of nonproprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability Weblänk till WS-I Basic Profile: http://www.wsi.org/profiles/basicprofile-1.1.html The Web Services Interoperability Organization och ISO [R4] WS-I Simple Soap Binding Profile Defines the WS-I Simple SOAP Binding Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability The Web Services Interoperability Organization Weblänk till profilen : http://www.wsi.org/profiles/simplesoapbindingprofile-1.0.html [R5] SOAP 1.1 spec Definierar ett XML-baserat protokoll för utbyte av information. Är grunden för den standardisering som går under benämningen web services. Webblänk till specifikationens hemsida: http://www.w3.org/tr/2000/note-soap-20000508/ [R6] WSDL 1.1 spec Beskrivningsspråk för web-services. Syftar till att stödja utvecklingsverktyg i design-time och web-service-konsumenter i runtime. Webbänk till specifikationens hemsida: http://www.w3.org/tr/wsdl [R7] XOP 1.0 Del av standard för hantering av bilagor. Webblänk till specifikationens hemsida: http://www.w3.org/tr/xop10/ [R8] MTOM Del av standard för hantering av bilagor. Webblänk till specifikationens hemsida: http://www.w3.org/tr/soap12-mtom/ W3C W3C W3C W3C SHS Version 2.0 SOAP-based Profile.docx

Profile 6 (10) 2. Beskrivning av namnregler Denna profils namn är SHS Version 2.0 SOAP-based Profile 1.0 och refereras ${profil} Denna profils kortnamn är shsbp10 och refereras ${profilkortnamn} Namngivningsregler i detta dokument är formulerade enligt följande uppställning: 1. Tjänstedomänens namn: ${tjänstedomän}, t ex itintegration:monitoring 2. Tjänsteinteraktionens namn: ${tjänsteinteraktion}, t ex MakeBooking 3. Tjänsteinteraktionsroll: ${roll} = Initiator eller Responder, motsvarande tjänsteinteraktionsroller initiativtagare och utförare 4. Tjänsteinteraktionens version: m.n = förkortning av ${majorversion}.${minorversion} m = förkortning av ${majorversion} 5. Operationens namn: ${operation}, t ex MakeBooking 3. Följsamhet mot externa regelverk Här definieras de externa regelverk (t.ex. profiler) som utgör regelbas för denna profil. Det är en målsättning att denna profil ska kunna läsas uppifrån och ner utan detaljerad kunskap om externa regelverk. För regler som inte lyfts fram i denna profil (av förbiseende eller för att de inte bedömts viktiga) hänvisas till de externa regelverk som redovisas här. Regel #1, Följsamhet mot WS-I-profiler Utforming av WSDL skall följa WS-I Basic Profile v1.1 [R3] och WS-I Simple SOAP Binding Profile v1.0 [R4] förutom i explicit beskrivna fall. Motiv: Interoperabilitet 4. Undantag från WS-I Basic Profile Regel #2, Bilagor Bilagor skall kunna hanteras enligt XML-binary Optimized Packaging (XOP) och Message Transmission Optimization Mechanism (MTOM). För detaljer se [R7] och [R8]. Motiv: Det finns ett identifierat behov att hantera bilagor 5. Detaljerade regler Regel #3, Namngivning av WSDL-fil WSDL-filen bör namnges enligt följande regel: ${tjänsteinteraktion}interaction_${m.n}_${profilkortnamn}.wsdl Motiv: Minska risk för missförstånd rörande vilken version som används Exempel: MakeBookingInteraction_1.0_SHSBP10.wsdl Regel #4, namn på <definitions>-element Name-attributet för elementet wsdl:definitions bör ges värde enligt följande regel: ${tjänsteinteraktion}interaction Motiv: Enhetlighet Exempel: MakeBookingInteraction Regel #5, namn på target namespace Namn på target namespace skall vara urn:shs:${tjänstedomän}:${tjänsteinteraktion}:m:${profilkortnamn} SHS Version 2.0 SOAP-based Profile.docx

Profile 7 (10) Motiv: Suffixet shsbp10 skall anges för att markera att wsdl'en är designad för att följa SHS Version 2.0 SOAP-based Profile v1.0. Versionsnumret saknar praktisk betydelse i WSDL:ens namnrymd, men är avgörande för versionering i tjänstescheman. Eftersom samma versionsnummer ska användas genomgående inom en tjänsteinteraktion blir konsekvensen att targetnamespace är angeläget att styra även för WSDL. Exempel: urn:shs:crm:scheduling:makebooking:1:shsbp10 Regel #6 Dokumentation av tjänsteinteraktion Första elementet under wsdl:definitions bör dokumenteras enligt följande uppställning: <wsdl:documentation> Tjänsteinteraktionens namn: ${tjänsteinteraktion} Beskrivning: ${beskrivande text för tjänsteinteraktionen} Revisioner: ${datum för version m.n} Version ${m.n} i lista Tjanstedoman: ${tjänstedomän} Tjansteinteraktionstyp: Ett av Fraga-svar, Informationsspridning, Uppdrag-resultat SHS Version 2.0 SOAP-based Protocol ${profil} Forvaltning: Referens till information om förvaltningsprocess för tjänsteinteraktionen </wsdl:documentation> Motiv: Underlätta användning och förvaltning. Exempel: <wsdl:documentation> Tjänsteinteraktionens namn: MakeBookingInteraction Beskrivning: Interaction to make a new booking. Revisioner: 2009-10-26: Utkast Version 1.0, <person>@<organisation> 2010-04-21: Fastställd version 1.0, <person>@<organisation> 2011-03-XX: Fastställd version 1.1, <person>@<organisation> - Se ändringslog i tjänsteschema Tjänstedomän: crm:scheduling SHS Version 2.0 SOAP-based Profile 1.0 Förvaltas av: Försäkringskassan </wsdl:documentation> Regel #7 Kryptering och Autentisering HTTPS med ömsesidig autentisering skall användas för autentisering av tjänsteproducent och tjänstekonsument samt för kryptering av meddelandeutbyte. Om elementet shs-label innehåller en from-adress (<shs:from>) skall denna valideras mot identiteten i det använda autenticeringscertifikatet. Det här fallet gäller normalt sett enbart i kommunikationen mellan SHS-noder. Motiv: Insynsskydd, oavvislighet m.a.p. parternas identitet och möjlighet för tjänsteproducent att verifiera teknisk anropsbehörighet. Exempel: Regel #8 Document/Literal För konsistent namngivning och ökad förståelse skall följande regler följas: "SOAP binding style" skall sättas till "document" "SOAP body use" skall sättas till "literal" Varje wsdl:message skall ha en och endast en wsdl:part för soap-bodyn, som skall vara namnsatt till "parameters" Varje message-element som inte är av schema-grundtyp skall referera till ett XML Schema element ur ett importerat (xsd:import) tjänsteschema ur samma tjänsteinteraktion som denna WSDL. SHS Version 2.0 SOAP-based Profile.docx

Profile 8 (10) XML Schema-elementet för "input message" skall vara namnsatt till operationens namn. Se SHS Version 2.0 SOAPbased Protocol Tjänsteschema [R2] för definition av element som refereras från wsdl:message XML Schema elementet för "output message" skall vara namnsatt till operationens namn + suffix "Response". Se SHS Version 2.0 SOAP-based Protocol Tjänsteschema [R2] för definition av element som refereras från wsdl:message. Motiv: Verktygsinteroperabilitet och följsamhet mot WS-I Basic Profile 1.1. Exempel: Regel #9, namn på <porttype>-element Name-attributet för elementet wsdl:porttype bör ha värde enligt följande regel: ${tjänsteinteraktion}${roll}interface. Motiv: Enhetlighet och koppling till referensarkitekturens terminologi Exempel: MakeBookingResponderInterface Regel #10, namn på <binding>-element Name-attributet för elementet wsdl:binding bör ha värde enligt följande regel: ${tjänsteinteraktion}${roll}binding. Motiv: Enhetlighet och koppling till referensarkitekturens terminologi Exempel: MakeBookingResponderBinding Regel #11, namn på <service>-element Name-attributet för elementet wsdl:service bör ha värde enligt följande regel: ${tjänsteinteraktion}${roll}service. Motiv: Enhetlighet och koppling till referensarkitekturens terminologi Exempel: MakeBookingResponderService Regel #12, namn på <port>-element Name-attributet för elementet wsdl:port bör ha värde enligt följande regel: ${tjänsteinteraktion}${roll}port. Motiv: Enhetlighet och koppling till referensarkitekturens terminologi Exempel: MakeBookingResponderPort Regel #13, namn på <message>-element Name-attributet för elementet wsdl:message skall ha värde enligt följande regler: In-meddelande skall namnges ${operation}request Ut-meddelande skall namnges ${operation}response Motiv: Konsekvent namngivning Exempel: MakeBookingRequest respektive MakeBookingResponse Regel #14, namn på <operation>-element Name-attributet för elementet wsdl:operation skall ha värde enligt följande regel: ${operation} Motiv: Konsekvent namngivning SHS Version 2.0 SOAP-based Profile.docx

Profile 9 (10) Exempel: MakeBooking Regel #15, värde för soapaction-attribut soapaction-attributet för elementet soap:operation skall ha värde enligt följande regel: urn:shs:${tjänstedomän}:${tjänsteinteraktion}${roll}:m:${operation} Motiv: När man följer WS-I Basic Profile har soapaction-attributet på operatonsbindningen för soap-binding ingen praktisk verkan. Det är istället viktigt att Qualified Name för varje operations meddelande ger en unik signatur. Se WS-I Basic profile 1.1, Appendix C - operation signatur och R1127. För interoperabilitet med Microsoft.Net-baserade tjänsteproducenter (WCF) måste dock soapaction sättas till ett för ändpunkten unikt värde. Denna regel anger att soapaction skall ha samma innehåll som "operation signature", vilket är tjänsteschemats namnrymd och elementnamnet på operationens "input message" (d.v.s. request-elementets namnrymd och namn). Exempel: urn:shs:crm:scheduling:makebookingresponder:1:makebooking Regel #16, targetnamespace i schema:import Vid import av scheman i WSDL-filen skall targetnamespace anges för xs:schema-elementet. Värdet på targetnamespaceattributet skall vara samma som WSDL:ens targetnamespace. Motiv: WS-I Basic Profile kräver ej den här ändringen men Microsoft s BizTalk kan inte importera WSDL-filen om inte targetnamespace anges på xs:schema elementet. Av den här anledningen skall man alltid ange targetnamespace för att få ökad interoperabilitet. WS-I tillåter inte att targetnamespace är samma som det importerade schemats namnrymd. Exempel: <wsdl:types> <xs:schema targetnamespace="urn:shs:crm:scheduling:makebooking:1:shsbp10"> <xs:import schemalocation="makebookingresponder_1.1.xsd" namespace="urn:shs:crm:scheduling:makebookingresponder:1"/> </wsdl:types> Regel #17, Förhållandet mellan porttype och operationer Endast en operation per porttype och en porttype per tjänsteschema. Det betyder att en wsdl-fil antingen har en eller två porttypes: WSDL-filen för en fråga-svar-interaktioner och en infotmationsspridningsinteraktioner har en porttype medan uppdrag-resultat-interaktioner har två porttypes. Motiv: Möjliggöra versionshanteringstrategin som beskrivs i SHS Version 2.0 SOAP-based Protocol Översikt Exempel: Se WSDL för referensapplikationen 6. Tjänstekomponenter Regel #18, WSDL-first Tjänstekonsumenter och tjänsteproducenter skapas genom s.k. wsdl-first. Det betyder att WSDL-filen för tjänsteinteraktionen definierar hur tjänsteproducentens gränssnitt ser ut, vanligen genom kodgenerering från WSDL-fil. Det samma gäller tjänstekonsumenter. Motiv: Säkerställa att tjänstekomponenter följer interaktionens tjänstekontrakt. Exempel: Se kodgenereringsskript för referensapplikationen Regel #19, Uppbyggnad av URL för tjänsteproducent SHS Version 2.0 SOAP-based Profile.docx

Profile 10 (10) SOAP-adressen för en driftsatt tjänsteproducent ska som del av URL:en ange SHS-profilens kortnamn och huvudversionen. Underversion får ej anges i URL:en. Motiv: Möjliggöra realisering av den versionsstrategi som stödjs av tjänstekontrakt som tagits fram enligt denna profil samt att parallellt erbjuda stöd för flera SHS profil-versioner mot samma tjänst (t.ex. shsbp10 och shsbpip10). Exempel: https://tidbok.landsting.sjunet.org/makebooking/1/shsbp21 Regel #20, Meta-data i run-time Det är INTE obligatoriskt för en tjänsteproducent att i runtime (t.ex. med?wsdl som suffix på soap-adressen) kunna återskapa den WSDL som låg till grund för utvecklingen av tjänsteproducenten. Det är dock en rekommendation att denna konvention följs. Observera att detta kräver soap-adresser som innehåller tjänstens namn, något som inte är obligatoriskt i SHS 2.0 SOAPbased Protocol. Motiv: Ett enkelt och de facto-standard sätt att publicera tjänstekontrakt. SHS Version 2.0 SOAP-based Profile.docx