WSDL - Abstract vs. Concrete parts of WSDL

1. Abstract Part of WSDL

The abstract part of WSDL describes what a service does — it defines the interface without worrying about the technical details of how or where it runs.

It includes:

  • Types – The data types used (defined via XML Schema).

  • Messages – The request and response message formats.

  • PortType – The set of operations supported by the service.

  • Operations – Actions the service can perform (with input/output/fault messages).

Think of this like a blueprint or interface in programming.

2. Concrete Part of WSDL

The concrete part of WSDL describes how and where the service can be accessed — it ties the abstract definitions to real protocols and endpoints.

It includes:

  • Binding – Specifies the communication protocol (SOAP, HTTP, MIME) and message format.

  • Service – Groups related ports (endpoints).

  • Port – Defines the actual network address (URL) where the service is available.

➡️ Think of this like the implementation details of an interface.

Example Breakdown

<!-- Abstract part -->
<types> ... </types>
<message name="GetWeatherRequest"> ... </message>
<message name="GetWeatherResponse"> ... </message>
<portType name="WeatherPortType">
  <operation name="GetWeather">
    <input message="tns:GetWeatherRequest"/>
    <output message="tns:GetWeatherResponse"/>
  </operation>
</portType>

<!-- Concrete part -->
<binding name="WeatherBinding" type="tns:WeatherPortType">
  <soap:binding style="document"
                transport="http://schemas.xmlsoap.org/soap/http"/>
</binding>

<service name="WeatherService">
  <port name="WeatherPort" binding="tns:WeatherBinding">
    <soap:address location="http://example.com/weatherService"/>
  </port>
</service>

  • Abstract: types, messages, portType, operations → what the service does.

  • Concrete: binding, service, port → how and where it is offered.

Why the Separation?

  1. Flexibility – The same abstract definition can be reused with multiple bindings (e.g., SOAP or HTTP).

  2. Reusability – Different services can share the same abstract interface.

  3. Clarity – Clean separation between business logic (abstract) and transport/implementation details (concrete).