Web Services and REST

Learning Objective

After completing this topic, you should be able to

describe the REST architecture

1. The REST architecture

Representational State Transfer, or REST, is a simple framework for designing
applications that uses HTTP to make calls. REST uses HTTP to perform the Create,
Read, Update, and Delete, or CRUD, operations. You can also use REST with HTTPS.
REST is platform and language independent. It can be used in environments with
firewalls because it's built on HTTP. REST can also use the security features of HTTPS
such as encryption or username and password tokens but doesn't rely on a
particular security standard.
Also, REST doesn't use cookies. A REST call includes all the information that's required
to return a result, in a process called state transfer.
The key characteristic of the REST architecture is that it involves the use of calls
between client and server devices. The World Wide Web, which has HTTP at its
foundation, can be regarded as a REST-based system.
Although REST may be regarded as a "lightweight" or simple framework, it can perform
the same functions as the Simple Object Access Protocol or SOAP and Web
Services Description Language, or WSDL.
Note that REST isn't a single standard or language. REST programming frameworks do
exist, but you can use the principles of the REST architecture while also using library
features in languages such as Java or C# to create your own applications.
In the REST architecture, applications interact with web services using the
HTTP POST, PUT, GET, and DELETE operations.
As an example, an application might use GET to retrieve a list of all students, POST to
add a student record, DELETE to remove a student record, and PUT to update an
existing student record.

Graphic
In this diagram, there are five sections: GET /student-list HTTP/1.1, POST
/employee HTTP/1.1,
Content-location: /employee/125

PUT /employee/125 HTTP/1.1,

DELETE /employee/12 HTTP/1.1, and No content. Each section is separated by
a set of two arrows that point in different directions.
Key characteristics of the REST architecture are that
it uses a client-server system
REST uses client-server architecture, in which a server can function as a server in one
instance and a client in another instance.
Provided a uniform interface is maintained between clients and servers, server issues are
transparent to clients and vice versa.
it's stateless
REST interactions between client and server are stateless, although the resources and
servers can be stateful. This means that client context isn't stored on the server at any
point.
To remove the need for a connection state, every new request has to contain all the
details required for successfully completing a task. If any session state has to be stored,
it's done on the client. The response for a specific request shouldn't be dependent on any
other interactions.
it supports caching of resources
In a REST system, resources can be cached. An advantage of caching is that it simplifies
or removes the need for certain client-server interactions. This leads to better
performance of the system as a whole. Ideally, resources should be cacheable as much
as possible and should have expiration dates and times.
The protocol used should allow a server to specify the time period and the resources for
caching. Because HTTP is the REST protocol, HTTP cache-control headers are used to
control the caching process.
A server's cache specification should be respected by the client.
it can use proxy servers, and
You can use any standard HTTP proxy as a proxy server in a REST-based system. Doing
this improves the scalability and performance of the system.
it uses logical URLs to identify resources
In the REST architecture, resources are identified by logical URLs. Resources are used
to represent functionality and state, and are regarded as the main component of a proper
RESTful design. This is in contrast to the methods or services that are used in web
services.
When using a web service, you might, for example, use a call such

as GetStudentName and then use GetStudentGrade to retrieve student information.

In a REST system student, information would be regarded as a resource that provides
the required information or a link to it.
By design, using a logical URL allows for a resource to be accessed from other
components of a system.
The REST system is based on the concept of a web of resources, which specifies that
one single resource shouldn't be overly complex or consist of too many levels of detail.
Wherever it's possible, a resource should include links to other details, in the same way
that a web page does. This achieves the aim of maintaining lean resources.
This example uses SOAP and web services to search a contacts list for a particular
entry. For a search to be performed, all of the code has to be sent to the server.
This will normally be in the form of an HTTP POST request.
The result of this type of processing is usually an XML file, which is stored within a
SOAP response envelope.
The query is a lot simpler using REST. It uses a URL, which is sent to the server using a
less complexGET request. The result is that the data received is ready to use it's not
embedded or encapsulated in any way.
Generally web services are used with libraries that create a SOAP request and then
parse a SOAP response. When using REST, however, you need only a connection to a
network and a browser although REST libraries are available.
Note that the method in a REST request generally takes the form of a noun
like Details whereas a SOAP request usually takes the form of a verb.
You can also use REST to perform more complex requests. In this example, multiple
parameters are passed to the server. In most cases, HTTP GET parameters are used in
the URL.
However, when a long parameter or a binary parameter has to be passed, an
HTTP POST request is usually used. The parameters are contained in the body of
the POST request.
It's generally a good idea to use GET requests only for read-only requests. In other
words, a GETrequest shouldn't be allowed to make state changes to a server or its
contents.
Similarly, it's better to use POST requests to create, update, or delete data.
When working with REST requests, a good rule of thumb is to assume that a web page
is using a REST API to provide its services. Then a GET request is used to read data

and a POST request is used to post a comment, which usually involves a longer and
more complex set of parameters.
Although REST services use XML to generate responses, XML is almost never used in
a REST request. Because the parameters for most requests are typically very basic,
XML isn't required.
However, using XML does offer the benefit of type-safety. But you should always check
that your input is correct because of the stateless nature of the REST architecture.
In REST, a server response is generally returned in the form of an XML file. However,
other formats can also be used. These can include the JavaScript Object Notation or
JSON and comma-separated values or CSV formats.
Each format has pros and cons. For example, CSV is very compact. JSON is very easy
for JavaScript clients to parse and is easily parsed by other languages. XML is easily
expandable and is type-safe.
An example of a format that's regarded as unsuitable as a REST response is HTML,
unless it's required in special cases. The same policy applies to all other formats that
are designed to be easy for humans to read but are difficult for clients to process. The
only exception to this policy is when the response is supposed to be a human-readable
document.
However, despite being regarded as an unsuitable format, the fact that the World Wide
Web is regarded as a RESTful application, it appears that the most widely used REST
response format is HTML.
Many service providers support a REST API. These include providers of services such
as Twitter, Flickr, Atom, and many Yahoo! services, including search, map, and photorelated services.
Some of these service providers also support a Web Services Description Language, or
WSDL, API so you can choose which to use. However, it's worth noting that REST
calls and the results they retrieve are simpler to work with and less resource intensive.
In this example, a URL directs a REST request to the Yahoo! search service.
The request includes two parameters appid, which Yahoo! uses to select the
application, andquery, which is the search query itself.

Graphic
The relevant code is appid=YahooDemo and
query=rest.
Unlike SOAP, which returns data embedded in an envelope, the request retrieves raw
XML data which can be accessed immediately.

Question
Identify the characteristics of the REST architecture.
Options:
1.
2.
3.
4.
5.
6.

Resources are identified by URLs

Resources are kept "lean"
Interactions are stateless
Resources can be cached
Responses are embedded in envelopes
Cookies must be used

Answer
Option 1: Correct. Instead of using complex methods to retrieve information,
REST uses logical URLs to get responses from resources. The resources are
therefore accessible from any system component.
Option 2: Correct. In a REST system, resources shouldn't be too detailed
instead they should have links to additional information.
Option 3: Correct. All interactions between a client and a server are stateless in
the REST architecture. There's no need for the server to maintain state
information about the client.
Option 4: Correct. In a REST system, it's ideal for all resources to be
cacheable. Caching resources can reduce the need for interactions between the
client and the server, and so improve system performance.
Option 5: Incorrect. When a REST response is returned, it's normally presented
as raw data in XML format. It's not embedded in an envelope.
Option 6: Incorrect. In the REST architecture, interactions are stateless. A
REST call contains all the required information for a request to be processed, so
cookies aren't required to maintain state information.
Correct answer(s):
1. Resources are identified by URLs
2. Resources are kept "lean"
3. Interactions are stateless
4. Resources can be cached

Simple Object Access Protocol (SOAP)

Learning Objective

After completing this topic, you should be able to

recognize how SOAP works

1. How SOAP works

XML documents don't conform to a particular structure, which can sometimes make
communication between disparate applications difficult. SOAP was developed to define
the XML structure in which data is sent or, more generally, to provide an interface
through which disparate systems can communicate.
SOAP is a W3C-recommended, XML-based protocol for web services that defines a
platform-independent, language-independent format for sending messages between
networked applications.
Before you can communicate using a web service with SOAP, you perform three steps:
search for a service
To search for a web service that suits your needs, you browse a web service directory
such as the Universal Description, Discovery, and Integration directory, or UDDI.
request access, and
During the second step, you request access to a Web Services Description Language, or
WSDL, document for a web service that you want to use. This step is also known as
"discovery."
establish a contract
In the third phase, establishing a contract, you examine the WSDL document, which
describes the input and output types for the service, as well as its location. It also defines
which SOAP call types are handled.
After examining a WSDL to establish the format required by a web service, you create a
proxy class with a suitable interface to send and receive SOAP messages to and from
the web service.

SOAP 1.1 was created in 2000 by Microsoft, IBM, and other companies as an open
standard supported by the W3C. It provided the standard for web services in .NET
version 1.
Three years later, SOAP 1.2 was created in response to a number of issues with the
first version. Chief among the changes was an increase in specificity in other words,
making the specification less ambiguous.
XML is an open standard and platform-independent language.
Many vendors, platforms, and tools can use XML in one form or another because XML
is self-structured. However, for disparate systems to communicate with each other,
there has to be an agreed structure for the XML. This is the function of SOAP.
SOAP mostly uses HTTP for transport.
You could perform some communication using HTTP-GET or HTTP-POST methods.
However, SOAP supports more complicated calls than simple name-value pairs.
Another benefit of using HTTP for SOAP communication is that it can tunnel through
port 80 on most firewalls.
To improve reliability and performance, or in circumstances where HTTP can't be used,
you can use Transmission Control Protocol or TCP to transport SOAP calls.

Question
After searching a UDDI for a WSDL and examining the specifications from a
particular WSDL, which step do you take to consume a web service?
Options:
1.
2.
3.
4.

Create an interface to send and receive calls to and from the web service
Request access to a WSDL document
Browse a web service directory
Change to SOAP 1.2 to reduce ambiguity

Answer
Option 1: Correct. You create a proxy class with a suitable interface to send and
receive SOAP messages to and from the web service.
Option 2: Incorrect. You already have access to a WSDL document from which
you write the web service's interface.
Option 3: Incorrect. You have already found a WSDL document so you don't
need to browse the UDDI directory.

Option 4: Incorrect. You can use SOAP 1.1 or 1.2 to create a proxy class with a
suitable interface for the web service.
Correct answer(s):
1. Create an interface to send and receive calls to and from the web
service

2. SOAP messages
The SOAP specification consists of a number of components, including
a description
The first part of the SOAP specification is the description of the SOAP envelope, in which
the SOAP message is sent.
serialization rules
The second part of the SOAP specification is the list of rules for serializing SOAP
messages.
definition of a protocol, and
The third part of the SOAP specification is the definition of the protocol which binds the
SOAP service to the transport protocol.
Remote Procedure Call or RPC binding
The last part of the SOAP specification is the ability of SOAP to make RPC-type binding.
SOAP messages are simple and intrinsically one-way. There is no calling method or
function built into SOAP. So SOAP messages are created within HTTP, to piggy-back on
HTTP request and response messages.
A SOAP message includes up to three components:

an envelope

an optional header, and

a body
SOAP messages are formatted as XML. The envelope or <soap:Envelope>
element is the root node of the message. SOAP messages qualify the soap envelope
with a different namespace, depending on the SOAP version. This example is the SOAP
1.1 version of the namespace.

Graphic
The namespace is http://www.schemas.xmlsoap.org/soap/envelope/.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<!-- The message contents go here -->
</soap:Body>
</soap:Envelope>
This example is the SOAP 1.2 version of the namespace.

Graphic
The namespace is http://www.w3.org/2003/05/soap-envelope.

Code
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<!-- The message contents go here -->
</soap:Body>
</soap:Envelope>
You can use variations of the schema structure, provided the envelope is qualified and
contains a message body.

Code
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<!-- The message contents go here -->
</env:Body>
</env:Envelope>
Optionally, the envelope of a SOAP message can include a message header, which
contains message metadata. Metadata is data about data. For example, it may specify
the size of the message or the format in which it's transmitted. The SOAP specification
doesn't cover what should be included as metadata so you can include any data.

A message header can provide information that's useful for determining whether
message data was handled correctly. For example, if a message arrives that's smaller
than the size specified in its header it's likely that the whole message wasn't transmitted
or received properly.
The header, if present, is included in the SOAP envelope before the body declaration.
Headers often contain information related to authentication and encryption, transaction
and routing management, and digital signing or timestamps.
For example, this SOAP message includes a header that provides authentication
credentials in the form of a user name and password.

Graphic
The header code is
<soap:Header>
<RequiredServiceHeader xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>

Code
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
Depending on which version of SOAP you're using, you can include one of two
attributes in a message header:
actor, or

You can use the actor attribute only in SOAP 1.1 messages. The actor attribute is
used to address the Header element to a particular endpoint. You include this attribute to
define how a message should be handled by intermediaries, which are applications that
can receive and forward SOAP messages between a requesting and a sending
application. The intermediaries can strip out headers that are for them alone. You can
define a header for the first intermediary or for a particular intermediary.
role
You can use the role attribute only in SOAP 1.2 messages. It's a substitute for
the actorattribute and performs the same function. However, you can also specify that a
header isn't for any one intermediary node, and you can specify in the header the
ultimate intermediary node, that is the ultimate receiver of the SOAP message.
To specify a header block to be consumed only by the first intermediary in a SOAP 1.1
message header, you define the actor attribute with this URI.

Graphic
The relevant code is
"http://schemas.xmlsoap.org/soap/actor/next"

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:actor="http://schemas.xmlsoap.org/soap/act
or/next"
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
And to specify a header block for a particular intermediary, you use the URI of the
intermediary.

Graphic

The URI is http://www.schemas.xmlsoap.org/soap/actor/next.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:actor="http://schemas.xmlsoap.org/soap/act
or/next"
xmlns="http://www.northglenn.com/extensions">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
For example, you might want a header to be used by the first intermediary it encounters
if it's a firewall and the header provides login credentials.
The role attribute for SOAP 1.2 provides more control over how intermediaries handle
SOAP messages. To specify a header block to be consumed only by the first
intermediary, you define therole attribute with this URI.

Graphic
The URI is http://www.w3.org/2003/05/soap-envelope/role/next.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:role="http://schemas.xmlsoap.org/soap/role
/next"
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>

<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
To define a header block that's not for any one intermediary in particular, such as when
the header is for processing by other header blocks, you use this URI.

Graphic
The URI is http://www.w3.org/2003/05/soapenvelope/
role/none.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:role="http://www.w3.org/2003/05/soapenvelo
pe/
role/none"
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
To specify that the header is for the last intermediary node, you use this URI. In SOAP
1.2, this is the default attribute if you don't specify a role.

Graphic
The URI is http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:role="http://www.w3.org/2003/05/soapenvelope/
role/ultimateReceiver"
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>
You can also use a specific URI if the header is for a particular intermediary that's not
the first or last hop or node the SOAP message is routed through.

Code
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<RequiredServiceHeader
soap:role="http://schemas.xmlsoap.org/soap/role
/next"
xmlns="http://www.northglenn.com/ws">
<Username>John Gold</Username>
<Password>amazing451</Password>
</RequiredServiceHeader>
</soap:Header>
<soap:Body>
<HelloWorld
xmlns="http://www.northglenn.com/ws" />
</soap:Body>
</soap:Envelope>

You can make processing of header blocks by recipients mandatory using

the mustUnderstandattribute. Using this attribute is optional. The default setting
is false.
For SOAP 1.1, you can set the attribute to 1 or 0.
And for SOAP 1.2, you can set the attribute to true or false.
The body of a SOAP message contains the data required by the method it's calling. This
includes the method name and the input parameters, and can include error-handling
information.
Web services also use the SOAP body element to return data.
Consider a sample ASP.NET web service. It takes two integer variables a and b as
input. It uses the Divide method to divide a by b and return an integer result.

Code
[WebMethod]
public int Divide(int a, int b) {
return (a/b);
}
You call the Divide method and pass it variables by serializing the call into XML. You
use the method name as an element in the SOAP body and you pass it the two integer
variables in this case 12 and 4 serialized into child elements using the variables'
names as element tags.

Code
<soap:Body>
<Divide xmlns="http://www.northglenn.com/ws">
<a>12</a>
<b>4</b>
</Divide>
</soap:Body>
The response is similarly serialized into XML in the message body. The method name
with Responseappended to it is used in the body element, and it returns a result
wrapped in the method name withResult appended to it.

Code
<soap:Body>
<DivideResponse
xmlns="http://www.northglenn.com/ws">

<DivideResult>3</DivideResult>
</DivideResponse>
</soap:Body>

Question
Match each description to the corresponding element of a SOAP message.
Options:
A.
B.
C.

Is the root node of the SOAP message

Contains message metadata
Contains the method name to be called and the input parameters

Targets:
1.
2.
3.

Envelope
Header
Body

Answer
The envelope consists of the root node of a SOAP message.
The header of a SOAP message contains the message metadata, which
describes the message.
The body of a SOAP message identifies the method that will be called and
passes it the input parameters.
Correct answer(s):
Target 1 = Option A
Target 2 = Option B
Target 3 = Option C

3. Handling errors with SOAP

You should be able to communicate with a web service if you build an interface using
WSDL. However, errors can still occur. When an error does occur, you need to know
that it has occurred and what type of error it was.
When an error is encountered, the fault element in the SOAP specification is used to
log the error details in the call reply message.
Error messages are handled differently in SOAP 1.1 and SOAP 1.2.

A SOAP 1.1 error message includes a number of elements.

Code
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.o
rg/soap
/encoding/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client.MissingParameter</faultcode
>
<faultstring>A parameter was missing</faultstring>
<faultactor>http://www.northglenn.com/ws/endpoint.
asp</faultactor>
<detail>
<w:error xmlns:w="http://www.northglenn.com/">
<code>316</code>
<desc>The flightname parameter was
missing.</desc>
</w:error>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
<soap:Fault>
The <soap:Fault> element is a child element of the <soap:Body> element.
<faultcode>
The <faultcode> element is a child element of the <soap:Fault> element required
in the SOAP 1.1 specification. There are four codes in the 1.1 specification
Client means the request was invalid, Server means there was a server-side error
that's unrelated to the request, MustUnderstand means the MustUnderstand rule
wasn't met, andVersionMismatch means the request envelope used an invalid
namespace declaration.
<faultstring>
The <faultstring> element is required in SOAP 1.1 and provides a plain-text
description of the error.
<faultactor>
The <faultactor> element contains the URI of the intermediary where the error was
encountered.
<detail>

The <detail> element contains application-specific information about the error, which
can be fed into the consuming application to provide helpful information about the error
type and cause.
A SOAP 1.2 error message includes slightly different elements.

Code
<soap:Fault>
<soap:Code>
<soap:Value>soap:VersionMismatch
| soap:MustUnderstand | Sender
| DataEncodingUnknown | Receiver</soap:Value>
(required)
<soap:Subcode>
<soap:Value>text</soap:Value> (required)
<soap:Subcode> ... </soap:Subcode>
</soap:Subcode>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang="languageCode">text<soap:Text>
(required)
<soap:Text xml:lang="languageCode">text<soap:Text>
(optional)
</soap:Reason>
<soap:Node>
http://www.northglenn.com/pNode
</soap:Node>
<soap:Role>
http://www.northglenn.com/pRole
</soap:Role>
<soap:Detail> ... </soap:Detail>
<soap:Fault>
The <soap:Fault> element is a child element of the <soap:Body> element, as in
SOAP 1.1.
<soap:Code>
The <soap:Code> element has two child elements <Value> and <Subcode>.
<soap:Value>
The <soap:Value> element specifies the error code and is mandatory. Sender means
the request was invalid, Receiver means there was a server-side error unrelated to the
request, and MustUnderstand and VersionMismatch are the same as in SOAP
1.1.DataEncodingUnknown is a new code that means that the SOAP header or body
used an unsupported type of encoding.
<soap:Reason>

The <soap:Reason> element is the same as the <faultstring> element in SOAP

1.1 except that it contains a <text> child element.
soap:Text
The <soap:Text> element contains a plain-text description of the error.
<soap:Node>
The <node> element contains the URI of the intermediary where the error was
encountered.
<soap:Role>
The <role> element describes the intermediary that returned the error. To specify the
first intermediary, you define the role with this URL:
http://www.w3.org/2003/05/
soap-envelope/role/next
To specify the last intermediary, you use this URI:
http://www.w3.org/2003/05/
soap-envelope/role/ultimateReceiver
<soap:Detail> ... </soap:Detail>
The <detail> element contains application-specific information about the error, which
can be fed into the consuming application to provide helpful information.
SOAP maintains data type integrity. This means, for example, that an integer in a web
service is not returned as a string by the SOAP call. You may need to convert your web
service type to a type supported by SOAP otherwise the data type integrity may not be
might not be maintained.
The supported types are found in this XML schema data types specification:
http://www.w3.org/TR/xmlschema-2
Supported types include

boolean

dateTime

double

duration

integer

short

string

unsignedInt, and

QName

Question
Which statements describe fault handling in SOAP 1.2?
Options:
1.
2.

The <soap:Fault> element is a child element of the <soap:Body> element

The Sender fault code means the request was invalid

3.
4.

The <faultstring> element describes the error

The Client fault code means the request was invalid

Answer
Option 1: Correct. The <soap:Fault> element is a child element of
the <soap:Body> element in both SOAP 1.1 and 1.2.
Option 2: Correct. The Sender fault code means a request was invalid in
SOAP 1.2.
Option 3: Incorrect. An error is described using the <faultstring> element in
SOAP 1.1. In SOAP 1.2, the <reason> element is used for this purpose.
Option 4: Incorrect. The Client fault code is used in SOAP 1.1. SOAP 1.2
uses the Sendercode for this purpose.
Correct answer(s):
1. The <soap:Fault> element is a child element of
the <soap:Body> element
2. The Sender fault code means the request was invalid

Summary
XML doesn't conform to a particular structure, which can make web service
communication between disparate applications difficult. SOAP was developed to define
the XML structure in which data is sent. After establishing the format that a web service
requires by checking its WSDL, you create a proxy class with a suitable interface to
send and receive SOAP calls to and from the web service. SOAP mostly uses HTTP as
the transport mechanism for its messages.
A SOAP message contains an envelope, a body, and optionally a header, and is
formatted as XML. The <soap:Envelope> element is the root node of the message.
The body of the SOAP message contains the data required by the method it's calling.

This includes the method name and the input parameters. The envelope of a SOAP
message may include a message header, which contains message metadata.
When an error is encountered, the fault element in the SOAP specification is used to
log the error details in the call reply.

Web Services and REST

Learning Objective

After completing this topic, you should be able to

describe the REST architecture

1. The REST architecture

Representational State Transfer, or REST, is a simple framework for designing
applications that uses HTTP to make calls. REST uses HTTP to perform the Create,
Read, Update, and Delete, or CRUD, operations. You can also use REST with HTTPS.
REST is platform and language independent. It can be used in environments with
firewalls because it's built on HTTP. REST can also use the security features of HTTPS
such as encryption or username and password tokens but doesn't rely on a
particular security standard.
Also, REST doesn't use cookies. A REST call includes all the information that's required
to return a result, in a process called state transfer.
The key characteristic of the REST architecture is that it involves the use of calls
between client and server devices. The World Wide Web, which has HTTP at its
foundation, can be regarded as a REST-based system.
Although REST may be regarded as a "lightweight" or simple framework, it can perform
the same functions as the Simple Object Access Protocol or SOAP and Web
Services Description Language, or WSDL.
Note that REST isn't a single standard or language. REST programming frameworks do
exist, but you can use the principles of the REST architecture while also using library
features in languages such as Java or C# to create your own applications.
In the REST architecture, applications interact with web services using the
HTTP POST, PUT, GET, and DELETE operations.
As an example, an application might use GET to retrieve a list of all students, POST to
add a student record, DELETE to remove a student record, and PUT to update an
existing student record.

Graphic
In this diagram, there are five sections: GET /student-list HTTP/1.1, POST
/employee HTTP/1.1,
Content-location: /employee/125
PUT /employee/125 HTTP/1.1,
DELETE /employee/12 HTTP/1.1, and No content. Each section is separated by
a set of two arrows that point in different directions.
Key characteristics of the REST architecture are that
it uses a client-server system
REST uses client-server architecture, in which a server can function as a server in one
instance and a client in another instance.
Provided a uniform interface is maintained between clients and servers, server issues are
transparent to clients and vice versa.
it's stateless
REST interactions between client and server are stateless, although the resources and
servers can be stateful. This means that client context isn't stored on the server at any
point.
To remove the need for a connection state, every new request has to contain all the
details required for successfully completing a task. If any session state has to be stored,
it's done on the client. The response for a specific request shouldn't be dependent on any
other interactions.
it supports caching of resources
In a REST system, resources can be cached. An advantage of caching is that it simplifies
or removes the need for certain client-server interactions. This leads to better
performance of the system as a whole. Ideally, resources should be cacheable as much
as possible and should have expiration dates and times.
The protocol used should allow a server to specify the time period and the resources for
caching. Because HTTP is the REST protocol, HTTP cache-control headers are used to
control the caching process.
A server's cache specification should be respected by the client.
it can use proxy servers, and
You can use any standard HTTP proxy as a proxy server in a REST-based system. Doing
this improves the scalability and performance of the system.
it uses logical URLs to identify resources

In the REST architecture, resources are identified by logical URLs. Resources are used
to represent functionality and state, and are regarded as the main component of a proper
RESTful design. This is in contrast to the methods or services that are used in web
services.
When using a web service, you might, for example, use a call such
as GetStudentName and then use GetStudentGrade to retrieve student information.
In a REST system student, information would be regarded as a resource that provides
the required information or a link to it.
By design, using a logical URL allows for a resource to be accessed from other
components of a system.
The REST system is based on the concept of a web of resources, which specifies that
one single resource shouldn't be overly complex or consist of too many levels of detail.
Wherever it's possible, a resource should include links to other details, in the same way
that a web page does. This achieves the aim of maintaining lean resources.
This example uses SOAP and web services to search a contacts list for a particular
entry. For a search to be performed, all of the code has to be sent to the server.
This will normally be in the form of an HTTP POST request.
The result of this type of processing is usually an XML file, which is stored within a
SOAP response envelope.
The query is a lot simpler using REST. It uses a URL, which is sent to the server using a
less complexGET request. The result is that the data received is ready to use it's not
embedded or encapsulated in any way.
Generally web services are used with libraries that create a SOAP request and then
parse a SOAP response. When using REST, however, you need only a connection to a
network and a browser although REST libraries are available.
Note that the method in a REST request generally takes the form of a noun
like Details whereas a SOAP request usually takes the form of a verb.
You can also use REST to perform more complex requests. In this example, multiple
parameters are passed to the server. In most cases, HTTP GET parameters are used in
the URL.
However, when a long parameter or a binary parameter has to be passed, an
HTTP POST request is usually used. The parameters are contained in the body of
the POST request.
It's generally a good idea to use GET requests only for read-only requests. In other
words, a GETrequest shouldn't be allowed to make state changes to a server or its
contents.

Similarly, it's better to use POST requests to create, update, or delete data.
When working with REST requests, a good rule of thumb is to assume that a web page
is using a REST API to provide its services. Then a GET request is used to read data
and a POST request is used to post a comment, which usually involves a longer and
more complex set of parameters.
Although REST services use XML to generate responses, XML is almost never used in
a REST request. Because the parameters for most requests are typically very basic,
XML isn't required.
However, using XML does offer the benefit of type-safety. But you should always check
that your input is correct because of the stateless nature of the REST architecture.
In REST, a server response is generally returned in the form of an XML file. However,
other formats can also be used. These can include the JavaScript Object Notation or
JSON and comma-separated values or CSV formats.
Each format has pros and cons. For example, CSV is very compact. JSON is very easy
for JavaScript clients to parse and is easily parsed by other languages. XML is easily
expandable and is type-safe.
An example of a format that's regarded as unsuitable as a REST response is HTML,
unless it's required in special cases. The same policy applies to all other formats that
are designed to be easy for humans to read but are difficult for clients to process. The
only exception to this policy is when the response is supposed to be a human-readable
document.
However, despite being regarded as an unsuitable format, the fact that the World Wide
Web is regarded as a RESTful application, it appears that the most widely used REST
response format is HTML.
Many service providers support a REST API. These include providers of services such
as Twitter, Flickr, Atom, and many Yahoo! services, including search, map, and photorelated services.
Some of these service providers also support a Web Services Description Language, or
WSDL, API so you can choose which to use. However, it's worth noting that REST
calls and the results they retrieve are simpler to work with and less resource intensive.
In this example, a URL directs a REST request to the Yahoo! search service.
The request includes two parameters appid, which Yahoo! uses to select the
application, andquery, which is the search query itself.

Graphic

The relevant code is appid=YahooDemo and

query=rest.
Unlike SOAP, which returns data embedded in an envelope, the request retrieves raw
XML data which can be accessed immediately.

Question
Identify the characteristics of the REST architecture.
Options:
1.
2.
3.
4.
5.
6.

Resources are identified by URLs

Resources are kept "lean"
Interactions are stateless
Resources can be cached
Responses are embedded in envelopes
Cookies must be used

Answer
Option 1: Correct. Instead of using complex methods to retrieve information,
REST uses logical URLs to get responses from resources. The resources are
therefore accessible from any system component.
Option 2: Correct. In a REST system, resources shouldn't be too detailed
instead they should have links to additional information.
Option 3: Correct. All interactions between a client and a server are stateless in
the REST architecture. There's no need for the server to maintain state
information about the client.
Option 4: Correct. In a REST system, it's ideal for all resources to be
cacheable. Caching resources can reduce the need for interactions between the
client and the server, and so improve system performance.
Option 5: Incorrect. When a REST response is returned, it's normally presented
as raw data in XML format. It's not embedded in an envelope.
Option 6: Incorrect. In the REST architecture, interactions are stateless. A
REST call contains all the required information for a request to be processed, so
cookies aren't required to maintain state information.
Correct answer(s):
1. Resources are identified by URLs
2. Resources are kept "lean"

3. Interactions are stateless

4. Resources can be cached
| Print | Contents | Close |

Web Services and WSDL

Learning Objective

After completing this topic, you should be able to

describe the elements of a WSDL file

1. WSDL elements and attributes

Web Services Description Language or WSDL provides a model for describing the
interface of a web service, in an XML grammar, so that the service can be called.
In order to find a service, a URL is sent to the server. The server responds with a link to
the service, or the server.
Then the service request is sent and its response is an XML document.

Graphic
This diagram has two sets of server requests and responses. The first set is
titled Find a service. The link http://myservice.northglenn.com/ is sent to the
server and the response is a link to the service.
In the second set, titled WSDL, the service request
http://northglenn.com/MyService.wsdl is sent and the response form the server
is an XML document.
A WSDL document describes how clients can interact with a particular service. It does
this in an XML format, using specific elements and attributes.
The latest version of WSDL is version 2.0. It can be found at this W3C web site:
http://www.w3.org/TR/wsdl20/
A WSDL 2.0 document contains the following elements:
description
The description element is the root element of a WSDL document and is required. All
other elements are nested in this element.
types

The types element identifies the data types that can be sent between the client and the
web service. These types are described using an XML schema by default. This is a
required element.
interface
The interface element describes the operations provided by the web service, and the
input, output, and fault messages for each operation. This is a required element.
binding
The binding element describes how a web service is accessed over the network and
usually binds the service to the HTTP protocol. This is a required element.
service
The service element specifies the endpoint of a web service which describes where the
web service can be accessed on the network and usually contains a URL that links to the
service. This is a required element.
documentation, and
The documentation element can contain information about a web service, such as a
description of its purpose, for users to read. This is an optional element.
import
The import element is used to import other WSDL files or XML schemas. It's an optional
element.
The required elements of a WSDL file can be structured as in this example.

Code
<description>
<types>
</types>
<interface>
</interface>
<binding>
</binding>
<service>
</service>
</description>
The description element supports various attributes for declaring the namespaces
used throughout a WSDL document.

Code
<?xml version="1.0" encoding="utf-8" ?>
<description
xmlns=
"http://www.w3.org/ns/wsdl"
targetNamespace= "http://northglenn.com/MyService"
xmlns:tns=
"http://northglenn.com/MyService"
xmlns:stns=
"http://northglenn.com/MyService/schema"
xmlns:wsoap=
"http://www.w3.org/ns/wsdl/soap"
xmlns:soap=
"http://www.w3.org/2003/05/soapenvelope"
xmlns:wsdlx=
"http://www.w3.org/ns/wsdl-extensions"
>
...
xmlns
The xmlns attribute sets the description element's default namespace. This
namespace is applied to all subsequent elements that don't have a specific namespace
declaration.
targetNamespace
The targetNamespace attribute contains the namespace of the web service. The
namespace URI should point to the WSDL of the service.
xmlns:tns
The xmlns:tns attribute refers to the target namespace using the tns prefix, and
should be the same as the targetNamespace attribute.
xmlns:stns
The xmlns:stns attribute specifies the URI pointing to the XML schema's namespace.
This namespace is declared in the types element.
xmlns:wsoap
The xmlns:wsoap attribute points to the WSDL SOAP URI that's declared in
the bindingselement of the WSDL.
xmlns:soap
The xmlns:soap attribute points to the SOAP URI of the SOAP version used by the
WSDL.
xmlns:wsdlx
The xmlns:wsdlx attribute points to the URI for WSDL extensions.
Web services usually use specific data types for input, output, and faults. These types
are identified by the types element in a WSDL document. If a service can perform
multiple operations, each operation may have a set of these types.

The data types specification can be found at this W3C web site:
http://www.w3.org/TR/xmlschema-2/
You can declare the data types in any language provided it's supported by the web
service API. You can also declare the types using an XML schema.
In this example, an XML schema is used to define input, output, and fault types.

Code
<types>
<xs:schema
xmlns:xs=
"http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://northglenn.com/MyService/schema"
xmltns=
"http://northglenn.com/MyService/schema">
<xs:element name="latestSampleRequest" type="typeLatest
SampleRequest"/>
<xs:complexType name="typeLatestSampleRequest">
<xs:sequence>
<xs:element name="date" type="xs:date"/>
</xs:sequence>
</xs:complexType>
<xs:element name="latestSampleResponse" type="xs:string
"/>
<xs:element name="invalidDateError" type="xs:string"/>
</xs:schema>
</types>
The input type in this example is the latestSampleRequest element. Its data type
istypeLatestSampleRequest, which is declared as being of the date type. This
input type can hold a date that specifies when the newest sample can be retrieved from
a server.

Graphic
The relevant code is
<xs:element name="latestSampleRequest"
type="typeLatestSampleRequest"/>

<xs:complexType name="typeLatestSampleRequest">
<xs:sequence>
<xs:element name="date" type="xs:date"/>
</xs:sequence>
</xs:complexType>

Code
<types>
<xs:schema
xmlns:xs=
"http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://northglenn.com/MyService/schema"
xmltns=
"http://northglenn.com/MyService/schema">
<xs:element name="latestSampleRequest" type="typeLatest
SampleRequest"/>
<xs:complexType name="typeLatestSampleRequest">
<xs:sequence>
<xs:element name="date" type="xs:date"/>
</xs:sequence>
</xs:complexType>
The output type is the latestSampleResponse element, which is defined as a string.
For example, this output type can contain a URL that directs the client to the location of
the latest sample using the input type date.

Graphic
The relevant code is
<xs:element name="latestSampleResponse" type="xs:string"/>

Code
<xs:element name="latestSampleResponse" type="xs:string
"/>
The fault type is the invalidDateError element, which is also defined as a string.
You can populate this string with information about why a specific input request would
be denied.

Graphic

The relevant code is

<xs:element name="invalidDateError" type="xs:string"/>

Code
<xs:element name="invalidDateError" type="xs:string"/>
You can define all sorts of elements and types in an XML schema. However, the WSDL
2.0interface and operation elements can refer only to single-element declarations
and top-level elements declared outside other elements.
In this example, for instance, you can't use the date type as a standalone element for
an input or output type operation because it's declared inside
the latestSampleRequest element.

Graphic
The relevant code is
xs:element name="latestSampleRequest" type="typeLatestSampleRequest"

Code
<types>
<xs:schema
xmlns:xs=
"http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://northglenn.com/MyService/schema"
xmltns=
"http://northglenn.com/MyService/schema">
<xs:element name="latestSampleRequest" type="typeLatest
SampleRequest"/>
<xs:complexType name="typeLatestSampleRequest">
<xs:sequence>
<xs:element name="date" type="xs:date"/>
</xs:sequence>
</xs:complexType>
<xs:element name="latestSampleResponse" type="xs:string
"/>
<xs:element name="invalidDateError" type="xs:string"/>
</xs:schema>
</types>

In the description element declaration, an XML namespace is declared with

the stns prefix. In this example, the same namespace is also referenced as the target
namespace of the XML schema using targetNameSpace and the tns prefix.

Graphic
The relevant code in the description element declaration is
xmlns:stns = "http://northglenn.com/MyService/schema"
The relevant code in the types element declaration is
xmlns:tns = "http://northglenn.com/MyService/schema"

Code
<description
xmlns=
"http://www.w3.org/ns/wsdl"
targetNamespace= "http://northglenn.com/MyService"
xmlns:tns=
"http://northglenn.com/MyService"
xmlns:stns=
"http://northglenn.com/MyService/schema"
xmlns:wsoap=
"http://www.w3.org/ns/wsdl/soap"
xmlns:soap=
"http://www.w3.org/2003/05/soapenvelope"
xmlns:wsdlx=
"http://www.w3.org/ns/wsdl-extensions"
>
...
<types>
<xs:schema
xmlns:xs=

"http://www.w3.org/2001/XMLSch

ema"
targetNamespace=
"http://northglenn.com/MyService/schema"
xmltns=
"http://northglenn.com/MyService/schema">
This is possible because the namespace specified for the XML schema is valid only
within the schema declaration so it won't conflict with any namespace declared in
the description element.

Graphic
The relevant code is
<xs:schema
xmlns:xs=
"http://www.w3.org/2001/XMLSchema"
targetNamespace= "http://northglenn.com/MyService/schema"
xmlns=
"http://northglenn.com/MyService/schema">

Code
<types>
<xs:schema
xmlns:xs=
"http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://northglenn.com/MyService/schema"
xmlns=
"http://northglenn.com/MyService/schema">
<xs:element name="latestSampleRequest" type="typeLatest
SampleRequest"/>
<xs:complexType name="typeLatestSampleRequest">
<xs:sequence>
<xs:element name="date" type="xs:date"/>
</xs:sequence>
</xs:complexType>
<xs:element name="latestSampleResponse" type="xs:string
"/>
<xs:element name="invalidDateError" type="xs:string"/>
</xs:schema>
</types>
The interface element describes the operations that can be performed by the web
service. Each operation involves to-and-fro communication between the client and the
service. A client can log only one operation request to the service at a time.

Code
<interface

name = "latestSampleInterface" >

<fault name = "invalidDateFault"

"stns:invalidDateError"/>

element =

<operation name="latestSampleOperation"
pattern="http://www.w3.org/ns/wsdl/in-out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input
messageLabel="In" element="stns:late
stSampleRequest" />
<output
messageLabel="Out" element="stns:late
stSampleResponse" />
<outfault messageLabel="Out" ref
="tns:inval

idDateFault" />
</operation>
</interface>
Operations are the WSDL version of procedures or methods in normal programming
languages.
The interface element declaration has three main parts.

Code
<interface

name = "latestSampleInterface" >

<fault name = "invalidDateFault"

"stns:invalidDateError"/>

element =

<operation name="latestSampleOperation"
pattern="http://www.w3.org/ns/wsdl/in-out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input
messageLabel="In" element="stns:late
stSampleRequest" />
<output
messageLabel="Out" element="stns:late
stSampleResponse" />
<outfault messageLabel="Out" ref
="tns:inval
idDateFault" />
</operation>
</interface>
< interface

name = " latestSampleInterface " >

When using WSDL 2.0, you can include multiple interface elements provided you give
each of these a unique name. You define the name of an interface element using
the name attribute.
< fault name = " invalidDateFault "

element = "

stns:invalidDateError "/>
You use the fault element to return fault notifications to the client. This element lets
you specify fault notifications outside of the operation element so that the notifications
can be reused for multiple operations. You name a fault by using the name attribute,
which is then used by the operation element to return a fault. The element attribute
references thefault element previously defined in the types element through
the stns namespace.

< operation name =" latestSampleOperation "

The operation element contains the operation declarations and can contain a number
of attributes and nested elements.
Attributes you can use with the operation element include

Code
<interface

name = "latestSampleInterface" >

<fault name = "invalidDateFault"

"stns:invalidDateError"/>

element =

<operation name="latestSampleOperation"
pattern="http://www.w3.org/ns/wsdl/in-out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input
messageLabel="In" element="stns:late
stSampleRequest" />
<output
messageLabel="Out" element="stns:late
stSampleResponse" />
<outfault messageLabel="Out" ref
="tns:inval
idDateFault" />
</operation>
</interface>
name
You use the name attribute to specify the name of the operation. This name must be
unique inside the interface element and is referenced when defining the bindings of
the operation.
pattern
You use the pattern attribute to describe the operation's exchange pattern. This
exchange pattern describes the flow of information and can be in, out, or in-and-out.
style, and
You use the style attribute to define additional information on an operation, such as
element declaration constraints of the interface message reference. This attribute is
optional.
wsdlx:safe
You use the wsdlx:safe attribute to indicate whether a fiscal agreement is being
entered into. When the attribute is set to true, it means an operation is safe to call and
the user isn't agreeing to order or buy anything.

Elements you can nest inside the operation element include

Code
<interface

name = "latestSampleInterface" >

<fault name = "invalidDateFault"

"stns:invalidDateError"/>

element =

<operation name="latestSampleOperation"
pattern="http://www.w3.org/ns/wsdl/in-out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input
messageLabel="In" element="stns:late
stSampleRequest" />
<output
messageLabel="Out" element="stns:late
stSampleResponse" />
<outfault messageLabel="Out" ref
="tns:inval
idDateFault" />
</operation>
</interface>
input
You use the input element to link the expected input data for the operation with the
input element defined in the types element of the WSDL document.
output, and
You use the output element to link the expected output data for the operation with the
output element defined in the types element of the WSDL document.
outfault
You use the outfault element to define a possible output error that can be sent to the
client if the operation fails. The ref attribute links to the fault defined earlier in
the interfaceelement, and the messageLabel attribute indicates which message will
be replaced by thefault message.
You use the binding element to bind a web service to a network protocol so that it's
accessible from the Web or another network.

Code
<binding name="latestSampleSOAPBinding"
interface="tns:latestSampleInterface"
type="http://www.w3.org/ns/wsdl/soap"

wsoap:protocol="http://www.w3.org/2003/05/soap/bind
ings/HTTP/">
<fault ref="tns:invalidDateFault"
wsoap:code="soap:Sender"/>
<operation ref="tns:latestSampleOperation"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soapresponse"/>
</binding>
You use a number of elements and attributes to bind a web service to a protocol.

Code
<binding name="latestSampleSOAPBinding"
interface="tns:latestSampleInterface"
type="http://www.w3.org/ns/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bind
ings/HTTP/">
<fault ref="tns:invalidDateFault"
wsoap:code="soap:Sender"/>
<operation ref="tns:latestSampleOperation"wsoap:mep
="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</binding>
name
The binding name attribute should be a unique identifier within the WSDL document
and is referenced in the service element.
interface
The interface attribute references the name of a defined interface element and
uses the tns: prefix to direct it to the target namespace in the WSDL document.
type
The type attribute specifies the type of message format that the interface is bound to. In
this example, it's set to SOAP.
wsoap:protocol
The wsoap:protocol attribute specifies which protocol must be used to transport a
SOAP message. In this example, it's transported via HTTP.
fault

The fault element specifies which fault message can be sent back to the web service
through this binding. In this example, the invalidDateFault fault declared in
the interfaceelement is used.
operation
The operation element references an operation defined in the interface element
using the ref attribute and tns: prefix.
wsoap:mep
The operation element's wsoap:mep attribute specifies SOAP's Message Exchange
Pattern, or MEP. The MEP defines the type of message that will be sent or received by
the SOAP service.
You use the service element to specify the endpoint of a web service, and you use
the nameattribute to specify the service element's name.

Graphic
The relevant code is
service
name="latestSampleService"

Code
<service
name
="latestSampleService"
interface="tns:latestSampleInterface">
<endpoint name ="latestSampleEndpoint"
binding ="tns:latestSampleSOAPBinding"
address ="http://northglenn.com/latestSample"/>
</service>
The interface attribute specifies the interface element that's linked to
the service element.

Graphic
The relevant code is
interface="tns:latestSampleInterface">

Code

<service
name
="latestSampleService"
interface="tns:latestSampleInterface">
<endpoint name ="latestSampleEndpoint"
binding ="tns:latestSampleSOAPBinding"
address ="http://northglenn.com/latestSample"/>
</service>
The endpoint element specifies the address of the web service. You use
the name attribute to specify the endpoint name. The binding attribute specifies which
binding element the endpoint should use, and the address attribute contains the URI
where the service can be reached.

Graphic
The relevant code is
<endpoint name ="latestSampleEndpoint"
binding ="tns:latestSampleSOAPBinding"
address ="http://northglenn.com/latestSample"/>

Code
<service
name
="latestSampleService"
interface="tns:latestSampleInterface">
<endpoint name ="latestSampleEndpoint"
binding ="tns:latestSampleSOAPBinding"
address ="http://northglenn.com/latestSample"/>
</service>

Supplement
Selecting the link title opens the resource in a new browser window.

Code Window
Access the code window Example of a WSDL File for an example of a
complete WSDL file.

Question

Match the descriptions to the corresponding WSDL elements. One of the

elements is optional and doesn't match to a description.
Options:
A.
B.
C.
D.
E.

Is the root element of the WSDL file

Specifies the types of data used by a web service
Describes the operations performed by a web service
Ties a web service to a network protocol
Specifies the address where a web service can be reached

Targets:
1.
2.

description
types

3.
4.

interface
binding

5.
6.

service
documentation

Answer
The description element is the root element of a WSDL document. All other
elements are nested within it.
The types element specifies the data types that can be sent between the client
and the web service.
The interface element describes the operations performed by a web service,
as well as the input, output, and fault messages for each operation.
The binding element identifies the network protocol that makes a web service
accessible via the Web or another network.
The service element specifies the address at which a web service can be
accessed by a client.
The documentation element is optional. You can use it to provide a
description of a web service for users.
Correct answer(s):
Target 1 = Option A
Target 2 = Option B
Target 3 = Option C
Target 4 = Option D

Target 5 = Option E
Target 6 =No Option Specified.

Summary
You use WSDL to describe the interface of a web service so that it can be called. In a
WSDL document, the description element is the root element. It contains all other
elements and identifies the namespaces that will be used. The types element identifies
the data types that can be used by the client and the web service, and
the interface element describes the operations that the web service performs.
The binding element identifies the network protocol that makes the service accessible
over a network, and the service element specifies the URI or endpoint at which the
service can be accessed.

Table of Contents
| Top of page |
| Learning Objective |
| 1.WSDL elements and attributes |
| Summary |
Copyright 2011