Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

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 [R4] och WS-I Simple SOAP Binding Profile v1.0 [R5].

...

4         Detaljerade regler

Regel #2, Namngivning av WSDL-fil

WSDL-filen bör namnges enligt följande regel: ${tjänsteInteraktion}Interaction_${m.n}_${profilKortnamn}.wsdl

...

Exempel: MakeBookingInteraction_1.0_RIVTABP21.wsdl

Regel #3, namn på <definitions>-element

Name-attributet för elementet wsdl:definitions bör ges värde enligt följande regel: ${tjänsteInteraktion}Interaction

...

Exempel: MakeBookingInteraction

Regel #4, namn på target namespace

Namn på target namespace skall vara urn:riv:${tjänsteDomän}:${tjänsteInteraktion}:m:${profilKortnamn}

...

Exempel: urn:crm:scheduling:MakeBooking:1:rivtabp21

Regel #5 – Dokumentation av tjänsteinteraktion

Första elementet under wsdl:definitions bör dokumenteras enligt följande uppställning:

...

     </wsdl:documentation>

Regel #6 – 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.

...

Exempel: Exempelapplikationer visar hur https med ömsesidig autentisering kan upprättas för prioriterade plattformar [R10].

Regel #7 – Document/Literal

För konsistent namngivning och ökad förståelse skall följande regler följas:

...

Exempel: Se exempel MakeBookingInteraction_1.1_RIVTABP21.wsdl [R9].

Regel #8: Logisk adressering

Elementet {urn:riv:itintegration:registry:1}LogicalAddress skall användas för att i soap-header ange logisk adressat.

...

Exempel: Se exempel MakeBookingInteraction_1.0_RIVTABP21.wsdl [R9] och exempelkod för tjänstekonsumenter [R10].

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.

...

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.

...

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.

...

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.

...

Exempel: MakeBookingResponderPort


Regel #13, namn på <message>-element

Name-attributet för elementet wsdl:message skall ha värde enligt följande regler:

...

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:

...

Motiv: Konsekvent namngivning


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:riv:${tjänsteDomän}:${tjänsteInteraktion}${roll}:m:${operation}

...

Exempel: urn:riv: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å targetNamespace-attributet skall vara samma som WSDL:ens targetNamespace.

...

       <xs:import schemaLocation="MakeBookingResponder_1.1.xsd" namespace="urn:riv: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 informationsspridningsinteraktioner har en porttype medan uppdrag-resultat-interaktioner har två porttypes.

...

Exempel: Se kodgenereringsskript för referensapplikationen

Regel #19, Uppbyggnad av URL för tjänsteproducent

SOAP-adressen för en driftsatt tjänsteproducent (gäller även intermediära tjänster så som virtuella tjänster i tjänsteplattform) ska som del av URL:en ange rivta-profilens kortnamn och huvudversionen. Underversion får ej anges i URL:en.

...

Exempel: https://tidbok.landsting.sjunet.org/MakeBooking/1/rivtabp21

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.

...

Motiv: Alla plattformar förmår inte återskapa metadata i runtime för tjänster som följer denna profil (t.ex. vissa .Net-versioner och versioner av BizTalk server). Det är inget problem eftersom tjänstekonsumenten ska utvecklas “wsdl-first” baserat på WSDL-fil – inte på runtime-metadata från tjänsten själv.


Regel #21, Övervakningstjänst

Varje tjänstekomponent som producerar tjänster (se definition i RIV TA Översikt) ska exponera en monitoreringstjänst enligt WSDL:en PingForConfigurationInteraction_1.x_RIVTABP21.wsdl, t.ex. PingForConfigurationInteraction_1.0_RIVTABP21.wsdl. PingForConfigurationInteraction ingår i tjänstedomänen itintegration:monitoring. Se tjänstekontraktsbeskrivning för itintegration:monitoring-domänen för ytterligare information om kontraktet.

...