soap Zelfstudie
Aan de slag met zeep

Opmerkingen

versies

Algemene informatie

SOAP is een acroniem voor Simple Object Access Protocol dat een protocol definieert dat wordt gebruikt om gegevens via een Remote Procedure Call (RPC) uit te wisselen met andere SOAP-services of clients. Het is beschikbaar in twee versies:

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

SOAP 1.2 veroudert SOAP 1.1. Het wordt daarom aanbevolen om indien mogelijk SOAP 1.2 te gebruiken.

Het is vaak gebaseerd op HTTP / S en zelden op SMTP of FTP, hoewel het het volgens het protocol zou ondersteunen. Hoewel HTTP vaak wordt gebruikt als onderliggend transportprotocol, gebruikt SOAP er slechts een beperkte subset van. Voor het verzenden van aanvragen is het bijna volledig afhankelijk van de POST bewerking van HTTP. GET aanroepingen zijn theoretisch mogelijk sinds 1.2, hoewel het document moet worden doorgegeven als URI-parameter en dus een grens van ongeveer 3000 tekens kan overschrijden die door de meeste frameworks wordt verworpen. Ook worden beveiligingsgerelateerde instellingen meestal gedefinieerd in een speciale SOAP-header.

Hoewel SOAP en REST webservices worden genoemd, zijn ze van nature erg verschillend. Sommige frameworks maken onderscheid tussen WS (voor SOAP-gebaseerde services) en RS (voor REST-gebaseerde services).

De volgende tabel geeft een kort overzicht van de verschillen tussen beide typen webservices.

ZEEP

Een SOAP-aanvraag bestaat uit een SOAP-envelop die een body-element moet bevatten en een optioneel header-element kan bevatten. Het header-element wordt gebruikt om bepaalde configuraties aan de service door te geven, zoals WS-Security kan bijvoorbeeld definiëren dat het bericht is gecodeerd of WS-Coordination / WS-Transaction kan bepalen dat het bericht binnen een transactie moet worden uitgevoerd.

Een eenvoudige SOAP 1.2-aanvragen via HTTP die twee waarden toevoegt, kan er zo uitzien:

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>

Een reactie op het bovenstaande voorbeeldverzoek kan er zo uitzien

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>

In het bovenstaande voorbeeld is een verzoek gedefinieerd dat de methode AddValues aangeroepen met twee argumenten, FirstValue ingesteld op 1 en SecondValue ingesteld op 2 . Het verzoek resulteerde in een uitvoering van deze methode op de externe SOAP-server, die een waarde van 3 berekende als resultaat dat is ingekapseld in een afzonderlijk antwoordelement, wat gewoonlijk de aangeroepen methode is plus een volgzame Response dus iedereen die het inspecteren van het antwoord kan concluderen dat dit het antwoord is van een eerdere AddValue methode-aanroep.

Verschillen tussen SOAP 1.1 en 1.2

SOAP 1.2 maakt andere transportprotocollen mogelijk dan HTTP, zolang het bindende raamwerk door het protocol wordt ondersteund.

SOAP 1.1 is gebaseerd op XML 1.0, terwijl 1.2 is gebaseerd op XML Infoset waarmee de SOAP-berichten kunnen worden geserialiseerd met andere serializers dan de standaard XML 1.0 serializer die wordt gebruikt door SOAP 1.1. Dit maakt het mogelijk om bijvoorbeeld berichten als binaire berichten te serialiseren en daardoor enige overhead van de XML-aard van het bericht te voorkomen. Daarnaast kan het serialisatiemechanisme van het gebruikte onderliggende protocol worden bepaald via de gegevensbinding.

Het interoperabiliteitsaspect werd ook bevorderd met SOAP 1.2 door een specifieker verwerkingsmodel te definiëren dan zijn voorganger dat vele interpretatiemogelijkheden elimineerde. SOAP met SAAJ (Attachment API), waarmee SOAP 1.1- en 1.2-berichten kunnen worden uitgevoerd, heeft veel framework-implementators geholpen bij het verwerken en maken van berichten.

W3C heeft een kort overzicht vrijgegeven van de belangrijkste wijzigingen tussen SOAP 1.1 en 1.2

Webservice-interoperabiliteit

Webservice-interoperabiliteit (ook bekend als WS-I) is een richtlijn voor interoperabiliteit die wordt beheerd door enkele bekende ondernemingen zoals IBM, Microsoft, Oracle en HP om er maar een paar te noemen. Deze richtlijnen bevelen onder andere aan om slechts één basiselement in de SOAP-body te gebruiken, hoewel de SOAP meerdere elementen in de body kan bevatten.

WS-I bestaat uit

• WS-I Basic Profile aka WSI-BP
• WS-I Basis beveiligingsprofiel
• Eenvoudig zeepbindend profiel

WSI-BP is beschikbaar in 4 verschillende versies v1.0 (2004) , v1.1 (2006) , v1.2 (2010) , v2.0 (2010) en definieert interoperabiliteitsrichtlijnen voor kernwebservicespecificaties zoals SOAP, WSDL en UDDI. Door het gebruik van Web Services Description Language (WSDL) kunnen SOAP-services hun ondersteunde bewerkingen en methoden binnen een samenhangende set naar andere eindpunten beschrijven. WSI-BP maakt gebruik van WSDL om een smallere set te definiëren dan het volledige WSDL- of SOAP-schema zou definiëren en elimineert daarmee een deel van de dubbelzinnigheid binnen de specificatie zelf en verbetert zo de interoperabiliteit tussen eindpunten.

WSDL

Om reclame te maken voor de beschikbare SOAP-bewerkingen, hun parameters en de respectieve eindpunten om aan clients op te roepen, wordt een ander op XML gebaseerd document gebruikt, kortweg Web Services Description Language of WSDL genoemd.

WSDL beschrijft het service-eindpunt, de binding van SOAP-berichten aan bewerkingen, de interface van bewerkingen en hun typen aan clients. WSDL is, net als SOAP, beschikbaar in 2 versies die enigszins verschillen in hun syntaxis, hoewel ze bijna dezelfde semantiek voor de klant uitdrukken.

WSDL 1.1

Een WSDL 1.1-beschrijving bevat een service , een binding , een portType en een message . Het kan verder schema's in het WSDL-bestand importeren of definiëren, zoals te zien is in een voorbeeld WSDL-bestand dat overeenkomt met het rekenmachinemonster hierboven weergegeven:

<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>

Een service definieert de concrete eindpunten waar de service naar binnenkomende aanvragen zal luisteren. De binding sectie bindt een bewerking aan een concrete stijl en definieert welke berichtindelingen de server verwacht of de client kan verwachten.

De abstracte sectie bestaat uit een portType blok dat de bewerkingen definieert die door de service worden aangeboden en welke berichten worden uitgewisseld. De berichten worden gespecificeerd in hun on block en gekoppeld aan de schematypes waarvan de argumenten en retourwaarden instanties zijn van. Berichten kunnen parameters of terugkeer waarden verklaren te zijn in , out of inout . Terwijl de eerste twee vrij eenvoudig te begrijpen zijn, bootst de laatste het gedrag van argumenten na die zijn doorgegeven. Aangezien pass-by-ref in sommige talen niet wordt ondersteund, wordt dit effect vaak gesimuleerd via bepaalde handlers.

WSDL 2.0

Dezelfde calculator kan in WSDL 2.0 als volgt worden beschreven:

<?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>

Verschillen tussen WSDL 1.1 en 2.0

Een grafisch overzicht van de verschillen tussen beide versies is te zien in de onderstaande afbeelding.

( Bron )

Zoals te zien is in de afbeelding is de message verwijderd die nu in de interface sectie zit. Sommige elementen hebben ook een andere naam gekregen, andere hebben een andere syntaxis, maar over het algemeen doen beide WSDL-versies in principe hetzelfde met versie 2.0 die iets minder schrijfkosten vereist in vergelijking met 1.1.

Naast de kleinere voetafdruk bij het definiëren van op SOAP gebaseerde services via WSDL 2.0, biedt de nieuwere versie ook mogelijkheden om REST-services te definiëren, hoewel WSDL 2.0 of zelfs WADL NIET worden aanbevolen voor RESTful-services omdat ze in tegenspraak zijn met het achterliggende idee.

Welke stijl heeft de voorkeur

De WSDL-bindende sectie beschrijft hoe de service is gebonden aan het SOAP-berichtenprotocol. In het bovenstaande voorbeeld is het document gebruikt als de bindstijl, waarmee de SOAP-body kan worden gestructureerd zoals we willen, zolang de resulterende uitvoer een geldige XML-instantie is. Dit is de standaard bindstijl en wordt vaak Message-Oriented style .

In tegenstelling tot de document moeten RPC stijlaanvraaginstanties zowel de bewerkingsnaam als de set methodeparameters bevatten. De structuur van de XML-instantie is daarom vooraf gedefinieerd en kan niet worden gewijzigd.

Naast de bindstijl definieert de bindsectie ook een vertaalmodel voor bindingen met SOAP-berichten in de naam literal of encoded . Het verschil tussen de twee is dat dat literal model moet voldoen aan een door de gebruiker gedefinieerde XSD-structuur, die kan worden gebruikt om de verzoeken en antwoorden te valideren, terwijl het encoded model XSD-gegevenstypen zoals xs:integer of xs:string maar in ruil daarvoor hoeft het niet te voldoen aan een door de gebruiker gedefinieerd schema. Dit maakt het echter moeilijker om de berichttekst te valideren of het bericht via XSLT te transformeren naar een ander formaat.

De combinatie van de bindende stijl met het gebruiksmodel maakt in feite 4 verschillende berichtuitkomsten mogelijk. Een 5e vermelding wordt aan de lijst toegevoegd die veel wordt gebruikt (hoewel niet echt onderdeel van de standaard).

• RPC / gecodeerd
• RPC / letterlijk
• Document / gecodeerd
• Document / letterlijk
• Document / letterlijk (ingepakt)

In de bericht- / letterstijl van het document bestaat er een patroon dat bekend staat als gewikkeld document / letterlijk. Dit is slechts een patroon en maakt geen deel uit van de WSDL-specificatie. Dit patroon heeft een vermelding in JSR 224 (JAX-WS: Java API voor op XML gebaseerde webservices). ( Bron )

De onderstaande sectie geeft een overzicht van de verschillen met betrekking tot WSDL of schemaverklaring en hun impact op de resulterende SOAP-berichtindeling bij het wijzigen van de bindstijl of het gebruik van modeldefinities.

RPC / gecodeerd

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' -->
...

ZEEP Verzoek

<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-reactie

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

Pros

• ongecompliceerde WSDL
• Naam van de bewerking en elementen beschikbaar in aanvraag en reactie

Cons

• Expliciete verklaring van XSI-typen
• Moeilijk te valideren
• Niet WS-I compliant

RPC / letterlijk

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' -->
...

ZEEP Verzoek

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

SOAP-reactie

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

Pros

• ongecompliceerde WSDL
• Naam van de bewerking en elementen beschikbaar in aanvraag en reactie
• Geen XSI-typespecificatie nodig
• Voldoet aan WS-I

Cons

• Moeilijk te valideren

Document / gecodeerd

Heeft dus geen zin daarom weggelaten.

Document / letterlijk

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' -->
...

ZEEP Verzoek

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

SOAP-reactie

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

Pros

• Geen XSI-type codering
• In staat om het lichaam te valideren
• WS-I voldoet aan beperkingen

Cons

• WSDL is gecompliceerder vanwege de extra XSD-definitie
• Operatienaam is verloren
• WS-I staat slechts één kind in SOAP-lichaam toe

Document / letterlijk (ingepakt)

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' -->
...

ZEEP Verzoek

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

SOAP-reactie

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

Pros

• Geen XSI-type codering
• In staat om het lichaam te valideren
• Naam van de bewerking en elementen beschikbaar in aanvraag en reactie
• Voldoet aan WS-I

Cons

• WSDL is gecompliceerder vanwege de extra XSD-definitie

UDDI

Universal Description, Discovery and Integration (UDDI) is een open industrie-initiatief uit 2000, dat fungeert als XML-gebaseerd geelboekregister voor webservices dat helpt bij het vinden van services die specifieke taken oplossen. Om een geschikte service te vinden, moet een service eerst worden geregistreerd bij een webserviceregister zoals de UDDI.

UDDI werkt op SOAP-berichtenuitwisseling en biedt toegang tot WSDL-documenten die kunnen worden gebruikt om de eigenlijke webservice op te roepen.

De UDDI biedt opzoekcriteria zoals

• bedrijfsidentificatie
• Bedrijfsnaam
• bedrijfslocatie
• bedrijfscategorie
• servicetype op naam
• ontdekkings-URL's

Een groot nadeel van de huidige UDDI is echter dat het slechts één enkel criterium binnen een zoekopdracht toestaat. Bepaalde implementators hebben daarom hun UDDI-implementaties gemodulariseerd om vragen mogelijk te maken die meerdere UDDI's tegelijkertijd voortbrengen en vervolgens de geretourneerde resultaten te aggregeren.

In de praktijk wordt UDDI echter niet zo vaak gebruikt. Sommigen zeggen zelfs dat UDDI dood is sinds IBM, Microsoft en SAP hun UDDI-services in 2005 hebben afgesloten .

Verdere opmerkingen:

SOAP / WSDL biedt een breed scala aan tooling-ondersteuning en maakt het ook mogelijk om dynamisch stub-klassen te genereren voor zowel clients als servers, aangezien het type berichten en uitgewisselde gegevens goed is gedefinieerd via de ingebedde of gekoppelde XSD-schema's.

Hoewel WSDL 2.0 minder overhead kost bij het definiëren van webservices, hebben bepaalde talen de nieuwe standaard nog steeds niet overgenomen. Dat wil zeggen dat in Java populaire tools zoals wsimport (van Oracle / Sun) of wsdl2java (van Apache CXF) WSDL 2.0-beschrijvingen niet correct kunnen verwerken. Daarom wordt om compatibiliteitsredenen nog steeds aanbevolen WSDL 1.1 te gebruiken. Als u een op WSDL 2.0 gebaseerde SOAP-service in Java moet ontwikkelen, kijk dan op wsdl2java van het Apache Axis2- project.

Tegenwoordig zijn echter ofwel HTTP-gebaseerde API-services, die HTTP-operatieaanroepingen combineren met schone, voor de mens begrijpelijke URI's en bepaalde aanpassingen aan het protocol om hun werk te doen, op REST gebaseerde services, die volledig voldoen aan de werkelijke aanbevelingen, of eigen byte-niveau protocollen, zoals OFTP2 .

SOAP is tegenwoordig nog steeds nuttig als u uw taak niet rechtstreeks kunt toewijzen aan bronnen, zoals HTTP / REST-basisservices, omdat de te vervullen taak van nature een actie vertegenwoordigt of bepaalde transactie-semantiek moet definiëren. Ook als u niet over de middelen beschikt om uw eigen protocol te definiëren of te implementeren, kunt u SOAP waarschijnlijk beter gebruiken. SOAP is vooral handig als u te maken hebt met orkestratie, omdat de WSDL-beschrijving in combinatie met UDDI het mogelijk maakt services dynamisch te combineren.

Java Client voor weerservice open source webservice beschikbaar op 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();
    }
}

}

Een eenvoudige webservice en clients maken met JAX-WS (document / letterlijk)

Dit is de projectmap.

1. Een service-eindpuntinterface

Eerst maken we een service-eindpuntinterface. De javax.jws.WebService @WebService annotatie definieert de klasse als een webservice eindpunt.

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. Service eindpunt implementatie (SEI)

Vervolgens maken we implementatie van service-eindpunt. We maken een expliciete interface door het element endpointInterface toe te voegen aan de annotatie @WebService in de implementatieklasse. Hier zijn enkele regels 28.1.1 Vereisten voor een JAX-WS-eindpunt waaraan JAX-WS-eindpunten moeten voldoen. De methode getHelloSoap retourneert een begroeting aan de client met de naam die eraan is doorgegeven.

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. Webservice-eindpuntuitgever

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. Volgende stappen zullen we HelloSoapPublisher.java als Java-toepassing. Vervolgens zullen we het WSDL-bestand bekijken door in een webbrowser de URL http://localhost:9000/ws/hello-soap?wsdl aan te vragen.

http: // localhost: 9000 / ws / hello-soap wsdl

Als het XML-gegevensformaat wordt weergegeven in de webbrowser, zijn we klaar om naar de volgende stap te gaan.

Notitie:
Als u een foutmelding krijgt, moet u misschien het hulpprogramma wsgen gebruiken om de benodigde draagbare JAX-WS-artefacten te genereren. We behandelen hier niet de wsgen tool.

5. Webservice-client

Laatste stap, we zullen een client maken die toegang heeft tot onze gepubliceerde service.

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 "));

    }

}

Uitgang: [JAX-WS] Hello : Soap

Opmerking: Poortnummer gewijzigd in 8000 in onze webservice-client. De reden hier is, ik gebruikte Eclipse IDE, ingebouwde TCP/IP monitor tool om berichten te traceren (Meer info: SOAP-bericht traceren in Eclipse IDE ). Probeer SoapUI | voor functioneel testen Functioneel testen voor SOAP en REST API's .