SOAP clients without a WSDL

599 views Asked by At

I am trying to get my head around using Standard Business Reporting (SBR). It uses SOAP and ebXML(ebms3).

They have given this xml as an example

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Header>
    <eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="true" wsu:Id="soapheader-1">
      <ns2:UserMessage xmlns:ns2="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
        <ns2:MessageInfo>
          <ns2:Timestamp>2018-01-07T23:01:31.592Z</ns2:Timestamp>
          <ns2:MessageId>A1515366089895.d1b7047b-2e8e-4fa1-81f0-c3eec198bddb@1515366089897</ns2:MessageId>
        </ns2:MessageInfo>
        <ns2:PartyInfo>
          <ns2:From>
            <ns2:PartyId type="http://abr.gov.au/PartyIdType/ABN">67094544519</ns2:PartyId>
            <ns2:Role>http://sbr.gov.au/ato/Role/Business</ns2:Role>
          </ns2:From>
          <ns2:To>
            <ns2:PartyId type="http://abr.gov.au/PartyIdType/ABN">51824753556</ns2:PartyId>
            <ns2:Role>http://sbr.gov.au/agency</ns2:Role>
          </ns2:To>
        </ns2:PartyInfo>
      </ns2:UserMessage>
    </eb:Messaging>

…

  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="soapbody"></soapenv:Body>
</soapenv:Envelope>

My understanding is that many SOAP libraries take a WSDL to create a client that you can call the listed services. However I am failing to find a WDSL for it.

Does a SOAP api need to have a WDSL? and can you progress without one?

2

There are 2 answers

0
Terry Lennox On BEST ANSWER

It's advisable to use the WSDL to generate your client side code, this is normally how SOAP services are called.

However it's possible to call a SOAP service without accessing the WSDL at all. This may be necessary if the technology stack you are using does not support processing WSDL files. You can simply use curl to access some SOAP services. Though I would emphasize that more complex SOAP APIs would be tricky to use without generating client side code from WSDL.

Example of calling a SOAP service using curl:

Create a file getcities.xml with the content below:

getcities.xml

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetCitiesByCountry xmlns="http://www.webserviceX.NET">
      <CountryName>France</CountryName>
    </GetCitiesByCountry>
  </soap:Body>
</soap:Envelope>

And then invoke curl like so:

curl -v -X POST --data @getcities.xml -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction: http://www.webserviceX.NET/GetCitiesByCountry" http://www.webservicex.net/globalweather.asmx

SOAP calls are really just HTTP POST requests (in almost all cases) with an XML body.

Oh and by convention the WSDL is available at the SOAP service URL with the parameter WSDL, e.g.

https://somesoapprovider.net/soapservice?WSDL.

e.g.

http://www.webservicex.net/globalweather.asmx?WSDL
0
Sander Fieten On

Please note that ebMS3/AS4 is based on SOAP and uses its processing model and structures, but it is a messaging protocol specification of its own. Although the ebMS3/AS4 specifications also use WS-Security, it is not a normal web service as there are additional processing requirements. For example regarding the implementation of reliable messaging using ebMS Receipt messages.

It is therefore common to use a implementation from a software vendor to implement the ebMS3/AS4 messaging in your solution. There are many implementations available, including supported open-source. For the Australian SBR you should however note that an extension to the AS4 specifications is sometimes included, which requires you to include SAML tokens in the WS-Security header of the message. This extension is not always supported.