soap Handledning
Komma igång med tvål

Anmärkningar

versioner

Allmän information

SOAP är en förkortning för Simple Object Access Protocol som definierar ett protokoll som används för att utbyta data via ett Remote Procedure Call (RPC) med andra SOAP-tjänster eller klienter. Det finns i två versioner:

• SOAP 1.1 [ IETF ]
• SOAP 1.2 [ IETF ]

SOAP 1.2 föråldrar SOAP 1.1. Det rekommenderas därför att använda SOAP 1.2 om möjligt.

Det bygger ofta ovanpå HTTP / S och sällan på SMTP eller FTP, även om det skulle stödja det enligt protokollet. Även om HTTP ofta används som underliggande transportprotokoll, använder SOAP endast en begränsad delmängd av det. För att skicka förfrågningar förlitar det sig nästan helt på HTTP: s POST operation. GET invokationer är teoretiskt möjliga sedan 1.2, även om dokumentet måste skickas som URI-parameter och därmed kan överskrida en ungefär 3000 teckengräns som avvisas av de flesta ramverk. Dessutom definieras säkerhetsrelaterade inställningar vanligtvis i en speciell SOAP-rubrik.

Även om SOAP och REST kallas webbtjänster är de väldigt olika. Vissa ramverk skiljer mellan WS (för SOAP-baserade tjänster) och RS (för REST-baserade tjänster).

Följande tabell ger en kort överblick över skillnaderna mellan båda typer av webbtjänster.

TVÅL

En SOAP-begäran består av ett SOAP-kuvert som måste innehålla ett karosserielement och kan innehålla ett valfritt huvudelement. Huvudelementet används för att vidarebefordra vissa konfigurationer till tjänsten som WS-Security kan definiera att meddelandet är krypterat eller WS-Coordination / WS-Transaction kan definiera att meddelandet måste utföras inom en transaktion.

En enkel SOAP 1.2-begäran via HTTP som lägger till två värden kan se ut så här:

POST /calculator HTTP/1.1
Host: http://example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 224

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <m:AddValues xmlns:m="http://example.org/calculator">
   <m:FirstValue>1</m:FirstValue>
   <m:SecondValue>2</m:SecondValue>
  </m:AddValues>
 </env:Body>
</env:Envelope>

Ett svar på ovanstående provbegäran kan se ut så här

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 329

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
 <soap:Body xmlns:m="http://www.example.org/calculator">
  <m:AddValuesResponse>
   <m:Result>3</m:Result>
  </m:AddValuesResponse>
 </soap:Body>
</soap:Envelope>

Exemplet ovan definierade en begäran som åberopade AddValues metoden med två argument, FirstValue inställd på 1 och SecondValue inställd på 2 . Begäran resulterade i en exekvering av denna metod på den fjärranslutna SOAP-servern som beräknade ett värde av 3 som ett resultat som är inkapslat i ett separat svarelement, vilket enligt konvention ofta är det åberopade metodnamnet plus en efterföljande Response så att alla som är genom att inspektera svaret kan man dra slutsatsen att detta är svaret från en tidigare AddValue metoden.

Skillnader mellan SOAP 1.1 och 1.2

SOAP 1.2 tillåter andra transportprotokoll sedan HTTP så länge bindningsramen stöds av protokollet.

SOAP 1.1 är baserat på XML 1.0, medan 1.2 är baserat på XML Infoset som gör det möjligt att serialisera SOAP-meddelanden med andra serienummer och sedan standard XML 1.0-serien som används av SOAP 1.1. Detta tillåter dvs. att serialisera meddelanden som binära meddelanden och därför förhindra en viss omkostnad av XML-meddelandet. Utöver detta kan serialiseringsmekanismen för det använda underliggande protokollet bestämmas via databindningen.

Interoperabilitetsaspekten främjades också med SOAP 1.2 genom att definiera en mer specifik bearbetningsmodell sedan dess föregångare som eliminerade många möjligheter för tolkning. SOAP med Attachment API (SAAJ), som gör det möjligt att arbeta med SOAP 1.1 och 1.2-meddelanden, hjälpte många ramverktyg att bearbeta och skapa meddelanden.

W3C har släppt en kort översikt över de viktigaste förändringarna mellan SOAP 1.1 och 1.2

Interoperabilitet för webbtjänster

Interoperabilitet för webbtjänster (även känd som WS-I) är en riktlinje för driftskompatibilitet som styrs av några välkända företag som IBM, Microsoft, Oracle och HP för att bara nämna några. Dessa riktlinjer rekommenderar bland annat att man bara använder ett enda rotelement i SOAP-kroppen även om SOAP tillåter att innehålla flera element i kroppen.

WS-I består av

• WS-I Basic Profile alias WSI-BP
• WS-I Basic Security Profile
• Enkel tvålbindande profil

WSI-BP finns i fyra olika versioner v1.0 (2004) , v1.1 (2006) , v1.2 (2010) , v2.0 (2010) och definierar driftskompatibilitetsriktlinjer för grundläggande webbtjänstspecifikationer som SOAP, WSDL och UDDI. Genom användning av WSDL (Web Services Description Language) kan SOAP-tjänster beskriva deras stödda operationer och metoder inom en sammanhängande uppsättning till andra slutpunkter. WSI-BP använder WSDL för att definiera en smalare uppsättning, då skulle hela WSDL- eller SOAP-schemat definiera och därmed eliminera en del av tvetydigheten i själva specifikationen och därmed förbättra interoperabiliteten mellan slutpunkter.

WSDL

För att marknadsföra tillgängliga SOAP-operationer, deras parametrar såväl som de respektive slutpunkterna för att åberopa klienter används ett ytterligare XML-baserat dokument som kallas Web Services Description Language eller WSDL för kort.

WSDL beskriver servicens slutpunkt, bindning av SOAP-meddelanden till operationer, gränssnittet för operationer samt deras typer till klienter. WSDL är, liksom SOAP, tillgänglig i två versioner som skiljer sig i sin syntax något men uttrycker nästan samma semantik för klienten.

WSDL 1.1

En WSDL 1.1-beskrivning innehåller en service , en binding , en portType och ett message . Det kan ytterligare importera eller definiera scheman inom WSDL-filen, som kan ses från ett exempel på WSDL-fil som motsvarar räknaren som visas ovan:

<wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFailure">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract message definitions
    -->

    <wsdl:message name="AddValuesRequest">
        <wsdl:part name="in" element="calc:AddValuesRequest" />
    </wsdl:message>
    <wsdl:message name="AddValuesResponse">
        <wsdl:part name="out" element="calc:AddValuesResponse" />
    </wsdl:message>
    <wsdl:message name="CalculationFault">
        <wsdl:part name="fault" element="calc:CalculationFailure" />
    </wsdl:message>

    <!--
        Abstract portType / interface definition
    -->

    <wsdl:portType name="CalculatorEndpoint">
        <wsdl:operation name="AddValues">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input message="tns:AddValuesRequest" />
            <wsdl:output message="tns:AddValuesResponse" />
            <wsdl:fault name="CalculationFault" message="tns:CalculationFault" />
        </wsdl:operation>
    </wsdl:portType>

    <!--
      Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" type="tns:CalculatorEndpoint">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="AddValues">
            <soap:operation soapAction="http://example.org/calculator/AddValuesMessage" />
            <wsdl:input>
                <soap:body parts="in" use="literal" />
            </wsdl:input>
            <wsdl:output>
                <soap:body parts="out" use="literal" />
            </wsdl:output>
            <wsdl:fault name="CalculationFault">
                <soap:fault name="CalculationFault" use="literal" />
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService">
        <wsdl:port name="CalculatorServicePort" binding="tns:CalculatorBinding">
            <soap:address location="http://localhost:8080/services/calculator" />
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

En service definierar de konkreta slutpunkterna som tjänsten ska lyssna på för inkommande förfrågningar. binding binder en operation till en konkret stil och definierar vilka meddelandeformat som servern förväntar sig eller klienten kan förvänta sig.

Det abstrakta avsnittet består av ett portType block som definierar de operationer som erbjuds av tjänsten och vilka meddelanden som utbyts. Meddelandena anges i deras on-block och länkas till schematyperna som argumenten och returnvärden är instanser av. Meddelanden kan förklara parametrar eller returnera värden som in , out eller inout . Medan de två första är ganska enkla att förstå de senare, efterliknar beteendet hos argument som skickas som referens. Eftersom pass-by-ref inte stöds på vissa språk simuleras denna effekt ofta via vissa hanterare.

WSDL 2.0

Samma räknare kan beskrivas i WSDL 2.0 på följande sätt:

<?xml version="1.0" encoding="utf-8" ?>
<wsdl:description xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:wsdl="http://www.w3.org/ns/wsdl"
                  xmlns:soap="http://www.w3.org/ns/wsdl/soap"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFault">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract interface
    -->

    <wsdl:interface name="CalculatorInterface">
        <wsdl:fault name="fault" element="calc:CalculationFault" />
        <wsdl:operation name="AddValues" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdl:safe="true">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input messageLabel="in" element="calc:AddValuesRequest" />
            <wsdl:output messageLabel="out" element="calc:AddValuesResponse" />
            <wsdl:outfault messageLabel="fault" ref="tns:fault" />
        </wsdl:operation>
    </wsdl:interface>

    <!--
        Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" interface="tns:CalculatorInterface" type="http://www.w3.org/ns/wsdl/soap" soap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
        <wsdl:operation ref="tns:AddValues" soap:mep="http://www.w3.org/2003/05/soap/mep/soap-response" />
        <wsdl:fault ref="tns:fault" soap:code="soap:Sender" />
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService" interface="tns:CalculatorInterface">
        <wsdl:endpoint name="CalculatorEndpoint" binding="tns:CalculatorBinding" address="http://localhost:8080/services/calculator" />
    </wsdl:service>

</wsdl:description>

Skillnader mellan WSDL 1.1 och 2.0

En grafisk översikt över skillnaderna mellan båda versionerna kan ses på bilden nedan.

( Källa )

Som framgår av bilden har message tagits bort som nu finns i interface . Vissa av elementen har också bytt namn, andra har en annan syntax men i allmänhet gör båda WSDL-versionerna i princip samma sak med version 2.0 som kräver lite mindre skrivkostnader jämfört med 1.1.

Förutom det mindre fotavtrycket att definiera SOAP-baserade tjänster via WSDL 2.0, ger den nyare versionen också möjligheter att definiera REST-tjänster men WSDL 2.0 eller till och med WADL rekommenderas INTE för RESTful-tjänster eftersom de motsäger själva idén bakom det.

Vilken stil att föredra

Avsnittet WSDL-bindning beskriver hur tjänsten är bunden till SOAP-meddelandeprotokollet. Exemplet ovan använde document som bindningsstil, vilket gör det möjligt att strukturera SOAP-kroppen som vi vill så länge den resulterande utgången är en giltig XML-instans. Detta är standardbindningsstil och kallas ofta Message-Oriented style .

Till skillnad från document måste RPC stilförfrågningsorgan innehålla både operationsnamn och uppsättning metodparametrar. Strukturen för XML-instansen är därför fördefinierad och kan inte ändras.

Förutom bindningssättet definierar bindningssektionen också en översättningsmodell för bindningar till SOAP-meddelanden i literal eller encoded . Skillnaden mellan de två är att den literal modellen måste överensstämma med en användardefinierad XSD-struktur, som kan användas för att validera förfrågningarna och svaren, medan den encoded modellen måste använda XSD-datatyper som xs:integer eller xs:string men i utbyte behöver därför inte överensstämma med något användardefinierat schema. Detta gör det dock svårare att validera meddelandekroppen eller omvandla meddelandet via XSLT till ett annat format.

Kombinationen av bindningsstil med användningsmodellen möjliggör faktiskt fyra olika meddelanden. En femte post läggs till i listan som ofta används (dock inte riktigt del av standarden).

• RPC / kodad
• RPC / literal
• Dokument / kodat
• Dokument / bokstavlig
• Dokument / bokstavligt (inslaget)

I dokument- / bokstavsstil för meddelanden finns det ett mönster som kallas wrapped-document / letteral. Detta är bara ett mönster och ingår inte i WSDL-specifikationen. Detta mönster nämns i JSR 224 (JAX-WS: Java API för XML-baserade webbtjänster). ( Källa )

Avsnittet nedan ger en översikt över skillnaderna beträffande WSDL- eller schemadeklaration och deras påverkan på det resulterande SOAP-meddelandeformatet på att ändra antingen bindningsstil eller definiera modellmodeller.

RPC / kodad

WSDL:

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'encoded' -->
...

SOAP-begäran

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue xsi:type="xsd:int">1</FirstValue>
      <SecondValue xsi:type="xsd:int">2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAP-svar

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result xsi:type="xsd:int">3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

Fördelar

• okomplicerad WSDL
• Operationsnamn och element tillgängliga vid begäran och svar

Nackdelar

• Explicit deklaration av XSI-typer
• Svårt att validera
• Inte uppfyller WS-I

RPC / literal

WSDL:

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'literal' -->
...

SOAP-begäran

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAP-svar

<soap:envelope>
  <soap:body>
    <AddValuesResult>
      <Result>3</Result>
    </AddValuesResult>
  </soap:body>
</soap:envelope>

Fördelar

• okomplicerad WSDL
• Operationsnamn och element tillgängliga vid begäran och svar
• Ingen specifikation av XSI-typ behövs
• WS-I-kompatibel

Nackdelar

• Svårt att validera

Dokument / kodat

Inget meningsfullt därför utelämnad.

Dokument / bokstavlig

WSDL:

...
<types>
  <schema>
    <element name="FirstValueElement" type="xsd:int" />
    <element name="SecondValueElement" type="xsd:int" />
    <element name="ResultValueElement" type="xsd:int" />
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" element="FirstValueElement" />
  <wsdl:part name="SecondValue" element="SecondValueElement" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" element="ResultValueElement" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

SOAP-begäran

<soap:envelope>
  <soap:body>
    <FirstValueElement>1</FirstValueElement>
    <SecondValueElement>2</SecondValueElement>
  </soap:body>
</soap:envelope>

SOAP-svar

<soap:envelope>
  <soap:body>
    <ResultElement>3</ResultElement>
  </soap:body>
</soap:envelope>

Fördelar

• Ingen XSI-kodning
• Kan validera organ
• WS-I överensstämmer med begränsningar

Nackdelar

• WSDL är mer komplicerat på grund av den ytterligare XSD-definitionen
• Operationsnamn går förlorad
• WS-I tillåter bara ett barn i SOAP-kroppen

Dokument / bokstavligt (inslaget)

WSDL:

...
<types>
  <schema>
    <element name="AddValues">
      <complexType>
        <sequence>
          <element name="FirstValue" type="xsd:int" />
          <element name="SecondValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
    <element name="AddValuesResponse">
      <complexType>
        <sequence>
          <element name="ResultValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="in" element="AddValues" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="out" element="AddValuesResponse" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

SOAP-begäran

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

SOAP-svar

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result>3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

Fördelar

• Ingen XSI-kodning
• Kan validera organ
• Operationsnamn och element tillgängliga vid begäran och svar
• WS-I-kompatibel

Nackdelar

• WSDL är mer komplicerat på grund av den ytterligare XSD-definitionen

UDDI

Universal Description, Discovery and Integration (UDDI) är ett öppet branschinitiativ crated 2000 som fungerar som XML-baserade gula sidoregistret för webbtjänster som hjälper till att hitta tjänster som löser specifika uppgifter. För att hitta en lämplig tjänst måste en tjänst registreras först med ett webbtjänstregister som UDDI.

UDDI arbetar med SOAP-meddelandeväxling och ger åtkomst till WSDL-dokument som kan användas för att åberopa den faktiska webbtjänsten.

UDDI ger uppslagskriterier som

• affärsidentifierare
• Företagsnamn
• affärsplats
• affärskategori
• servicetyp efter namn
• upptäckts-webbadresser

En stor nackdel med det nuvarande UDDI är emellertid att det bara tillåter att använda ett enda kriterium i en sökuppgift. Vissa implementatorer modulerade därför sina UDDI-implementationer för att möjliggöra frågor som gyster flera UDDI: er samtidigt och sedan aggregera de returnerade resultaten.

I praktiken används dock inte UDDI så ofta. Vissa säger till och med att UDDI är död sedan IBM, Microsoft och SAP stängde av sina UDDI-tjänster 2005 .

Ytterligare anmärkningar:

SOAP / WSDL ger ett brett utbud av verktygsstöd och gör det också möjligt att dynamiskt generera stubklasser för både klienter och servrar eftersom typen av meddelanden och data som utbyts är väl definierade genom det inbäddade eller länkade XSD-schemat.

Även om WSDL 2.0 har mindre omkostnader för att definiera webbtjänster har vissa språk fortfarande inte antagit den nya standarden ännu. Det vill säga i Java populära verktyg som wsimport (från Oracle / Sun) eller wsdl2java (från Apache CXF) kan inte hantera WSDL 2.0-beskrivningar korrekt. Av kompatibilitetsskäl rekommenderas därför fortfarande att använda WSDL 1.1. Om du behöver utveckla en WSDL 2.0-baserad SOAP-tjänst i Java, titta på wsdl2java från Apache Axis2- projektet.

Men mer populära nuförtiden är emellertid antingen HTTP-baserade API-tjänster, som blandar HTTP-operationskallningar med rena, mänskliga förståelige URI: er och vissa anpassningar till protokollet för att få sitt jobb gjort, REST- baserade tjänster, som helt följer de faktiska rekommendationerna, eller egna protokoll på bytenivå , t.ex. OFTP2 .

SOAP är fortfarande användbart för närvarande om du inte kan kartlägga din uppgift direkt till resurser, som HTTP / REST-bastjänster gör, eftersom uppgiften att utföra representerar naturligtvis en åtgärd eller måste definiera vissa transaktionssemantik. Om du inte har resurser att definiera eller implementera ditt eget protokoll är du förmodligen bättre att använda SOAP. SOAP är särskilt användbart om du måste hantera orkestrering eftersom WSDL-beskrivningen i kombination med UDDI gör det möjligt att kombinera tjänster dynamiskt.

Java Client for Weather-tjänsten är öppen källkodsservice tillgänglig på http://www.webserviceX.NET

  package com.test.ws.example;

 import javax.xml.soap.MessageFactory;
 import javax.xml.soap.MimeHeaders;
 import javax.xml.soap.SOAPBody;
 import javax.xml.soap.SOAPConnection;
 import javax.xml.soap.SOAPConnectionFactory;
 import javax.xml.soap.SOAPElement;
 import javax.xml.soap.SOAPEnvelope;
 import javax.xml.soap.SOAPMessage;
 import javax.xml.soap.SOAPPart;
 import javax.xml.transform.Source;
 import javax.xml.transform.Transformer;
 import javax.xml.transform.TransformerFactory;
 import javax.xml.transform.stream.StreamResult;

 /*
  * WSDL url :  http://www.webservicex.com/globalweather.asmx?WSDL
  * Endpoint URL: http://www.webservicex.com/globalweather.asmx   */

    public class WSClient {

   public static void main(String args[]) {

    try {
        SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();
        SOAPConnection soapConnection = soapConnectionFactory.createConnection();

        // Generate SOAP request XML

        MessageFactory messageFactory = MessageFactory.newInstance();
        SOAPMessage soapMessage = messageFactory.createMessage();
        MimeHeaders header = soapMessage.getMimeHeaders();
        header.setHeader("SOAPAction", "http://www.webserviceX.NET/GetCitiesByCountry");
        SOAPPart soapPart = soapMessage.getSOAPPart();
        SOAPEnvelope envelope = soapPart.getEnvelope();
        envelope.addNamespaceDeclaration("web", "http://www.webserviceX.NET");
        SOAPBody soapBody = envelope.getBody();
        SOAPElement soapBodyElem = soapBody.addChildElement("GetCitiesByCountry", "web");
        SOAPElement soapBodyElem1 = soapBodyElem.addChildElement("CountryName", "web");
        soapBodyElem1.addTextNode("INDIA");
        soapMessage.saveChanges();
        soapMessage.writeTo(System.out);
        
                    
        // Call webservice endpint
        String url = "http://www.webservicex.com/globalweather.asmx";
        SOAPMessage soapResponse = soapConnection.call(soapMessage, url);
        Source sourceContent = soapResponse.getSOAPPart().getContent();

        // Print SOAP response
        TransformerFactory transformerFactory = TransformerFactory.newInstance();
        Transformer transformer = transformerFactory.newTransformer();
        System.out.println("Response SOAP Message \n");
        StreamResult result = new StreamResult(System.out);
        transformer.transform(sourceContent, result);
        soapConnection.close();

    } catch (Exception e) {

        e.printStackTrace();
    }
}

}

Skapa en enkel webbtjänst och klienter med JAX-WS (dokument / bokstavlig)

Detta är projektkatalog.

1. Ett gränssnitt för servicens slutpunkt

Först skapar vi ett servicens slutpunktgränssnitt. Javax.jws.WebService @ @WebService kommentaren definierar klassen som en slutpunkt för webbtjänsten.

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.jws.soap.SOAPBinding.Use;

// Service Interface with customize targetNamespace
@WebService(targetNamespace = "http://hello-soap/ws")
@SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) //optional
public interface HelloSoap {

    @WebMethod String getHelloSoap(String name);

}

2. Implementering av servicens slutpunkt (SEI)

Nästa kommer vi att skapa implementering av servicens slutpunkt. Vi kommer att skapa ett tydligt gränssnitt genom att lägga till endpointInterface elementet till @WebService anteckningen i implementeringsklassen. Här är några uppsättningar av regler 28.1.1 Krav på en JAX-WS Endpoint som JAX-WS slutpunkter måste följa. Metoden getHelloSoap returnerar en hälsning till klienten med namnet skickat till den.

import javax.jws.WebService;

// Customized Service Implementation (portName,serviceName,targetNamespace are optional)

@WebService(portName = "HelloSoapPort", serviceName = "HelloSoapService",
endpointInterface = "com.wonderland.hellosoap.HelloSoap", targetNamespace = "http://hello-soap/ws")
public class HelloSoapImpl implements HelloSoap {

    @Override
    public String getHelloSoap(String name) {
        return "[JAX-WS] Hello : " + name;
    }

}

3. Webbplatsens slutpunktsförlag

import javax.xml.ws.Endpoint;

public class HelloSoapPublisher {

    public static void main(String[] args) {
        // creating web service endpoint publisher
        Endpoint.publish("http://localhost:9000/ws/hello-soap", new HelloSoapImpl());
    }

}

4. Nästa steg kommer vi att köra HelloSoapPublisher.java som java-applikation. Då kommer vi att visa WSDL-filen genom att begära URL: en http://localhost:9000/ws/hello-soap?wsdl i en webbläsare.

http: // localhost: 9000 / WS / Hello-tvål wsdl

Om XML-dataformat visas i webbläsaren är vi redo att gå nästa steg.

Notera:
Om du får något slags felmeddelande, kanske du måste använda wsgen verktyget för att generera nödvändiga JAX-WS-bärbara artefakter. Vi är inte täckta om wsgen verktyg här.

5. Webbtjänsteklient

Sista steget skapar vi en klient som kommer åt vår publicerade tjänst.

import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;

public class HelloSoapClient {

    public static void main(String[] args) throws Exception {

        // create wsdl url
        URL wsdlDocumentUrl = new URL("http://localhost:8000/ws/hello-soap?wsdl");
        QName helloSoapService = new QName("http://hello-soap/ws", "HelloSoapService");
        // create web service
        Service service = Service.create(wsdlDocumentUrl, helloSoapService);
        // get object of pointed service port
        HelloSoap helloSoap = service.getPort(HelloSoap.class);
        // testing request
        System.out.println(helloSoap.getHelloSoap("Soap "));

    }

}

Output: [JAX-WS] Hello : Soap

Obs: Portnummer har ändrats till 8000 i vår webbtjänsklient. Anledningen här är att jag använde Eclipse IDE, det inbyggda TCP/IP monitor för att spåra meddelanden (Mer information: Hur man spårar SOAP-meddelande i Eclipse IDE ). Testa SoapUI | för funktionellt teständamål Funktionstestning för SOAP- och REST-API: er .