Using SOAP

Message Framework
•Version 1.1
•Written in XML infoset

Principal features
•A message structure: envelop, body, header(s)
•A mechanism for data representation: data structures in XML (abstract data structure)
•An RPC mechanism: XML form in SOAP msg
•A processing model: rules that SOAP msg dealt with
•A protocol-binding framework: different transport protocols (HTTP etc)
•Extensibility mechanisms: place in header(s)
•An error-handling mechanism: fault messages can transfer error data


Features not supported by SOAP
•Activation: remote server object is activated only when a call to server is made
•Distributed garbage collection: disposal from memory of remote objects when local and remote reference are no longer active
•Message batching: grouping of multiple messages in to a batch and send to message dispatcher (use same TCP packet)
•Objects by reference: object resides on the remote machine

Syntax
•An envelope: entire SOAP message
•Message headers: supplementary information not part of the message itself
•Header entries: supplementary data (such as security or policy settings, extend basic functionality)
•Message body: holds message payload, follows the headers, if there are any
•Message payload: data or instructions in XML need to be passed. Can also be SOAP fault if an error occurs during processing


Message structure (data model)
•Simple-value node: incoming edges
•Compound-value node: outgoing edges
•A named edg is the equivalent of an XML element
























Encoding
•Provides a set of rules that translates a SOAP data model graph into XML code
•Transform grogrammatic entities (objects, arrays, variables, etc) into XML

Message Exchange Pattern (MEP)
•How SOAP message are exchanged between SOAP nodes
•Specifies number of messages inolved, where messages originate, and where they go
•Each SOAP binding must support at least one MEP


MEP type supported (SOAP 1.2)
•Request-Response: both SOAP message
•SOAP Response: requesting node sends an initial non-SOAP message; the responding node replies with a SOAP message. (respond to an HTTP request with a SOAP message)

Communication styles
•RPC: can be synchronous or asynchronous; no easy XML schema validation; data structure depends on structure of the method being called-limits the extent; tighter coupling between message structure and WS implementation code
•Document-style: can be synchronous or async; unencoded XML; XML schema validate; can be extended more easily

Transport bindings
•Infoset should be serialized using XML 1.0 serialization specification
•Bindings also use custom serializations (data compression, security)
•SOAP HTTP binding URI: W3C web site
•Java Message Service: guarantee arrival
•HTTPS: security
•HTTP: support both MEPs; encapsulated in HTTP request/response; SOAP Response MEP uses HTTP GET as request


HTTP
•HTTP binding can use the value held by Web Method (defined by SOAP 1.2) instead of the default POST method
•SOAPAction: custom HTTP header in SOAP 1.1; In SOAP 1.2 is replaced by media type application/soap+xml (can be used in HTTP Content-Type header)


Summary
Specification: processing model, data representation mechanisms, error-handling mechanisms, extensibility mechanisms, protocol-binding framework, RPC mechanism and SOAP-message definition.

Message Structure
•Not used to create application functionality
•But to transmit data or remote procedure calls in a technology-neutral way


Basic Structure
Java Class















Request / Response
















RPC Style SOAP
•Request – method: orderProduct;
•Serialized according encodingStyle
















•Response
•orderCode has return value
•orderTrackingURL is an out parameter (supplementary parameter)














Document-style SOAP
•Unencoded XML in SOAP envelope
•Header to connect the response


















Document-style Response
Header: same reference














Using headers
•Vertical extensibility
•Extend the messaging structure: additional metadata; (relatedto routing, message correiation, security, etc); middleware can define infrastructure headers (transparent to end application)
•Define orthogonal data: separate from, but related to data in body. (use headers to send extra data to accompany non-extensible body elements (useful for recipient application processing the message)


Using <Header>
Must be first child of <Envelope>



















mustUnderstand
•If not, send SOAP fault back



















Using intermediaries
•Horizontally extending SOAP message
Value-added services
•Securing message exchanges: encrypts, digitally signs
•Notarizing messages: make third party record of the interaction. (explicit intermediaries = client is aware when sending a message)
•Tracing messages: find out path followed, time of arrivals and departures and intermeiaries used.

Intermediaries Type
•Forwarding: SOAP node based on the semantics of message headers and forwards it to another node
•Active: performs additional processing not based on message’s semantics (eg. Encrypt a message even though none of the message’s headers specifically request encryption)

<Header> address to Intermediary

Role for next/none/ultimateReceiver intermediary
Relay: mast relay headers targeted

























Processing Model
•Determine the roles that apply to it: scan body & header
•Identifying mandatory headers: mandatory header blocks targeted at the node
•Generating faults, if necessary: if fails to understand, single SOAP fault with thevalue of set to
•Processing mandatory headers:also process nonmandatory SOAP header blocks
•Relaying the message


Fault structure
•Not only indicates error, but also the reason for the failure to the originator of the message


Fault message



Headers for faults
•<NotUnderstood>: response to @mustUnderstand
•Upgrade

Attachments and implementations
•Using SOAP to send binary data
•MTOM (SOAP Message Transmission Optimization Mechanism): how serialization method be used for SOAP over HTTP
•XOP (XML-binary Optimized Packaging): how binary data be serialized as XML
•SOAP Resource Representation Header
•WS-I Attachments Profile 1.0