SOAP is a specification for the exchange of structured information in a decentralized, distributed environment. As such, it represents the main way of communication between the three key actors in a service oriented architecture (SOA): service provider, service requestor and service broker. The main goal of its design is to be simple and extensible. A SOAP message is used to request a web service.
We can use tools such as SOAPUI to test SOAP connections outside of the application server.
WebSphere Application Server follows the standards outlined in SOAP 1.1.
SOAP was submitted to the World Wide Web Consortium (W3C) as the basis of the XML Protocol Working Group by several companies, including IBM and Lotus . This protocol consists of three parts:
- An envelope that defines a framework for describing message content and processing instructions.
- A set of encoding rules for expressing instances of application-defined data types.
- A convention for representing remote procedure calls and responses.
SOAP 1.1 is a protocol-independent transport and can be used in combination with a variety of protocols. In web services developed and implemented with WAS, SOAP is used in combination with HTTP, HTTP extension framework, and JMS. SOAP is also operating-system independent and not tied to any programming language or component technology.
As long as the client can issue XML messages, it does not matter what technology is used to implement the client. Similarly, the service can be implemented in any language, as long as the service can process SOAP messages. Also, both server and client sides can reside on any suitable platform.
The SOAP 1.2 specification is also a W3C recommendation, and WAS follows the standards that are outlined in SOAP 1.2. The SOAP 1.2 specification comes in three parts plus some assertions and a test collection:
- Part 0: Primer
- Part 1: Messaging Framework
- Part 2: Adjuncts
- Specification Assertions and Test Collection
SOAP 1.2 provides a more specific definition of the SOAP processing model, which removes many of the ambiguities that sometimes led to interoperability problems in the absence of the Web Services-Interoperability (WS-I) profiles. SOAP 1.2 should reduce the chances of interoperability issues with SOAP 1.2 implementations between different vendors.
Some of the more significant changes in the SOAP 1.2 specification include:
- The ability to now officially define other transport protocols other than the HTTP protocol as long as vendors conform to the binding framework defined in SOAP 1.2. While HTTP is ubiquitous, it is not as reliable of a transport as other things such as TCP/IP, Q, and so forth.
- The fact that SOAP 1.2 is based on the XML Information Set (XML Infoset). The information set provides a way to describe the XML document using the XSD schema but does not necessarily serialize the document using XML 1.0 serialization. SOAP 1.1 is based upon XML 1.0 serialization. The information set will make it easier to use other serialization formats such as a binary protocol format. Use a binary protocol format shrink the message into a much more compact format where some of the verbose tagging information might not be required.
The JAX-WS standard introduces the ability to support both SOAP 1.1 as well as SOAP 1.2.
See the differences is SOAP versions information for additional differences between SOAP 1.1 and SOAP 1.2.
For a complete list of the supported standards and specifications, see the web services specifications and API documentation.
- SOAP with Attachments API for Java interface
- Differences in SAAJ versions
- Message Transmission Optimization Mechanism
- Differences in SOAP versions
Web services specifications and APIs SOAP Version 1.1 Note SOAP Version 1.2