Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Web services provide a common platform that allows multiple applications built on
various programming languages to have the ability to communicate with each other
SOAP:
SOAP is known as the Simple Object Access Protocol.
WSDL:
WSDL is known as the Web Services Description Language(WSDL).
WSDL is an XML-based file which tells the client application what the web service
does and gives all the information required to connect to the web service.
REST:
REST stands for REpresentational State Transfer.
REST is used to build Web services that are lightweight, maintainable, and scalable.
Most often than not, these heterogeneous applications need some sort of
communication to happen between them. Since they are built using different
development languages, it becomes really difficult to ensure accurate
communication between applications.
Here is where web services come in. Web services provide a common platform that
allows multiple applications built on various programming languages to have the
ability to communicate with each other.
In this introductory tutorial, we will explain more about what web services are about,
the different elements which constitute web services, and a little bit about SOA
(Service Oriented Architecture) principles
Web service is a standardized medium to propagate communication between the client and server
applications on the World Wide Web.
A web service is a software module which is designed to perform a certain set of tasks.
o The web services can be searched for over the network and can also be invoked
accordingly.
o When invoked the web service would be able to provide functionality to the client which
invokes that web service.
The above diagram shows a very simplistic view of how a web service would
actually work. The client would invoke a series of web service calls via
requests to a server which would host the actual web service.
These requests are made through what is known as remote procedure calls.
Remote Procedure Calls(RPC) are calls made to methods which are hosted
by the relevant web service.
As an example, Amazon provides a web service that provides prices for
products sold online via amazon.com. The front end or presentation layer can
be in .Net or Java but either programming language would have the ability to
communicate with the web service.
The main component of a web service is the data which is transferred
between the client and the server, and that is XML. XML (Extensible markup
language) is a counterpart to HTML and easy to understand the intermediate
language that is understood by many programming languages.
So when applications talk to each other, they actually talk in XML. This
provides a common platform for application developed in various
programming languages to talk to each other.
Web services use something known as SOAP (Simple Object Access
Protocol) for sending the XML data between applications. The data is sent
over normal HTTP. The data which is sent from the web service to the
application is called a SOAP message. The SOAP message is nothing but an
XML document. Since the document is written in XML, the client application
calling the web service can be written in any programming language.
In order for a web service to be fully functional, there are certain components
that need to be in place. These components need to be present irrespective
of whatever development language is used for programming the web service.
The diagram below shows a simple example of the communication via SOAP.
<definitions>
<message name="TutorialRequest">
<part name="TutorialID" type="xsd:string"/>
</message>
<message name="TutorialResponse">
<part name="TutorialName" type="xsd:string"/>
</message>
<portType name="Tutorial_PortType">
<operation name="Tutorial">
<input message="tns:TutorialRequest"/>
<output message="tns:TutorialResponse"/>
</operation>
</portType>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:Tutorialservice"
use="encoded"/>
</output>
</operation>
</binding>
</definitions>
The important aspects to note about the above WSDL declaration are as
follows;
UDDI is a standard for describing, publishing, and discovering the web services that are provided by a
particular service provider. It provides a specification which helps in hosting the information on web
services.
Now we discussed in the previous topic about WSDL and how it contains information on what the Web
service actually does. But how can a client application locate a WSDL file to understand the various
operations offered by a web service? So UDDI is the answer to this and provides a repository on which
WSDL files can be hosted. So the client application will have complete access to the UDDI, which acts as
a database containing all the WSDL files.
Just as a telephone directory has the name, address and telephone number of a particular person, the
same way the UDDI registry will have the relevant information for the web service. So that a client
application knows, where it can be found.
Web Services Advantages
We already understand why web services came about in the first place, which was
to provide a platform which could allow different applications to talk to each other.
But let's look at some other advantages of why it is important to use web services.
Every framework needs some sort of architecture to make sure the entire framework
works as desired. Similarly, in web services, there is an architecture which consists
of three distinct roles as given below
1. Provider - The provider creates the web service and makes it available
to client application who want to use it.
2. Requestor - A requestor is nothing but the client application that needs
to contact a web service. The client application can be a .Net, Java, or
any other language based application which looks for some sort of
functionality via a web service.
3. Broker - The broker is nothing but the application which provides
access to the UDDI. The UDDI, as discussed in the earlier topic
enables the client application to locate the web service.
The diagram below showcases how the Service provider, the Service requestor and
Service registry interact with each other.
1. Publish - A provider informs the broker (service registry) about the existence
of the web service by using the broker's publish interface to make the service
accessible to clients
2. Find - The requestor consults the broker to locate a published web service
3. Bind - With the information it gained from the broker(service registry) about
the web service, the requestor is able to bind, or invoke, the web service.
1. They are XML-Based - Web Services uses XML to represent the data at the
representation and data transportation layers. Using XML eliminates any
networking, operating system, or platform sort of dependency since XML is
the common language understood by all.
2. Loosely Coupled – Loosely coupled means that the client and the web
service are not bound to each other, which means that even if the web service
changes over time, it should not change the way the client calls the web
service. Adopting a loosely coupled architecture tends to make software
systems more manageable and allows simpler integration between different
systems.
3. Synchronous or Asynchronous functionality- Synchronicity refers to the
binding of the client to the execution of the service. In synchronous
operations, the client will actually wait for the web service to complete an
operation. An example of this is probably a scenario wherein a database read
and write operation are being performed. If data is read from one database
and subsequently written to another, then the operations have to be done in a
sequential manner. Asynchronous operations allow a client to invoke a
service and then execute other functions in parallel. This is one of the
common and probably the most preferred techniques for ensuring that other
services are not stopped when a particular operation is being carried out.
4. Ability to support Remote Procedure Calls (RPCs) - Web services enable
clients to invoke procedures, functions, and methods on remote objects using
an XML-based protocol. Remote procedures expose input and output
parameters that a web service must support.
5. Supports Document Exchange - One of the key benefits of XML is its
generic way of representing not only data but also complex documents.
These documents can be as simple as representing a current address, or
they can be as complex as representing an entire book.
SOAP is an XML-based protocol for accessing web services over HTTP. It has some specification which
could be used across all applications.
SOAP is known as the Simple Object Access Protocol, but in later times was just shortened to SOAP v1.2.
SOAP is a protocol or in other words is a definition of how web services talk to each other or talk to
client applications that invoke them.
SOAP was developed as an intermediate language so that applications built on various programming
languages could talk easily to each other and avoid the extreme development effort.
SOAP Introduction
In today's world, there is huge number of applications which are built on different
programming languages. For example, there could be a web application designed in
Java, another in .Net and another in PHP.
Exchanging data between applications is crucial in today's networked world. But
data exchange between these heterogeneous applications would be complex. So
will be the complexity of the code to accomplish this data exchange.
One of the methods used to combat this complexity is to use XML (Extensible
Markup Language) as the intermediate language for exchanging data between
applications.
Every programming language can understand the XML markup language. Hence,
XML was used as the underlying medium for data exchange.
But there are no standard specifications on use of XML across all programming
languages for data exchange. That is where SOAP comes in.
SOAP was designed to work with XML over HTTP and have some sort of
specification which could be used across all applications. We will look into further
details on the SOAP protocol in the subsequent chapters.
Advantages of SOAP
SOAP is the protocol used for data interchange between applications. Below are
some of the reasons as to why SOAP is used.
When developing Web services, you need to have some of language which
can be used for web services to talk with client applications. SOAP is the
perfect medium which was developed in order to achieve this purpose. This
protocol is also recommended by the W3C consortium which is the governing
body for all web standards.
SOAP is a light-weight protocol that is used for data interchange between
applications. Note the keyword 'light.' Since SOAP is based on the XML
language, which itself is a light weight data interchange language, hence
SOAP as a protocol that also falls in the same category.
SOAP is designed to be platform independent and is also designed to be
operating system independent. So the SOAP protocol can work any
programming language based applications on both Windows
and Linux platform.
It works on the HTTP protocol –SOAP works on the HTTP protocol, which is
the default protocol used by all web applications. Hence, there is no sort of
customization which is required to run the web services built on the SOAP
protocol to work on the World Wide Web.
The diagram below shows the various building blocks of a SOAP Message.
The SOAP message is nothing but a mere XML document which has the below
components.
The complex type is defined by the element tag <xsd:complexType>. All of the
required elements of the structure along with their respective data types are then
defined in the complex type collection.
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Tutorial Name" type="string"/>
<xsd:element name="Tutorial Description" type="string"/>
</xsd:sequence>
</xsd:complexType>
A Body element that contains call and response information – This element is
what contains the actual data which needs to be sent between the web
service and the calling application. Below is an example of the SOAP body
which actually works on the complex type defined in the header section. Here
is the response of the Tutorial Name and Tutorial Description that is sent to
the calling application which calls this web service.
<soap:Body>
<GetTutorialInfo>
<TutorialName>Web Services</TutorialName>
<TutorialDescription>All about web services</TutorialDescription>
</GetTutorialInfo>
</soap:Body>
Whenever a client application calls a method in the web service, the web service will
automatically generate a SOAP message which will have the necessary details of
the data which will be sent from the web service to the client application.
As discussed in the previous topic, a simple SOAP Message has the following
elements –
Let's look at an example below of a simple SOAP message and see what element
actually does.
1. As seen from the above SOAP message, the first part of the SOAP message
is the envelope element which is used to encapsulate the entire SOAP
message.
2. The next element is the SOAP body which contains the details of the actual
message.
3. Our message contains a web service which has the name of
"Guru99WebService".
4. The "Guru99Webservice" accepts a parameter of the type 'int' and has the
name of TutorialID.
Now, the above SOAP message will be passed between the web service and the
client application.
You can see how useful the above information is to the client application. The SOAP
message tells the client application what is the name of the Web service, and also
what parameters it expects and also what is the type of each parameter which is
taken by the web service.
The SOAP envelope element is used to indicate the beginning and end of a SOAP
message. This enables the client application which calls the web service to know
when the SOAP message ends.
<?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:Body>
<Guru99WebService xmlns="http://tempuri.org/">
<TutorialID>int</TutorialID>
</Guru99WebService>
</soap:Body>
</SOAP-ENV:Envelope>
When a request is made to a SOAP web service, the response returned can be of
either 2 forms which are a successful response or an error response. When a
success is generated, the response from the server will always be a SOAP
message. But if SOAP faults are generated, they are returned as "HTTP 500" errors.
An example of a fault message is given below. The error is generated if the scenario
wherein the client tries to use a method called TutorialID in the class GetTutorial.
The below fault message gets generated in the event that the method does not exist
in the defined class.
When you execute the above code, it will show the error like "Failed to locate
method (GetTutorialID) in class (GetTutorial)"
Let's consider the below diagram to see how this communication works. In this
example, let's assume the server hosts a web service which provided 2 methods as
In the normal RPC style communication, the client would just call the methods in its
request and send the required parameters to the server, and the server would then
send the desired response.
To overcome all of the limitations cited above, SOAP would then use the below
communication model
1. The client would format the information regarding the procedure call and any
arguments into a SOAP message and sends it to the server as part of an
HTTP request. This process of encapsulating the data into a SOAP message
was known as Marshalling.
2. The server would then unwrap the message sent by the client, see what the
client requested for and then send the appropriate response back to the client
as a SOAP message. The practice of unwrapping a request sent by the client
is known as Demarshalling.
Probably one of the best ways to see how SOAP messages get generated is to
actually see a web service in action.
This topic will look at using the Microsoft.Net framework to build an ASMX web
service. This type of web service supports both SOAP version 1.1 and version 1.2.
ASMX web services automatically generate the Web Service Definition Language
(WSDL) document. This WSDL document is required by the calling client application
so that the application knows what the web service is capable of doing.
In our example, we are going to create a simple web service, which will be used to
return a string to the application which calls the web service.
This web service will be hosted in an Asp.Net web application. We will then invoke
the web service and see the result that is returned by the web service.
Visual Studio will also show us what the SOAP message being passed between the
web service and the calling application.
The first pre-requisite to setup our Web service application which can be done by
following the below steps.
Please ensure that you have Visual Studio 2013 installed on your system for this example.
Step 1) The first step is to create an empty ASP.Net Web application. From Visual
Studio 2013, click on the menu option File->New project.
Once you click on the New Project option, Visual Studio will then give you another
dialog box for choosing the type of project and to give the necessary details of the
project. This is explained in the next step.
1. Ensure to first choose the C# web template of ASP.NET Web application. The
project has to be of this type in order to create web services project. By
choosing this option, Visual Studio will then carry out the necessary steps to
add required files which are required by any web-based application.
2. Give a name for your project which in our case has been given as
webservice.asmx. Then ensure to give a location where the project files will
be stored
Once done you will see the project file created in your solution explorer in Visual
Studio 2013.
Step 3) In this step,
2. Once you right-click on the project file, you have the chance to choose the
option "Add->Web Service(ASMX) to add a web service file. Just provide a
name of Tutorial Service for the web service name file.
Step 4) Add the following code to your Tutorial Service asmx file.
Code Explanation:
1. This line of code provides a name for your web service file. This is an
important step because it gives way for the client application to call the web
service via the name of the web service.
2. Normally a class file is used to encapsulate the functionality of a web service.
So the class file will have the definition of all the web methods which will
provide some functionality to the client application.
3. Here [WebMethod] is known as an attribute which describes a function. The
subsequent step creates a function called "Guru99WebService", but with the
inclusion of this step of adding a [WebMethod] attribute makes sure that this
method can be invoked by a client application. If this attribute is not in place,
then the method can never be called by a client application.
4. Here we are defining a function called 'Guru99WebService' which will be used
to return a string to the calling client application. This function is a web service
which can be called by any client application.
5. We are using the return statement to return the string "This is a Guru99 Web
service" to the client application.
If the code is executed successfully, the following Output will be shown when you
run your code in the browser.
Output:
The output clearly shows that the name of our web service is "Guru99 Web
Service" which is the result of giving a name for our web service.
We can also see that we can to invoke the web service. If we click the Invoke
button, we will get the below response in the web browser.
The above output,
It clearly shows that by invoking the web method, the string "This is a Gu99
Web service" is returned.
Visual Studio also allows you to view the SOAP message request and
response which is generated when the above web service is called.
The SOAP request which is generated when the web service is called is shown
below.
Code Explanation:
1. The first part of the SOAP message is the envelope element which is what
was discussed in the prior chapters. This is the encapsulating element which
is present in every SOAP message.
2. The SOAP Body is the next element and contains the actual details of the
SOAP message.
3. The third part is the element which specifies that we want to call the service
which is called 'Guru99WebService.'
<soap:Envelopexmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<Guru99WebServiceResponse xmlns="http://tempuri.org/">
<Guru99WebServiceResult>string</Guru99WebServiceResult>
</Guru99WebServiceResponse>
</soap:Body>
</soap:Envelope>
Code Explanation:
1. The first part of the SOAP message is the envelope element which is what
was discussed in the prior chapters. This is the encapsulating element which
is present in every SOAP message.
2. The SOAP Body is the next element and contains the actual details of the
SOAP message.
3. The interesting part you will see now is the 'string' attribute. This tells the
client application that the web service being called returns an object of the
type string. This is very useful because if the client application which
otherwise would not know what the web service returns.
Summary