SOAP (protocol)

SOAP (protocol)
Name	SOAP
Title	SOAP (protocol)
Developer	World Wide Web Consortium; Microsoft Corporation
Released	1999
Latest release	1.2 (2003)
Operating system	Cross-platform
Genre	Network protocol; Web services
License	Open standard

SOAP (protocol) SOAP is an XML-based messaging protocol for exchanging structured information in distributed computing environments. It was developed to enable interoperable Microsoft Corporation and IBM-era web services interactions and later standardized through the World Wide Web Consortium and IETF efforts, influencing interfaces in enterprise software such as SAP SE, Oracle Corporation, and Apache Software Foundation projects. SOAP messages are independent of programming models and transport protocols, enabling integration across platforms like Windows NT, Linux, and HP-UX.

History

SOAP originated in late 1990s interoperability work between Microsoft Corporation and UserLand Software engineers and was presented to standards bodies including the World Wide Web Consortium and the Internet Engineering Task Force. Early drafts were influenced by XML technologies such as XML Schema and Namespaces in XML, and by prior messaging concepts found in CORBA, DCOM, and RMI. Major corporate stakeholders included Microsoft Corporation, IBM, BEA Systems, and Sun Microsystems, all of which contributed to submissions and test suites. The protocol evolved through versions culminating in SOAP 1.2, which was published as a W3C Recommendation and refined via interoperability events with organizations like OASIS and standards such as WS-Security.

Architecture and Protocol Overview

SOAP defines a framework for message exchange rather than a concrete remote procedure call model, allowing for document-oriented and RPC-oriented interactions. It specifies an envelope abstraction and processing model influenced by Extensible Markup Language standards including XML Schema and Namespaces in XML. The architecture separates message syntax from the underlying application model; implementations can map SOAP onto transport bindings like Hypertext Transfer Protocol, Simple Mail Transfer Protocol, or Message Queuing Telemetry Transport. The SOAP processing model addresses intermediaries and routing consistent with practices from HTTP/1.1 and the Internet Protocol Suite.

Message Structure

A SOAP message consists of an envelope that contains an optional header and a mandatory body. The envelope uses XML namespace declarations compatible with Namespaces in XML and is constrained by XML Schema definitions in the 1.2 Recommendation. Headers can include extensions for routing, transactions, or security tokens defined in specifications such as WS-Security and WS-Addressing. The body carries application data which may be serialized according to XML Schema types or application profiles used by vendors like Microsoft Corporation or Oracle Corporation. Fault reporting follows a structured format for error codes and human-readable diagnostics that interoperates with management frameworks including Simple Network Management Protocol in integrated deployments.

Protocol Bindings and Transports

SOAP is deliberately transport-agnostic; common bindings map SOAP envelopes to transports such as Hypertext Transfer Protocol, Simple Mail Transfer Protocol, File Transfer Protocol, and message-oriented middleware like Java Message Service and IBM MQ. The most widespread binding is SOAP over HTTP, leveraging HTTP/1.1 semantics for methods like POST and status codes employed by servers like Apache HTTP Server and Microsoft Internet Information Services. Bindings to protocols used in enterprise integration, such as Advanced Message Queuing Protocol and Message Queuing Telemetry Transport, enable asynchronous and constrained-device scenarios favored by vendors like Red Hat and projects under the Eclipse Foundation.

Security and Reliability

Security extensions and profiles for SOAP were developed collaboratively by consortia including OASIS and industry players such as Microsoft Corporation and IBM. WS-Security defines mechanisms for attaching signature and encryption tokens using XML Signature and XML Encryption standards from the W3C and supports tokens from SAML assertions issued by identity providers like Microsoft Active Directory Federation Services. Reliable messaging specifications such as WS-ReliableMessaging address guaranteed delivery, duplicate elimination, and ordering for use with middleware from IBM and Oracle Corporation. Deployments often integrate with transport-level security offered by TLS on HTTP/1.1.

Implementations and Tooling

SOAP has been implemented in numerous toolkits and stacks across languages and platforms: for Java Platform, prominent implementations include Apache Axis and JAX-WS reference implementations from Oracle Corporation; for .NET, the protocol is supported in frameworks from Microsoft Corporation such as Windows Communication Foundation and legacy ASMX web services. Open-source tooling and frameworks from organizations like Apache Software Foundation, Eclipse Foundation, and vendors including Red Hat provide client and server bindings, test suites, and message inspectors. Development environments such as Eclipse IDE, Microsoft Visual Studio, and IntelliJ IDEA offer wizards and code generation from WSDL artifacts that describe SOAP service interfaces.

Criticism and Alternatives

SOAP has attracted criticism centered on perceived complexity, verbosity, and the proliferation of closely related specifications (the so-called "WS-* stack"). Critics from companies like Google and projects such as RESTful architecture proponents argue for simpler approaches using HTTP/1.1 verbs and hypermedia principles popularized by Roy Fielding. Alternative technologies include Representational State Transfer APIs, gRPC from Google, and lightweight data formats like JSON used by services at Twitter and Facebook. In response, some ecosystems simplified usage patterns or adopted hybrid models combining SOAP for guaranteed enterprise-level guarantees with RESTful interfaces for public-facing APIs.

Category:Web services protocols