In an API-driven world dominated by REST and JSON, there’s an often-overlooked layer of infrastructure that still powers the most critical systems in the world — from international banking and airline ticketing to legal and government platforms.

This foundation is built on XML standards:

• XSD defines what your data should look like
• SOAP transports that data securely
• WSDL describes how to interact with the service
• XML Digital Signatures (XML DSig) ensure the data is trusted and tamper-proof

This tech concept walks you through these technologies in logical order, showing how they interact and why they still matter today.

XSD (XML Schema Definition): Defining the Structure of Your Data

Before any data is sent, we need to define what the data should look like. That’s where XSD comes in.

What is XSD?

XSD (XML Schema Definition) is used to validate the structure, order, and type of elements in an XML document.

It ensures:

• Correct data types (string, date, decimal)
• Mandatory vs optional fields
• Nested hierarchies (complex types)
• No unexpected or malformed data is accepted

Sample XSD Schema for a User

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="User">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="ID" type="xs:int"/>
        <xs:element name="Name" type="xs:string"/>
        <xs:element name="Email" type="xs:string"/>
        <xs:element name="JoinDate" type="xs:date"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Corresponding XML Document That Validates Against the XSD

<User>
  <ID>101</ID>
  <Name>Dushyant Gadewal</Name>
  <Email>[email protected]</Email>
  <JoinDate>2025-07-09</JoinDate>
</User>

This XML will successfully validate against the XSD because:

• ID is an integer
• Name and Email are strings
• JoinDate follows the xs:date format (YYYY-MM-DD)

Why It Matters

• Guarantees data quality and consistency
• Makes integration across systems safe and predictable
• Required for validating incoming/outgoing XML messages in finance, health, aviation, etc.

SOAP (Simple Object Access Protocol): The Transport Layer

Once we have validated XML data, we need a way to send it over the wire. That’s what SOAP does.

What is SOAP?

SOAP is a protocol specification for exchanging structured XML data over network protocols like HTTP, SMTP, or JMS.

It wraps your data in a standard XML envelope and supports:

• Action-based routing
• Optional headers (authentication, security tokens)
• Robust error handling (SOAP Faults)

SOAP Message Example

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUser xmlns="http://example.com/">
      <userId>123</userId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

Why Use SOAP?

• Works across heterogeneous platforms
• Supports strict typing via XSD
• Integrates with WS- standards* (WS-Security, WS-ReliableMessaging)
• Essential for banking, insurance, and aviation APIs still using legacy systems

WSDL (Web Services Description Language): Describing the Service Contract

Now that we can structure and send the data, we need to describe the service—what operations are available, what input they take, and how to interact with them. That’s the job of WSDL.

What is WSDL?

WSDL is an XML-based document that defines the web service interface. It tells the client:

• What operations exist (e.g., GetUser, SubmitPayment)
• What XML input/output format is expected
• Where the service lives (endpoint URL)
• What transport (SOAP/HTTP) to use

Example WSDL Snippet

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
             xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns:tns="http://example.com/service"
             targetNamespace="http://example.com/service">

  <!-- Define the request message structure -->
  <message name="GetUserRequest">
    <part name="userId" type="xs:string"/> <!-- Input: a string-based user ID -->
  </message>

  <!-- Define the response message structure -->
  <message name="GetUserResponse">
    <part name="userDetails" type="xs:string"/> <!-- Output: a string containing user details -->
  </message>

  <!-- Define the operations this service supports -->
  <portType name="UserService">
    <operation name="GetUser">
      <input message="tns:GetUserRequest"/>   <!-- This operation takes a GetUserRequest -->
      <output message="tns:GetUserResponse"/> <!-- And returns a GetUserResponse -->
    </operation>
  </portType>

  <!-- Specify how the service is bound to SOAP and which transport to use -->
  <binding name="UserServiceBinding" type="tns:UserService">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    
    <operation name="GetUser">
      <soap:operation soapAction="http://example.com/GetUser"/> <!-- The SOAP action URI -->
      <input><soap:body use="literal"/></input>  <!-- Use literal XML from schema -->
      <output><soap:body use="literal"/></output>
    </operation>
  </binding>

  <!-- Define the actual service and endpoint -->
  <service name="UserService">
    <port name="UserServicePort" binding="tns:UserServiceBinding">
      <soap:address location="http://example.com/service/UserService"/> <!-- Service endpoint URL -->
    </port>
  </service>
</definitions>

Why It Matters

• Enables automated code generation in Java, .NET, Python
• Provides a machine-readable API contract
• Makes large enterprise systems interoperable and standardized

XML DSig (XML Digital Signature): Securing the Message

With data structured, transported, and described—how do we ensure it hasn’t been tampered with? Enter XML Digital Signatures (XML DSig).

What is XML DSig?

XML DSig allows you to digitally sign all or part of an XML document. It verifies:

• The message originated from a trusted party
• The content was not altered in transit
• The sender cannot deny sending it (non-repudiation)

XML Signature Snippet

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://..."/>
    <SignatureMethod Algorithm="http://..."/>
    <Reference URI="">
      <DigestMethod Algorithm="http://..."/>
      <DigestValue>abc123==</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>xyz456==</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate>MIIC+jCCAeKgAw...</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

Use Cases

• Signed invoices (e-invoicing platforms)
• Secured banking instructions (SWIFT, ISO 20022)
• Authenticated SOAP headers using WS-Security

Real-World Scenario: How It All Works Together

Let’s walk through a real-world flow in a SOAP-based payment API:

1. The bank defines the XML schema (XSD) to ensure data is correct.
2. The SOAP message wraps the data into a standard request envelope.
3. The WSDL describes what operations the API offers, and how to call them.
4. The full SOAP message is digitally signed with XML DSig, so it can’t be spoofed or modified.

Why These Standards Still Matter

Despite the rise of REST, JSON, and gRPC, XML-based standards like XSD, SOAP, WSDL, and XML DSig are still widely used in:

• Banking (SWIFT, SEPA, RTGS, ISO 20022)
• Airlines (Amadeus, Sabre, NDC APIs)
• Government (GST, e-Invoicing, UIDAI, Tax Filings)
• Healthcare (HL7, EHR Systems)

They provide:

• Schema enforcement
• Enterprise-grade security
• Formal contracts for integration
• Platform independence and backward compatibility

My Tech Advice: These technologies might not trending with developers, but they’re the plumbing behind the world’s most secure and regulated digital systems. If you’re building or integrating with legacy APIs—or working in enterprise grade finance, travel, healthcare, or public sector—you’ll likely encounter these tools. Embrace them, understand them, and use them wisely. Because in the world of digital trust, structure, security, and standards always win over speed alone.

Ready to build your own tech solution ? Try the above tech concept, or contact me for a tech advice!

#AskDushyant

Note: The names and information mentioned are based on my personal experience; however, they do not represent any formal statement. The example and pseudo code is for illustration only.

#TechConcept #TechAdvice #XML #Finance #Enterprise #Application #SOAP #WSDL