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 name—where, 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 unique—hence 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 namespaces—being IRIs—are 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 XML—the 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:

http://www.w3.org/TR/REC-xml/

<?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.

<?xml version="1.0"?><Book xmlns:lib="http://www.library.com"> <lib:Title>Sherlock Holmes - I</lib:Title> <lib:Author>Arthur Conan Doyle</lib:Author> <purchase xmlns:lib="http://www.otherlibrary.com"> <lib:Title>Sherlock Holmes - II</lib:Title> <lib:Author>Arthur Conan Doyle</lib:Author> </purchase> <lib:Title>Sherlock Holmes - III</lib:Title> <lib:Author>Arthur Conan Doyle</lib:Author></Book>

The W3C Namespaces in XML Recommendation enforces some namespace constraints:

1. 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.

2. 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:

<?xml version="1.0"?><Book xmlns:XmlLibrary="http://www.library.com"> <lib:Title>Sherlock Holmes - I</lib:Title> <lib:Author>Arthur Conan Doyle</lib:Author></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" />

<?xml version="1.0"?><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.

<?xml version="1.0"?><Book xmlns="http://www.library.com"> <Title>Sherlock Holmes - I</Title> <Author>Arthur Conan Doyle</Author> <purchase xmlns="http://www.otherlibrary.com"> <Title>Sherlock Holmes - II</Title> <Author>Arthur Conan Doyle</Author> </purchase> <Title>Sherlock Holmes - III</Title> <Author>Arthur Conan Doyle</Author></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.

<?xml version="1.0"?><Book isbn="1234" pfx:cover="hard" xmlns="http://www.library.com" xmlns:pfx="http://www.library.com"> <Title>Sherlock Holmes</Title> <Author>Arthur Conan Doyle</Author></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="" />

<?xml version="1.0"?><Book xmlns="http://www.library.com"> <Title>Sherlock Holmes - I</Title> <Author>Arthur Conan Doyle</Author> <purchase xmlns=""> <Title>Sherlock Holmes - II</Title> <Author>Arthur Conan Doyle</Author> </purchase> <Title>Sherlock Holmes - III</Title> <Author>Arthur Conan Doyle</Author></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.

http://www.oracle.com/technetwork/articles/srivastava-namespaces-092580.html#f2

http://www.oracle.com/technetwork/articles/srivastava-namespaces-092580.html#f1

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502

http://www.w3.org/TR/xmlschema-1/

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 affected—and 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) : unqualifiedattributeFormDefault = ( 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} exists—which is legal—but 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 language-independent.

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:

-  - <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">

-  <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:anyAttribute namespace="##other" processContents="lax" />

</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>-  <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:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />

</xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax" />

</xs:complexType> </xs:schema>

and the default namespace for SOAP encoding and data types is:

-  - <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" /> <xs:anyAttribute namespace="##other" processContents="lax" />

</xs:attributeGroup>-  -  - <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" />

http://www.w3.org/2001/12/soap-encoding#%23










</xs:attributeGroup> <xs:attribute name="position" type="tns:arrayCoordinate" /> - <xs:attributeGroup name="arrayMemberAttributes"> <xs:attribute ref="tns:position" />

</xs:attributeGroup>- <xs:group name="Array">- <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />

</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>-  <xs:element name="Struct" type="tns:Struct" /> - <xs:group name="Struct">- <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />

</xs:sequence> </xs:group>

- <xs:complexType name="Struct"> <xs:group ref="tns:Struct" minOccurs="0" /> <xs:attributeGroup ref="tns:commonAttributes" />

</xs:complexType>-  - <xs:simpleType name="base64"> <xs:restriction base="xs:base64Binary" />

</xs:simpleType>-  <xs:element name="duration" type="tns:duration" /> - <xs:complexType name="duration">- <xs:simpleContent>- <xs:extension base="xs:duration"> <xs:attributeGroup ref="tns:commonAttributes" />

</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:attributeGroup ref="tns:commonAttributes" />


<xs:element name="time" type="tns:time" /> - <xs:complexType name="time">- <xs:simpleContent>- <xs:extension base="xs:time">






















<xs:attributeGroup ref="tns:commonAttributes" /> </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:attributeGroup ref="tns:commonAttributes" />


<xs:element name="gYearMonth" type="tns:gYearMonth" /> - <xs:complexType name="gYearMonth">- <xs:simpleContent>- <xs:extension base="xs:gYearMonth"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="gYear" type="tns:gYear" /> - <xs:complexType name="gYear">- <xs:simpleContent>- <xs:extension base="xs:gYear"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="gMonthDay" type="tns:gMonthDay" /> - <xs:complexType name="gMonthDay">- <xs:simpleContent>- <xs:extension base="xs:gMonthDay"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="gDay" type="tns:gDay" /> - <xs:complexType name="gDay">- <xs:simpleContent>- <xs:extension base="xs:gDay"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="gMonth" type="tns:gMonth" /> - <xs:complexType name="gMonth">- <xs:simpleContent>- <xs:extension base="xs:gMonth"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="boolean" type="tns:boolean" /> - <xs:complexType name="boolean">- <xs:simpleContent>- <xs:extension base="xs:boolean"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="base64Binary" type="tns:base64Binary" /> - <xs:complexType name="base64Binary">- <xs:simpleContent>- <xs:extension base="xs:base64Binary"> <xs:attributeGroup ref="tns:commonAttributes" />


























<xs:element name="hexBinary" type="tns:hexBinary" /> - <xs:complexType name="hexBinary">- <xs:simpleContent>- <xs:extension base="xs:hexBinary"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="float" type="tns:float" /> - <xs:complexType name="float">- <xs:simpleContent>- <xs:extension base="xs:float"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="double" type="tns:double" /> - <xs:complexType name="double">- <xs:simpleContent>- <xs:extension base="xs:double"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="anyURI" type="tns:anyURI" /> - <xs:complexType name="anyURI">- <xs:simpleContent>- <xs:extension base="xs:anyURI"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="QName" type="tns:QName" /> - <xs:complexType name="QName">- <xs:simpleContent>- <xs:extension base="xs:QName"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:attribute name="NOTATION" type="tns:NOTATION" /> - <xs:complexType name="NOTATION">- <xs:simpleContent>- <xs:extension base="xs:NOTATION"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="string" type="tns:string" /> - <xs:complexType name="string">- <xs:simpleContent>- <xs:extension base="xs:string"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="normalizedString" type="tns:normalizedString" /> - <xs:complexType name="normalizedString">- <xs:simpleContent>- <xs:extension base="xs:normalizedString"> <xs:attributeGroup ref="tns:commonAttributes" />

</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:attributeGroup ref="tns:commonAttributes" />


<xs:element name="language" type="tns:language" /> - <xs:complexType name="language">- <xs:simpleContent>- <xs:extension base="xs:language"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="Name" type="tns:Name" /> - <xs:complexType name="Name">- <xs:simpleContent>- <xs:extension base="xs:Name"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="NMTOKEN" type="tns:NMTOKEN" /> - <xs:complexType name="NMTOKEN">- <xs:simpleContent>- <xs:extension base="xs:NMTOKEN"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="NCName" type="tns:NCName" /> - <xs:complexType name="NCName">- <xs:simpleContent>- <xs:extension base="xs:NCName"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="NMTOKENS" type="tns:NMTOKENS" /> - <xs:complexType name="NMTOKENS">- <xs:simpleContent>- <xs:extension base="xs:NMTOKENS"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="ID" type="tns:ID" /> - <xs:complexType name="ID">- <xs:simpleContent>- <xs:extension base="xs:ID"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="IDREF" type="tns:IDREF" /> - <xs:complexType name="IDREF">- <xs:simpleContent>- <xs:extension base="xs:IDREF"> <xs:attributeGroup ref="tns:commonAttributes" />

</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:attributeGroup ref="tns:commonAttributes" />


<xs:element name="IDREFS" type="tns:IDREFS" /> - <xs:complexType name="IDREFS">- <xs:simpleContent>- <xs:extension base="xs:IDREFS"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="ENTITIES" type="tns:ENTITIES" /> - <xs:complexType name="ENTITIES">- <xs:simpleContent>- <xs:extension base="xs:ENTITIES"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="decimal" type="tns:decimal" /> - <xs:complexType name="decimal">- <xs:simpleContent>- <xs:extension base="xs:decimal"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="integer" type="tns:integer" /> - <xs:complexType name="integer">- <xs:simpleContent>- <xs:extension base="xs:integer"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="nonPositiveInteger" type="tns:nonPositiveInteger" /> - <xs:complexType name="nonPositiveInteger">- <xs:simpleContent>- <xs:extension base="xs:nonPositiveInteger"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="negativeInteger" type="tns:negativeInteger" /> - <xs:complexType name="negativeInteger">- <xs:simpleContent>- <xs:extension base="xs:negativeInteger"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="long" type="tns:long" /> - <xs:complexType name="long">- <xs:simpleContent>- <xs:extension base="xs:long"> <xs:attributeGroup ref="tns:commonAttributes" />


























<xs:element name="int" type="tns:int" /> - <xs:complexType name="int">- <xs:simpleContent>- <xs:extension base="xs:int"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="short" type="tns:short" /> - <xs:complexType name="short">- <xs:simpleContent>- <xs:extension base="xs:short"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="byte" type="tns:byte" /> - <xs:complexType name="byte">- <xs:simpleContent>- <xs:extension base="xs:byte"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="nonNegativeInteger" type="tns:nonNegativeInteger" /> - <xs:complexType name="nonNegativeInteger">- <xs:simpleContent>- <xs:extension base="xs:nonNegativeInteger"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="unsignedLong" type="tns:unsignedLong" /> - <xs:complexType name="unsignedLong">- <xs:simpleContent>- <xs:extension base="xs:unsignedLong"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="unsignedInt" type="tns:unsignedInt" /> - <xs:complexType name="unsignedInt">- <xs:simpleContent>- <xs:extension base="xs:unsignedInt"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="unsignedShort" type="tns:unsignedShort" /> - <xs:complexType name="unsignedShort">- <xs:simpleContent>- <xs:extension base="xs:unsignedShort"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="unsignedByte" type="tns:unsignedByte" /> - <xs:complexType name="unsignedByte">- <xs:simpleContent>- <xs:extension base="xs:unsignedByte"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="positiveInteger" type="tns:positiveInteger" />

























- <xs:complexType name="positiveInteger">- <xs:simpleContent>- <xs:extension base="xs:positiveInteger"> <xs:attributeGroup ref="tns:commonAttributes" />


<xs:element name="anyType" /> </xs:schema>

SOAP Message Structure

<?xml version="1.0"?><SOAP-ENV:Envelopexmlns: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




<?xml version="1.0"?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"

SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... 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.1Host: www.tutorialspoint.comContent-Type: application/soap; charset="utf-8"Content-Length: nnnn<?xml version="1.0"?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... Message information goes here ...</SOAP-ENV:Envelope>

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 attributeIndicates 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.

<?xml version="1.0"?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><SOAP-ENV:Header><t:Transactionxmlns:t="http://www.tutorialspoint.com/transaction/"SOAP-ENV:mustUnderstand="true">5</t:Transaction></SOAP-ENV:Header>......</SOAP-ENV:Envelope>

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:

<?xml version="1.0"?>

<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></SOAP-ENV:Envelope>

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:

<?xml version="1.0"?>

<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></SOAP-ENV:Envelope>

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 Fault element is an optional part of SOAP Message

For the HTTP binding, a successful response is linked to the 200 to 299 range of status codes;

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

The SOAP Fault element has the following sub elements:

Sub Element Description<faultCode> A text code used to indicate a class of errors. See the next Table for a

listing of predefined fault codes.<faultString> A text message explaning the error<faultActor> 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.

<detail> 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 DescriptionSOAP-ENV:VersionMismatch

Found an invalid namespace for the SOAP Envelope element

SOAP-ENV:MustUnderstand

An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood

SOAP-ENV:Client The message was incorrectly formed or contained incorrect informationSOAP-ENV:Server 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:xsi="http://www.w3.org/1999/XMLSchema-instance"

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-ENV:Envelope>

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: Primerhttp://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

http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/

http://www.w3.org/2001/12/soap-encoding

http://schemas.xmlsoap.org/soap/encoding/

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 xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body> <ns1:getPriceResponse xmlns:ns1="urn:examples:priceservice" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <return xsi:type="xsd:double">54.99</return> </ns1:getPriceResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

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:

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

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body> <ns1:getPriceListResponse xmlns:ns1="urn:examples:pricelistservice" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <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></SOAP-ENV:Envelope>

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:

<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body> <ns1:getProductResponse xmlns:ns1="urn:examples:productservice" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <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></SOAP-ENV:Envelope>

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.0Host: services.xmethods.comContent-Type: text/xml; charset=utf-8Content-Length: 538SOAPAction: "urn:xmethodsBabelFish#BabelFish"

<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP-ENV:Body><ns1:BabelFishxmlns: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></SOAP-ENV:Envelope>

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 GMTServer: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2SOAPServer: SOAP::Lite/Perl/0.50Cache-Control: s-maxage=60, proxy-revalidateContent-Length: 539Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelopexmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP-ENV:Body><namesp1:BabelFishResponse xmlns:namesp1="urn:xmethodsBabelFish"><return xsi:type="xsd:string">Bonjour, monde!</return></namesp1:BabelFishResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

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.0Host: www.xyz.orgContent-Type: text/xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <SOAP-ENV:Body xmlns:m="http://www.xyz.org/quotations"> <m:GetQuotation> <m:QuotationsName>MiscroSoft</m:QuotationsName> </m:GetQuotation> </SOAP-ENV:Body></SOAP-ENV:Envelope>

A corresponding SOAP response will look like :

HTTP/1.0 200 OKContent-Type: text/xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><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:Body xmlns:m="http://www.xyz.org/quotation"> <m:GetQuotationResponse> <m:Quotation>Here is the quotation</m:Quotation> </m:GetQuotationResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope>

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" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <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"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" 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 Type : Using built-in data types and they are defined in XMLSchema.

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.

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" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> ................................................</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"> <operation name="sayHello"> <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 input message SayHelloRequest

The operation itself consists of a single output message SayHelloResponse

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:input name="nmtoken"? message="qname"/> <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:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <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:definitions .... >

<wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </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.

<binding name="Hello_Binding" type="tns:Hello_PortType">

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:

<binding name="Hello_Binding" type="tns:Hello_PortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" 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:definitions .... > <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:

<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>

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:

<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>

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

<binding name="Hello_Binding" type="tns:Hello_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding>