WSDL - Service Consumer

1. Who is a Service Consumer?

A Service Consumer is the application, system, or developer that uses a web service provided by the Service Provider.

  • The consumer does not need to know how the service is implemented.

  • It only needs to know how to communicate with the service.

  • To achieve this, the consumer reads the WSDL file.

In simple terms:
Service Consumer = The one who uses the service.


2. Role of WSDL for the Service Consumer

The WSDL (Web Services Description Language) acts as a contract between the consumer and provider.

When the consumer reads the WSDL, they learn:

  • What operations the service provides.

  • What input parameters are required.

  • What output they will receive.

  • Which protocol to use (SOAP/HTTP, REST, etc.).

  • The endpoint URL to access the service.


3. How the Service Consumer Uses WSDL

The process can be explained in four main steps:

Step 1 — Download or Access WSDL

  • The consumer gets the WSDL from:

    • A direct URL:

      http://example.com/CustomerService?wsdl
      
    • A UDDI registry (less common today).

    • A shared file from the provider.


Step 2 — Read WSDL Contents

The consumer examines the WSDL to understand:

  • Operations → What functions are available.

  • Messages → Input/output data types.

  • Bindings → Communication protocol.

  • Service Endpoint → Where to send requests.


Step 3 — Generate Client Code Automatically

Developers don’t write SOAP request XML manually; instead, they generate client code using tools.
This code acts as a proxy to call the service.

Tools to Generate Client Code:

Technology Tool/Command Purpose
Java (JAX-WS) wsimport Generates Java stubs from WSDL
Java (Apache CXF) cxf-codegen-plugin Generates Java client code
.NET / C# svcutil Generates C# proxy classes
Python zeep library Reads WSDL and creates client
PHP SoapClient class Uses WSDL directly
Testing Tool SoapUI / Postman Import WSDL and test API

Step 4 — Invoke Web Service

Once the client code (proxy) is generated, the consumer can call the service just like calling a normal local method.

Example in Java (JAX-WS):

// Generated classes from WSDL
CustomerService service = new CustomerService();
CustomerPort port = service.getCustomerPort();

// Call the operation defined in WSDL
String response = port.getCustomer(101);
System.out.println("Customer Name: " + response);

Behind the scenes:

  1. The generated client converts the method call → into a SOAP XML request.

  2. Sends the request to the service endpoint defined in the WSDL.

  3. Receives a SOAP XML response.

  4. Converts it back into a Java object for easy use.


4. Service Consumer Example

Imagine a company XYZ Corp wants to check customer details from ABC Bank’s web service.

  • Step 1: XYZ gets the WSDL URL from ABC Bank.

  • Step 2: XYZ uses wsimport (Java) to generate client stubs.

  • Step 3: XYZ writes a simple program to call getCustomer(123).

  • Step 4: ABC Bank returns customer details in SOAP response.


5. Service Consumer in Web Services Architecture

In the WSDL-based architecture, the Service Consumer:

  1. Reads WSDL from the Service Provider.

  2. Generates client code using tools.

  3. Invokes operations defined in WSDL.

  4. Receives response from the Service Provider.

Role Action
Service Provider Publishes WSDL
Service Consumer Reads WSDL, generates client code
Service Registry Stores WSDL for discovery

6. Real-Time Analogy

Think of WSDL as a restaurant menu:

  • Restaurant (Service Provider) → Prepares dishes (web services).

  • Menu (WSDL) → Explains available dishes, ingredients, and prices.

  • Customer (Service Consumer) → Reads the menu (WSDL), orders food (sends request), and receives the dish (response).


7. Key Benefits for Service Consumers

  • No need to understand backend logic → Only WSDL is required.

  • Automatic client code generation → Saves time and avoids manual SOAP coding.

  • Interoperability → A Java client can consume a .NET service and vice versa.

  • Error prevention → The WSDL defines strict input/output rules.