Web Services Tutorial: Components, Architecture, Types & Examples

This Web Services Tutorial Explains The Architecture, Types & Components of a Web Service Along With Important Terminologies and the Differences Between SOAP Vs REST:

In this Complete API Testing Tutorial Series, we explored all about API Testing in our previous tutorial. Go through this tutorial to become familiar with WSDL and UDDI and how they store and define a Web Service.

This tutorial will also explain how Web Services works internally when a client application makes a request. WSS, which is another very important concept of SOAP Services, is also explained here.

Important Terminologies In Web Service Testing

Web Services Tutorial

Before we start exploring Web Services, we should be familiar with the important terms that are used in Web Services Testing.

Let’s Start!!

#1) Interoperability

Web Services support “One Code Different Applications”. This means one generic code for all applications across different platforms.

Thus, interoperability is the process that facilitates multiple applications to communicate with the other applications residing on a different platform.

#2) Authentication And Authorization

These are mainly used in SOAP Web Services. In general terms, Authentication means validating something whereas Authorization means giving/having the right to access something.

For Example – If I have a Facebook page, then I can be treated as an authenticated user of Facebook. Whereas, if you have the right to view my photos on Facebook then you are an authorized user.

Combining these two we can say that “All authenticated users who have access to the resources are known as Authorized Users for those resources.”

The same thing happens in Web Services i.e. the user id, and password that is used to generate the token covers the authentication portion, and this token which will be used in sending a request to the webserver cover the authorization portion.

#3) Loosely Coupled Architecture

Web Services are based on Loosely Coupled Architecture. This means that the interfaces of Web Services are dynamic (changes during a given timeline) in nature. But the client logic does not necessarily have to change while interacting with the service.

This facilitates the integration of multiple software in a more efficient way. If it was a Tightly Coupled Architecture, then each time when the interface changes, the client logic has to be changed to make it synchronized with the service.

#4) Artifact

It is a term that is used in Web Services to denote information or data. This is not the whole data but a piece of information that may include a URL or URI, context key, document key, payload, or supportive images.

#5) End Point

This is a very common term that is used in every request of the web service. This is the complete URL that hits the instance of the Web Service.

For Example – https://www.facebook.com/imsaket -> this is the complete URL or endpoint which has facebook.com as the URL and “imsaket” is passed as a context key to uniquely identify a specific address.

#6) Idempotent

This is in the client-server interaction in which it does not matter how many times you hit the instance of the service, and the server will always return the same response to the client.

#7) Marshalling And Demarshalling

As we know, encapsulation is an OOPS principle that is defined as wrapping up code and data into one. The same thing happens in SOAP Web Services. When we wrap or encapsulate data into a payload (XML) to form a SOAP message and send it to the server, then this process of encapsulating is called Marshalling.

Demarshalling is just the reciprocal of Marshalling. The method of decapsulating or unwrapping data and code (XML) from the SOAP message is called “Demarshalling”.

What Is A Web Service?

As discussed earlier, Web Services are the services that serve from one machine to another over a network.

Example of Web Services: AWS (Amazon Web Services) which allows the online users to view the prices of different items sold on Amazon.com and Amazon.in

Components Of Web Services

Enlisted below are the various components of Web Services.

#1) SOAP

Web Services use the Simple Object Access Protocol (SOAP) which uses XML as a payload or request body. This is a stateful protocol as there is no independent method for the specific type of operation.

All the requests and responses are carried at once through XML and no independent methods like GET, PUT, POST or DELETE are explicitly provided.

#2) WSDL

This SOAP request makes use of Web Services Description Language (WSDL) which is a very useful component of Web Service.

This defines where the Web Service actually resides and also the type of Web Service to be picked up for a specific request. This makes use of an XML file that describes the Web Service functionality.

#3) UDDI

Another useful component is UDDI. This stands for Universal Description Discovery and Integration. There is a service provider who provides the Web Service. Hence, for a particular service provider, this UDDI is used for describing, discovering, and publishing those Web Services.

UDDI is responsible for letting a client find out (UDDI provides a repository for WSDL) where the WSDL’s XML file is located. This is how a Web Service is defined and described.


It stands for Extensible Markup Language – Remote Procedure. Another very important component of Web Service is XML – RPC which is responsible for sending messages across systems. Requests and responses are in the form of XML and are sent/received through the HTTP POST.

The best feature of XML-RPC is that a client application residing on a different platform can communicate with a different server. There is something called JSON-RPC which has been explained in the latter part of the article as it does not form a component of a Web Service.

The Architecture Of A Web Service

The architecture of a Web Service can be depicted in the following diagram.

Web Services Architecture

As we already know, a typical Web Services architecture comprises three entities i.e. a Client, a Web Server, and an Internet to carry out the operation. The operation is nothing but the request and response in a client-server architecture.

A Client is typically a set of all the applications or software systems that requests a Web Service thereby making it a Service Consumer.

A Web Server is a set of all applications or software systems that provide Web Service. Every Web Service requires a network to perform and this results in the third entity called the Internet.

This is just an overview of the architecture of a Web Service.

The working diagram of a Web Service is defined by the three components shown below.

  • Service Requestor (Find())
  • Service Provider (Publish())
  • Service Registry or Repository (Bind())

This is explained (in detail with a diagram) in the architecture of SOAP Service.

Types Of Web Services

Two types of Web Services are explained below in detail.

#1) SOAP Service

SOAP Service stands for Simple Object Access Protocol. SOAP services are stateful services that use XML language to form an envelope. A SOAP envelope can be described in two portions i.e. one is a SOAP header and body, and the other one is the protocol used to send SOAP messages.

This SOAP header consists of Authentication and Authorization which grants access. The body comes under the payload section of the request which uses WSDL to describe the Web Service and the protocol is mainly HTTP (HyperText Transmission Protocol).

Web Services Security

SOAP services have an SSL layer (Secure Socket Layer) which is responsible for avoiding any data leakage during transmission, and thus provides encryption and decryption.

Meanwhile, the SOAP services are more secure as it also has WSS (Web Services Security) which guarantees no divulging during communication between the service and the application.

As we all know, every Web Service (unlike Web API), needs a network to carry out its operation. Thus, it becomes necessary for Web Services to provide security when connected to a network. Hence, Web Services has three important entities to cover the security factor during message transfer.

  • Authentication and Authorization (Already explained above).
  • Confidentiality: This is entirely dependent on the SSL which provides encryption and decryption of the SOAP envelope.
  • Network Security: This means extracting all the SOAP and XML – RPC responses that you get from the server. For Example, If you take any Web Service tool like POSTMAN or PARASOFT, you will find that under the HTTP header manager, there is an option to set the value of the Content-Type. The value can be set to the Application/JSON so that it will extract all REST (Since SOAP services do not support HTTP Header manager options). Thus, you can pass the content-type: Application/XML in a payload itself in the form of XML. This would also extract SOAP and XML-RPC.

These three factors constitute Web Services Security to cope with the external attacks.

The Architecture Of SOAP Service

Every SOAP service depends on three entities which ultimately form the architecture of SOAP Service.

  • Service Provider: All software systems or application which is a part of or provides Web Service.
  • Service Requester: All software systems or applications which are a part of requests Web Service from Service Provider.
  • Service Registry: A registry or repository where all the information about Web Service is provided by the Service Provider. (Already discussed in UDDI)


SOAP Services Architecture

These three entities interact with each other to carry out a successful Web Service Implementation. This is done in three phases. The first phase is the Publish() phase where a Service Provider feeds all the details about a Web Service in a Service Registry or Repository.

The second phase is Find() where a Service Request mainly the client application finds the details about Web Service from a repository (also has WSDL XML file). The last phase is Binding() where the client application or the Service Requester synchronizes with the Service Provider for the final implementation of the Web Service.

#2) RESTful Service

REST stands for Representational State Transfer which is a Stateless Service.

It is called Stateless as the Web Server does not store any information about the client session (time duration till the client application is connected and in execution) which means each request type is treated and performed easily with the help of REST inbuilt methods like GET, POST, CUSTOM (PUT), DELETE, HEAD and so on.

Indeed, these methods are not present in SOAP.

Method or Verbs

Each method in REST has its significance. Given Below is the briefing about each of them.

  • GET: This method is used to retrieve the information that is sent to the server using any of the methods like PUT or POST. This does not have a request body. Successful execution will give you 200 response objects.
  • POST: This method is used to create a document or record using a request body, specified URL, document key, context key, etc. The same can be retrieved using the GET method. Successful execution will give you a 201 response.
  • PUT: This is under the CUSTOM option that is available in POSTMAN or PARASOFT. This method is used to update any document or record that is already present. Successful execution will give you a 201 or 200 response.
  • DELETE: This method is used to delete any record. Successful execution will give you a 204 response (no content).

Note: The HTTP response codes depend on how developers code and can be manipulated at times. We have listed down the common response codes that we get from each method type.

The Architecture Of REST Service

The architecture of REST service depends on two entities i.e. Service Consumer or Requestor and Service Provider. The Service Consumer is the one who avails the Web Service and Service Provider is the collection of software or system which provides the Web Service.

The client application which is typically a Service Consumer uses inbuilt methods of REST, a URL or URI, an HTTP version, and a payload (if supported by method).

REST Service Architecture


Although these two types of Web Services are used to carry out the request and response, they are entirely different in the way they operate.

Their differences are listed down for your reference.

  • SOAP envelope can be used in the REST but not vice versa. E.g. A user token that is created in SOAP can be passed in the REST request under the HTTP header manager -> Authorization.
  • SOAP is typically more secure than REST services as SOAP services provide WSS apart from SSL. This SSL is present both in SOAP and REST.
  • SOAP is slower than REST as the request processing takes more time in SOAP due to the XML data format. REST uses JSON which is very light-weighted and thus makes it faster.
  • SOAP does not have any inbuilt method but REST does have GET, PUT, POST, etc.
  • SOAP is stateful whereas REST is stateless.
  • The request and response bodies in SOAP support only the XML data format. In REST, the request and response bodies support many data formats like JSON, XML, Plain Text, etc.


This Web Services tutorial explained the architecture, components, and types of Web Services.

We also learned about the differences between SOAP and REST services, along with other important concepts and terminologies related to Web Services.

We hope that this tutorial helped you understand Web Services!!

PREV Tutorial | NEXT Tutorial