SOAP Overview
Peter Komisar © Conestoga College  v.1.1 / 2005

references: "SOAP Version 1.2 Part 1: Messaging Framework,W3C Recommendation",
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/, "What's New in SOAP 1.2",
Marc Hadley, Sun MicroSystems, http://www.hadleynet.org/marc/whatsnew.html
'Professional Java Web Services' , M.Hendricks et. al., Wrox Press,
'Developing Java Web Services', R. Nagappan et. al. Wiley Press.

Brief History

Circa 1998, individuals from Microsoft, DevelopMentor and UserLand Software
created SOAP or the Simple Object Access Protocol. For unknown political
reasons, SOAP was not being released, so one of the participants, Dave Winer
of UserLand Software along with another of the SOAP originators produced and
published a protocol called XML-RPC which could be described as a subset of
SOAP. This action may have helped to precipitate the publication of SOAP 1.0
in 1999. 

SOAP had a native type system which was subsequently replaced by the datatype
specified in the XML Schema Part 2 Datatypes specification and SOAP 1.1 was
submitted to the W3C or the World Wide Web Consortium. The W3C started a
working group which drafted SOAP 1.2, Working Draft 1.

SOAP is now described in two parts, 'Messaging Frameworks' and Adjuncts. The
first part describes the SOAP envelope and the transport-binding framework. The
second part describe RPC conventions and encoding rules. 'SOAP Version 1.2
Part 1: Messaging Framework' and 'SOAP Version 1.2 : Adjuncts' were proposed
as W3C Recommendations in June of 2003.

A specification that is related to SOAP is the 'SOAP Messages with Attachments'
which is a W3C Note.  It shows how different attachments like images files can
be sent in association with a SOAP message using MIME multi-part messaging.
This allows compound documents to be sent using SOAP messaging without
interfering with SOAP processing.

The W3C Note is available for viewing at: http://www.w3.org/TR/SOAP-attachments
// an example from the note is included at the end of this web page.



SOAP W3C Recommendations

In addition to the Messaging Frameworks, and Adjuncts Recommendations, there is
also a Primer that is supplied that attempts to provide a user friendly explanation of
SOAP. The three documents listed below along with their web addresses.

SOAP Version 1.2 Part 0: Primer W3C Proposed Recommendation
http://www.w3.org/TR/2003/REC-soap12-part0-20030624


SOAP Version 1.2 Part 1: Messaging Framework W3C Proposed Recommendation
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/


SOAP Version 1.2 Part 2: Adjuncts W3C Proposed Recommendation
http://www.w3.org/TR/2003/REC-soap12-part2-20030624


SOAP Topic Divisions

SOAP is described in sections that pertain to different aspects of message processing.

• SOAP Processing Model                                                                                                                                                                                                // defines rules that control how SOAP messages are processed

• SOAP Extensibility Model                                                                                                                                                                                               // describes how SOAP can be extended to supply additional 'features'

• SOAP Protocol Binding Framework                                                                                                                                                                                 // defines a framework describing rules for how SOAP messages                                                                                                                                       // are exchanged over a variety of underlying protocols

• SOAP Message Construct                                                                                                                                                                                              // defines the structure of SOAP messages

Soap Terms and Concepts

Following are a set of terms adapted from a similar list supplied in the 
SOAP specification. Many terms are quoted. Long or complex definitions 
are paraphrased and shortened. Some attempts at brevity come at a loss 
of precision in meaning. Please refer to the SOAP 1.2 recommendation 
for the actual definitions. 

The XML Infoset

The following table supplies a quick overview of the XML InfoSet. While we will 
describe the elements used in SOAP in terms of traditional XML it should be 
noted that there is a trend to describing XML defined languages like SOAP in 
terms of 'XML Infosets'. The following table supplies a quick introduction to 
XML Infoset terminology. 

SOAP talks about the 'base URI' and the schema type xs:anyURI. The following 
table differentiates between the URI, URL URN.  


Reference for Distinguishing Uniform Resource Identifiers

SOAP Construct Overview

The Header element definitions seemed a little ambiguous. This is because 
it is designed to accommodate a series of 'Header Blocks', elements that are 
named by the developer and represent processing directives that are used by 
the SOAP application. We look at details of these 'blocks' in the next section. 
The other major element of the 'Envelope' element is the 'Body' element. In the 
schema the Body element is specified as follows.


Body Element Definition in the SOAP Schema

 <xs:element name="Body" type="tns:Body"/>
  <xs:complexType name="Body">
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>


The body element is the container for the messaging part of SOAP which
we look at in detail below.

The SOAP 1.1 specification including one child element for the Body element
called the Fault element. The Fault element is used to return information when
errors occur in a SOAP messaging system. In SOAP 1.2  Fault is not included
in the Body Element definition, but is allowable because the Body element is
a sequence of 'any' element types.

The Fault element definition in the SOAP 1.2 Schema is as follows. Again
we see the element defined in an empty form declared to the 'tns:Fault' type
followed by the complexType declaration called 'Fault'. Here we see that the
Fault element is made up of two required children, 'Code' and 'Reason' with
optional 'Node', 'Role' and 'Detail' child elements.


The Fault Element Definition in the SOAP Schema

<xs:element name="Fault" type="tns:Fault"/>
 <xs:complexType name="Fault" final="extension">
  // the final attribute restricts derivation by extension
  // #all restricts derivation by either derivation or extension
 <xs:annotation>
  <xs:documentation>
  Fault reporting structure
  </xs:documentation>
 </xs:annotation>
 <xs:sequence>
 <xs:element name="Code" type="tns:faultcode"/>
 <xs:element name="Reason" type="tns:faultreason"/>
 <xs:element name="Node" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="Role" type="xs:anyURI" minOccurs="0"/>
 <xs:element name="Detail" type="tns:detail" minOccurs="0"/>
 </xs:sequence>
 </xs:complexType>

The Fault Element and it's children add a lot to the complexity of understanding
the SOAP construct. We need to pay attention to the Fault Element as any
breakdowns in a SOAP system will be reported by the Fault element.

// When a fault occurs the response is provided as a SOAP Fault Message.
// SOAP 1.2 restricts a message to carrying a single Fault Element

To carry this analysis to it's logical conclusion we could look at the schema
code for each of the child elements of the Fault element. We will defer showing
these schema examples when we look at the details of these elements below.

Details of Elements of the SOAP Construct

After the tour of the SOAP Schema the following diagram that depicts a 
SOAP message may be welcomed.

A Simplified Depiction of the general structure of a SOAP message 

The SOAP Envelope Element  //  <soap:Envelope> 


The root element of a SOAP message is the 'Envelope' Element. It must
be associated with the namespace URI of either the SOAP 1.1 or 1.2
specification. Following are the namespace forms used by SOAP 1.1 
and 1.2


SOAP 1.1 and 1.2 Namepsaces // shown being assigned to conventional 'env' prefix

xmlns:env ="http:www.s3.org/2003/05/soap-envelope" // SOAP 1.2
xmlns:env ="http://schemas.xmlsoap.org/soap/envelope/  // SOAP 1.1 


While we are on the topic of namespaces two other namespaces are 
used frequently in SOAP.  One is used to identify the SOAP encoding 
style, which defines how SOAP defines data. The second defines 
elements used in SOAP RPC messaging. The examples also show 
the common prefix that is used for each of these namespaces.


Namespaces for  SOAP Encoding and RPC Formats
 
xmlns:enc = "http://www.w3.org/2003/05/soap-encoding"
xmlns:rpc = "http://www.w3.org/2003/05/soap-rpc"


Following is an example of an empty SOAP Envelope element. 

Example

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
// SOAP1.2 URI values
  ...
  <!--optional Header & mandatory Body -->
  ...
</soap:Envelope>

Global Attributes of the <soap:Envelope> Element

Recall that there were four global attributes contained in the schema
definition for the Envelope element.


Schema Definition of Global Attributes of the SOAP Construct

  <xs:attribute name="mustUnderstand" type="xs:boolean" default="0"/>
  <xs:attribute name="relay" type="xs:boolean" default="0"/>
  <xs:attribute name="role" type="xs:anyURI"/>
  <xs:attribute name="encodingStyle" type="xs:anyURI"/>


As mentioned earlier the first three attributes, 'mustUnderstand', 'relay', and
'role' are all directed at the way different  SOAP nodes will react to  header
information in SOAP messages. They become more significant when one
considers that the SOAP messaging model envisions the possibility of SOAP
intermediary nodes doing different sorts of processing based on directive that
are targeted to them in the Header. They are global which makes them
accessible for use in Header blocks, or elements inside the Header element.

In this context consider the role attribute.


The 'role' Attribute

A SOAP role is used to indicate to which SOAP node(s) a particular SOAP
header block is targeted . These roles are determined by a custom URI or
one of three pre-defined URIs, listed below.

Pre-defined Values for 'role' attribute URIs

• "http://www.w3.org/2003/05/soap-envelope/role/none"  //  "none"

• "http://www.w3.org/2003/05/soap-envelope/role/next"   // "next"

• "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" // "ultimateReceiver"

The following example from the W3C SOAP Primer shows these role types are
typically used in elements ('header blocks' )  inside the Header element.


Example From the W3C SOAP Primer   // a fourth block has been added

<?xml version="1.0" ?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header>
     <p:oneBlock xmlns:p="http://example.com" 
            env:role="http://example.com/Log">
     // 'oneBlock' is targeted at any SOAP node that plays the
     // application-defined role defined by the URI http://example.com/Log         
     </p:oneBlock>
     
     <q:anotherBlock xmlns:q="http://example.com"
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
     // "next" must be capable of processing the contents of the element, 
     // as this is a standardized role that every SOAP node must be 
     // willing to assume. 
     </q:anotherBlock>
     <r:aThirdBlock xmlns:r="http://example.com">
     // aThirdBlock does not have the env:role attribute. It is 
     // targeted at a SOAP node which assumes the "ultimateReceiver"
     // role.
     </r:aThirdBlock>
     
  <r:aThirdBlock xmlns:r="http://example.com">
     // aThirdBlock does not have the env:role attribute. It is 
     // targeted at a SOAP node which assumes the "ultimateReceiver"
     // role.
     </r:aThirdBlock>      
  <s:aFourthBlock xmlns s="http://example.com"
     env:role="http://www.w3.org/2003/05/soap-envelope/role/none">
      // a block assigned none is not to be processed by any SOAP
      // node. Rather it is there to supply supplemental information
      // and can be read by all nodes. 
    </env:Header>
   <env:Body >
     ...
     ...
   </env:Body>
 </env:Envelope>


When is assigned an empty string the URI will resolve to the base URI.

Example       env:role=""


This might be the Request-URI of the HTTP request, or the value of the HTTP
Content-Location header.

The following table shows the standardized roles various SOAP nodes may assume
where "Yes" and "No" determines if that corresponding node can play the named role.

W3C Table Summarizing How Different 'role' Attribute values Correspond to Roles 
Played by different SOAP Node Types.  // table from "SOAP Version 1.2 Part 1: Messaging 
Framework,W3C Recommendation",  http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

The  'mustUnderstand' Attribute

The 'mustUnderstand' attribute is a boolean value which may be specified
as a literal 'true' or 'false' value or alternatively, as ' 1 ' or ' 0 '. The default
value is false. This attribute is used to signal a SOAP node that is acting in 
the role to which this block is targeted that it must process this block correctly
or otherwise, it must return a fault message.
The  'encodingStyle' Attribute

The 'encodingStyle' attribute is used to specify what model data types will be
templated to. From the schema sample, it can be seen there is no 'default'
value for this attribute.  A typical assignment is SOAP's own Data Modeling
Description.

Example soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"

// In SOAP 1.2 the 'encodingStyle' attribute can be used only on children of the Body,
// Header and Detail elements. SOAP 1.1 allowed any element to use the attribute



The 'relay' Attribute

The 'relay' attribute signals intermediary nodes whether a header must be
relayed to the 'next' node if it has not been processed. It takes an xs:boolean
value, which if set to true means the associated block must be relayed to the
next SOAP node.

 The SOAP Header Element  // <soap:Header>

Recall we discovered that the SOAP Header element was an optional child
the Envelope element. Also note we saw an example of a Header with
'header blocks' in the example above. The Header element is the container
for header elements that may supply application specific information apart
from the message payload which is carried in the Body tag. Features such
as 'authentication', 'security', 'reliability' and 'routing' are all items that might
be dealt with inside header blocks.

The schema example we looked at earlier dictated that, if present, the Header
element would be the first child present in the Envelope element. All the
immediate children of the Header element also need to be namespace
qualified. In the following example the header block element is qualified
with the namespace associated with the 'cs' prefix.

Example

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="

 xmlns:env="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
<cs:creditStatus
xmlns:cs="http://www.example.com/status/" soap:mustUnderstand="true"> 
              1 
              </cs:creditStatus>
</soap:Header>
...

...
</soap:Envelope>

The SOAP Body Element

The Body element is required in a SOAP message. It is the carrier of the SOAP
message that is communicated to the 'ultimate receiver'. Depending on the type
of messaging exchange pattern that is being used the Body will carry messages
or remote procedure call and response. If something goes wrong, the Body tag
will, in SOAP 1.2, carry a single Fault element. Following is an example of a
typical SOAP message showing the required Body tag, (in bold).

Example  // Example 4 from the SOAP 1.2 Primer
< style="font-family: helvetica,arial,sans-serif;">
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaction
           xmlns:t="http://thirdparty.example.org/transaction"
           env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true" >5</t:transaction>
 </env:Header>
 <env:Body>
  <m:chargeReservation
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
         xmlns:m="http://travelcompany.example.org/">
   <m:reservation xmlns:m="http://travelcompany.example.org/reservation">
    <m:code>FT35ZBQ</m:code>
   </m:reservation>
   <o:creditCard xmlns:o="http://mycompany.example.com/financial">
    <n:name xmlns:n="http://mycompany.example.com/employees">
           Åke Jógvan Øyvind
    </n:name>
    <o:number>123456789099999</o:number>
    <o:expiration>2005-02</o:expiration>
   </o:creditCard>
  </m:chargeReservation>
 </env:Body>
</env:Envelope>


Marc Hadley, in 'What's new in SOAP 1.2' states  "SOAP 1.2 constrains the
body of a SOAP fault message to only contain a single child element, that
element being the SOAP Fault element. The semantics of a SOAP message
containing a SOAP Fault element plus sibling elements are not defined". 

To corroborate this further, Section 5.4 of the SOAP 1.2 Recommendation states

" To be recognized as carrying SOAP error information, a SOAP message MUST
contain a single SOAP Fault element information item as the only child element
information item of the SOAP Body . When generating a fault, SOAP senders MUST
NOT include additional element information items in the SOAP Body . A message
whose Body contains a Fault plus additional element information items has no
SOAP-defined semantics.

The Body schema definition is repeated below.

Body Element Definition in the SOAP Schema
 
<xs:element name="Body" type="tns:Body"/>
  <xs:complexType name="Body">
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" 
                 minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>

The Body definition shows it is possible to have a message with a Fault element
and other elements however it would not, in this case, have any SOAP-defined
meaning.

In any case this provides a segue* into an inspection of the Fault element.

// * a brief musical passage between episodes

The  SOAP Fault Element   //   <soap:Fault >

An failure or error condition that might occur in a SOAP communication
is reported using a Fault Element. Recall from our SOAP schema description
that there were a sequence of sub-elements that made up the Fault element.

The schema 'sequence' inside the Fault complexType Declaration
  
<xs:sequence>
 <xs:element name="Code" type="tns:faultcode"/>
 <xs:element name="Reason" type="tns:faultreason"/>
 <xs:element name="Node" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="Role" type="xs:anyURI" minOccurs="0"/>
 <xs:element name="Detail" type="tns:detail" minOccurs="0"/>
 </xs:sequence>


The sequence shows two required elements 'Code' and 'Reason' and 
three optional elements called 'Node', 'Role' and 'Detail'. A major 
restructuring of the Fault element has ocurred, transitioning from 
SOAP 1.1 to 1.2.   

SOAP 1.2  faults have different names than their SOAP 1.1 counterparts.
and are all namespace qualified. Following is a table from 'What's new in
SOAP 1.2' by Marc Hadley.

Table Comparing SOAP 1.1 to 1.2 Fault Sub-Elements
// Table adapted "Whats New in SOAP 1.2", Marc Hadley,
http://www.hadleynet.org/marc/whatsnew.html

The Code Element   

The following line from the SOAP 1.2 schema, shows that the Code 
element is of type 'faultcode'.

Example   <xs:element name="Code" type="tns:faultcode"/> 


The associated named, complexType definition is shown next. 


The 'faultcode' complexType Declaration

<xs:complexType name="faultcode">
    <xs:sequence>
      <xs:element name="Value" type="tns:faultcodeEnum"/>
      <xs:element name="Subcode" type="tns:subcode" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>


The Code element, being of type 'faultcode' has two sub-elements, a Value
sub-element that is type 'faultcodeEnum' and an optional 'Subcode' element
that is itself defined as a 'subcode' type. The schema definitions for these
two types are shown next.

The 'faultcodeEnum' complexType Declaration

 <xs:simpleType name="faultcodeEnum">
    <xs:restriction base="xs:QName">
      <xs:enumeration value="tns:DataEncodingUnknown"/>
      <xs:enumeration value="tns:MustUnderstand"/>
      <xs:enumeration value="tns:Receiver"/>
      <xs:enumeration value="tns:Sender"/>
      <xs:enumeration value="tns:VersionMismatch"/>
    </xs:restriction>
  </xs:simpleType>


Fault Codes

Recall this is a simpleType restricted to the enumeration values shown.
These values, 'DataEncodingUnknown', 'MustUnderstand', 'Receiver',
'Sender' and 'VersionMisMatch' represent the different types of faults
that can be specified.

The following table supplies details regarding the meaning of these
fault codes.


Description of SOAP 1.2 Fault Code // Adapted from Table 4 SOAP 1.2 Recommendation

The Subcode Element

The second child element of the Code element with the following schema definition.


Example <xs:element name="Subcode" type="tns:subcode" minOccurs="0"/>


The 'subcode' complexType declaration is as follows.

The 'subcode' complexType Declaration

  <xs:complexType name="subcode">
    <xs:sequence>
      <xs:element name="Value" type="xs:QName"/>
      <xs:element name="Subcode" type="tns:subcode" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>

Notice it supplies a Value element that is a built-in schema type, xs:QName, which
is an XML qualified name. This value would be is an application-defined sub-category
of the value of the Subcode 's parent element. Optionally the sub-categorization
could continue with another 'subcode' element.

The Reason Element

The following schema element definition shows that the Reason element is a
'faultreason' type.

Example  <xs:element name="Reason" type="tns:faultreason"/>


Following is the complexType definition for the 'faultreason' type.

<xs:complexType name="faultreason">
    <xs:sequence>
      <xs:element name="Text" type="tns:reasontext" minOccurs="1" maxOccurs="unbounded"/>
        </xs:sequence>
  </xs:complexType>

The definition shows that there can be one or more 'Text' elements associated with the 
'Reason' element. The 'Text' is in turn another type, 'reasontext' which we need to 
investigate. 

The 'reasontext' complexType Declaration

<xs:complexType name="reasontext">
    <xs:simpleContent>
          <xs:extension base="xs:string">
            <xs:attribute ref="xml:lang" use="required"/>
          </xs:extension>
        </xs:simpleContent>
  </xs:complexType>

The above definition may remind you of the formula for creating an element that has
simple content but also has an attribute. This definition indicates the element provides
a text string but also includes a required xml:lang attribute.  

This explanation is a little complex, considering the Reason element with it's set of
Text elements is provided to simply supply a humanly readable explanation of the
fault. 

The Node Element

Following is the Node element schema definition. It is typed to a built in schema
type, xs:anyURI. 

Example <xs:element name="Node" type="xs:anyURI" minOccurs="0"/>

This element is used to store the URI of the SOAP node that generated the fault. 
If an intermediary node generates the fault, this element must be supplied. If the 
ultimate receiver is the Node that generates the fault, then the receiver node, may
supply the Node element, but it is not necessary. 


The Role Element 

The role element is also simple and uses a built in type to describe the role played
by the faulting node. 

Example   <xs:element name="Role" type="xs:anyURI" minOccurs="0"/>


The value of the Role element must be one of the roles that was assumed by the
node taken during the processing of the message.  

The Detail Element

Example  <xs:element name="Detail" type="tns:detail" minOccurs="0"/> 


Last but not least, of the Fault sub-elements is the Detail Element. The Detail 
element has a type called 'detail'. The SOAP 1.2 Schema reveals the 'detail' 
definition. The detail can be any number of elements and attributes as long
as they are namespace qualified. 
 
The 'detail' complexType Declaration

<xs:complexType name="detail">
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType> 

SOAP Fault Example

Just so we don't lose sight of the SOAP Fault XML following is an example 
taken from the W3C SOAP Primer which shows many of the elements we 
have discussed being deployed. Notice this follows SOAP 1.2's prescription 
that only a single Fault element be included in a correct SOAP Fault Message.  


Fault Example // from the W3C SOAP Primer 

HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="en-US">Processing error</env:Text>
      <env:Text xml:lang="cs">Chyba zpracování</env:Text>
     </env:Reason>
     <env:Detail>
      <e:myFaultDetails 
        xmlns:e="http://travelcompany.example.org/faults" >
        <e:message>Name does not match card number</e:message>
        <e:errorcode>999</e:errorcode>
      </e:myFaultDetails>
     </env:Detail>
   </env:Fault>
 </env:Body>
</env:Envelope>


Handling a Version Fault

The SOAP 1.2 schema also defines an Upgrade header element. It has 
been added to assist in dealing with SOAP messaging that causes errors 
by cross version communications. The SOAP 1.2 mechanism to handle 
this problem is described in the following statement.  "A SOAP 1.2 node 
receiving a SOAP 1.1 message is required to create a SOAP 1.1 envelope 
containing 'VersionMismatch' fault and an Upgrade header which lists
the supported envelope version. 

Example // from 'What's new in SOAP 1.2 

<V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-envelope">
  <envelope
    qname="ns1:Envelope" 
    xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/"/>
  <envelope
    qname="ns2:Envelope" 
    xmlns:ns2="http://www.w3.org/2001/12/soap-envelope"/>
</V:Upgrade>

Changes in HTTP Binding From SOAP 1.1 to SOAP 1.2

SOAP 1.1 had a mandatory SOAPAction HTTP header that has been
removed in SOAP 1.2 and been replaced by an optional 'action' parameter.
Also the Content Type in SOAP 1.2 has been changed from text/xml to
media type, 'application/soap+xml'.

SOAP 1.2 Media Type    application/soap+xml

Following are two examples, the first of an HTTP Get Request using
the new media type value in the Accept. In SOAP 1.2, in a GET request
the 'Accept' header must be allocated  the  'application/soap+xml '
media type value to signal to the receiver that SOAP response is
required.

Example Showing Required Accept Value Specified  in a GET Request
// example from 'What's new in SOAP 1.2" by Marc Hadley

GET /itinerary?reservation=1234567890 HTTP/1.1
Host: travelcompany.com
Accept: application/soap+xml

A SOAP Response Example
// example from 'What's new in SOAP 1.2" by Marc Hadley

HTTP/1.1 200 OK
Content-Type: application/soap+xml
Content-Length: nnnn
<?xml version="1.0"?>
<e:Envelope xmlns:e='...'>
  <e:Body>
    <f:itinerary xmlns:f='...'>
      <f:itinid>1234567890</f:itinid>
      ...
    </f:itinerary>
  </e:Body>
</e:Envelope>

SOAP Messages With Attachments Example 

Earlier in the note we said we would show an example of a SOAP message being 
sent with an attachment.  Here is that example. 

Example from the SOAP Messages With Attachments Note  // w3.org // for reference 

 "The following example shows a SOAP 1.1 message with an attached 
  facsimile image of the signed claim form (claim061400a.tiff):"
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
        start="<claim061400a.xml@claiming-it.com>"
Content-Description: This is the optional message description.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
...binary TIFF image...
--MIME_boundary--

 The MIME Multipart/Related encapsulation of a SOAP message is semantically equivalent to a SOAP 
 protocol binding in that the SOAP message itself is not aware that it is being encapsulated. That is, 
 there is nothing in the primary SOAP message proper that indicates that the SOAP message is
 encapsulated
.

Text Reading Chapter 4, 103 to 138  
// Read being aware that this section is based on SOAP 1.1, particularly
// the section on 'Encoding'. Refer to 'What's new in SOAP 1.2'  by Marc
// Hadley to note differences between SOAP 1.1 and 1.2 . 

Alternatively, just read our note and we will cover SOAP 1.2 Encoding
and other SOAP details next week.

Exercise

1) Create a SOAP Message with an XML declaration and a SOAP Envelope.
Create three fictional Header Blocks, that relate to authentication, accountBalance
and creditStatus. Target one at 'none' to be used by any SOAP node. Target one at
'next' and one at the ultimate receiver, this by omitting specifying the 'role' attribute.
Remember each header element must be namespace qualified.

Create a message body that contains a Customers basic information, including
first and last name, address and Postal Code. ( Feel free to use XML instances
you have created in earlier exercises.)

2) Create a SOAP Fault Message modeled on the W3C Fault example provided.
However make this fault a 'receiver' type error. This Fault might be designed
as a potential error response to the SOAP message created in question 1.

Supplemental

3) If you have time read through this note in preparation for next week.