SOAP

SOAP (formerly known as Simple Object Access Protocol) is a lightweight protocol for the exchange of information in a decentralized, distributed environment. A SOAP message is a transmission of information from a sender to a receiver. SOAP messages can be combined to perform request/response patterns.

SOAP is transport independent but is most commonly carried over HTTP in order to run with the existing Internet infrastructure. SOAP enables the binding and use of discovered web services by defining a message path for routing messages. SOAP is used to query UDDI for web services.

The Java™ API for XML web services (JAX-WS) standard introduces the ability to support both SOAP 1.1 as well as SOAP 1.2. With WebSphere® Application Server V7.0 and later or WebSphere Application Server Liberty installed, the workbench supports SOAP 1.1 and SOAP 1.2.

SOAP 1.1

SOAP 1.1 is a protocol-independent transport and can be used in combination with a variety of protocols. In web services that are developed and implemented with WebSphere Application Server, SOAP is used in combination with HTTP, HTTP extension framework, and Java Message Service (JMS). SOAP is also operating-system independent and not tied to any programming language or component technology. Provided that 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, provided that the service can process SOAP messages. Also, both server and client sides can reside on any suitable platform.

SOAP is an XML-based protocol that defines three parts of every message:

  • Envelope. The envelope defines a framework for describing what is in a message and how to process it. A SOAP message is an envelope that contains zero or more headers and exactly one body. The envelope is the top-level element of the XML document, providing a container for control information, the address of a message, and the message itself. Headers transport any control information such as quality-of-service attributes. The body contains the message identification and its parameters. Both the headers and the body are child elements of the envelope.
  • Encoding rules. The set of encoding rules expresses instances of application-defined data types. Encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types. SOAP defines a programming language-independent data type scheme based on XSD plus encoding rules for all data types defined according to this model. SOAP encoding is not WS-I compliant and thus the Literal use (which is no encoding) is suggested for interoperable Web services and required for WS-I compliance.
  • Communication styles. Communications can follow a remote procedure call (RPC) or message-oriented (Document) format.

SOAP supports two different communication styles:

  • Remote procedure call (RPC): RPC is the invocation of an operation returning a result. RPC is typically used with SOAP encoding, which is not WS-I compliant.
  • Document Style: Document style is also known as document-oriented or message-oriented style. This style provides a deeper layer of abstraction, and requires more programming work.

In distributed computing environments, encoding styles define how data values that are defined in the application can be translated to and from a particular protocol format. The translation process is known as serialization and deserialization. The SOAP 1.1 specification defines the SOAP encoding style:

  • SOAP encoding: The SOAP encoding style enables you to serialize/deserialize values of data types from the SOAP data model. This encoding style is defined in the SOAP 1.1 standard, and is not WS-I compliant.

WSDL defines the Literal XML encoding style:

  • Literal XML: Literal refers to the fact that the document should be read as-is, or unencoded. The document is serialized as XMI, meaning that the message XML complies with the Schema in the WSDL. When using Literal encoding, each message part references a concrete schema definition. Literal encoding is WS-I compliant.

SOAP 1.2

The SOAP 1.2 specification is also a World Wide Web Consortium (W3C) recommendation, and the tools included in this workbench follow 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:

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 that is defined in SOAP 1.2. While HTTP is ubiquitous, it is not as reliable of a transport as other things such as TCP/IP, MQ, 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 by 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. You can 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.

Additional information about SOAP

For a more detailed examination of the differences between SOAP 1.1 and 1.2, see Differences in SOAP versions.