1. Vad är WS-I Basic Profile 1.0?
WS-I står för "Web Service Interoperability Organization", en organisation som standardiserar webbtjänster. WS-I utfärdar olika profiler, som är en typ av paketering av specifikationer och övriga regler som underlättar interoperabilitet mellan de som stödjer profilen. Basic Profile 1.0 är den mest spridda profilen.
Från och med nu förkortar vi WS-I Basic Profile 1.0 med BP. BP refererar till följande specifikationer:
BP beskriver inte bara vilka specifikationer som ska ingå i profilen utan lägger även till extra restriktioner på de ingående specifikationerna eftersom de ofta är för generella eller har avsnitt som anses vara tvetydiga. Nedan följer en kort sammanfattning på hur specifikationerna begränsas av BP:
- XML 1.0: BP begränsar inte användningen av XML 1.0, utom att endast XML Schema 1.0 är tillåten för att validera XML. XML 1.0 utgör grunden för de tre övriga specifikationerna.
- SOAP 1.1: BP specifierar att version 1.1 av SOAP ska användas för meddelandeöverföring, däremot är SOAP with Attachments utanför BP. BP begränsar SOAP 1.1 bland annat genom att endast tillåta de fyra standardfelkoderna och tvingar anroparen att avsluta flödet då ett SOAP Fault inträffar .
- WSDL 1.1: WSDL är en mycket generell teknologi som i vissa fall kan vara tvetydig. BP begränsar WSDL genom att t.ex. endast tillåta HTTP som transportprotokoll.
- UDDI 2.0: UDDI är den enda teknoligi som BP deklarerar som valfri. Om man behöver utnyttja ett register rekommenderar BP att man använder UDDI, men BP tillåter även andra teknologier för detta ändamål.
2. Definitioner och allmänna regler
Profilen definierar följande termer:
- Instans (Instance): Mjukvara som implementerar wsdl:port eller uddi:bindingTemplate.
- Konsument (Consumer): Mjukvara som anropar instansen.
- Register (Registry): Mjukvara som implementerar UDDI.
Första regeln: Beskrivning måste finnas. En Instans måste beskrivas av minst en av föjande:
- WSDL 1.1: En WSDL 1.1-fil.
- UDDI: En UDDI Binding template.
Om ingen av dessa beskrivningar av tjänsten finns tillgänglig går den inte att hitta.
3. Knyt en WSDL-fil till en profil
Man kan knyta en WSDL-fil till en profil med hjälp av wsi:Claim-elementet.
- wsi:Claim: Med detta menas att man vill att den som implementerar tjänsten (instansen) ska uppfylla alla de krav som den (av wsi:Claim-elementet) specifierade profilen innehåller.
wsi:Claim måste ligga innanför en wsdl:documentation-tagg. Man kan placera knytningen på flera ställen i WSDL-filen, men vanligaste är att man gör det i port-elementet, se exemplet nedan:
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
xmlns:tns="http://example.org/myservice"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
targetNamespace="http://example.org/myservice">
<wsdl:portType name="MyPortType">
...
</wsdl:portType>
<wsdl:binding name="MyBinding" portType="MyPortType" >
...
</wsdl:binding>
<wsdl:service name="MyService" >
<wsdl:port name="MyPort" binding="tns:MyBinding" >
<wsdl:documentation>
<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
</wsdl:documentation>
<soapbind:address location="http://example.org/myservice/myport" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
För att SOAP-meddelanden ska kunna signalera vilken profil de uppfyller kan de innehålla ett eller flera wsi:Claim i soap:Header.
- Valfri: Det är valfritt för ett meddelande som uppfyller en profil att signalera detta med ett wsi:Claim-element (inget tvång föreligger).
- soap:mustunderstand: Avsändaren FÅR INTE ha attributet soap:mustUnderstand på ett wsi:Claim-element.
Detta exempel visar hur ett SOAP-meddelande kan se ut:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
<soap:Header>
<!-- other headers -->
<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
<!-- other headers -->
</soap:Header>
<soap:Body>
<!-- body content -->
</soap:Body>
</soap:Envelope>
|
4. HTTP
Följande regler gäller för HTTP-versioner:
- HTTP 1.1: Ett meddelande ska helst skickas över HTTP 1.1.
- HTTP 1.0: Ett meddelande måste skickas över HTTP 1.0 eller HTTP 1.1.
Följande gäller för HTTP-headern "SOAPAction":
- SOAPAction: Värdet på denna header måste stå inom citattecken ('foo').
BP ställer upp följande regler för statuskoder för instansen:
- 200 OK: SKA HELST returneras då man vill indikera att HTTP har lyckats och returnerar ett svar som är ett SOAP-meddelande.
- 200 OK eller 202 Accepted: SKA HELST returneras då man vill indikera att HTTP har lyckats och returnerar ett svar som inte innehåller SOAP-meddelande.
- 2xx: MÅSTE retuneras då man vill indikera att HTTP har lyckats.
- 307 Temporary Redirect: MÅSTE retuneras då man skickar vidare anropet till en annan slutpunkt.
- 4xx: MÅSTE retuneras för svar som indikerar att det är något fel på meddelandets format.
- 500 Internal Server Error: MÅSTE retuneras om svarsmeddelandet är ett SOAP-fault.
Cookies är ett annat intressant ämne för webbtjänster. Cookies används för att behålla tillståndet i konversationen då man surfar, men eftersom SOAP 1.1 och WSDL 1.1 är tillståndslösa och därför inte utnyttjar Cookies förlorar den sin funktion för webbtjänster. Cookies kan däremot användas till andra saker, som t.ex. lastbalansering, och därför förbjuds inte Cookies av BP:
- Instansen FÅR använda Cookies.
- Instansen BORDE INTE kräva Cookies för att fungera korrekt.
- Instansen MÅSTE ses som .