Cloud Architecture and Services

CCA2002

Module 2
 ⚫ Cloud Services: Web Service Architecture – Web Service APIs –
Web service Authentication - Web service authentication methods
- Technologies and the processes required when deploying web
services; Deploying a web service from inside and outside a cloud
architecture, advantages and disadvantages.

⚫ Service Oriented Architecture: Introduction, Characteristics,

Primitive SOA vs Contemporary SOA, Comparing SOA to client-
server and distributed internet architectures, Anatomy of SOA

2
 Web Service Architecture
⚫ Web service architecture is a structured approach to designing
and building web services, which are systems that allow
applications to communicate over a network using standard
protocols like HTTP.

⚫ Web services enable different software applications to interact

with each other, often independent of programming languages,
platforms, or devices.

3
Core components of Web Service Architecture
⚫ 1. Service Provider
The service provider hosts the web service and provides the functionality to be
accessed remotely. It defines the service description and makes the service
available to clients.
Key role: Provides the actual service, including resources or business logic.

⚫ 2. Service Consumer (Client)

The client, or consumer, is the entity that calls or uses the web service. It sends
a request to the service provider and processes the response.
Key role: Requests and consumes the service.

⚫ 3. Service Registry (Optional)

A registry, such as Universal Description, Discovery, and Integration (UDDI),
can be used to publish and discover web services.
Key role: Acts as a directory for service descriptions that clients can use to
discover services.
4
Core components of Web Service Architecture
⚫ Communication Protocols
The interaction between the service provider and consumer happens over a
network using standard communication protocols like HTTP or HTTPS.
Key role: Facilitates communication between distributed components over
the internet or an intranet.
⚫ 5. Service Description (WSDL for SOAP, or OpenAPI/Swagger
for REST)
The service description contains the details of how to use the web service.
For example, in a SOAP web service, the service is described using Web
Services Description Language (WSDL), and in RESTful services, it might be
described using OpenAPI or Swagger documentation.
Key role: Provides a contract or interface between the provider and
consumer.
5
Core components of Web Service Architecture

6
Web Service
⚫ A web service is a software system that enables machine-to-
machine communication over a network.

⚫ It allows applications to interact with each other, typically using

standard web protocols like HTTP or HTTPS.

⚫ Web services provide a way for different systems to exchange data

and perform functions, often across different platforms,
programming languages, or devices.

7
Key features of Web Service

• Interoperability: Web services are designed to allow different

systems to work together, regardless of the technologies they use.

• Standard Protocols: Web services use standard

communication protocols such as HTTP, HTTPS, SOAP (Simple
Object Access Protocol), and REST (Representational State
Transfer).

• XML/JSON: Data is typically exchanged using structured

formats like XML (for SOAP) or JSON (for RESTful services).

8
Key features of Web Service

• Platform Independence: Web services can work across

various platforms (e.g., Windows, Linux, macOS) and
programming languages (e.g., Java, Python, C#).

• Network Accessibility: Web services are accessed over a

network (e.g., the internet or an internal network), making them
highly scalable and accessible from anywhere.

9
Types of Web Service
1. SOAP (Simple Object Access Protocol)
• A protocol-based web service that uses XML for communication.
SOAP is highly structured and supports standards like security,
transactions, and reliable messaging.

• Advantages:
• Stronger security standards (e.g.,WS-Security)
• Reliability and transaction support

• Disadvantages:
• Heavier and more complex
• Slower due to extensive XML processing
10
Types of Web Service
2. REST (Representational State Transfer)
1. REST is an architectural style, not a protocol, and it typically uses
HTTP methods (GET, POST, PUT, DELETE) to operate on resources
represented by URLs.

2. Advantages:
1. Lightweight and easy to implement
2. Scalability and performance

3. Disadvantages:
1. Stateless nature may require additional logic for managing sessions
2. Less formal structure for contracts compared to SOAP
11
Web Service Authentication
Web service authentication refers to the process of verifying the
identity of users or systems before they can access a web service.

Authentication is critical for securing web services and ensuring that

only authorized users or systems can interact with them.

Dependingon the type of web service (SOAP or REST), different

authentication mechanisms can be implemented.

12
Web Service Authentication Methods
⚫ 1. HTTP Basic Authentication
How it works:The client sends the username and password encoded
in Base64 as part of the HTTP request header (using the
"Authorization" header).
Example:

⚫ Advantages:
• Simple to implement.
⚫ Disadvantages:
• Username and password are transmitted with every request, even though encoded,
not encrypted.
• Should always be used over HTTPS to prevent credentials from being exposed.

13
Web Service Authentication Methods
⚫ OAuth (Open Authorization)
• How it works: OAuth is a token-based authentication protocol that
allows third-party services to access resources without exposing user
credentials. OAuth 2.0 is the most widely used version.
• The user authenticates with an authorization server, which issues an
access token.
• The client includes the access token in the Authorization header with
every request to the web service.

14
Web Service Authentication Methods
Advantages:
• Secure and scalable.
• Does not require sharing credentials with the client.
• Can grant limited access (scope-based) to services.

Disadvantages:
• More complex to implement compared to Basic or API key
authentication.

15
Web Service Authentication Methods
API Key Authentication
How it works:The service provider issues an API key to the client,
which must be included in the request header or URL query
parameters.

• Advantages:
• Simple to implement.

16
Web Service Authentication Methods
• Disadvantages:

• Less secure than other methods because API keys can be easily
shared or leaked.

17
Web Service Authentication Methods
⚫ SAML (Security Assertion Markup Language)
• How it works: SAML is an XML-based standard used for exchanging
authentication and authorization data between a service provider and an
identity provider (typically in Single Sign-On (SSO) scenarios).
• The service provider trusts the identity provider to authenticate users.
• Once authenticated, the identity provider sends an assertion to the service
provider.
• Advantages:
• Suitable for enterprise-level services.
• Can be used for SSO.
• Disadvantages:
• Heavy XML-based format.
• More complex to implement than OAuth or JWT.
18
Web Service Authentication Methods
⚫ Digest Authentication
• How it works: Digest authentication is more secure than basic
authentication. Instead of sending plain credentials, it sends a hashed
version of the username and password.
• Advantages:
• Credentials are not sent in plain text.
• Disadvantages:
• More complex to implement than basic authentication.
• Still vulnerable to man-in-the-middle attacks if not used over HTTPS.

19
Key Technologies for Deploying Web Services
⚫ 1.Web Server
• Examples: Apache HTTP Server, Nginx, Microsoft IIS
• Purpose: A web server handles HTTP requests from clients and
routes them to the appropriate web service.
• Role: Serves as the entry point for web service requests and can be
configured to handle SSL (HTTPS), load balancing, and redirection.

⚫ 2. Application Server
• Examples: Tomcat, Jetty, JBoss,WebSphere
• Purpose: Hosts the web service’s business logic. An application
server is where your web service runs.
• Role: Executes code, manages the lifecycle of service requests, and
communicates with databases or other services.
20
Key Technologies for Deploying Web Services
⚫ 3. Database
• Examples: MySQL, PostgreSQL, MongoDB, Redis
• Purpose: Stores and manages the data consumed or produced by the web
service.
• Role: Ensures data persistence, supports queries, and allows for efficient
storage and retrieval of information.

⚫ 4. API Gateway
• Examples: Kong, AWS API Gateway, NGINX, Apigee
• Purpose: An API gateway manages API requests from clients, often acting
as a reverse proxy.
• Role: Provides rate limiting, security (authentication, authorization),
routing, and caching. It also serves as a central entry point for API calls.
21
Key Technologies for Deploying Web Services
⚫ 5. Containerization Platforms
• Examples: Docker, Kubernetes
• Purpose: Containerization allows you to package your web service along
with its dependencies, ensuring it runs consistently across environments.
• Role: Containers make it easy to deploy web services to various
environments (local, testing, production) and offer scalability.
• Kubernetes is often used to orchestrate containerized applications, manage
scaling, and handle load balancing.

⚫ 6. Load Balancer
• Examples: HAProxy, AWS Elastic Load Balancer (ELB), NGINX
• Purpose: Distributes incoming requests across multiple servers or
instances of a web service.
• Role: Ensures high availability, fault tolerance, and load distribution to
22 improve performance and handle traffic spikes.
Key Technologies for Deploying Web Services
⚫ 7. CI/CD Pipeline Tools
• Examples: Jenkins, GitLab CI, CircleCI,Travis CI
• Purpose: Continuous Integration and Continuous Deployment (CI/CD)
pipelines automate the process of building, testing, and deploying web
services.
• Role: Ensures that changes made by developers are integrated and
deployed quickly, with minimal manual intervention.

⚫ 8. Cloud Platforms
• Examples: AWS (Amazon Web Services), Microsoft Azure, Google Cloud
Platform (GCP)
• Purpose: Cloud platforms provide infrastructure as a service (IaaS) and
platform as a service (PaaS) for deploying web services.
• Role: Cloud services can host your web service, manage scaling, and
handle networking and security.They also offer managed databases, load
balancers, and serverless architectures.
23
Key Technologies for Deploying Web Services
⚫ 9. Security Technologies
• Examples: OAuth, JWT, SSL/TLS, Firewall, IAM (Identity and Access
Management)
• Purpose: Secures the web service from unauthorized access and attacks.
• Role: Implements authentication, authorization, encryption, and access
control measures to protect sensitive data and ensure secure
communication.

⚫ 10. Monitoring and Logging Tools

• Examples: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash,
Kibana), Datadog
• Purpose: Monitoring tools track the performance, health, and security of
the deployed web service.
• Role: Ensures system uptime, provides alerts on performance issues, and
logs data for analysis and debugging.
24
Key Processes Involved in Deploying Web Services:
⚫ 1. Development
• Technology: Integrated Development Environment (IDE),Version
Control (Git, GitHub, GitLab)
• Process:
• Writing code for the web service using frameworks such as Spring Boot
(Java), Flask (Python), Express (Node.js).
• Version control to manage code changes and collaborate with teams.

⚫ 2.Testing
• Technology:Testing frameworks (JUnit, Mocha, Postman), CI/CD
Pipeline Tools
• Process:
• Unit Testing:Testing individual components of the web service to ensure they
behave as expected.
• Integration Testing: Ensures that different parts of the web service work
together.
• API Testing:Validates the input/output and behavior of the web service’s API
25 endpoints.
Key Processes Involved in Deploying Web Services:
⚫ 3. Containerization & Packaging
• Technology: Docker, Docker Compose, Kubernetes (for
orchestration)
• Process:
• Packaging the application into containers to isolate dependencies.
• Using container orchestration tools like Kubernetes to manage scaling,
load balancing, and fault tolerance.
⚫ 4. Continuous Integration (CI)
• Technology: Jenkins, GitLab CI, CircleCI
• Process:
• Automating the build process to compile the web service.
• Running automated tests on every code change to ensure the stability
of the service.
26
Key Processes Involved in Deploying Web Services:
⚫ 5. Continuous Deployment (CD)
• Technology: Jenkins, AWS CodeDeploy, GitLab CI
• Process:
• Automatically deploying the web service to a production or staging
environment after it passes all tests.
• Managing blue/green or rolling deployments to avoid downtime.
⚫ 6. Deployment to Cloud
• Technology: AWS, Microsoft Azure, Google Cloud, DigitalOcean
• Process:
• Setting up infrastructure (e.g., virtual machines, databases, and
networking) in the cloud.
• Deploying the web service to cloud platforms or using PaaS (Platform
as a Service) like AWS Lambda (for serverless architecture) or Azure
App Services.
27
Key Processes Involved in Deploying Web Services:
⚫ 7. Load Balancing and Scaling
• Technology: HAProxy, AWS ELB, Kubernetes
• Process:
• Configuring load balancers to distribute incoming traffic across multiple
instances of the web service.
• Configuring auto-scaling to add/remove instances based on traffic and
resource usage.
⚫ 8. Monitoring and Logging
• Technology: Prometheus, Grafana, ELK Stack, Datadog
• Process:
• Setting up performance metrics monitoring for server and service health.
• Implementing logging for troubleshooting and debugging issues in
production.
• Configuring alert systems for failures or anomalies in service behavior.
28
Key Processes Involved in Deploying Web Services:
⚫ 9. Security
• Technology: SSL/TLS, OAuth2, Firewalls, IAM (Identity Access
Management)
• Process:
• Implementing SSL/TLS for encrypted communication.
• Configuring OAuth, JWT, or API key-based authentication.
• Setting up firewalls, secure access policies, and role-based access
control (RBAC).
⚫ 10. Backup and Disaster Recovery
• Technology: Cloud-native backup solutions, Database replication
tools
• Process:
• Configuring automated backups of databases and critical services.
• Planning and testing disaster recovery strategies for system failures.
29
Summary of the Web Service Deployment Process:
• Development:Write and manage the code for the web service.
• Testing: Run tests to ensure that the service is functional and error-free.
• Containerization: Package the service in a container for consistent
deployment.
• CI/CD Pipeline: Automate building, testing, and deploying the service.
• Deployment: Deploy to a cloud or on-premises infrastructure.
• Load Balancing and Scaling: Ensure the service can handle traffic and
scale as needed.
• Security: Implement robust security measures for authentication,
encryption, and access control.
• Monitoring: Continuously monitor the service’s health and performance.
• Backup & Recovery: Prepare for disaster recovery and ensure data
integrity.

30
Deploying a Web Service Inside a Cloud Architecture
Cloud architecture refers to deploying and managing services on cloud
infrastructure such as AWS, Microsoft Azure, Google Cloud Platform (GCP), or
others. Cloud environments provide on-demand resources, flexibility, scalability,
and automation, making deployment faster and easier.

⚫ Key Steps and Technologies for Cloud Deployment:

⚫ a. Infrastructure Setup
• Infrastructure as a Service (IaaS): You can create virtual machines (VMs) or
containers for hosting your web service.
• Platform as a Service (PaaS): Platforms like AWS Elastic Beanstalk, Azure
App Services, or Google App Engine handle the infrastructure management,
allowing developers to focus solely on code.
• Serverless Architecture: You can deploy services without worrying about
server management using serverless computing platforms like AWS Lambda,
Azure Functions, or GCP Cloud Functions.
31
Deploying a Web Service Inside a Cloud Architecture
⚫ b. Deployment Process
1. Development:
1. Develop your web service using programming languages like Java, Python,
Node.js, or others.
2. Containerization:
1. Use Docker to containerize the web service for a consistent environment
across development, testing, and production.
2. Use Kubernetes or managed services like AWS EKS (Elastic Kubernetes
Service), GCP GKE (Google Kubernetes Engine) to orchestrate the containers.
3. Infrastructure as Code (IaC):
1. Use IaC tools like Terraform, AWS CloudFormation, or Azure Resource
Manager (ARM) templates to define and provision infrastructure
automatically.
2. Automates the deployment of servers, networking, databases, and other
services.
32
Deploying a Web Service Inside a Cloud Architecture
4. CI/CD Pipeline:
• Implement CI/CD pipelines using Jenkins, GitLab CI, or AWS CodePipeline to
automate testing and deployment.

5. Security Configuration:
• Set up IAM (Identity and Access Management) for role-based access.
• Configure SSL/TLS certificates for secure communication using cloud services like
AWS Certificate Manager or Let’s Encrypt.
• Implement OAuth, JWT, or API keys for securing APIs.

6. Auto Scaling and Load Balancing:

• Use Auto Scaling Groups (AWS) or Azure Virtual Machine Scale Sets to
automatically scale your service based on traffic.

• Deploy a Load Balancer (e.g., AWS Elastic Load Balancer, Azure Load Balancer, GCP
Load Balancer) to distribute traffic across instances
33
Deploying a Web Service Inside a Cloud Architecture
7. Database and Storage:
• Use managed databases like Amazon RDS, Azure SQL Database, or Google
Cloud SQL for relational data.
• Use S3 (AWS), Blob Storage (Azure), or Google Cloud Storage for object
storage.

• 8. Monitoring and Logging:

• Monitor using tools like CloudWatch (AWS), Azure Monitor, or Google
Stackdriver.
• Set up logging with services like AWS CloudTrail or Azure Log Analytics.

• 9. Backup and Disaster Recovery:

• Enable automated backups for databases using cloud-native backup services.
• Design disaster recovery solutions using multi-region deployments and auto-
failover configurations

34
Deploying a Web Service Inside a Cloud Architecture
⚫ Advantages of Cloud Deployment:

• Scalability: Cloud platforms automatically scale resources based on

demand (auto-scaling).
• Cost Efficiency: Pay for resources on a pay-as-you-go basis.
• Automation: Automated infrastructure management (e.g., auto-scaling,
serverless).
• Flexibility: Easily integrate other cloud services such as databases,
storage, and analytics.
• Security: Built-in security tools for managing identity, encryption, and
compliance.

35
Deploying a Web Service Inside a Cloud Architecture
⚫ Disadvantages:

• Vendor Lock-In:You may become reliant on a specific cloud provider’s

ecosystem.
• Cost Control:Without proper management, costs can increase due to
overuse of resources.
• Latency: Some services may experience latency depending on
geographical locations and network configurations.

36
Deploying a Web Service Outside a Cloud Architecture
⚫ Deploying a web service outside the cloud typically involves using traditional,
on-premises infrastructure or third-party hosting services. In this case, you are
responsible for managing the entire hardware and software stack, which can offer
greater control but requires more manual management.

⚫ Key Steps and Technologies for Non-Cloud Deployment:

⚫ a. Infrastructure Setup
• Physical Servers: Host your service on physical machines located in a data
center or within your organization.
• Virtual Machines (VMs): Use a hypervisor (e.g., VMware, Hyper-V, KVM) to
run virtual machines on physical hardware.
• Managed Hosting: Services like GoDaddy, DigitalOcean provide virtual or
dedicated servers but don’t offer the extensive automation of cloud providers.
37
Deploying a Web Service Outside a Cloud Architecture
• Load Balancing:
• Set up load balancing using HAProxy, Nginx, or hardware load balancers.

• Networking:
• Configure firewalls, VPNs, and DNS settings manually.

• Database and Storage:

• Set up your own databases such as MySQL, PostgreSQL, or MongoDB on
physical servers or VMs.
• Set up NAS (Network Attached Storage) or SAN (Storage Area Network) for
storage.

• Security Configuration:
• Manage your own SSL/TLS certificates, set up firewalls, and configure IP
whitelisting.
3•8Use LDAP or Active Directory for authentication.
Deploying a Web Service Outside a Cloud Architecture
• Monitoring and Logging:
• Set up your own monitoring tools like Nagios, Zabbix, or Prometheus
to monitor the health and performance of the service.

• Backup and Disaster Recovery: - Use custom scripts for backup or

third-party tools like Bacula, Veeam, or Acronis for disaster recovery.

39
Advantages of Non-Cloud Deployment:
• Full Control:You have complete control over hardware, networking, and
configurations.

• Customization: Customize every layer of the stack (hardware, network,

storage, and software) to fit your specific needs.

• Security: Some organizations prefer the control of on-premise deployment

for sensitive data or compliance reasons.

40
Disadvantages of Non-Cloud Deployment:
• Cost: Higher upfront capital expenditure (CAPEX) for hardware, with ongoing
costs for maintenance and upgrades.

• Maintenance:You are responsible for hardware maintenance, software updates,

and security patches.

• Scalability: Scaling up requires manual hardware provisioning, which can be

slow and costly.

• Disaster Recovery: Requires building and managing your own disaster

recovery plan, including backup solutions and failover mechanisms.

• Elasticity: Unlike the cloud, it’s difficult to scale resources up and down based
41
on fluctuating traffic.
Comparison of Cloud vs Non-Cloud Deployment:

42
Service-Oriented Architecture (SOA):
• Service-Oriented Architecture (SOA) is a design pattern where
software components, called services, are made available to other
components over a network.

• These services are reusable, loosely coupled, and can interact with each
other using standard communication protocols.

• SOA is used to support distributed computing by integrating a wide range

of applications and systems within an organization or across different
organizations.

43
 Characteristics of SOA
• Loose Coupling: Services in SOA are designed to be independent. The
implementation of each service does not depend on the implementation of other
services, allowing for flexibility in changes and upgrades.

• Interoperability: SOA enables the interaction between different systems and

platforms by using standard communication protocols such as SOAP (Simple Object
Access Protocol) and REST (Representational State Transfer).

• Reusability: Services can be reused across different applications or projects. For

instance, a payment processing service could be used by multiple e-commerce
applications.

• Abstraction: The inner workings of a service are hidden from the consumer.
Users interact with services through well-defined interfaces without knowing how
the service is implemented.
44
Characteristics of SOA
• Discoverability: Services are published in a registry where they can be
found and invoked by service consumers. This promotes the reuse of services
across different domains.

• Statelessness: Services generally do not store the state of their interactions

between calls. Each request from the service consumer should be processed
independently.
 Primitive SOA
Primitive SOA is an earlier form of service-oriented architecture that
emerged in the early days of software engineering. It laid the
foundation for the concept of loosely coupled, service-based
interactions but had some limitations.
•Characteristics:
• Basic Service Interactions: Primitive SOA typically used
simple, stateless services with limited capabilities. The services
were not highly standardized, and communication was often
point-to-point.
• Synchronous Communication: It primarily relied on
synchronous communication protocols, such as RPC (Remote
Procedure Call) or basic HTTP, which limited scalability and
flexibility.
• Limited Interoperability: Different services often used varied
protocols and formats, making interoperability a challenge.
Primitive SOA
• Manual Service Management: Service management, discovery,
and orchestration were mostly manual, with few automated tools
or standards.
• Monolithic Integration: While services were introduced, they
often existed in a monolithic system with less emphasis on
separating services into fully independent units.
• XML and SOAP: XML-based communication using SOAP
(Simple Object Access Protocol) was common, but it had a heavy
and complex structure that made it cumbersome for lightweight
applications.
 Primitive SOA

Challenges:
•Scalability and Flexibility Issues: The synchronous nature and tight
coupling made it difficult to scale.

•Complex Integration: Heterogeneous systems required a lot of effort

to integrate.

•Performance Overhead: XML-based communication was not

optimized for high-performance requirements.
 Contemporary SOA
Contemporary SOA has evolved significantly, incorporating modern technologies,
standards, and best practices to address the limitations of primitive SOA. It embraces
the principles of microservices and cloud-native architectures, bringing a more
flexible and scalable approach.

•Characteristics:
• Standardization and Loose Coupling: Contemporary SOA emphasizes
standardized service contracts, protocols (e.g., REST, GraphQL), and data
formats (e.g., JSON) to achieve loose coupling and interoperability.

• Microservices Architecture: It often adopts a microservices-based approach,

where services are smaller, independently deployable, and can be scaled
separately.

• Asynchronous Communication: There is a greater emphasis on

asynchronous messaging (e.g., using message queues, event-driven
architectures) to improve scalability and resilience.
ContemporarySOA

• Service Discovery and Orchestration: Automated service discovery and

orchestration are integrated, often using service mesh technologies (e.g., Istio)
and API gateways.

• DevOps Integration: DevOps practices, including CI/CD pipelines, automated

testing, and monitoring, are tightly integrated into the lifecycle of services.
 Summary Primitive vs. Contemporary SOA

•Primitive SOA was characterized by basic service interactions,

limited interoperability, and monolithic integration, often using
XML/SOAP.

•Contemporary SOA has adopted modern practices like

microservices, asynchronous messaging, cloud-native technologies, and
DevOps, allowing for scalable, flexible, and resilient service-oriented
systems.
Contemporary SOA builds on the foundational ideas of primitive SOA
but significantly enhances them to meet modern enterprise needs.
 Client-Server Architecture
Client-server architecture is one of the earliest and simplest models for network-based
computing, where the workload is distributed between servers and clients.

•Characteristics:
• Two-Tier Architecture: It consists of two main components: the client
(frontend) and the server (backend). Clients send requests to the server, which
processes them and returns responses.
• Tight Coupling: The client and server are often tightly coupled, meaning that
changes to one can significantly impact the other.
• Synchronous Communication: Requests are usually processed
synchronously, meaning the client waits for a response before continuing its
workflow.
• Centralized Server: The server acts as a central point of control, handling
most of the business logic and data processing.
• Limited Scalability: As the number of clients grows, the central server can
become a bottleneck, limiting scalability.
 Client-Server Architecture

Use Cases:

•Small to Medium Applications: Ideal for smaller applications where

the number of clients is manageable.

•LAN-based Applications: Often used in local area network (LAN)

environments for internal business applications.
 Distributed Internet Architecture
Distributed internet architecture is more complex, designed to handle a wider
distribution of components across various networked locations.
•Characteristics:
• Multi-Tier Architecture: It typically involves more than two layers,
such as presentation, application (business logic), and data layers. This
allows for better separation of concerns.
• Decentralized Components: Different parts of the application can be
hosted on different servers, which can be geographically distributed.
• Loose Coupling and Scalability: Components can be loosely coupled,
with communication occurring through standardized protocols like
HTTP, making it easier to scale.
• Synchronous and Asynchronous Communication: Supports both
synchronous (e.g., HTTP) and asynchronous (e.g., messaging queues,
event streams) communication.
• Cloud and Web Integration: Well-suited for web-based applications,
cloud-native designs, and internet-scale services.
 Distributed Internet Architecture

Use Cases:

•Web Applications: Commonly used in web applications and cloud

services.
•Highly Scalable Systems: Ideal for applications that need to scale
across a wide range of users and locations.
 Service Oriented Architecture (SOA)
SOA builds on concepts from both client-server and distributed architectures,
but it has its own distinctive principles, emphasizing services as reusable
components.
•Characteristics:
• Service Abstraction: Services are designed to encapsulate business
logic and can be accessed independently from their implementation.
• Loose Coupling: Services interact through well-defined interfaces,
typically using standardized protocols (e.g., SOAP, REST), which
makes the architecture loosely coupled.
• Reusability and Interoperability: Services can be reused across
different applications and can communicate even if built on different
platforms.
• Asynchronous and Event-Driven Communication: Supports both
synchronous requests and asynchronous messaging, allowing for
flexibility in handling different types of workloads.
• Service Governance and Management: SOA often includes tools and
frameworks for managing services, including service registries,
orchestration, and security.
 Service Oriented Architecture (SOA)
Use Cases:

•Enterprise Applications: SOA is widely used in large organizations

where integration across different systems and departments is required.

•B2B Integrations: Suitable for business-to-business (B2B)

integrations where services from different companies need to
communicate.

•Microservices: SOA principles underpin microservices architectures,

which extend the concept of services to more granular, independently
deployable components.
Comparison