Understanding abstract request-response operations in WSDL 1.1

Other Questions Notion
1

I’m trying to wrap my head around WSDL 1.1 and I’m stuck on the concept of request-response operations. The spec says they’re abstract and that you need to look at the binding to figure out how messages are actually sent. Can anyone break this down for me with a real-world example?

I’m especially curious about:

  1. How a single communication (like HTTP request/response) might work
  2. What two independent communications would look like

I’ve been googling for hours but can’t find a clear explanation. Any help would be awesome!

<!-- Example WSDL snippet -->
<binding name="exampleBinding" type="tns:examplePortType">
  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
  <operation name="exampleOperation">
    <soap:operation soapAction="http://example.com/exampleAction"/>
    <input><soap:body use="literal"/></input>
    <output><soap:body use="literal"/></output>
  </operation>
</binding>

Can someone explain how this binding relates to the abstract request-response operation? Thanks!

2

I’ve been working with WSDL for a while now, and I can tell you it’s tricky at first. The abstract operations are like a blueprint - they define the structure without getting into the nitty-gritty of how it’s implemented.

In your example, the binding is telling us to use SOAP over HTTP. This means when you call exampleOperation, it’ll send an HTTP POST request with a SOAP envelope containing your input message. The server will process it and send back an HTTP response with another SOAP envelope holding the output message.

For two independent communications, you might see separate and bindings, possibly using different protocols. This could be useful for asynchronous operations where the response comes much later through a different channel.

The key is to remember that the abstract part defines ‘what’, while the binding specifies ‘how’. It’s a bit like separating the interface from the implementation in OOP, if that helps.

3

hey grace, i’ve struggled with this too! basically, the abstract part is just saying ‘here’s what messages we expect’ without caring how they’re sent. the binding is where the rubber meets the road.

for your example, it’s saying ‘use HTTP and SOAP’ for the actual communication. so when you call exampleOperation, it’ll send an HTTP POST with a SOAP envelope. hope that helps!

4

As someone who’s dealt with WSDL 1.1 extensively, I can shed some light on this. The abstract request-response operations in WSDL are like a contract, defining the expected input and output without specifying the transport mechanism.

Your binding example is crucial. It’s linking the abstract operation to a concrete implementation using SOAP over HTTP. When exampleOperation is invoked, it triggers an HTTP POST request with a SOAP envelope containing the input message. The server then responds with an HTTP response, again using a SOAP envelope for the output.

This setup allows for flexibility; you could, theoretically, swap out the SOAP/HTTP binding for something else without changing the abstract operation definition. It’s a powerful concept for maintaining a separation between the interface and implementation in web services.

Remember, the binding is where the actual communication details are specified, bridging the gap between the abstract WSDL definitions and the concrete network protocols used.