SOAP.
SOAP is an XML-based protocol for web services with formal contracts in WSDL, and standards covering security, transactions and reliable messaging. It remains common in enterprise, financial and government systems.
Where SOAP fits on a long engagement.
SOAP persists because it offers things REST does not standardise. A WSDL is a machine-readable contract from which clients are generated, and the WS-* standards cover message-level security, transactions and reliable delivery in ways that require bespoke implementation elsewhere.
It is verbose and the tooling has aged, but a working SOAP integration with a bank or a government service is not a candidate for modernisation simply because the protocol is unfashionable. The other end is not changing.
What an assigned team does with SOAP.
Most SOAP work is consuming someone else's service, which means their conventions, their quirks and their undocumented behaviour. Namespace handling, optional element semantics and fault structures all vary in ways the WSDL does not fully capture.
Working effectively within those constraints is the job rather than improving them, and how that scope is agreed is described in how an assignment runs.
What we use SOAP for.
- Integrating with institutional services Banking and government endpoints where SOAP is what is offered.
- Contracts that generate clients WSDL-driven code generation, keeping the client in step with the contract.
- Message-level security where required WS-Security signing and encryption when transport security is not sufficient.
How SOAP capacity is assigned.
Legacy protocol integration is assigned inside development capacity, working within the counterparty's constraints rather than proposing they change.
Tell us what your roadmap needs SOAP for.
A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.
Loading the contact form… You can also email hello@azendo.co.
We reply within one working day. No obligation, and no newsletter.