0% found this document useful (0 votes)
7 views70 pages

Web Services Computing

The document provides an overview of web services, including their architecture, operational models, and communication protocols like SOAP and REST. It explains the roles of service providers, registries, and requestors, along with the benefits and challenges of using web services. Additionally, it highlights the importance of interoperability and standard protocols in enabling different applications to communicate effectively across various platforms and languages.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views70 pages

Web Services Computing

The document provides an overview of web services, including their architecture, operational models, and communication protocols like SOAP and REST. It explains the roles of service providers, registries, and requestors, along with the benefits and challenges of using web services. Additionally, it highlights the importance of interoperability and standard protocols in enabling different applications to communicate effectively across various platforms and languages.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 70

Web services

computing
prepared by : ashish(cse.2A)
Introduction to Web Services
operational model of web services
tools and technologies enabling web
services, benefits and challenges of
using web services.

Web services Web Services Architecture Web


services Architecture and its
characteristics
computing core building blocks of web services
standards and technologies available
for implementing web services
web services communication models
basic steps of implementing web
services.
WEB
SERVICES

Web services are mode of


communication between client
and server similar to ( client
server architecture ) which
displays us the content which
we requested through
browser
Real life analogy :

Think of Web Services Like a Waiter in a Restaurant

Imagine you go to a restaurant and want to order food. The process works like
this:

1.You(Customer) – You don’t go directly to the kitchen; instead, you give your
order to the waiter.

2.Waiter(Web Service) – The waiter takes your order and passes it to the kitchen
(the service provider).

3.Kitchen (Server) – The kitchen prepares the food and gives it back to the waiter.

4.Waiter (Web Service) – The waiter brings your food back to you.

In this example
Web service
Why Do We Need Web Some Socializing
Services? Applications :
• To
allow different apps or systems to
share data and functionality.

• Example: Mobile apps use web


services to show weather, news, or
book a cab.

• Web services help apps “talk” even


if they are built using different
technologies.

• For example : SOCIAL MEDIA


Online Payments (PayPal, Google Pay)
When you pay online, the website connects to a payment web service
When you make an online payment, the website connects to a payment
gateway web service.
the service processes the payment and sends back the response (Success
or Failure)

(Facebook, Instagram, Twitter)


When you log in using Google, it uses a web service for authentication.

Google Maps & Uber/Ola


Uber and Ola use Google Maps Web Service to calculate fares and show routes.
Types of Web Services

1. SOAP (Simple Object Access Protocol)

2. REST (Representational State Transfer) or Rest.Ful

and XML-RPC and JSON-RPC formats


SOAP ( simple object access protocol)
SOAP is a protocol designed to enable communication between applications
over the internet. It strictly uses XML for message format. SOAP messages are
sent via HTTP, SMTP, or other internet protocols.

🔸 Structure of a SOAP Message:

A SOAP message is an XML document with 4 main parts:

1.Envelope – wraps the entire message.

2.Header – optional info like authentication, security.

3.Body – actual data or function being sent.

4.Fault – used to show error messages.


How SOAP Works
(Step-by-Step): Imagine this scene:
Example: A Weather App
1.You Ask a Question (SOAP Request):
The app wants to know the weather in Delhi. It creates a SOAP message in XML format with the
question.

Packing the Message (XML Format):


The message is written in a structured way using XML.
Example: <soap:envelope>
<soap:body>
<getweather>
<city>delhi</city>
</getweather>
</soap:body>
</soap:envelope>
• Sending the Message:
This SOAP message is sent over
the internet (usually using HTTP).
• Server Reads and Answers
(SOAP Response):
The server receives the request
and replies in XML.
Example:

<soap:Envelope>
<soap:Body> • App Shows the Answer:
<GetWeatherResponse> The app reads the
<Temperature>34 degrees
Celsius</Temperature> response and shows:
"Today in Delhi: 34
<Condition>Sunny</Condition>
</GetWeatherResponse> degrees Celsius, Sunny.
</soap:Body>
</soap:Envelope>
SOAP is Used:

Advantages of SOAP: • Banking apps – to send secure money transfer


requests.
• Hospital systems – for sharing patient details.
• Strict
Standards – Ideal for
• Government portals – where data safety is very
regulated environments (finance, important.
healthcare).

• Built-in
Error Handling – via the Real-World Applications:
Fault section.
• Bank APIs – Transferring money securely
• Extensibility
– Supports security, between banks (NEFT, IMPS APIs).
transactions, and messaging • eBay & PayPal – Their older APIs use SOAP.
patterns.
• Healthcare – Patient data exchange
• Language Independent – Works between hospital systems.
with Java, .NET, Python, etc. • B2B Communications – Between large
companies’ internal software.
(Representational State Transfer)

. REST (Representational State Transfer)


What is REST?
REST is an architecture style that makes
communication over the internet
simple and fast using standard URLs and
HTTP methods like GET, POST, PUT,
DELETE.
It’s like ordering food online – you
select from a menu (URL), choose what
to do (GET = see menu, POST = order,
DELETE = cancel order).
Key Concepts of REST: Features:

• Stateless – Every request is separate. Server does not remember old


• Everything
is a resource (user,
requests.
photo, product).
• Lightweight and fast – Works well on mobile and web.
• Each resource is identified by a
URL (like • Easy to test using Postman, browser, or curl.
www.site.com/product/1).
• Widely used in cloud and mobile app development.
• Uses standard HTTP actions: Advantages:
• GET – To read data
• Easy to understand and implement.
• POST – To create data
• Works fast even on slow networks.
• PUT – To update data
• Supports many formats (JSON, XML).
• DELETE – To remove data
• Easy to cache, improving performance.
Formats Supported:
Disadvantages:
• Mostly JSON
• Not suitable for very complex operations (like banking transactions).
• Also
supports XML, HTML, and • Less security features than SOAP (relies on HTTPS).
plain text
(JavaScript Object Notation)

JSON is a lightweight and easy way to store and exchange data.

Think of JSON as a digital way of writing down information, like how we write in
notebooks using keys (name) and values (data).

It is mainly used for sending data between a server and a web browser or mobile
app.

JSON Is Popular:
• It is easy to read and write for humans. It is easy to understand and process by computers.
It is used everywhere — in websites, apps, games, APIs, IoT, and more.
An example :

Imagine you’re ordering food online.


You select a burger, Coke, and fries.
That data (your order) goes from your
phone to the restaurant’s server in a
structured way.
JSON is the language used to send
that structured food order.
{

"order_id": 456,

"customer_name": "Aman",

"items": ["Burger", "Coke", "Fries"],

"total_price": 299

}
How JSON Works (Step by Step)

1. A webpage/app sends a
request to a server.

2. Server fetches the data from a


database.

3. Server sends that data in JSON


format back to the browser.

4. The browser reads and shows


the data to the user.
basic operational model of
web services

The basic operational


model of web services
describes how web
services work — how they
are published, found, and
used. It mainly involves
three roles and three basic
operations.
It defines how web services function
and interact with client and servers.
They describe the architecture and
communication style between
different systems.
• Operational models and standard protocols in web services are closely related but not
the same.

Operational models define how web services work and interact (the architecture and
communication style).

• Standard protocols define the rules and formats used for communication (the technical
methods for data exchange).

Think of a courier service:


The operational model is how the courier company operates
(home delivery, pickup points, express delivery, etc.).
The standard protocol is the set of rules they follow (packaging
standards, tracking systems, delivery methods).
Service provider
A Service Provider is the one that creates, hosts, and offers a web service for others to use. It
provides the actual functionality that other applications (Service Requestors) need.

What Does a Service Provider Do?

1.Creates the Web Service


1. The service provider develops and maintains the service.
2. It ensures that the service is always available and functioning correctly.

2.Publishes the Service in a Registry


1. It registers the service in a directory (Service Registry) so that other applications can find it.

3.Handles Requests from Users (Service Requestors)


1. When an app needs data or functionality, it sends a request to the service provider.
2. The service provider processes the request and sends back the required data.

Ex. Google Maps API (Mapping Service), weather upi, youtube upi ( that create web services )
Service registry
Service Registry (Where Are Services Listed)
A Service Registry is like Pages directory ( khata ) where businesses (services) are listed so
that people can find them. It stores and organizes information about available web
services.
How It Works?
1.The Service Provider registers its service in the registry.
2.The Service Requestor searches for a service in the registry.
3.The registry shows a list of available services, and the requestor can choose one.
Real-Life Example: Google Play Store,Zomato,github,aws
• The Google Play Store (Service Registry) lists all available mobile apps.
• If you need a food delivery app, you search for it in the Play Store.
Service requestor
Service Requestor (Who Needs the Service)

A Service Requestor is like a customer who wants to buy a product or use a service. It searches for a
web service, connects to it, and starts using it.

How It Works?

1. The Service Requestor searches for a needed service in the registry.

2. It finds the right service and connects with the provider.

3. The Service Provider sends back the required data, and the requestor uses it.

Real-Life Example: Uber (Service Requestor)

• Uber’s app (Service Requestor) needs location services to track drivers and customers.

• It searches for a mapping service and finds Google Maps API.

• Uber connects to Google Maps and gets live location data.

• Uber displays the map to the user.


tools and technologies enabling web services,
Communication Protocols
• HTTP/HTTPS – Core protocol for data exchange.
• SOAP (Simple Object Access Protocol) – XML-based protocol.
• REST (Representational State Transfer) – Lightweight, uses HTTP methods (GET, POST...).
Data Formats

• XML – Used in SOAP.


• JSON – Lightweight, used in REST.
Service Description Language

• WSDL (Web Services Description Language) – Describes SOAP services.

• OpenAPI/Swagger – For REST APIs.

Service Discovery
• UDDI (Universal Description, Discovery, and Integration) – Registry system.
benefits of using web services

• Platform Independent
• Java, Python, PHP apps can all talk using web services.
• Language Independent
• Data is exchanged using common formats (JSON/XML).
• Reusability
• Once built, the service can be reused across apps.
• Modularity
• Easy to break complex apps into microservices.
• Scalability
• Easily scale services as per usage demand.
• Interoperability
• A .NET app can call a Java service seamlessly.
• Low Cost and Time
• Speeds up development with ready-made APIs.
⚠️ 6. Challenges in Using Web Services
Security Concerns
Data sent over networks can be hacked if not encrypted (need HTTPS, OAuth).
Performance Issues
High response time in large services or due to network latency.
Versioning and Compatibility
Changing API structure can break client systems.
Dependency
Third-party services may go down or become paid.
Complex Error Handling
Managing faults in SOAP can be tricky; REST is easier.
Testing Complexity
Testing distributed systems is more difficult than standalone apps.
What Is Web Services Architecture?

Web Services Architecture describes how components of web services


interact to allow communication and data exchange over a network. It
consists of several layers and components that define the structure of a
web service system.
web services
architecture
uses standard rules and
technologies that allow different
software applications to
communicate, even if they are
built on different platforms
(windows, linux, macos,
android, ios) or use different
programming languages (java,
python, c++, javascript, php,
etc.).
ACTUAL WORKING
ACTUAL
( WHOLE WORKING
PROCESS AND ARCHITECTURE )AND
How Web Services Handle Different Platforms
& Languages?

Common Standards That Web Services Use Example:


1.HTTP(HyperText Transfer Protocol) – The language • A Windows-based bank system
that web browsers and servers use to talk to each (written in Python) can send
other. account details to an Android
banking app (written in Java)
2.JSON (JavaScript Object Notation) – A lightweight using a web service API.
data format that all programming languages
understand. • The web service converts the data into
JSON format, which both systems can
3.SOAP& REST APIs – Methods used to exchange understand.
data between applications.
Key Characteristics of web
services

Interoperability Platform and


Loosely Standardized Reusablilty Language
coupled Protocols Independent
Architecture
1. Interoperability –
Web services enable applications built on different
platforms to communicate with each other.

2. Platform & Language Independence – They can be developed in


one language (e.g., Java) and accessed by another (e.g., Python)

• Web services are designed to work across different platforms (Windows,


Linux, Mac, etc.) and programming languages (Java, Python, C++, etc.). This
is possible because they use standard communication formats like XML,
JSON, and HTTP protocols.
Similarly, a Java-based web service can send data to a Python-based
application because they both understand XML or JSON formats, just like
people understand common languages in emails.
• Thus, web services allow different applications on different platforms to
communicate seamlessly.
Loosely Coupled
Architecture

• Web services follow a loosely coupled architecture, meaning the client


(consumer) and server (provider) are independent of each other. They
can evolve separately without directly affecting one another, as long as
they follow standard communication protocols (like HTTP, SOAP, REST,
etc.).
Imagine you are shopping online on • Do you need to worry if
Amazon: your supplier changes their
warehouse or shipping
method, as long as your
You (Client) – You browse products and order still arrives on time?
Similarly, in web services, the
place an order.
client only sends a request and
receives a response without
Amazon (Web Service) – Amazon
worrying about the internal
receives your order and processes it.
implementation of the service.
This flexibility makes web services
Seller (Server/Backend System) – The
scalable and adaptable to
product is shipped from the seller’s
changes.
warehouse
Reusability
Web services are reusable because once they are created, they can be
used by multiple applications without needing to be rewritten. Instead of
developing the same functionality again and again, different systems can
reuse an existing web service

Instead of each • This saves


Suppose a bank, one creating its
an e-commerce
time, effort,
own system,
website, and a and
they all use the That is a :
travel agency all same currency
resources, A Currency
need a currency conversion web making the Converter
conversion service to get system
feature real-time efficient and
exchange rates scalable.
Standardized Protocols
• Standard Protocols are the rules and formats used to transmit data
between systems. They define how communication happens in web
services.

SOAP (Simple Object Access Protocol)


REST (Representational State Transfer)

XML-RPC (XML Remote Procedure Call)


JSON-RPC (JavaScript Object Notation Remote Procedure Call)
gRPC (Google Remote Procedure Call)
Core Building Blocks of
Web Services
There are 8 key building
blocks that form the
foundation of Web
Services:
(eXtensible Markup Language)
XML is a markup language designed to store and transport data. It doesn't do
anything on its own, but it helps structure data so machines and systems can
understand and share it easily.
Key Features :
• Self-descriptive tags (like <name> or <price>)
• Platform & programming language independent
• Used to encode the request and response messages between services
Why XML in Web Services?
Web services need a way to send data between different systems (maybe Java on
one side and Python on the other). XML acts as the bridge that both systems can
read and understand.
Xml format :

<student>
<id>101</id>
<name>Aman</name>
<course>Computer Science</course>
</student>
This XML can be shared between any systems – web,
mobile, desktop – and it will be understood by all.
SOAP (Simple Object Access Protocol)
🔧 Role: A protocol for sending and receiving messages over the internet

Features:

• XML-based

• Platform & language independent

• Works over HTTP, SMTP, etc.

🧠 Real-life Use:

• Used by banking systems to securely exchange transaction data between servers.


(Web Services Description
Language)
Role of WSDL in the previous one diagram Diagram:
• WSDL Doc (Pink Paper Icon):
• Published by the Service Provider to the Service Directory.
• Returned by the Service Directory to the Service Requestor.
• Contains:
• Service name
• Methods available
• Input/Output formats
• URL to access the service
• Protocols used (e.g., SOAP)
Main Components of WSDL (Explained Simply):
Component Meaning in Simple Language
Defines what kind of data will be used
Types
(e.g., string, number, date).
Defines the data sent/received (like the
Messages
ingredients in a recipe).
Defines the functions/methods the
PortType
service has (like options on a menu).
Tells how to access the service (via
Binding
HTTP, SOAP, etc.).
Gives the actual location (URL) of the
Service
service.
Combines the binding and address
Port
(specific access point to the service).
Features of WSDL:
Examples of
WSDL Use:
XML-based (easy to parse and App WSDL Use
readable)
Online Result Fetch student marks via a
• Platform-independent (works WSDL-described API
Portal
with Java, Python, .NET, etc.)

• Canbe auto-read by tools like Bank Payment Secure money transfer


Postman, SoapUI, Eclipse Gateway functions defined in WSDL

• Supports both SOAP and HTTP

• Publicly
accessible by Get flight details using WSDL-
Airline Website defined web services
consumers

Access product data, shipping


E-commerce Site APIs using WSDL
(Universal Description,
Discovery, and Integration)
UDDI is a platform-independent registry system for web services.
It allows businesses to list, discover, and integrate web services on the
internet.

• Think of UDDI like an online directory or phonebook for web services.

Purpose of UDDI:
• To publish web services (like a company registering on JustDial).

• To allow other applications or developers to discover those services.

• To connect service providers with consumers without human interaction.


UDDI working
1.UDDI Registry
1. Think of this like a "Yellow Pages" or Search Engine for
web services.
2. It stores the details of available services (name,
description, WSDL link, etc.).
3. It doesn’t store the actual services — just info about
them.

2.Service Bus
1. A communication channel or medium where web
services (like payment, weather, hotel booking APIs)
are available.
2. Has two key service types:
1. Proxy Services
2. Business Services
How Does UDDI Work? Publish
1. Companies register (publish) their web services in the UDDI
registry.
2. Example: OYO uploads details of its hotel booking API.

1.Find (Browse)
1. Users (like app developers) search the UDDI registry to find
services they need.
2. Example: You search “hotel booking service” in UDDI.

2.Use (Import)
1. You get the WSDL link of the service.
2. Then, you import it and use it in your app.
3. Example: You use OYO’s API in your travel app to show hotel
availability.
Examples of UDDI
Government Portals (DigiLocker, 3. Banking Apps (Paytm,
Aadhaar, eGov) PhonePe)
What happens: What happens:
Need to connect with many banks
• These
portals connect to services like and UPI services.
Aadhaar verification, PAN card check, etc.
Example:
Example: Paytm finds “HDFC Bank UPI API” via
UDDI → Imports WSDL → Allows you
• DigiLockerfinds and uses UIDAI (Aadhaar) to send money.
service via UDDI → Verifies Aadhaar
number. Example:
Finds “PNB Balance Check API” →
Example: Integrates in app → User can check
• ImportsIncome Tax PAN API → Verifies bank balance
user’s PAN card.
web services
communication models
Web services need to
exchange information
between clients and servers
over a network. The way they
communicate and interact is
called a communication
model.
These models define:
• How data is sent
• Who sends first
• Who waits for reply
• When data is exchanged
Types of Web Services
Communication Models
Request-Response Model (Synchronous Communication)
Synchronous communication means the client sends a request to the web service and then waits until
the response comes back from the server.

Both parties (client & server) must be online and active at the same time.
🏧 Example : ATM Machine
• You insert your card and
ow It Works : check balance.
• ATM sends request to the
1. Client sends a request (like a question). bank server.
• Waits for response (your
2. Server receives it and processes it.
balance info).
3. Server sends back the response (like an answer). • Then displays it on the
scree
4. Client waits during this whole process.

• 🧠 Think of it like a phone call – you ask something and wait for the other person to reply.
Technologies That Support Synchronous
Communication
Role in Synchronous
Technology / Protocol
Communication
Basic communication
HTTP/HTTPS
protocol (web)
Secure and reliable XML
SOAP
messaging
Simple and fast data
REST API
exchange using JSON
High-performance sync calls
gRPC
(Google)
One-Way Message Model
(Asynchronous Communication)
One-Way Message Model (Asynchronous Communication) – Detailed
Explanation

What is the One-Way Message Model?

The One-Way Message Model refers to a communication method where a


message is sent from the sender to the receiver, but there is no immediate
response or feedback from the receiver. In this model, the sender does not
wait for an acknowledgment or reply from the receiver, and the
communication continues without any direct interaction.

In simple terms:

• Sender sends a message.

• Receiver gets the message, but does not immediately reply.


What is Asynchronous
Communication?
Asynchronous communication is a
type of communication where
messages are sent without requiring
the sender to wait for a response or
for the receiver to be online at the
same time.
In asynchronous systems, the
sender and receiver do not need
to interact in real time. The sender
can send a message at any time,
and the receiver can read and
respond to it later.
• Receiver: The person reads
the email whenever they want.
You don’t expect an immediate
reply.
2. Social Media Posts:
• Sender: You post a message
or picture on social media.
• Receiver: Followers see your
post at their convenience and
can respond later. No real-time
interaction is required.
3. Push Notifications:
• A company sends push
notifications to users. The users
Callback Model /
Server Push
Normally, in web communication:
• The client (browser) sends a
request to the server.
• Server Push (or
Callback Model) is a • The server sends back a response.
way for the server to • If the client wants new updates, it
must send another request.
send updates or
responses to the • 📦 Example: You are waiting for a
parcel. You keep calling the
client without the delivery person again and again
client asking again to ask, “Has my parcel arrived?”
and again. That’s the normal (client pull)
model.
What is Server
Push
How Server
In Server Push, the server itself sends data Real-life App
to the client whenever something new
Push Works
happens — without the client asking
repeatedly.
New messages
Chat Apps (e.g.,
appear instantly
For Example: You are waiting for a parcel. WhatsApp Web)
without refreshing.
• Instead
of calling the delivery person
again and again…
Scores update live
Live Score
without pressing
• The delivery person calls you (callback) or
Websites
reload.
sends you a notification when the parcel is
about to arrive. Prices change in
Stock Market Apps
That’s Server Push.
real time.
Pub/sub model
1.Publishers send messages to a specific Topic
(not to a specific subscriber).
2.Broker receives the message and checks which
Subscribers are subscribed to that topic.
3.The Broker delivers a copy of the message to
each Subscriber.
Think of it like a YouTube Channel:
• You (Subscriber) subscribe to a channel (Topic).
• The creator (Publisher) uploads a new video
(Message).
• You get notified by YouTube (Broker) and can
Applications of Pub/Sub
For example :
• Chat applications (real-time messaging)
• Notification systems
• Real-time analytics
News App: • IoT (Internet of Things) devices
• Online multiplayer gaming
• Topic = "Breaking News" • Log and event processing

• Publisher = News agency ⚠️ Challenges

• Message ordering may not be


• Subscriber= User subscribed guaranteed.
to "Breaking News"
• Need proper message delivery
handling (e.g., retries, duplicate
• Broker = Notification service messages).

• Subscribers must handle load properly


to avoid data loss.
Basic Steps to Implement Web Services
We’ll go step-by-step with simple explanations.
1. Choose a Web Service Type

There are mainly two types of web services:


Type Description Data Format

SOAP Uses XML. Strict structure. XML

Uses URLs and standard


REST JSON / XML
HTTP.
2. Set Up the Environment

To create and test web services, you need:


Languages/Frameworks:
• Java (Spring Boot)
• Python (Flask/Django)
• Node.js (Express)
• PHP, .NET, etc.

Tools:
• Postman – to test APIs
• VS Code / IntelliJ – code editors
• Browser / Terminal – for testing

Choose language + framework that you’re comfortable with.


3. Design the Web Service
Decide what your service will do.

Example: A student service that gives student info.


Design:

• URL Endpoint /students


• Method: GET
• Response: { "name": "Rahul", "age": 20 }
RESTful Web
Services
Method
use: Purpose
GET Read data
POST Create data
PUT Update data
DELETE Delete data
4th. Writing a code
5. Test the Web Service

Use tools like


:

• Browser: Just go to the URL (for GET)


• Postman: You can test all methods (GET, POST, etc.)

curl
• Curl (in Terminal
http://localhost:5000/student
6. Connect with Database (Optional)

If your data is dynamic, you can connect


with databases like:
• MySQL
• MongoDB
• PostgreSQL
7. Deploy Your Web Service

After testing, you can deploy your


web service to a cloud server so
others can access it online.
Popular platforms:

• Heroku
• Render
• AWS
• Azure
• Google Cloud
Example: Your local service → localhost:5000
Deployed version → https://myapp.onrender.com/student
9. Document the API

To make it easy for others to use your service.


Use:
•Swagger/OpenAPI
•Provide sample URLs, input/output format.
Example:

Endpoint Method Description


/student GET Get student info
/student/<id> GET Get by ID
Conclusion :
What We have Learned :
This presentation showed that web services are a way
for applications to communicate. We learned they use
standard methods (like HTTP) and formats (like
XML/JSON) to share data, and that SOAP and REST
are the main ways web services are built.
• We learned that web services are important for allowing different
applications to work together. We saw that they use common standards
to send and receive information, and that this helps make applications
reusable and able to work across different systems
.
Thanks !

You might also like