Namespaces Soap

Declaring and Applying Namespaces
Namespaces are declared as an attribute of an element. It is not mandatory to declare namespaces only at
the root element; rather it could be declared at any element in the XML document. The scope of a declared
namespace begins at the element where it is declared and applies to the entire content of that element,
unless overridden by another namespace declaration with the same prefix namewhere, the content of an
element is the content between the <opening-tag> and </closing-tag> of that element. A namespace is
declared as follows:
<someElement xmlns:pfx="http://www.foo.com" />
In the attribute xmlns:pfx, xmlns is like a reserved word, which is used only to declare a namespace. In
other words, xmlns is used for binding namespaces, and is not itself bound to any namespace. Therefore,
the above example is read as binding the prefix "pfx" with the namespace "http://www.foo.com."
It is a convention to use XSD or XS as a prefix for the XML Schema namespace, but that decision is purely
personal. One can choose to use a prefix ABC for the XML Schema namespace, which is legal, but doesn't
make much sense. Using meaningful namespace prefixes add clarity to the XML document. Note that the
prefixes are used only as a placeholder and must be expanded by the namespace-aware XML parser to use
the actual namespace bound to the prefix. In Java analogy, a namespace binding can be correlated to
declaring a variable, and wherever the variable is referenced, it is replaced by the value it was assigned.
In our previous namespace declaration example, wherever the prefix "pfx" is referenced within the
namespace declaration scope, it is expanded to the actual namespace ( http://www.foo.com) to which it
was bound:
In Java: String pfx = "http://www.library.com"
In XML: <someElement xmlns:pfx="http://www.foo.com" />
Although a namespace usually looks like a URL, that doesn't mean that one must be connected to the
Internet to actually declare and use namespaces. Rather, the namespace is intended to serve as a virtual
"container" for vocabulary and un-displayed content that can be shared in the Internet space. In the Internet
space URLs are uniquehence you would usually choose to use URLs to uniquely identify namespaces.
Typing the namespace URL in a browser doesn't mean it would show all the elements and attributes in that
namespace; it's just a concept.
But here's a twist: although the W3C Namespaces in XML Recommendation declares that the namespace
name should be an IRI, it enforces no such constraint. Therefore, I could also use something like:
<someElement xmlns:pfx=" foo" />
which is perfectly legal.
By now it should be clear that to use a namespace, we first bind it with a prefix and then use that prefix
wherever required. But why can't we use the namespaces to qualify the elements or attributes from the
start? First, because namespacesbeing IRIsare quite long and thus would hopelessly clutter the XML
document. Second and most important, because it might have a severe impact on the syntax, or to be
specific, on the production rules of XMLthe reason being that an IRI might have characters that are not
allowed in XML tags per the W3C XML 1.0 Recommendation .
Invalid) <http://www.library.com:Book />

Valid) <lib:Book xmlns:lib="http://www.library.com" />
Below the elements Title and Author are associated with the Namespace http://www.library.com:
<?xml version="1.0"?>
<Book xmlns:lib="http://www.library.com">
<lib:Title>Sherlock Holmes</lib:Title>
<lib:Author>Arthur Conan Doyle</lib:Author>
</Book>
In the example below, the elements Title and Author of Sherlock Holmes - IIIand Sherlock
Holmes - I are associated with the namespace http://www.library.com and the elements Title
and Author of Sherlock Holmes - II are associated with the namespace
http://www.otherlibrary.com.
<Book xmlns:lib="http://www.library.com">
<lib:Title>Sherlock Holmes - I</lib:Title>
<purchase xmlns:lib="http://www.otherlibrary.com">
<lib:Title>Sherlock Holmes - II</lib:Title>
</purchase>
<lib:Title>Sherlock Holmes - III</lib:Title>
</Book>
The W3C Namespaces in XML Recommendation enforces some namespace constraints:
1.
2.
Prefixes beginning with the three-letter sequence x, m, and l, in any case combination, are
reserved for use by XML and XML-related specifications. Although not a fatal error, it is inadvisable
to bind such prefixes. The prefix xml is by definition bound to the namespace name
http://www.w3.org/XML/1998/namespace.
A prefix cannot be used unless it is declared and bound to a namespace. (Ever tried to use a
variable in Java without declaring it?)
The following violates both these constraints:
<Book xmlns:XmlLibrary="http://www.library.com">
<lib:Title>Sherlock Holmes - I</lib:Title>
</Book>
[Error]: prefix lib not bound to a namespace.
[Inadvisable]: prefix XmlLibrary begins with 'Xml.'
Default Namespace (Not Default Namespaces)
It would be painful to repeatedly qualify an element or attribute you wish to use from a namespace. In such
cases, you can declare a {default namespace} instead. Remember, at any point in time, there can be only
one {default namespace} in existence. Therefore, the term "Default Namespaces" is inherently incorrect.
Declaring a {default namespace} means that any element within the scope of the {default namespace}
declaration will be qualified implicitly, if it is not already qualified explicitly using a prefix. As with prefixed
namespaces, a {default namespace} can be overridden too. A {default namespace} is declared as follows:
<someElement
xmlns="http://www.foo.com" />
<Book xmlns="http://www.library.com">
<Title>Sherlock Holmes</Title>
<Author>Arthur Conan Doyle</Author>
</Book>
In this case the elements Book, Title, and Author are associated with the Namespace
http://www.library.com.
Remember, the scope of a namespace begins at the element where it is declared. Therefore, the element
Book is also associated with the {default namespace}, as it has no prefix.
<Title>Sherlock Holmes - I</Title>
<purchase xmlns="http://www.otherlibrary.com">
<Title>Sherlock Holmes - II</Title>
</purchase>
<Title>Sherlock Holmes - III</Title>
</Book>
In the above, the elements Book, and Title, and Author of Sherlock Holmes - III and Sherlock
Holmes - I are associated with the namespace http://www.library.com and the elements
purchase, Title, and Author of Sherlock Holmes - II are associated with the namespace
http://www.otherlibrary.com.
Default Namespace and Attributes
Default namespaces do not apply to attributes; therefore, to apply a namespace to an attribute the attribute
must be explicitly qualified. Here the attribute isbn has {no namespace} whereas the attribute cover is
associated with the namespace http://www.library.com.
<Book isbn="1234"
pfx:cover="hard"
xmlns="http://www.library.com"
xmlns:pfx="http://www.library.com">
<Title>Sherlock Holmes</Title>
</Book>
Undeclaring Namespace
Unbinding an already-bound prefix is not allowed per the W3C Namespaces in XML 1.0 Recommendation,
but is allowed per W3C Namespaces in XML 1.1 Recommendation. There was no reason why this should
not have been allowed in 1.0, but the mistake has been rectified in 1.1. It is necessary to know this
difference because not many XML parsers yet support Namespaces in XML 1.1.
Although there were some differences in unbinding prefixed namespaces, both versions allow you to unbind
or remove the already declared {default namespace} by overriding it with another {default namespace}
declaration, where the namespace in the overriding declaration is empty. Unbinding a namespace is as good
as the namespace not being declared at all. Here the elements Book, Title, and Author of Sherlock
Holmes - III and Sherlock Holmes - I are associated with the namespace
http://www.library.com and the elements purchase, Title, and Author of Sherlock Holmes II have {no namespace}:
<someElement
xmlns="" />
<Title>Sherlock Holmes - I</Title>
<purchase xmlns="">
<Title>Sherlock Holmes - II</Title>
</purchase>
<Title>Sherlock Holmes - III</Title>
</Book>
Here's an invalid example of unbinding a prefix per Namespaces in XML 1.0 spec, but a valid example per
Namespaces in XML 1.1:
<purchase xmlns:lib="">
From this point on, the prefix lib cannot be used in the XML document because it is now undeclared as
long as you are in the scope of element purchase. Of course, you can definitely re-declare it.
No Namespace
No namespace exists when there is no default namespace in scope. A {default namespace} is one that is
declared explicitly using xmlns. When a {default namespace} has not been declared at all using xmlns, it is
incorrect to say that the elements are in {default namespace}. In such cases, we say that the elements are in
{no namespace}. {no namespace} also applies when an already declared {default namespace} is
undeclared.
In summary:
The scope of a declared namespace begins at the element where it is declared and applies to all
the elements within the content of that element, unless overridden by another namespace
declaration with the same prefix name.
Both prefixed and {default namespace} can be overridden.
Both prefixed and {default namespace} can be undeclared.
{default namespace} does not apply to attributes directly.

A {default namespace} exists only when you have declared it explicitly. It is incorrect to use the
term {default namespace} when you have not declared it.
No namespace exists when there is no default namespace in scope.
Namespaces and XML Schema

Thus far we have seen how to declare and use an existing namespace. Now let's examine how to create a
new namespace and add elements and attributes to it using XML Schema.
XML Schema is an XML before it's anything else. In other words, like any other XML document, XML
Schema is built with elements and attributes. This "building material" must come from the namespace
http://www.w3.org/2001/XMLSchema, which is a declared and reserved namespace that contains
elements and attributes as defined in W3C
XML Schema Structures Specification and W3C

XML Schema Datatypes Specification . You should not add elements or attributes to this
namespace.
Using these building blocks we can create new elements and attributes as required and enforce the required
constraints on these elements and attributes and keep them in some namespace. (See Figure 1 .) XML
Schema calls this particular namespace as the {target namespace}, or the namespace where the newly
created elements and attributes will reside.
Figure 1: Elements and attributes in XML Schema namespace are used to write an
XML Schema document, which generates elements and attributes as defined by user
and puts them in {target namespace}. This {target namespace} is then used to
validate the XML instance.
This {target namespace} is referred from the XML instance for ensuring validity of the instance document.
(See Figure 2 .) During validation, the Validator verifies that the elements/attributes used in the instance
exist in the declared namespace, and also checks for any other constraint on their structure and datatype.
Figure 2: From XML Schema to XML Schema instance
Qualified or Unqualified
In XML Schema we can choose to specify whether the instance document must qualify all the elements and
attributes, or must qualify only the globally declared elements and attributes. Regardless of what we choose,
the entire instance would be validated. So why do we have two choices?
The answer is "manageability." When we choose qualified , we are specifying that all the elements and
attributes in the instance must have a namespace, which in turn adds namespace complexity to instance. If
say that the schema is modified by making some local declarations global and/or making some global
declarations local, then the instance documents are not affected at all. In contrast, when we choose
unqualified , we are specifying that only the globally declared elements and attributes in the instance must
have a namespace, which in turn hides the namespace complexity from the instance. But in this case, if say,
the schema is modified by making some local declarations global and/or making some global declarations
local, then all instance documents are affectedand the instance is no longer valid. The XML Schema
Validator would report validation errors if we try to validate this instance against the modified XML Schema.
Therefore, the namespaces must be fixed in the instance per the modification done in XML Schema to make
the instance valid again.
<?xml version="1.0" encoding="US-ASCII"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.library.com"
targetNamespace="http://www.library.com"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<element name="Book" type="tns:BookType" />
<complexType name="BookType">
<sequence>
<element name="Title" type="string" />
<element name="Author" type="string" />
</sequence>
</complexType>
</schema>
The declarations that are the immediate children of the element <schema> are the global declarations, and
the rest are local declarations. In the above example, Book and BookType are declared globally whereas
Title and Author are local declarations.
We can express the choice between qualified and unqualified by setting the schema element attributes
elementFormDefault and attributeFormDefault to either qualified or unqualified.
elementFormDefault
= (
qualified | unqualified) : unqualified

attributeFormDefault = (
qualified | unqualified) : unqualified
When elementFormDefault is set to qualified , it implies that in the instance of this grammar all the
elements must be explicitly qualified, either by using a prefix or setting a {default namespace}. An
unqualified setting means that only the globally declared elements must be explicitly qualified, and the
locally declared elements must not be qualified. Qualifying a local declaration in this case is an error.
Similarly, when attributeFormDefault is set to qualified , all attributes in the instance document
must be explicitly qualified using a prefix.
Remember, {default namespace} doesn't apply to attributes; hence, we can't use a {default namespace}
declaration to qualify attributes. Unqualified seems to imply being in the namespace by virtue of the
containing element. This is interesting, isn't it?
In the following diagrams, the concept symbol space is similar to the non-normative concept of namespace
partition. For example, if a namespace is like a refrigerator, then the symbol spaces are the shelves in the
refrigerator. Just as shelves partition the entire space in a refrigerator, the symbol spaces partition the
namespace.
There are three primary partitions in a namespace: one for global element declarations, one for global
attribute declarations, and one for global type declarations (complexType/simpleType). This arrangement
implies we can have a global element, a global attribute, and a global type all have the same name, and still
co-exist in a {target namespace} without any name collisions. Further, every global element and a
global complexType have their own symbol space to contain the local declarations.
Let's examine the four possible combinations of values for the pair of attributes elementFormDefault and
attributeFormDefault.
Case 1: elementFormDefault=qualified, attributeFormDefault=qualified
Here the {target namespace} directly contains all the elements and
attributes; therefore, in the instance, all the elements and attributes
must be qualified.
Case 2: elementFormDefault=qualified, attributeFormDefault=unqualified
Here the {target namespace} directly contains all the elements and the
corresponding attributes for these elements are contained in the symbol
space of the respective elements. Therefore, in the instance, only the
elements must be qualified and the attributes must not be qualified,
unless the attribute is declared globally.
Case 3: elementFormDefault=unqualified, attributeFormDefault=qualified
Here the {target namespace} directly contains all the attributes and only the
globally declared elements, which in turn contains its child elements in its symbol
space. Therefore, in the instance, only the globally declared elements and all the
attributes must be qualified.
Case 4: elementFormDefault=unqualified, attributeFormDefault=unqualified
Here the {target namespace} directly contains only the globally declared
elements, which in turn contains its child elements in its symbol space. Every
element contains the corresponding attributes in its symbol space; therefore, in
the instance, only the globally declared elements and attributes must be
qualified.
The above diagrams are intended as a visual representation of what is directly contained in a namespace
and what is transitively contained in a namespace, depending on the value of elementFormDefault/
attributeFormDefault. The implication of this setting is that the elements/attributes directly in the
{target namespace} must have a namespace associated with them in the corresponding XML instance,
and the elements/attributes that are not directly (transitively) in the {target namespace} must not have a
namespace associated with them in the corresponding XML instance.
Target Namespace and No Target Namespace
Now we know that XML Schema creates the new elements and attributes and puts it in a namespace called
{target namespace}. But what if we don't specify a {target namespace} in the schema? When we don't
specify the attribute targetNamespace at all, no {target namespace} existswhich is legalbut specifying
an empty URI in the targetNamespace attribute is "illegal."
For example, the following is invalid. We can't specify an empty URI for the {target namespace}:
<schema targetNamespace="" . . .>
In this case, when no {target namespace} exists, we say, as described earlier, that the newly created
elements and attributes are kept in {no namespace}. (It would have been incorrect to use the term {default
namespace}.) To validate the corresponding XML instance, the corresponding XML instance must use the
noNamespaceSchemaLocation attribute from the http://www.w3.org/2001/XMLSchema-instance
namespace to refer to the XML Schema with no target namespace.
Referencing Schema Documents

In addition to providing a means of referencing the schema of a schema document,
namespaces also play an important role in documents that rely on an XSD schema for
validation. If this sounds confusing, I think a quick explanation will clear things up. In
order to identify the physical schema document for a document, you must use a special
attribute and assign the location of the schema document to it. There are two attributes
you can use to accomplish this task:
schemaLocation Locates a schema and its associated namespace
noNamespaceSchemaLocation Locates a schema with no namespace
These attributes are standard attributes that are located in a namespace named
http://www.w3.org/2001/XMLSchema-instance. In order to properly reference either of
these attributes, you must first explicitly declare the namespace in which they are located.
It is standard to use the xsi prefix for this namespace, as the following attribute
assignment shows:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
With this namespace declared, you can now use one of the schema location attributes to
reference the physical schema document
SOAP is an XML-based protocol for exchanging information between computers.

SOAP is XML. That is, SOAP is an application of the XML specification.
All statements are TRUE for SOAP
SOAP is acronym for Simple Object Access Protocol

SOAP is a communication protocol
SOAP is designed to communicate via Internet
SOAP can extend HTTP for XML messaging
SOAP provides data transport for Web services
SOAP can exchange complete documents or call a remote procedure
SOAP can be used for broadcasting a message
SOAP is platform and language independent
SOAP is the XML way of defining what information gets sent and how
Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of
transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.
SOAP enables client applications to easily connect to remote services and invoke remote methods.
Other frameworks, including CORBA, DCOM, and Java RMI, provide similar functionality to SOAP, but
SOAP messages are written entirely in XML and are therefore uniquely platform- and languageindependent.
SOAP message is an ordinary XML document containing the following elements.
Envelope:
(Mandatory)
Defines the start and the end of the message.
Header:
(Optional)
Contains any optional attributes of the message used in processing the message, either at
an intermediary point or at the ultimate end point.
Body:
(Mandatory)
Contains the XML data comprising the message being sent.
Fault:
(
Optional
)
An optional Fault element that provides information about errors that occurred while
processing the message
All these elements are declared in the default namespace for the SOAP envelope:
- <!-Schema defined in the SOAP Version 1.2 Part 1 specification
17 December 2001 Working Draft:
http://www.w3.org/TR/2001/WD-soap12-part1-20011217/
$Id: soap-envelope.xsd,v 1.1 2001/12/14 13:35:22 ylafon Exp $
Copyright 2001 W3C (Massachusetts Institute of Technology,
Institut National de Recherche en Informatique et en Automatique,
Keio University). All Rights Reserved.

http://www.w3.org/Consortium/Legal/
This document is governed by the W3C Software License [1] as
described in the FAQ [2].
[1] http://www.w3.org/Consortium/Legal/copyright-software-19980720
[2] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620.html#DTD
-->
- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.w3.org/2001/12/soap-envelope"
targetNamespace="http://www.w3.org/2001/12/soap-envelope">
- <!-Envelope, header and body
-->
<xs:element name="Envelope" type="tns:Envelope" />
<xs:complexType name="Envelope">
<xs:sequence>
<xs:element ref="tns:Header" minOccurs="0" />
<xs:element ref="tns:Body" minOccurs="1" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
<xs:element name="Header" type="tns:Header" />
<xs:complexType name="Header">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
</xs:complexType>
<xs:element name="Body" type="tns:Body" />
<xs:complexType name="Body">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax">
<xs:annotation>
<xs:documentation>Prose in the spec does not specify that attributes are allowed on the Body
element</xs:documentation>
</xs:annotation>
</xs:anyAttribute>
</xs:complexType>
- <!-Global Attributes. The following attributes are intended to be usable via qualified
attribute names on any complex type referencing them.
-->
<xs:attribute name="mustUnderstand" type="xs:boolean" default="0" />
<xs:attribute name="actor" type="xs:anyURI" />
<xs:simpleType name="encodingStyle">
<xs:annotation>
<xs:documentation>'encodingStyle' indicates any canonicalization conventions followed in the
contents of the containing element. For example, the value
'http://schemas.xmlsoap.org/soap/encoding/' indicates the pattern described in SOAP
specification</xs:documentation>
</xs:annotation>
<xs:list itemType="xs:anyURI" />
</xs:simpleType>
<xs:attributeGroup name="encodingStyle">
<xs:attribute name="encodingStyle" type="tns:encodingStyle" />
</xs:attributeGroup>
<xs:element name="Fault" type="tns:Fault" />
<xs:complexType name="Fault" final="extension">
- <xs:annotation>
<xs:documentation>Fault reporting structure</xs:documentation>
</xs:annotation>
- <xs:sequence>
<xs:element name="faultcode" type="xs:QName" />
<xs:element name="faultstring" type="xs:string" />
<xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
<xs:element name="detail" type="tns:detail" minOccurs="0" />
</xs:sequence>
</xs:complexType>
- <xs:complexType name="detail">
- <xs:sequence>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
</xs:schema>
and the default namespace for SOAP encoding and data types is:
<!-Schema defined in the SOAP Version 1.2 Part 2 specification

17 December 2001 Working Draft:
http://www.w3.org/TR/2001/WD-soap12-part2-20011217/
$Id: soap-encoding.xsd,v 1.1 2001/12/14 13:35:22 ylafon Exp $
Copyright 2001 W3C (Massachusetts Institute of Technology,
Institut National de Recherche en Informatique et en Automatique,
Keio University). All Rights Reserved.
http://www.w3.org/Consortium/Legal/
This document is governed by the W3C Software License [1] as
described in the FAQ [2].
[1] http://www.w3.org/Consortium/Legal/copyright-software-19980720
[2] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620.html#DTD
-->
- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.w3.org/2001/12/soap-encoding"
targetNamespace="http://www.w3.org/2001/12/soap-encoding">
- <xs:attribute name="root" type="xs:boolean" default="0">
- <xs:annotation>
<xs:documentation>'root' can be used to distinguish serialization roots from other elements that are
present in a serialization but are not roots of a serialized value graph</xs:documentation>
</xs:annotation>
</xs:attribute>
- <xs:attributeGroup name="commonAttributes">
- <xs:annotation>
<xs:documentation>Attributes common to all elements that function as accessors or represent
independent (multi-ref) values. The href attribute is intended to be used in a manner like
CONREF. That is, the element content should be empty iff the href attribute
appears</xs:documentation>
</xs:annotation>
<xs:attribute name="id" type="xs:ID" />
<xs:attribute name="href" type="xs:anyURI" />
- <!-Global Attributes. The following attributes are intended to be usable via qualified
attribute names on any complex type referencing them.
-->
- 
- <xs:simpleType name="arrayCoordinate">
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:attribute name="arrayType" type="xs:string" />
<xs:attribute name="offset" type="tns:arrayCoordinate" />
- <xs:attributeGroup name="arrayAttributes">
<xs:attribute ref="tns:arrayType" />
<xs:attribute ref="tns:offset" />
<xs:attribute name="position" type="tns:arrayCoordinate" />
- <xs:attributeGroup name="arrayMemberAttributes">
<xs:attribute ref="tns:position" />
- <xs:group name="Array">
- <xs:sequence>
</xs:sequence>
</xs:group>
<xs:element name="Array" type="tns:Array" />
- <xs:complexType name="Array">
- <xs:annotation>
<xs:documentation>'Array' is a complex type for accessors identified by position</xs:documentation>
</xs:annotation>
<xs:group ref="tns:Array" minOccurs="0" />
<xs:attributeGroup ref="tns:arrayAttributes" />
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:complexType>
- <!-'Struct' is a complex type for accessors identified by name.
Constraint: No element may be have the same name as any other,
nor may any element have a maxOccurs > 1.
-->
<xs:element name="Struct" type="tns:Struct" />
- <xs:group name="Struct">
- <xs:sequence>
</xs:sequence>
</xs:group>
- <xs:complexType name="Struct">
<xs:group ref="tns:Struct" minOccurs="0" />
</xs:complexType>
- <!-'Base64' can be used to serialize binary data using base64 encoding
as defined in RFC2045 but without the MIME line length limitation.
-->
- <xs:simpleType name="base64">
<xs:restriction base="xs:base64Binary" />
</xs:simpleType>
- <!-Element declarations corresponding to each of the simple types in the
XML Schemas Specification.
-->
<xs:element name="duration" type="tns:duration" />
- <xs:complexType name="duration">
- <xs:simpleContent>
- <xs:extension base="xs:duration">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="dateTime" type="tns:dateTime" />
<xs:complexType name="dateTime">
<xs:simpleContent>
<xs:extension base="xs:dateTime">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="time" type="tns:time" />
<xs:complexType name="time">
<xs:simpleContent>
<xs:extension base="xs:time">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="date" type="tns:date" />
<xs:complexType name="date">
<xs:simpleContent>
<xs:extension base="xs:date">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gYearMonth" type="tns:gYearMonth" />
<xs:complexType name="gYearMonth">
<xs:simpleContent>
<xs:extension base="xs:gYearMonth">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gYear" type="tns:gYear" />
<xs:complexType name="gYear">
<xs:simpleContent>
<xs:extension base="xs:gYear">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gMonthDay" type="tns:gMonthDay" />
<xs:complexType name="gMonthDay">
<xs:simpleContent>
<xs:extension base="xs:gMonthDay">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gDay" type="tns:gDay" />
<xs:complexType name="gDay">
<xs:simpleContent>
<xs:extension base="xs:gDay">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="gMonth" type="tns:gMonth" />
<xs:complexType name="gMonth">
- <xs:extension base="xs:gMonth">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="boolean" type="tns:boolean" />
- <xs:complexType name="boolean">
- <xs:extension base="xs:boolean">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="base64Binary" type="tns:base64Binary" />
- <xs:complexType name="base64Binary">
- <xs:extension base="xs:base64Binary">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="hexBinary" type="tns:hexBinary" />
- <xs:complexType name="hexBinary">
- <xs:extension base="xs:hexBinary">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="float" type="tns:float" />
- <xs:complexType name="float">
- <xs:extension base="xs:float">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="double" type="tns:double" />
- <xs:complexType name="double">
- <xs:extension base="xs:double">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="anyURI" type="tns:anyURI" />
- <xs:complexType name="anyURI">
- <xs:extension base="xs:anyURI">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="QName" type="tns:QName" />
- <xs:complexType name="QName">
- <xs:extension base="xs:QName">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attribute name="NOTATION" type="tns:NOTATION" />
<xs:complexType name="NOTATION">
<xs:simpleContent>
<xs:extension base="xs:NOTATION">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="string" type="tns:string" />
<xs:complexType name="string">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="normalizedString" type="tns:normalizedString" />
<xs:complexType name="normalizedString">
<xs:simpleContent>
<xs:extension base="xs:normalizedString">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="token" type="tns:token" />
<xs:complexType name="token">
<xs:simpleContent>
<xs:extension base="xs:token">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="language" type="tns:language" />
<xs:complexType name="language">
<xs:simpleContent>
<xs:extension base="xs:language">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Name" type="tns:Name" />
<xs:complexType name="Name">
<xs:simpleContent>
<xs:extension base="xs:Name">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NMTOKEN" type="tns:NMTOKEN" />
<xs:complexType name="NMTOKEN">
<xs:simpleContent>
<xs:extension base="xs:NMTOKEN">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NCName" type="tns:NCName" />
<xs:complexType name="NCName">
<xs:simpleContent>
<xs:extension base="xs:NCName">

</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NMTOKENS" type="tns:NMTOKENS" />
<xs:complexType name="NMTOKENS">
<xs:simpleContent>
<xs:extension base="xs:NMTOKENS">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ID" type="tns:ID" />
<xs:complexType name="ID">
<xs:simpleContent>
<xs:extension base="xs:ID">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="IDREF" type="tns:IDREF" />
<xs:complexType name="IDREF">
<xs:simpleContent>
<xs:extension base="xs:IDREF">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ENTITY" type="tns:ENTITY" />
<xs:complexType name="ENTITY">
<xs:simpleContent>
<xs:extension base="xs:ENTITY">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="IDREFS" type="tns:IDREFS" />
<xs:complexType name="IDREFS">
<xs:simpleContent>
<xs:extension base="xs:IDREFS">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ENTITIES" type="tns:ENTITIES" />
<xs:complexType name="ENTITIES">
<xs:simpleContent>
<xs:extension base="xs:ENTITIES">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="decimal" type="tns:decimal" />
<xs:complexType name="decimal">
<xs:simpleContent>
<xs:extension base="xs:decimal">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="integer" type="tns:integer" />
- <xs:complexType name="integer">
- <xs:extension base="xs:integer">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="nonPositiveInteger" type="tns:nonPositiveInteger" />
- <xs:complexType name="nonPositiveInteger">
- <xs:extension base="xs:nonPositiveInteger">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="negativeInteger" type="tns:negativeInteger" />
- <xs:complexType name="negativeInteger">
- <xs:extension base="xs:negativeInteger">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="long" type="tns:long" />
- <xs:complexType name="long">
- <xs:extension base="xs:long">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="int" type="tns:int" />
- <xs:complexType name="int">
- <xs:extension base="xs:int">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="short" type="tns:short" />
- <xs:complexType name="short">
- <xs:extension base="xs:short">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="byte" type="tns:byte" />
- <xs:complexType name="byte">
- <xs:extension base="xs:byte">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="nonNegativeInteger" type="tns:nonNegativeInteger" />
- <xs:complexType name="nonNegativeInteger">
- <xs:extension base="xs:nonNegativeInteger">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedLong" type="tns:unsignedLong" />
<xs:complexType name="unsignedLong">
<xs:simpleContent>
<xs:extension base="xs:unsignedLong">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedInt" type="tns:unsignedInt" />
<xs:complexType name="unsignedInt">
<xs:simpleContent>
<xs:extension base="xs:unsignedInt">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedShort" type="tns:unsignedShort" />
<xs:complexType name="unsignedShort">
<xs:simpleContent>
<xs:extension base="xs:unsignedShort">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="unsignedByte" type="tns:unsignedByte" />
<xs:complexType name="unsignedByte">
<xs:simpleContent>
<xs:extension base="xs:unsignedByte">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="positiveInteger" type="tns:positiveInteger" />
<xs:complexType name="positiveInteger">
<xs:simpleContent>
<xs:extension base="xs:positiveInteger">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="anyType" />
</xs:schema>
SOAP Message Structure

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP_ENV:Envelope>
The SOAP envelope indicates the start and the end of the message so that the receiver knows when
an entire message has been received. The SOAP envelope solves the problem of knowing when
you're done receiving a message and are ready to process it. The SOAP envelope is therefore basic
ally a packaging mechanism
SOAP Envelope element can be explained as:
Every SOAP message has a root Envelope element.

Envelope element is mandatory part of SOAP Message.
Every Envelope element must contain exactly one Body element.
If an Envelope contains a Header element, it must contain no more than one, and it must
appear as the first child of the Envelope, beforethe Body.
The envelope changes when SOAP versions change.
The SOAP envelope is specified using the ENV namespace prefix and the Envelope element.
The optional SOAP encoding is also specified using a namespace name and the optional
encodingStyle element, which could also point to an encoding style other than the SOAP
one.
A v1.1-compliant SOAP processor will generate a fault when receiving a message containing
the v1.2 envelope namespace.
A v1.2- compliant SOAP processor generates a VersionMismatch fault if it receives a
message that does not include the v1.2 envelope namespace.
Example for v1.2 is given below
<SOAP-ENV:Envelope
...
Message information goes here
...
</SOAP-ENV:Envelope>
Following example illustrates the use of a SOAP message within an HTTP POST operation, which
sends the message to the server. It shows the namespaces for the envelope schema definition and
for the schema definition of the encoding rules. The OrderEntry reference in the HTTP header is the
name of the program to be invoked at the tutorialspoint.com Web site.
POST /OrderEntry HTTP/1.1

Host: www.tutorialspoint.com
Content-Type: application/soap; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
...
Message information goes here
...
NOTE: The HTTP binding specifies the location of the service.

The optional Header element offers a flexible framework for specifying additional application-level
requirements. For example, the Header element can be used to specify a digital signature for
password-protected services; likewise, it can be used to specify an account number for pay-per-use
SOAP services.
SOAP Header element can be explained as:
Header elements are optional part of SOAP messages.

Header elements can occur multiple times.
Headers are intended to add new features and functionality
The SOAP header contains header entries defined in a namespace.
The header is encoded as the first immediate child element of the SOAP envelope.
When more than one header is defined, all immediate child elements of the SOAP header
are interpreted as SOAP header blocks.
SOAP Header element can have following two attributes
Actor
attribute:
The SOAP protocol defines a message path as a list of SOAP service nodes. Each of these
intermediate nodes can perform some processing and then forward the message to the next
node in the chain. By setting the Actor attribute, the client can specify the recipient of the
SOAP header.
MustUnderstand
attribute
Indicates whether a Header element is optional or mandatory. If set to true ie. 1 the
recipient must understand and process the Header attribute according to its defined
semantics, or return a fault.
Following example shows how to use a Header in the SOAP message.
<SOAP-ENV:Envelope
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="http://www.tutorialspoint.com/transaction/"
SOAP-ENV:mustUnderstand="true">5</t:Transaction>
</SOAP-ENV:Header>
...
...
The SOAP body is a mandatory element which contains the application-defined XML data being
exchanged in the SOAP message. The body must be contained within the envelope and must follow
any headers that might be defined for the message. The body is defined as a child element of the
envelope, and the semantics for the body are defined in the associated SOAP schema.
The body contains mandatory information intended for the ultimate receiver of the message. For
example:
<SOAP-ENV:Envelope
........
<SOAP-ENV:Body>
<m:GetQuotation xmlns:m="http://www.tp.com/Quotation">
<m:Item>Computers</m:Item>
</m:GetQuotation>
</SOAP-ENV:Body>
The example above requests the quotation of computer sets. Note that the m:GetQuotation and the
Item elements above are application-specific elements. They are not a part of the SOAP standard.
Here is the response of above query:
<SOAP-ENV:Envelope
........
<SOAP-ENV:Body>
<m:GetQuotationResponse xmlns:m="http://www.tp.com/Quotation">
<m:Quotation>This is Qutation</m:Quotation>
</m:GetQuotationResponse>
</SOAP-ENV:Body>
Normally, the application also defines a schema to contain semantics associated with the request
and response elements.
The Quotation service might be implemented using an EJB running in an application server; if so,
the SOAP processor would be responsible for mapping the body information as parameters into and
out of the EJB implementation of the GetQuotationResponse service. The SOAP processor could also
be mapping the body information to a .NET object, a CORBA object, a COBOL program, and so on.
When an error occurs during processing, the response to a SOAP message is a SOAP fault element in the body of the message,
and the fault is returned to the sender of the SOAP message.
The SOAP fault mechanism returns specific information about the error, including a predefined code, a description, the
address of the SOAP processor that generated
A SOAP Message can carry only one fault block
For the HTTP binding, a successful response is linked to the 200 to 299 range of status codes;
Fault element is an optional part of SOAP Message
SOAP fault is linked to the 500 to 599 range of status codes.
The SOAP Fault element has the following sub elements:

Sub Element
<faultCode>
<faultString>
<faultActor>
<detail>
Description
A text code used to indicate a class of errors. See the next Table for a
listing of predefined fault codes.
A text message explaning the error
A text string indicating who caused the fault. This is useful if the SOAP
message travels through several nodes in the SOAP message path, and
the client needs to know which node caused the error. A node that does
not act as the ultimate destination must include a faultActor element.
An element used to carry application-specific error messages. The detail
element can contain child elements, called detail entries.
SOAP Fault Codes

The faultCode values defined below must be used in the faultcode element when describing faults
Error
SOAPENV:VersionMismatch
SOAPENV:MustUnderstand
SOAP-ENV:Client
SOAP-ENV:Server
Description
Found an invalid namespace for the SOAP Envelope element
An immediate child element of the Header element, with the
mustUnderstand attribute set to "1", was not understood
The message was incorrectly formed or contained incorrect information
There was a problem with the server so the message could not proceed
SOAP Fault Example

The following code is a sample Fault. The client has requested a method named ValidateCreditCard , but the service does not
support such a method. This represents a client request error, and the server returns the following SOAP response:
<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
<faultstring xsi:type="xsd:string">
Failed to locate method (ValidateCreditCard) in class
(examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/
site_perl/5.6.0/SOAP/Lite.pm line 1555.
</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
SOAP includes a built-in set of rules for encoding data types.This enables the SOAP message to indicate specific data types,
such as integers, floats, doubles, or arrays.
SOAP data types are divided into two broad categories: scalar types and compound types.
Scalar types contain exactly one value, such as a last name, price, or product description.
Compound types contain multiple values, such as a purchase order or a list of stock quotes.
Compound types are further subdivided into arrays and structs.
The encoding style for a SOAP message is set via the SOAP-ENV:encodingStyle attribute.
To use SOAP 1.1 encoding, use the value http://schemas.xmlsoap.org/soap/encoding/
To use SOAP 1.2 encoding, use the value http://www.w3.org/2001/12/soap-encoding
Latest SOAP specification adopts all the built-in types defined by XML Schema. Still SOAP maintains its own
convention for defining constructs not standardized by XML Schema, such as arrays and references.
Scalar Types
For scalar types, SOAP adopts all the built-in simple types specified by the XML Schema specification. This includes strings,
floats, doubles, and integers.
Following table lists the main simple types, excerpted from the XML Schema Part 0: Primer
http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/
Simple Types Built-In to XML Schema
Simple Type
Example(s)
string
Confirm this is electric
boolean
true, false, 1, 0
float
-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN
double
-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN
decimal
-1.23, 0, 123.4, 1000.00
binary
100010
integer
-126789, -1, 0, 1, 126789
nonPositiveInteger
-126789, -1, 0
negativeInteger
-126789, -1
long
-1, 12678967543233
int
-1, 126789675
short
-1, 12678
byte
-1, 126
nonNegativeInteger
0, 1, 126789
unsignedLong
0, 12678967543233
unsignedInt
0, 1267896754
unsignedShort
0, 12678
unsignedByte
0, 126
positiveInteger
1, 126789
date
1999-05-31, ---05
time
13:20:00.000, 13:20:00.000-05:00
For example, here is a SOAP response with a double data type:
<?xml version='1.0' encoding='UTF-8'?*gt;

<SOAP-ENV:Envelope
<SOAP-ENV:Body>
<ns1:getPriceResponse
xmlns:ns1="urn:examples:priceservice"
<return xsi:type="xsd:double">54.99</return>
</ns1:getPriceResponse>
</SOAP-ENV:Body>
Compound Types
SOAP arrays have a very specific set of rules, which require that you specify both the element type and array size. SOAP also
supports multidimensional arrays, but not all SOAP implementations support multidimensional functionality.
To create an array, you must specify it as an xsi:type of Array. The array must also include an arrayType attribute. This
attribute is required to specify the data type for the contained elements and the dimension(s) of the array.
For example, the following attribute specifies an array of 10 double values:
arrayType="xsd:double[10]"
In contrast, the following attribute specifies a two-dimensional array of strings:
arrayType="xsd:string[5,5]"
Here is a sample SOAP response with an array of double values:

<SOAP-ENV:Envelope
<SOAP-ENV:Body>
<ns1:getPriceListResponse
xmlns:ns1="urn:examples:pricelistservice"
<return
xmlns:ns2="http://www.w3.org/2001/09/soap-encoding"
xsi:type="ns2:Array" ns2:arrayType="xsd:double[2]">
<item xsi:type="xsd:double">54.99</item>
<item xsi:type="xsd:double">19.99</item>
</return>
</ns1:getPriceListResponse>
</SOAP-ENV:Body>
Structs contain multiple values, but each element is specified with a unique accessor element. For example, consider an item
within a product catalog. In this case, the struct might contain a product SKU, product name, description, and price. Here is
how such a struct would be represented in a SOAP message:

<SOAP-ENV:Envelope
<SOAP-ENV:Body>
<ns1:getProductResponse
xmlns:ns1="urn:examples:productservice"
<return xmlns:ns2="urn:examples" xsi:type="ns2:product">
<name xsi:type="xsd:string">Red Hat Linux</name>
<price xsi:type="xsd:double">54.99</price>
<description xsi:type="xsd:string">
Red Hat Linux Operating System
</description>
<SKU xsi:type="xsd:string">A358185</SKU>
</return>
</ns1:getProductResponse>
</SOAP-ENV:Body>
NOTE: Please you take care of proper indentation while you write your SOAP code.
Each element in a struct is specified with a unique accessor name. For example, the message above includes four accessor
elements: name , price , description , and SKU. Each element can have its own data type; for example, name is specified as a
string , whereas price is specified as a double.
SOAP is not tied to any one transport protocol.

SOAP can be transported via SMTP, FTP, IBM's MQSeries, or Microsoft Message Queuing
(MSMQ).
SOAP specification includes details on HTTP only.
HTTP remains the most popular SOAP transport protocol.
SOAP via HTTP

Quite logically, SOAP requests are sent via an HTTP request and SOAP responses are returned within
the content of the HTTP response. While SOAP requests can be sent via an HTTP GET, the
specification includes details on HTTP POST only.
Additionally, both HTTP requests and responses are required to set their content type to text/xml.
The SOAP specification mandates that the client must provide a SOAPAction header, but the actual
value of the SOAPAction header is dependent on the SOAP server implementation.
For example, to access the AltaVista BabelFish Translation service, hosted by XMethods,
you must specify the following as a SOAPAction header.
urn:xmethodsBabelFish#BabelFish
Even if the server does not require a full SOAPAction header, the client must specify an
empty string (""), or a null value. For example:
SOAPAction: ""
SOAPAction:
Here is a sample request sent via HTTP to the XMethods Babelfish Translation service:
POST /perl/soaplite.cgi HTTP/1.0

Host: services.xmethods.com
Content-Type: text/xml; charset=utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"
<SOAP-ENV:Envelope
<SOAP-ENV:Body>
<ns1:BabelFish
xmlns:ns1="urn:xmethodsBabelFish"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<translationmode xsi:type="xsd:string">en_fr</translationmode>
<sourcedata xsi:type="xsd:string">Hello, world!</sourcedata>
</ns1:BabelFish>
</SOAP-ENV:Body>
Note the content type and the SOAPAction header. Also note that the BabelFish method requires two
String parameters. The translation mode en_fr will translate from English to French.
Here is the response from XMethods:
HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage=60, proxy-revalidate
Content-Length: 539
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
<SOAP-ENV:Body>
<namesp1:BabelFishResponse xmlns:namesp1="urn:xmethodsBabelFish">
<return xsi:type="xsd:string">Bonjour, monde!</return>
</namesp1:BabelFishResponse>
</SOAP-ENV:Body>
SOAP responses delivered via HTTP are required to follow the same HTTP status codes. For example,
a status code of 200 OK indicates a successful response. A status code of 500 Internal Server Error
indicates that there is a server error and that the SOAP response includes a Fault element.
In the example below, a GetQuotation request is sent to a SOAP Server over HTTP. The request has
a QuotationName parameter, and a Quotation will be returned in the response.
The namespace for the function is defined in "http://www.xyz.org/quotation" address.
Here is the SOAP request:
POST /Quotation HTTP/1.0

Host: www.xyz.org
Content-Length: nnn
<SOAP-ENV:Envelope
<SOAP-ENV:Body xmlns:m="http://www.xyz.org/quotations">
<m:GetQuotation>
<m:QuotationsName>MiscroSoft</m:QuotationsName>
</m:GetQuotation>
</SOAP-ENV:Body>
A corresponding SOAP response will look like :
HTTP/1.0 200 OK
Content-Length: nnn
<SOAP-ENV:Envelope
<SOAP-ENV:Body xmlns:m="http://www.xyz.org/quotation">
<m:GetQuotationResponse>
<m:Quotation>Here is the quotation</m:Quotation>
</m:GetQuotationResponse>
</SOAP-ENV:Body>
WSDL breaks down Web services into three specific, identifiable elements that can be combined or
reused once defined.
Three major elements of WSDL that can be defined separately and they are:
Types
Operations
Binding
A WSDL document has various elements, but they are contained within these three main elements,
which can be developed as separate documents and then they can be combined or reused to form
complete WSDL files.
Following are the elements of WSDL document. Within these elements are further subelements, or
parts:
Definition: element must be the root element of all WSDL documents. It defines the name
of the web service, declares multiple namespaces used throughout the remainder of the
document, and contains all the service elements described here.
Data types: the data types - in the form of XML schemas or possibly some other
mechanism - to be used in the messages
Message: an abstract definition of the data, in the form of a message presented either as
an entire document or as arguments to be mapped to a method invocation.
Operation: the abstract definition of the operation for a message, such as naming a
method, message queue, or business process, that will accept and process the message
Port type : an abstract set of operations mapped to one or more end points, defining the
collection of operations for a binding; the collection of operations, because it is abstract,
can be mapped to multiple transports through various bindings.
Binding: the concrete protocol and data formats for the operations and messages defined
for a particular port type.
Port: a combination of a binding and a network address, providing the target address of
the service communication.
Service: a collection of related end points encompassing the service definitions in the file;
the services map the binding to the port and include any extensibility definitions.
In addition to these major elements, the WSDL specification also defines the following utility
elements:
Documentation: element is used to provide human-readable documentation and can be

included inside any other WSDL element.
Import: element is used to import other WSDL documents or XML Schemas.
NOTE: WSDL parts usually are generated automatically using Web services-aware tools.
The WSDL Document Structure

The main structure of a WSDL document looks like this:
<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
<operation>
definition of a operation.......
</operation>
</portType>
<binding>
definition of a binding....
</binding>
<service>
definition of a service....
</service>
</definitions>
A WSDL document can also contain other elements, like extension elements and a service element
that makes it possible to group together the definitions of several web services in one single WSDL
document.
Proceed further to analyze an example of WSDL Document.
Following is the WSDL file that is provided to demonstrate a simple WSDL program.
Assuming the service provides a single publicly available function, called sayHello. This function expects a single string
parameter and returns a single string greeting. For example if you pass the parameter world then service function sayHello
returns the greeting, "Hello, world!".
Content of HelloService.wsdl file

<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
<portType name="Hello_PortType">
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
<binding name="Hello_Binding" type="tns:Hello_PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<soap:operation soapAction="sayHello"/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"
use="encoded"/>
</input>
<output>
<soap:body
use="encoded"/>
</output>
</operation>
</binding>
<service name="Hello_Service">
<documentation>WSDL File for HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address
location="http://www.examples.com/SayHello/">
</port>
</service>
</definitions>
Analysis of the Example
Definition : HelloService
Message :
1. sayHelloRequest : firstName parameter

2. sayHelloresponse: greeting return value
Port Type: sayHello operation that consists of a request and response service.
Binding: Direction to use the SOAP HTTP transport protocol.
Service: Service available at http://www.examples.com/SayHello/.
Port: Associates the binding with the URI http://www.examples.com/SayHello/ where the running service can be
accessed.
Type : Using built-in data types and they are defined in XMLSchema.
A detailed description of these elements is given in subsequent sections of the tutorial.

The <definition> element must be the root element of all WSDL documents. It defines the name
of the web service.
Here is the example piece of code from last session which uses definition element.
<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
................................................
</definitions>
From the above example we can conclude the followings points:
The definitions element is a container of all the other elements.

The definitions element specifies that this document is the HelloService.
The definitions element specifies a targetNamespace attribute. The targetNamespace is a
convention of XML Schema that enables the WSDL document to refer to itself. In this
example
we
have
specified
a
targetNamespace
of
http://www.examples.com/wsdl/HelloService.wsdl.
The
definition
element
specifies
a
default
namespace:
xmlns=http://schemas.xmlsoap.org/wsdl/. All elements without a namespace prefix, such
as message or portType, are therefore assumed to be part of the default WSDL namespace.
It also specifies numerous namespaces that will be used throughout the remainder of the
document.
NOTE: The namespace specification does not require that the document actually exist at the given
location. The important point is that you specify a value that is unique, different from all other
namespaces that are defined.
Web service needs to define its inputs and outputs and how they are mapped into and out of
services. WSDL <types> element take care of defining the data types that are used by the web
service. Types are XML documents, or document parts.
Here is a piece of code taken from W3C specification. This code depicts how a types element can be
used within a WSDL.
The types element describes all the data types used between the client and server.
WSDL is not tied exclusively to a specific typing system
WSDL uses the W3C XML Schema specification as its default choice to define data types.
If the service uses only XML Schema built-in simple types, such as strings and integers,
then types element is not required.
WSDL allows the types to be defined in separate elements so that the types are reusable
with multiple Web services.
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
Data types address the problem of how to identify the data types and formats you intend to use
with your Web services. Type information is shared between sender and receiver. The recipients of
messages therefore need access to the information you used to encode your data and must
understand how to decode the data.
The <message> element describes the data being exchanged between the Web service
providers and consumers.
Each Web Service has two messages: input and output.
The input describes the parameters for the Web Service and the output describes the return
data from the Web Service.
Each message contains zero or more <part> parameters, one for each parameter of the
Web Service's function.
Each <part> parameter associates with a concrete type defined in the <types> container
element.
Lets take a piece of code from the Example Session:
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
Here, two message elements are defined. The first represents a request message SayHelloRequest,
and the second represents a response message SayHelloResponse.
Each of these messages contains a single part element. For the request, the part specifies the
function parameters; in this case, we specify a single firstName parameter. For the response, the
part specifies the function return values; in this case, we specify a single greeting return value.
The <portType> element combines multiple message elements to form a complete oneway or round-trip operation.
For example, a <portType> can combine one request and one response message into a single request/response operation. This
is most commonly used in SOAP services. A portType can define multiple operations.
Lets take a piece of code from the Example Session:
<portType name="Hello_PortType">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
The portType element defines a single operation, called sayHello.
The operation itself consists of a single output message SayHelloResponse
The operation itself consists of a single input message SayHelloRequest
Patterns of Operation
WSDL supports four basic patterns of operation:
One-way :
The service receives a message. The operation therefore has a single input element. The grammar
for a one-way operation is:
<wsdl:definitions .... > <wsdl:portType .... > *

<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Request-response:
The service receives a message and sends a response. The operation therefore has one input
element, followed by one output element. To encapsulate errors, an optional fault element can also
be specified. The grammar for a request-response operation is:
<wsdl:definitions .... >

<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Solicit-response:
The service sends a message and receives a response. The operation therefore has one output
element, followed by one input element. To encapsulate errors, an optional fault element can also
be specified. The grammar for a solicit-response operation is:

<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
Notification :
The service sends a message. The operation therefore has a single output element. Following is the
grammer for a notification operation:

<wsdl:operation name="nmtoken">
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>
The <binding> element provides specific details on how a portType operation will actually be transmitted over the
wire.
The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.
The bindings provide concrete information on what protocol is being used to transfer portType operations.
The bindings provide information where the service is located.
For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.
You can specify multiple bindings for a single portType.
The binding element has two attributes - the name attribute and the type attribute.

The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this case the
"tns:Hello_PortType" port.
SOAP Binding
WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAPspecific details, including SOAP
headers, SOAP encoding styles, and the SOAPAction HTTP header. The SOAP extension elements include:
soap:binding
This element indicates that the binding will be made available via SOAP. The style attribute indicates
the overall style of the SOAP message format. A style value of rpc specifies an RPC format.
The transport attribute indicates the transport of the SOAP messages. The value http://schemas.xmlsoap.org/soap/http
indicates the SOAP HTTP transport, whereas http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.
soap:operation
This element indicates the binding of a specific operation to a specific SOAP implementation. The
soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service.
soap:body
This element enables you to specify the details of the input and output messages. In the case of
HelloWorld, the body element specifies the SOAP encoding style and the namespace URN associated
with the specified service.
Here is the piece of code from Example section:

<input>
<soap:body
use="encoded"/>
</input>
<output>
<soap:body
use="encoded"/>
</output>
</operation>
</binding>
<port> element defines an individual endpoint by specifying a single address for a binding.
Here is the grammer to specify a port:

<wsdl:service .... > *
<wsdl:port name="nmtoken" binding="qname"> *
<-- extensibility element (1) -->
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
The port element has two attributes - the name attribute and the binding attribute.
The name attribute provides a unique name among all ports defined within in the enclosing
WSDL document.
The binding attribute refers to the binding using the linking rules defined by WSDL.
Binding extensibility elements (1) are used to specify the address information for the port.
A port MUST NOT specify more than one address.
A port MUST NOT specify any binding information other than address information.
Here is the pice of code from Example session:
<soap:address
</port>
</service>
The <service> element defines the ports supported by the Web service. For each of the
supported protocols, there is one port element. The service element is a collection of ports.
Web service clients can learn from the service element where to access the service, through
which port to access the Web service, and how the communication messages are defined.
The service element includes a documentation element to provide human-readable
documentation.
Here is a pice of code from Example Session:
<soap:address
</port>
</service>
The binding attributes of por element associate the address of the service with a binding element
defined in the Web service. In this example this is Hello_Binding

<input>
<soap:body
use="encoded"/>
</input>
<output>
<soap:body
use="encoded"/>
</output>
</operation>
</binding>

Namespaces Soap

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Namespaces Soap

Uploaded by

Copyright:

Available Formats

Declaring and Applying Namespaces

Invalid) <http://www.library.com:Book />

The following violates both these constraints:

{default namespace} does not apply to attributes directly.

Namespaces and XML Schema

XML Schema Structures Specification and W3C

Figure 2: From XML Schema to XML Schema instance

<?xml version="1.0" encoding="US-ASCII"?>

qualified | unqualified) : unqualified

Case 2: elementFormDefault=qualified, attributeFormDefault=unqualified

Case 3: elementFormDefault=unqualified, attributeFormDefault=qualified

Case 4: elementFormDefault=unqualified, attributeFormDefault=unqualified

Referencing Schema Documents

SOAP is an XML-based protocol for exchanging information between computers.

SOAP is acronym for Simple Object Access Protocol

Keio University). All Rights Reserved.

<!-Schema defined in the SOAP Version 1.2 Part 2 specification

<xs:attributeGroup ref="tns:commonAttributes" />

SOAP Message Structure

Every SOAP message has a root Envelope element.

Example for v1.2 is given below

POST /OrderEntry HTTP/1.1

NOTE: The HTTP binding specifies the location of the service.

Header elements are optional part of SOAP messages.

SOAP Header element can have following two attributes

Following example shows how to use a Header in the SOAP message.

A SOAP Message can carry only one fault block

Fault element is an optional part of SOAP Message

SOAP fault is linked to the 500 to 599 range of status codes.

The SOAP Fault element has the following sub elements:

SOAP Fault Codes

SOAP Fault Example

<?xml version='1.0' encoding='UTF-8'?>

Compound types are further subdivided into arrays and structs.

To use SOAP 1.1 encoding, use the value http://schemas.xmlsoap.org/soap/encoding/

To use SOAP 1.2 encoding, use the value http://www.w3.org/2001/12/soap-encoding

Confirm this is electric

-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN

-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN

-1.23, 0, 123.4, 1000.00

-126789, -1, 0, 1, 126789

For example, here is a SOAP response with a double data type:

<?xml version='1.0' encoding='UTF-8'?*gt;

<?xml version='1.0' encoding='UTF-8'?>

<?xml version='1.0' encoding='UTF-8'?>

SOAP is not tied to any one transport protocol.

SOAP via HTTP

POST /perl/soaplite.cgi HTTP/1.0

POST /Quotation HTTP/1.0

Documentation: element is used to provide human-readable documentation and can be

The WSDL Document Structure

Content of HelloService.wsdl file

Analysis of the Example

1. sayHelloRequest : firstName parameter

Binding: Direction to use the SOAP HTTP transport protocol.

Service: Service available at http://www.examples.com/SayHello/.

A detailed description of these elements is given in subsequent sections of the tutorial.

The definitions element is a container of all the other elements.

Lets take a piece of code from the Example Session:

The portType element defines a single operation, called sayHello.

The operation itself consists of a single output message SayHelloResponse

The operation itself consists of a single input message SayHelloRequest

<wsdl:definitions .... > <wsdl:portType .... > *

<wsdl:definitions .... >