7.2.1: SOAP Web Services (SOAP and WSDL)

SOAP (Simple Object Access Protocol) is a messaging protocol for exchanging structured data in distributed systems, using XML as the message format. Despite the acronym, SOAP is quite complex – it defines an envelope structure for messages, encoding rules, and conventions for representing remote procedure calls and responses. A SOAP message is an XML document containing an <Envelope> element with a <Header> (optional) and a <Body> (mandatory), where the Body carries the actual message payload (e.g., a request or response for an operation). SOAP was designed to be transport-agnostic (it can work over HTTP, SMTP, etc., though HTTP is by far the most common). In practice, SOAP messages are usually sent over HTTP using POST requests, with a content type of text/xml.

Originally, SOAP was conceived alongside WSDL and UDDI as part of a web services stack. In this model, a service provider would publish a WSDL (Web Services Description Language) document describing the service’s interface (the operations, input/output types, etc.), and a service registry (using UDDI – Universal Description, Discovery, and Integration) could be used to find available services. The flow was often described as publish–find–bind: a provider publishes its WSDL to a registry, a consumer finds the service via the registry, then the consumer binds to the service by using the WSDL details to call it (via SOAP). In practice, public UDDI registries did not see wide adoption on the open internet (they saw more use within enterprises), and many services shared WSDL files through other means (like direct URLs).

A WSDL file is an XML document that formally describes a web service’s interface. It specifies the operations (methods) the service exposes, the input and output messages for each operation (often tied to XML Schema types), and the binding details (how the service can be accessed, e.g., SOAP over HTTP at a certain endpoint URL). In essence, WSDL acts similarly to an IDL from CORBA, but for web services. Development tools can take a WSDL and generate client-side stubs or server skeletons, making it easier to implement or consume the service. WSDL 1.1 (the version used in the 2000s) defines sections for types, messages, portTypes (interfaces), bindings, and service endpoints. For example, a WSDL might describe a getWeather(city) operation that takes a city name and returns weather data; the WSDL would include an XML Schema definition for the request/response structure, a portType with a getWeather operation, a binding (typically SOAP binding) and a service element with the endpoint URL.

When a SOAP service is invoked, the client typically uses the WSDL to format a SOAP request message in XML, sends it to the service’s URL (often an HTTP endpoint). The server parses the SOAP envelope, processes the request, and returns a SOAP response (also XML) containing the result or fault. One advantage of SOAP is that it is quite standardized: it supports formal error handling (via SOAP Fault messages), and over time the WS- extensions added features like security (WS-Security) for message encryption and signing, transactions, reliable messaging*, etc. These extensions made SOAP very powerful for enterprise needs — for instance, WS-Security could enforce authentication and integrity at the message level (beyond just transport-level TLS), and WS-ReliableMessaging could ensure messages get delivered even with network hiccups. However, these features also made the stack heavy and complicated.

It’s worth noting that SOAP was initially an acronym for Simple Object Access Protocol, reflecting that early usage treated it like a way to do RPC (call methods) in a platform-neutral way (somewhat analogous to an object invocation). However, later versions of SOAP de-emphasized the acronym – SOAP is not tied to object-oriented semantics; it can just as well exchange document-oriented messages. Today, SOAP is simply a protocol name, not an abbreviation.

When to use SOAP: SOAP remains useful in scenarios that require strong contracts and advanced features. For example, in banking or enterprise integrations where ACID transactions or standardized security assertions are needed, SOAP’s standards can be beneficial. SOAP is also used in certain legacy systems and government or enterprise integrations that were built in its heyday. If an organization already has SOAP APIs, it may continue using them especially for internal or B2B services where both sides use enterprise service buses or SOAP clients. But for public-facing APIs on the web, SOAP is less common today compared to RESTful approaches.

Example: Consider an enterprise application that provides a SOAP web service for employee data. The WSDL defines operations like CreateEmployee, GetEmployeeDetails, etc., with complex data types. A partner company can consume this service by importing the WSDL into their development toolkit, which generates proxy classes. They then call service.createEmployee(employeeObject) in code, which under the hood creates a SOAP XML message and posts it to the service. The SOAP response returns an XML with either a success confirmation or a fault if something went wrong (e.g., validation failure). Both sides have a clear agreement (via WSDL) on message format. This strict contract is useful for catching integration errors early (e.g., if the wrong data type is sent, the SOAP stack will throw an error).

WSDL and UDDI in context: WSDL is central to SOAP services as the interface definition. UDDI was the envisioned discovery mechanism. In the publish-find-bind model, UDDI registries would contain entries that describe businesses and the web services they offer, including technical details (by reference to the WSDL). In practice, many developers bypassed UDDI and shared WSDLs directly or via simpler directories. Nonetheless, the concept of a service registry lives on in other forms (as we discuss in Service Discovery, Section 7.5). UDDI itself is rarely used openly today, but within enterprises, some registry/repository systems (like IBM’s WebSphere Service Registry and Repository, or other SOA governance tools) played a similar role to manage services [9].

To summarize SOAP & WSDL:

• SOAP is the communication protocol (XML-based messaging over HTTP, etc.) used to exchange data.
• WSDL is the service description that tells consumers what messages and operations are available and how to call them.
• Together with UDDI (a service registry standard for publishing/discovering services), they comprised the original web services architecture. “SOAP enables the messaging between applications, WSDL describes the web services and their operations, and UDDI facilitates the discovery and integration of services.” [11]

---