Service Oriented Architecture

Lecture Notes, Discussion Points and References

Updated
15th Apr 2024
 Table of Contents

SOA Syllabus 4
Unit 1: Introduction to Service-Oriented Architecture 4
Unit 2: SOA Design and Modeling 4
Unit 3: SOA Implementation Technologies 4
Unit 4: Security and Governance in SOA 5
Unit 5: SOA Emerging Trends 5
Lab Exercises 5
Reference Books 6
Terminology 7
Unit-1 Introduction to Service Oriented Architecture 8
Motivations of SOA 8
What is SOA 10
Key Characteristics of SOA 11
SOA Components 12
Evolution and Historical Context of SOA 13
Early Web Services 14
E-commerce Integration - Amazon.com 15
Travel Booking System - Expedia.com 15
Enterprise Resource Planning - SAP ERP 16
Emergence of SOA Standards 16
Adoption in Industry 17
Benefits and Challenges of SOA 17
Benefits of SOA 17
Contemporary Trends of SOA 19
Cloud Computing and SOA 20
Serverless Computing and SOA 21
Unit-2 SOA Design and Modeling 23
Service Design Principles and Patterns 23
Service Coupling 23
Service Cohesion 24
Applying Coupling and Cohesion to SOA 24
Design for Change 26
Service Contract Design and Management 26
Contract-First Design 27
Versioning and Evolution 27
Interface Definition Languages (IDLs) 28
Definition of IDLs 28
Features of IDLs 28
Application of IDLs in SOA 29
2
 Protocol Buffers (protobuf) 29
Apache Thrift 30
Designing for Scalability and Resilience 31
Load Balancing 32
Fault Tolerance 32
Circuit Breaker Pattern 32
Unit-3 SOA Implementation Techniques 34
Web Services Standards 34
Simple Object Access Protocol 34
Representational State Transfer (REST) 34
Graph QL 35
Examples and Code Snippets 35
Microservices Architecture and its Relationship with SOA 36
Decentralized Data Management: 36
Independent Deployment: 37
Infrastructure Automation 38
Relationship with SOA 39
Containerization and Orchestration 40
Containerization 40
Docker Container 40
Kubernetes Orchestration 42
Service Mesh Technologies 43
Event-Driven Architecture 44
Event Sourcing 44
Command Query Responsibility Segregation (CQRS) 44
Event-Driven Messaging Systems 45
API Management and Governance 45
API Design Principles 46
Developer Portals 46
Rate Limiting and Quotas 46
Lab Exercises - Solution 48
Exercise 1: Overview of SOA: Implement a REST Web Service 48
REST Web Service - Python Implementation (GET and POST Methods) 48
REST Web Service - Spring Boot (Java) Implementation 50
Exercise 2: Principles and Concepts of SOA 53
Pub-Sub: Demonstrate a Publisher-Subscriber message exchange using RabbitMQ. 53
RabbitMQ tutorial - "Hello world!" 54
Exercise 3: Demonstrate a Content Delivery Network (CDN) 54
Design a simple Content Delivery Network (CDN) using Python with focus on distributing
content efficiently to users from multiple edge servers 55
Exercise 4: Build a AI-driven Customer Support service and integrate into a SOA application
57
Design a simple AI driven Customer support SOA service using ML models and
integrate it into a SOA. 58
3
Reference Articles 60

4
 SOA Syllabus

Unit 1: Introduction to Service-Oriented Architecture

1.1 Overview of Service-Oriented Architecture

-Idea of a Service, Key Characteristics, Historical Context

1.2 Principles and Concepts of SOA

- Service Loose Coupling, Service Reusability, Service Abstraction

1.3 Evolution and History of SOA

- Early Web Services, Emergence of SOA Standards, Adoption in Industry

1.4 Benefits and Challenges of SOA

- Business Agility, Interoperability, Challenges in Implementation

1.5 Contemporary Trends in SOA

- Microservices Architecture, Cloud Computing and SOA
- Serverless Computing and SOA

Unit 2: SOA Design and Modeling

2.1 Service Design Principles and Patterns

- Service Cohesion, Granularity, Design for Change

2.2 Service Contract Design and Management

- Interface Definition Languages (IDLs), Contract-First Design, Versioning
and Evolution

2.3 Designing for Scalability and Resilience

- Load Balancing, Fault Tolerance, Circuit Breaker Pattern

Unit 3: SOA Implementation Technologies

3.1 Web Services Standards

- Simple Object Access Protocol (SOAP), Representational State Transfer (REST)
- GraphQL

3.2 Microservices Architecture and its Relationship with SOA

- Decentralized Data Management, Independent Deployment
- Infrastructure Automation

3.3 Containerization and Orchestration

- Docker Container, Kubernetes Orchestration, Service Mesh Technologies

3.4 Event-Driven Architecture (EDA) and SOA

5
 - Event Sourcing, Command Query Responsibility Segregation (CQRS)
- Event-Driven Messaging Systems

3.5 API Management and Governance

- API Design Principles, Developer Portals, Rate Limiting and Quotas

Unit 4: Security and Governance in SOA

4.1 Security Considerations in SOA

- Understanding Threat Models, Common Security Risks in SOA
- Security Design Patterns

4.2 Data Encryption and Integrity

- Message-Level Encryption (XML Encryption), Digital Signatures (XML Signature)
- Secure Hash Algorithms (SHA), Securing APIs and Web Services

4.3 API Security Best Practices

- Securing RESTful APIs, Web Service Security Standards (WS-Security)

4.4 XML Security and SAML Assertions

- XML Security Considerations, Introduction to SAML
- SAML Assertions and Assertions Consumers

Unit 5: SOA Emerging Trends

5.1 Serverless Computing and its Impact on SOA

- Function-as-a-Service (FaaS), Event-Driven Architectures
- Operational Characteristics

5.2 Artificial Intelligence (AI) and Machine Learning (ML) in SOA

- Intelligent Agents, Predictive Analytics, Natural Language Processing (NLP)

5.3 Edge Computing and SOA Integration

- Edge Gateway Architectures, Low-Latency Data Processing. Offline Capabilities

Lab Exercises
Exercise 1: Overview of Service-Oriented Architecture

6
- Code Example: Develop a simple web service using a framework like Flask (Python),
Spring Boot (Java), or Express (Node.js). Demonstrate how clients can consume this
service to retrieve or manipulate data.

Exercise 2: Principles and Concepts of SOA

- Code Example: Implement a basic service demonstrating loose coupling by using
asynchronous messaging (e.g., RabbitMQ or Kafka). Create a publisher service that
sends messages to a message broker and a consumer service that receives and
processes these messages independently.

Exercise 3: Contemporary Trends in SOA

- Code Example: Build a serverless function using a platform like AWS Lambda or
Azure Functions. Create a simple function that performs a specific task (e.g., image
resizing, data processing) and expose it as a RESTful endpoint. Integrate this function
into an existing SOA architecture to demonstrate its interoperability with other services.

Exercise 4: Artificial Intelligence (AI) and Machine Learning (ML) in SOA:

- Exercise: Build a simple AI-driven service using machine learning models. Explore
how intelligent agents can be integrated into SOA architectures.

Reference Books
1. Service-Oriented Architecture: Concepts, Technology and Design by Thomas Erl

2. Building Microservices" by Sam Newman

3. Microservices Patterns: With examples in Java by Chris Richardson

4. SOA Security by Ramarao Kanneganti and Prasad Chodavarapu

7
 Terminology

Enterprise Enterprise refers to an organization or a business

Service A basic granular unit of a system that provide a specific function

Architecture An organization or design pattern of an software system

IT Systems Refers to hardware and software components of an Enterprise

Applications A software designed to specific functions or services

Web Service An HTTP based application used over internet

Security Refer to protecting user, data, infrastructure and applications of

an enterprise

8
Unit-1 Introduction to Service Oriented Architecture

1.1 Overview of Service-Oriented Architecture

- Why learn SOA, Key Characteristics, Historical Context

Motivations of SOA

Consider modern applications that we use in our daily lives:

- Cab Booking applications (Ola, Uber, Rapido, Namma Yatri, etc)
- e-Commerce (Amazon, Flipkart)
- Quick Commerce (Zepto, Blinkit)
- Navigation (Google Maps, Open Street Maps)
- Food Delivery (Swiggy, Zomato, etc)
- Payment (NCPI: BHIM, Paytm, Google Pay, etc)
- Social Media (Instagram, Twitter)
- Communication (WhatsApp, Telegram, Jabber)

Challenges of building such applications

● Scalability - very high number of users (thousands, millions of active users,
transactions)

9
 NPCI Transactions: https://www.npci.org.in/statistics/monthly-metrics

Day Volume (million)

March 1, 2024 454.629

March 2, 2024 452.081

March 3, 2024 433.882

● Multiple and Heterogeneous components - each application has many

components interconnected (front-end, backend, databases) and each
component is designed differently and coded in different languages (e.g. Java,
Go-lang, JS, Python, etc)
● Security - authentication (e.g. login), protecting data (encryption), data privacy
● High Availability and Business Continuity - making applications available with
minimal down time.
● Cost and Operational Expenses (OpEx) -
○ Development Cost - developing new products and features
○ Deployment Cost - high cost of running these applications in data centers
and cloud.
○ Paytm OpEx: Software, Cloud and Data Center costs were ₹171 Cr,
up 31% YoY in Feb 2023, ₹188 Cr in Mar 2023

10
Source:https://paytm.com/blog/investor-relations/how-paytm-achieved-operational-profit
ability/

What is SOA

Home Work References

1. Read about original publication on SOA:

https://www.opengroup.org/soa/source-book/soa/index.htm
2. Read Martin Fowler (ThoughtWorks) take on SOA for an article in 2005
https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

● SOA refers to → Service Oriented Architecture

○ Service-Oriented Architecture (SOA) is an architectural style that supports
service-orientation.
○ It’s a Design Pattern: a way to build modern complex applications using
granular, reusable services.
○ It’s an approach to build software systems that are based on distributed
systems.
○ It’s an approach to build software systems based on loosely coupled
service components
11
 ● A service:
● Is a logical representation of a repeatable business activity that has a
specified outcome (e.g., check customer credit, provide weather data,
consolidate drilling reports)
● Is self-contained
● May be composed of other services
● Is a “black box” to consumers of the service
● Idea of a Service - A service is defined as a specific granular, functional,
self-contained, reusable component or code consumed by other services or
applications (e.g. Login Service, Order History, Map APIs)
○ Service interface - provides interface to invoke a service and define
formats to pass and receive data from a service. For example, user of
RESTAPI for request and response, XML, JSON for sending and receiving
data from service.
○ Service is technology independent and interoperable - consumers of
the service can invoke the service on any hardware or software platform
or code. For example, a Cab booking app running in AWS can invoke
Google Map API services to from source to destination
○ Service is discoverable - consumers of the service can easily detect the
purpose and use of the service. For example, a E-Commerce app can
discover various payment methods.
○ Service is stateless - a service doesn’t maintain any specific state of a
service call. For example, a QR scanning service takes a QR code, just
returns the value of code and doesn’t maintain any other context of
service invocation.

Key Characteristics of SOA

Service-Oriented Architecture (SOA) is defined by several key characteristics that

shape its design and implementation. These characteristics include:

1. Loosely Coupled: SOA promotes loose coupling between software components,

allowing them to interact independently without tight dependencies. This enables

12
flexibility and agility in system design, as services can be modified or replaced without
impacting other components.

2. Interoperable: SOA facilitates interoperability between heterogeneous systems and

technologies. By adhering to open standards and protocols, such as XML, SOAP and
REST, services can communicate seamlessly across different platforms and
programming languages.

3. Flexible: SOA is inherently flexible, allowing for the composition and recomposition
of services to meet changing business requirements. Services can be combined and
orchestrated in various ways to create new functionalities, enabling organizations to
adapt to evolving needs.

4. Scalable: SOA provides scalability by distributing functionality across multiple

services, each capable of running independently and horizontally scaling to
accommodate increased demand. This allows systems to handle varying workloads and
scale resources efficiently.

5. Stateless: SOA promotes statelessness, where services do not maintain session

state between requests. This enhances scalability and fault tolerance by allowing
services to handle each request independently, without relying on previous interactions.

These key characteristics of SOA—loose coupling, interoperability, flexibility, scalability

and statelessness—lay the foundation for building resilient, adaptable and efficient
complex and distributed software systems.

SOA Components

The basic unit of Service Oriented Architecture is a Service

● It’s a self-contained software system
● Accessible via APIs

13
Evolution and Historical Context of SOA

​ Late 1990s - Early 2000s: Emergence of Web Services

● Key Events:
● Rise of Internet technologies - Dot Com Boom!
● The term first appeared in 1998
● Need for interoperability between systems
● Technologies:
● Introduction of SOAP and WSDL
​ Early to Mid-2000s: Paradigm Shift with SOA
● Key Events:
● Transition towards modular, loosely coupled architectures
● Emergence of SOA as a new architectural paradigm
● Technologies:
● Adoption of SOA principles in enterprise integration
​ Standardization Efforts and Industry Consortia
14
 ● Key Events:
● Development of SOA-related standards and specifications
● Role of organizations like W3C and OASIS
● Technologies:
● Definition of XML, SOAP, WSDL and WS-* standards
​ Challenges and Criticisms in SOA Adoption
● Key Challenges:
● Complexity in service design and governance
● Cultural resistance to change
● Concerns about ROI
● Critiques:
● Effectiveness of SOA in delivering promised benefits
​ Legacy and Impact
● Key Influences:
● Evolution towards microservices and cloud-native architectures
● Continued relevance in modern software design practices

Early Web Services

Early web services emerged in the late 1990s and early 2000s as a means of enabling
interoperability and communication between disparate systems over the Internet.

● Key Features of Early Web Services

● Utilized technologies such as HTTP, XML and SOAP (Simple Object
Access Protocol) for communication.
● SOAP provided a standardized protocol for exchanging structured
information between systems.
● Web services allow for the integration of applications across different
platforms and programming languages.

Here are use cases of SOA in early web services:

● E-commerce Integration: Early web services facilitated the integration of

e-commerce platforms with payment gateways, enabling secure transactions and
real-time order processing.

15
 ● Travel Booking Systems: Travel agencies use web services to integrate with
airline reservation systems, allowing customers to search for flights, book tickets
and receive real-time updates on flight availability.
● Enterprise Resource Planning (ERP): Organizations utilise web services to
integrate ERP systems with third-party vendors for tasks such as inventory
management, supply chain optimization and financial reporting.

E-commerce Integration - Amazon.com

● Use Case Scenario: In the mid-90s, Amazon.com began its journey as an online
bookstore, but it quickly evolved into a platform selling a wide range of products.
To handle the complex nature of its e-commerce operations, Amazon likely
employed service-oriented principles, even before SOA was formally recognized.
● SOA Characteristics: Amazon's platform likely utilised loosely coupled services
to handle various aspects of its operations, such as inventory management, order
processing, payment processing and customer relationship management (CRM).
These services would have communicated with each other using standardized
protocols such as HTTP and XML

Travel Booking System - Expedia.com

● Use Case Scenario: Expedia, founded in the late 1990s, revolutionized the travel
industry by offering an online platform for booking flights, hotels, rental cars and
vacation packages. To provide a seamless booking experience to its users,
Expedia likely employed SOA principles in its system architecture.
● SOA Characteristics: Expedia's platform likely consisted of various services
responsible for different functions, such as flight search, hotel booking, payment
processing and itinerary management. These services would have been loosely
coupled, allowing for flexibility and scalability. For example, the flight search
service could communicate with airline reservation systems via standardized
interfaces, such as SOAP or XML over HTTP.

16
Enterprise Resource Planning - SAP ERP

● Use Case Scenario: SAP, a leading provider of ERP software, has been in the
industry since the early 1970s. While its early systems may not have fully
embraced SOA principles, SAP likely transitioned towards a more
service-oriented approach in the late 1990s and early 2000s to address the
growing complexity of enterprise operations.
● SOA Characteristics: SAP's ERP system would consist of various modules or
services responsible for different business functions, such as finance, human
resources, supply chain management and customer relationship management.
These services would have been designed to be reusable and interoperable,
allowing organizations to customize their ERP implementations based on their
specific needs.

Emergence of SOA Standards

The emergence of SOA standards occurred as organizations sought more structured

and scalable approaches to integrating systems and building software applications.

● Key Standards:
● SOAP (Simple Object Access Protocol): A protocol for exchanging
structured information in the implementation of web services.
● WSDL (Web Services Description Language): A standard for describing
the functionality of web services, facilitating their discovery and invocation.
● XML (eXtensible Markup Language): A markup language used for
encoding documents in a format that is both human-readable and
machine-readable.
● Importance:
● SOA standards provided a common framework for designing,
implementing and consuming web services.
● They promoted interoperability and reusability by establishing common
protocols and formats for communication between systems.

17
Adoption in Industry
● Drivers for Adoption:
● The adoption of SOA in industry was driven by the need for more flexible,
scalable and interoperable solutions to address complex business
challenges.
● Organizations sought to modernize their IT infrastructure and improve
agility by adopting SOA principles.
● Benefits of Adoption:
● SOA adoption enabled organizations to achieve greater flexibility and
agility in responding to changing business requirements.
● It promoted interoperability between disparate systems, allowing for
seamless communication and integration across the enterprise.
● Challenges:
● Despite its benefits, SOA adoption presented challenges such as cultural
resistance to change, complexity in implementation and concerns about
Return of Investment.
● Organizations faced hurdles in transitioning from traditional monolithic
architectures to a more service-oriented approach.

Benefits and Challenges of SOA

Benefits of SOA

● Business Agility:
● SOA enables organizations to respond quickly to changing market
conditions and business requirements.
● Real Use Case Netflix: Netflix employs SOA to continuously innovate its
streaming platform. With SOA, Netflix can rapidly introduce new features,
personalize recommendations and scale its infrastructure to accommodate
fluctuations in viewer demand. For example, Netflix's recommendation
service analyzes user preferences in real-time, leveraging microservices
to deliver personalized content recommendations instantly.
● Interoperability:
18
 ● SOA promotes interoperability by standardizing communication protocols
and data formats.
● Real Use Case: Salesforce.com: Salesforce.com leverages SOA to
integrate its cloud-based CRM platform with various third-party
applications and services. Through standardized APIs and web services,
Salesforce enables seamless data exchange between its CRM system
and other business systems, such as marketing automation tools, ERP
systems and customer support platforms.

Challenges in Implementation

● Cultural Resistance to Change:

● Implementing SOA often requires cultural shifts within organizations, as it
may disrupt traditional development practices and organizational
structures.
● Real Use Case: Banking Industry: Large banks often face cultural
resistance when transitioning to SOA due to the legacy nature of their
systems and the hierarchical structure of their IT departments. Developers
may be accustomed to working in silos and there may be resistance from
management to adopt new development methodologies. Overcoming this
resistance requires strong leadership, effective communication and a
focus on the benefits of SOA for delivering customer-centric solutions.
● Complexity in Governance and Management:
● SOA introduces complexity in governance, management and lifecycle
management of services.
● Real Use Case: Government Services: Government agencies
implementing SOA face challenges in managing service lifecycles,
ensuring data security and maintaining compliance with regulations. For
example, a government agency responsible for citizen services may
struggle with governing access to sensitive data across multiple
departments and agencies. Implementing robust governance frameworks
and security policies is essential to address these challenges and ensure
the integrity and confidentiality of citizen data.

19
Realizing the Benefits

● Best Practices for Implementation:

● Successful implementation of SOA requires a strategic approach and
adherence to best practices.
● Real Use Case: Amazon Web Services (AWS): AWS provides a
comprehensive set of cloud services built on SOA principles. By offering a
wide range of modular services, such as computing, storage and
databases, AWS enables organizations to build scalable and resilient
applications. Best practices include leveraging AWS services in a
decoupled manner, implementing auto-scaling and fault-tolerant
architectures and continuously monitoring and optimizing performance.
● Continuous Improvement and Adaptation:
● SOA is an iterative process that requires continuous improvement and
adaptation to changing business needs and technology landscapes.
● Real Use Case: Uber: Uber continually evolves its platform using SOA
principles to meet the demands of its global user base. By breaking down
its monolithic architecture into microservices, Uber can deploy new
features independently, optimize performance and scale its infrastructure
dynamically. Continuous improvement involves gathering feedback from
users, monitoring system performance and iteratively enhancing services
to deliver a seamless and reMicroservices Architecture
● liable ride-sharing experience.

Contemporary Trends of SOA

Microservices architecture is an architectural style that structures an application as a

collection of loosely coupled services, each responsible for a specific business function
and independently deployable.

● Key Characteristics:

20
 ● Service Decomposition: Applications are decomposed into smaller,
independently deployable services, each responsible for a specific
business capability.
● Decentralized Data Management: Each service manages its own
database or data store, enabling greater autonomy and scalability.
● Polyglot Persistence: Services can use different databases or data
storage technologies based on specific requirements.
● Infrastructure Automation: Microservices rely on automation for
deployment, scaling and monitoring to ensure resilience and reliability.
● Real Use Case: Netflix
● Netflix transitioned from a monolithic architecture to a
microservices-based architecture to support its rapid growth and global
expansion.
● Each microservice at Netflix handles a specific function, such as user
authentication, content recommendation, billing and streaming.
● This architecture enables Netflix to scale its services independently,
deploy updates faster and deliver personalized experiences to millions of
users worldwide.

Cloud Computing and SOA

Cloud computing is the delivery of computing services—including servers, storage,

databases, networking, software and analytics—over the internet to offer faster
innovation, flexible resources and economies of scale.

● Key Characteristics:
● On-Demand Self-Service: Users can provision and manage computing
resources, such as servers and storage, without human intervention.
● Resource Pooling: Cloud providers pool and dynamically allocate
resources to multiple users, optimizing resource utilization and scalability.
● Pay-Per-Use Billing: Users pay only for the resources they consume,
enabling cost-effective and scalable solutions.
● Scalability and Elasticity: Cloud services can scale up or down based on
demand, ensuring performance and availability.
21
 ● Real Use Case: Airbnb
● Airbnb leverages cloud computing services, such as Amazon Web
Services (AWS), to power its online marketplace for lodging and tourism
experiences.
● By using cloud infrastructure, Airbnb can quickly scale its services to
accommodate spikes in demand during peak booking seasons or events.
● Additionally, cloud-based analytics and machine learning services enable
Airbnb to personalize search results, recommend listings and optimize
pricing for hosts.

Serverless Computing and SOA

Serverless computing is a cloud computing model where cloud providers manage the
infrastructure, dynamically allocating resources as needed and users only pay for the
compute resources consumed by their applications.

● Key Characteristics:
● No Server Management: Users do not need to provision, manage, or
maintain servers or infrastructure, allowing for faster development and
deployment.
● Event-Driven Architecture: Serverless applications are event-driven and
respond to triggers or events, such as HTTP requests, database changes,
or messages from queues.
● Auto-Scaling: Serverless platforms automatically scale resources based
on demand, ensuring high availability and performance without user
intervention.
● Pay-Per-Use Billing: Users are billed based on the actual resources
consumed by their applications, offering cost savings and efficiency.
● Real Use Case: Lyft
● Lyft utilizes serverless computing for its backend infrastructure to handle
millions of ride requests and data-intensive operations in real-time.
● By adopting a serverless architecture on AWS Lambda, Lyft can
dynamically scale its backend services in response to user demand,
ensuring low-latency responses and optimal performance.
22
● Serverless computing enables Lyft to focus on building and improving its
core ride-sharing platform without worrying about managing servers or
infrastructure.

23
 Unit-2 SOA Design and Modeling

Service Design Principles and Patterns

Service Design Principles and Patterns form the foundations of effective
Service-Oriented Architecture (SOA). This unit delves into the essential concepts and
strategies for designing services that are cohesive, granular and adaptable to change.
Understanding these principles and patterns will provide iinsight into creating robust,
scalable and maintainable service-oriented systems.

Service Coupling

Definition: Service Coupling refers to the degree of interdependence between any two
business processes or services within a system.

Preferable State: In SOA, weak coupling is preferred, indicating lower dependency

for increased flexibility, scalability and maintainability.

● Explanation:
● Weak coupling allows services to evolve independently, reducing the risk
of unintended consequences when modifications or updates are made.
● Services with weak coupling can adapt more easily to changes in
business requirements, ensuring that adjustments in one part of the
system do not propagate unexpectedly to other interconnected services.
● Example:
● A service employing standardized interfaces and protocols can interact
with other services more loosely, minimizing the impact of changes in one
service on others.
● Example: Consider an e-commerce platform where a "Checkout Service"
encapsulates functionalities such as processing payment, updating
inventory and sending order confirmation emails. This service
demonstrates strong cohesion by focusing on a cohesive set of operations
related to completing the checkout process.

24
Service Cohesion

Definition: Service Cohesion refers to the degree of functional relatedness and focus of
operations within a service.

Preferable State: Strong cohesion is preferred in SOA, indicating that a service should
encapsulate closely related and well-defined functionalities.

● Explanation:
○ Strong cohesion ensures that a service encapsulates a well-defined and
closely related set of functionalities, enhancing clarity, maintainability and
usability.
○ Cohesive services promote reusability and contribute to a modular and
extensible architecture.
● Example:
○ A service responsible for order processing should encapsulate
functionalities such as order validation, payment processing and inventory
management, exhibiting strong cohesion.

Applying Coupling and Cohesion to SOA

● The principles of coupling and cohesion remain relevant in modern

service-oriented systems.
● Analyzing different approaches, such as WS-* versus REST, reveals differences in
coupling and cohesion. For example, in systems based on WS-, interfaces often
exhibit higher degrees of coupling due to their ad hoc and variable nature. Each
service endpoint may have its own unique interface, leading to increased
complexity and tighter coupling between services. Conversely, RESTful systems
adhere to uniform interfaces, promoting loose coupling and greater cohesion. For
instance, consider a banking application where WS- services handle transactions
with varying interfaces for different account types. In contrast, a RESTful
approach may use a uniform interface for all account-related operations, such as

25
 GET, POST, PUT and DELETE methods, leading to more cohesive service
interactions and easier integration across the system.
● Creating understandable and maintainable Web service orchestrations requires
considering the cohesion of services being orchestrated.

Service Granularity

Service design principles such as cohesion, granularity and design for change are
fundamental to creating effective and maintainable service-oriented architectures. By
adhering to these principles, organizations can develop robust and adaptable systems
capable of meeting the dynamic needs of the business environment.

Definition: Service Granularity denotes the scope of functionality exposed by a service.

Preferable State: Coarse granularity is recommended in SOA, suggesting that services

should provide broad functionalities to address specific needs, promoting reusability.

● Coarse-grained services encapsulate broader and more encompassing

functionalities, reducing the number of service invocations and promoting
simplicity.
● Coarse granularity enhances service reuse, reduces the impact of changes on
service interfaces and aligns with the goal of creating a modular and scalable
architecture.
● Example: A coarse-grained service responsible for customer management
provides functions such as creating, updating and deleting customer
profiles, providing a comprehensive set of functionalities within a single
service interface.
● Example: In a travel booking system, a "Reservation Service" might
provide coarse-grained functionalities such as booking flights, hotels and
rental cars in a single service call, enabling customers to make
comprehensive travel arrangements efficiently.

26
Design for Change

● Designing services for change is essential in SOA to ensure adaptability to

evolving business requirements.
● Service-oriented systems should be designed with flexibility and agility in mind,
allowing services to evolve independently without impacting other parts of the
architecture.
● Example: Consider a healthcare management system where a "Patient
Information Service" is designed to accommodate changes in medical record
formats or regulatory requirements. By encapsulating data access and
manipulation logic within the service, it can adapt to evolving standards without
affecting other components of the system.

Service Contract Design and Management

This section explores critical aspects of designing and managing service contracts in a
Service-Oriented Architecture (SOA).

A service contract serves as the interface between service providers and consumers,
defining the obligations, responsibilities and expectations of both parties. This enables
creation of interoperable and extendable service contracts that facilitate seamless
integration and collaboration within distributed systems.

Example: In a modern e-commerce platform, the use of OpenAPI Specification (known

as Swagger) allows developers to define clear and standardized interfaces for various
microservices responsible for product catalog, user authentication and payment
processing. By utilizing OpenAPI Specification, developers can ensure consistent
communication between services and enable seamless integration with third-party
applications.

27
Contract-First Design

● Understanding the concept of Contract-First Design as a methodology for

designing services from the perspective of their contracts.
● Discussing the advantages of Contract-First Design in promoting loose coupling,
interoperability and alignment with business requirements.
● Case studies demonstrating the implementation of Contract-First Design
principles in real-world service development projects.
​

Example: A telecommunications company adopts Contract-First Design when

developing a new API for their billing system. By defining the contract (API
specifications) first, based on the requirements gathered from stakeholders, the
development team ensures that the API meets the exact needs of the consumers. Any
changes or updates to the API contract are communicated and agreed upon before
implementation, reducing the risk of compatibility issues.

Versioning and Evolution

● Addressing the challenges of versioning and evolution in service contracts over

time.
● Strategies for managing backward and forward compatibility while introducing
changes to service contracts.
● Best practices for versioning service contracts to ensure seamless migration and
coexistence of multiple service versions.

Example: A cloud storage provider (e.g. AWS S3, DropBox) introduces a new version of
its API to support additional features and improve performance. To ensure backward
compatibility, the provider maintains support for the previous API version while allowing
clients to migrate to the new version at their own pace. Through versioning and effective
communication of changes, the provider minimizes disruptions for existing clients and
facilitates the adoption of new features by offering clear migration paths.

28
Interface Definition Languages (IDLs)

Interface Definition Languages (IDLs) are formal languages used to describe the
interfaces of software components, enabling communication and interaction between
distributed systems. This lecture explores the role of IDLs in service-oriented
architectures (SOAs), their key features and their application in modern software
development.

Definition of IDLs

● IDLs provide a standardized way to define the structure, operationsand

data types of interfaces between software components.
● They facilitate interoperability by enabling communication between
heterogeneous systems implemented in different programming languages
or running on different platforms.

Features of IDLs

● Interface Specification: IDLs allow application developers to specify the

methods, parameters and data types exposed by a software component's
interface.
● Language Neutrality: IDLs are independent of programming languages,
allowing components written in different languages to communicate
seamlessly.
● Platform Independence: IDLs abstract away platform-specific details,
enabling components running on different operating systems or hardware
architectures to interact.

Types of IDLs

● Operation-Oriented IDLs: Focus on defining remote procedure calls (RPCs)

and method invocations between distributed components. Examples
include CORBA IDL and DCOM IDL.

29
 ● Data-Oriented IDLs: Primarily used for defining data structures and
messages exchanged between systems. Examples include Google
Protocol Buffers, Apache Thriftand Apache Avro.

Application of IDLs in SOA

● Contract-First Design: IDLs promote a contract-first approach to service

design, where interfaces are defined and agreed upon before
implementation.
● Versioning and Evolution: IDLs support versioning mechanisms, allowing
services to evolve over time while maintaining backward compatibility.
● Interoperability: IDLs enable interoperability between services
implemented in different languages or running on different platforms,
fostering a heterogeneous and distributed ecosystem.

Protocol Buffers (protobuf)

● Developed by Google, Protocol Buffers is a widely-used IDL for serializing

structured data, particularly in microservices and cloud-native
applications.

30
 ● Example: In a distributed messaging system, Protocol Buffers is used to
define message formats for communication between microservices,
ensuring efficient data serialization and deserialization.

Apache Thrift

● Apache Thrift is a cross-language IDL framework developed by Facebook,

used for defining and communicating between services in diverse
environments.

● Example: In a scalable web application, Apache Thrift is employed to

define service interfaces for handling user authentication, session
management and data storage, allowing seamless communication
between backend services written in different languages.

31
Designing for Scalability and Resilience
Designing for Scalability and Resilience is essential for building robust and adaptable
service-oriented architectures (SOAs) that can handle varying workloads and maintain
availability under challenging conditions. This section describes key design principles
and patterns, including Load Balancing, Fault Tolerance and the Circuit Breaker Pattern,
along with modern application examples to illustrate their practical implementation.

● Load Balancing in Cloud-Native Applications:

● Example: In a containerized microservices application deployed on
Kubernetes, an ingress controller acts as a load balancer, distributing
incoming HTTP traffic to pods running the same service. Kubernetes
dynamically adjusts the load balancing configuration based on resource
availability and service health.
● Fault Tolerance in Serverless Computing:
● Example: In a serverless architecture for a real-time analytics platform,
functions are deployed across multiple cloud providers to ensure fault
tolerance and high availability. If one cloud provider experiences an
outage, the platform automatically scales up instances in alternative
regions to maintain service uptime.
● Fault-tolerant systems include monitoring tools, such as Netflix's Eureka,
and stress-testing tools, like Chaos Monkey. They help to discover issues
earlier by testing in pre-deployment environments, like integration (INT),
quality assurance (QA), and user acceptance testing (UAT), to prevent
potential problems before moving to the production environment.
● Circuit Breaker Pattern in API Gateways:
● Example: In a modern API gateway (Kong, Envoy, Apigee) for a mobile
banking application, circuit breakers are implemented to protect against
backend service failures. If the authentication service experiences errors,
the circuit breaker opens, temporarily routing requests to a cached
authentication token to maintain user session integrity.

32
Load Balancing

● Definition: Load Balancing is the process of distributing incoming network traffic

across multiple servers to ensure optimal resource utilization and prevent
overload on any single server.
● Application: In SOA, load balancers are used to evenly distribute requests among
service instances, improving scalability and responsiveness.
● Example: In a cloud-based e-commerce platform, a load balancer distributes
incoming web traffic across multiple instances of the Product Catalog Service,
ensuring that no single instance becomes overwhelmed during peak shopping
periods.
■ Nginx - https://www.youtube.com/watch?v=MxPVAaBb-wA
■ HAProxy - https://www.youtube.com/watch?v=qYnA2DFEELw

Fault Tolerance

● Definition: Fault Tolerance refers to the ability of a system to continue operating

properly in the event of component failures or disruptions.
● Application: In SOA, fault-tolerant designs incorporate redundancy, error handling
and failover mechanisms to mitigate the impact of failures on system availability.
● Example: In a financial trading application, redundant instances of the Order
Execution Service are deployed across geographically distributed data centers. If
one data center experiences an outage, traffic is automatically redirected to the
backup data center to maintain service continuity.
● Reference: https://opensource.com/article/19/3/tools-fault-tolerant-system

Circuit Breaker Pattern

● Definition: The Circuit Breaker Pattern is a design pattern used to handle faults
and failures in distributed systems by temporarily suspending requests to a failing
service.
● b: In SOA, circuit breakers monitor the health of downstream services and prevent
cascading failures by quickly detecting and isolating faulty components.
33
● Example: In a microservices architecture for a social media platform, a circuit
breaker is implemented in the Notification Service to prevent excessive retries
when sending notifications to users. If the Notification Service experiences a high
error rate, the circuit breaker opens, temporarily halting requests to the service
and preventing overload.

34
 Unit-3 SOA Implementation Techniques

Web Services Standards

Web services standards define the protocols and formats used for communication
between different software applications over the internet. These standards enable
interoperability and integration between heterogeneous systems, allowing them to
exchange data and invoke functionality seamlessly.

Simple Object Access Protocol

● SOAP is a protocol used for exchanging structured information between systems.
● It defines a standard XML format for messages, which typically include headers
and bodies.
● SOAP messages are typically transported over HTTP. Other protocols like SMTP
(Simple Mail Transfer Protocol) and JMS (Java Message Service) can also be
used.
● SOAP provides a robust messaging framework with features such as security,
reliability, and transactionality.
● It follows a contract-based approach, where the structure of messages and
operations is defined in a WSDL (Web Services Description Language)
document.

Representational State Transfer (REST)

● REST is an architectural style for designing networked applications, emphasizing
simplicity, scalability, and statelessness.
● It relies on standard HTTP methods such as GET, POST, PUT, DELETE for
performing CRUD (Create, Read, Update, Delete) operations on resources.
● RESTful APIs expose resources as URIs (Uniform Resource Identifiers) and use
HTTP status codes for indicating the outcome of operations.
● REST APIs are lightweight, easy to understand, and widely adopted for building
web services, especially for public-facing APIs.

35
Graph QL
● GraphQL is a query language and runtime for APIs developed by Facebook.
● It allows clients to specify exactly what data they need, enabling more efficient
and flexible data retrieval compared to traditional REST APIs.
● With GraphQL, clients can request multiple resources in a single query and
receive only the data they ask for, reducing over-fetching and under-fetching of
data.
● GraphQL APIs are introspective, meaning they expose a schema that describes
the types of data available and the operations that can be performed.

Examples and Code Snippets

SOAP:
● Example: Integrating a payment gateway API into an e-commerce platform.
● Code Snippet: SOAP
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://www.example.com/webservice">
<soapenv:Header/>
<soapenv:Body>
<web:ProcessPayment>
<web:Amount>100.00</web:Amount>
<web:CardNumber>1234567890123456</web:CardNumber>
<!-- Additional Payment Details -->
</web:ProcessPayment>
</soapenv:Body>
</soapenv:Envelope>

REST:
● Real-life Example: Retrieving weather data from a public API.
● Code Snippet (Python using requests library)

import requests

url = "https://api.weather.com/data"
params = {"city": "Bangalore", "format": "json"}

36
response = requests.get(url, params=params)
weather_data = response.json()
print(weather_data)

GraphQL:
● Example: Fetching user profile data from a social media platform API.
● Code Snippet (GraphQL query)
query {
user(id: "[email protected]") {
id
name
email
posts {
id
title
content
}
}
}

Microservices Architecture and its Relationship with SOA

Microservices architecture is an approach to developing software applications as a

collection of small, independently deployable services. Each service is self-contained,
focused on a specific business capability, and communicates with other services
through well-defined APIs.

Decentralized Data Management:

● In microservices architecture, each service manages its own data store, which is
often optimized for the service's specific requirements.
● This decentralized approach to data management allows services to be more
autonomous and reduces dependencies between services.
● Services can choose the most suitable data storage technology for their needs,
such as relational databases, NoSQL databases, or in-memory caches.

37
Example:

Consider a social media platform where each microservice handles a specific

functionality, such as user management, post management, and notification handling.
Each service manages its own database tailored to its requirements, enabling flexibility
and scalability.

Code Snippet

# Example of a microservice handling user management

class UserService:
def __init__(self, db):
self.db = db

def create_user(self, user_data):

# Code to create a new user in the user database
pass

def get_user(self, user_id):

# Code to retrieve user information from the user database
pass

# Example usage
user_db = UserDatabase()
user_service = UserService(user_db)
user_service.create_user(user_data)

Independent Deployment:

● Microservices can be independently deployed, updated, and scaled without

affecting other services in the system.
● This flexibility allows teams to release new features and fixes more frequently,
improving agility and time-to-market.
● Each service can have its own deployment pipeline, testing strategy, and release
schedule, reducing coordination overhead.

Example:

In a retail application, the product catalog service can be updated with new product
information independently of the checkout service. This allows the product team to

38
release updates to the catalog without waiting for the checkout team, enabling faster
innovation.

Code Snippet

# Example deployment configuration for a microservice

services:
- name: product-catalog
version: v1.2.0
replicas: 3
image: product-catalog:v1.2.0
ports:
- 8080
environment:
- ENVIRONMENT=production
- DATABASE_URL=postgres://user:password@localhost:5432/catalog

Infrastructure Automation

● Microservices architecture relies heavily on automation for provisioning, scaling,

and managing infrastructure.
● Infrastructure is often defined as code using tools like Terraform or Kubernetes,
allowing for consistent and repeatable deployments.
● Automation enables efficient resource utilization, improves system reliability, and
reduces manual overhead.

Example:

In a cloud-native microservices application, infrastructure resources such as virtual

machines, containers, and networking are provisioned and managed automatically
using Infrastructure as Code (IaC) tools like Terraform or AWS CloudFormation.

Code Snippet:

# Example Terraform configuration for provisioning AWS resources

resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
39
 Name = "example-instance"
}
}

Relationship with SOA

● Microservices architecture shares similarities with Service-Oriented Architecture

(SOA) in its focus on modularization, loose coupling, and service autonomy.
● Both architectures aim to improve agility, scalability, and maintainability by
breaking down monolithic systems into smaller, more manageable components.
● However, microservices tend to be more fine-grained and decentralized
compared to traditional SOA, which often relies on heavyweight middleware and
centralized governance.

Example

A comparison between a traditional SOA implementation and a microservices-based approach

in a banking application. While SOA might involve large, monolithic services managed by a
central ESB (Enterprise Service Bus), microservices would consist of smaller, independently
deployable services handling specific banking functions like account management, transactions,
and customer notifications.

Code Snippet

// Example microservice handling transaction processing

@RestController
@RequestMapping("/transactions")
public class TransactionController {

@Autowired
private TransactionService transactionService;

@PostMapping("/process")
public ResponseEntity<Transaction>
processTransaction(@RequestBody TransactionRequest request) {
Transaction transaction =
transactionService.processTransaction(request);
return ResponseEntity.ok(transaction);
}
}

40
Containerization and Orchestration

Containerization

Containerization is a lightweight, portable, and efficient method for packaging,

distributing, and running applications. Containers encapsulate everything needed to run
an application, including the code, runtime, libraries, and dependencies, into a single
unit.

Source: https://www.xenonstack.com/insights/containerization

Docker Container

● Docker is a leading containerization platform that allows developers to build,

ship, and run applications in containers.
● Docker containers are isolated environments that share the host operating
system's kernel, providing consistency across different environments.
● Docker uses Dockerfiles to define container configurations and Docker images to
package applications and their dependencies.

41
 Source: Alexsoft

Containerization - Pros and Cons

Reference: https://www.xenonstack.com/insights/containerization

● Pros
○ Portability - no dependency on hardware, containers (dockers) abstracts
running of application on any host
○ Lightweight - contains only application specific requirements and no
unnecessary OS overhead, keep it lightweight
○ Speed - more faster and efficient in application bring up
○ Cost-effective - cost of running containers is much lower than running
virtual machines
● Cons
○ Security - vulnerability of container engine and poor access control has
associated risks
○ Manageability - managing large number of containers is challenging
○ Monitoring - needs a good monitoring system for effective maintenance
and troubleshooting.

42
Example: A web application running in a Docker container:

# Dockerfile
FROM python:3.9-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Kubernetes Orchestration

● Kubernetes is an open-source container orchestration platform for automating

the deployment, scaling, and management of containerized applications.
● Kubernetes abstracts away underlying infrastructure complexities and provides
features like automatic scaling, load balancing, and self-healing.
● Kubernetes organizes containers into logical units called pods, which are the
smallest deployable units in Kubernetes.

Example: A Kubernetes deployment manifest for a web application:

43
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: my-webapp:latest
ports:
- containerPort: 80

Service Mesh Technologies

● Service mesh technologies like Istio and Linkerd provide a dedicated

infrastructure layer for handling service-to-service communication within a
containerized environment.
● Service meshes offer features like traffic management, load balancing,
encryption, and observability to improve reliability, security, and performance.
● Service mesh components, such as sidecar proxies, intercept and manage
communication between services transparently.

Example- Istio service mesh

Istio configuration for implementing mutual TLS encryption between services:

# destination-rule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: default-mtls
spec:
host: "*.default.svc.cluster.local"
44
 trafficPolicy:
tls:
mode: ISTIO_MUTUAL

Event-Driven Architecture
Event-Driven Architecture (EDA) is an architectural pattern where the production,
detection, consumption, and reaction to events are central to the design. EDA enables
decoupled, scalable, and responsive systems by promoting loose coupling between
components and allowing them to communicate asynchronously through events.

Event Sourcing

● Event Sourcing is a pattern where changes to an application's state are captured

as a sequence of immutable events.
● Instead of storing the current state of an entity, Event Sourcing stores a log of
events that represent state transitions over time.
● Event Sourcing enables reconstructing the current state of an entity at any point
in time by replaying the events.

Example: FinTech app

In a banking application or a FinTech application, each transaction, such as deposits,

withdrawals, UPI payments, Wallet updates, is recorded as an event. The current
account balance is derived by replaying these events.

Command Query Responsibility Segregation (CQRS)

● Command Query Responsibility Segregation (CQRS) is a pattern that separates

the responsibility of handling commands (write operations) from queries (read
operations).
● In CQRS, different models are used to process commands and queries, allowing
each model to be optimized for its respective use case.
● CQRS simplifies scalability, as read-heavy and write-heavy operations can be
scaled independently.
45
Example: e-commerce platform

In an e-commerce platform, the command model handles order creation, modification,

and cancellation, while the query model handles product catalog queries and order
history retrieval.

Event-Driven Messaging Systems

● Event-Driven Messaging Systems facilitate communication between decoupled

components by sending and receiving events.
● Event messages contain information about a specific event, such as its type,
timestamp, and payload data.
● Messaging systems like Apache Kafka, RabbitMQ, and Amazon SNS/SQS
provide reliable, scalable, and fault-tolerant event delivery.

Example: Ride-sharing App

A ride-sharing application uses event-driven messaging to notify drivers of ride

requests, update the status of ongoing rides, and handle payment transactions.

Code Snippet: Publishing an event to a message broker (using Apache Kafka):

from kafka import KafkaProducer

import json

producer = KafkaProducer(bootstrap_servers='localhost:9092',
value_serializer=lambda v:
json.dumps(v).encode('utf-8'))

event = {'type': 'amount_credited', 'transaction_id': '12345',

'amount': 100.00}
producer.send('orders', value=event)
producer.flush()

API Management and Governance

API Management and Governance involve the planning, design, deployment, and
monitoring of APIs to ensure they meet business objectives, adhere to standards, and

46
provide a positive developer experience. It encompasses various aspects such as API
design, documentation, security, versioning, and usage policies.

API Design Principles

● API Design Principles focus on creating APIs that are intuitive, consistent, and
easy to use.
● Principles include using descriptive and meaningful endpoint URLs, following
RESTful design principles, using HTTP methods appropriately, and providing
clear and concise documentation.

Example: Design an API for a weather service

Designing an API for a weather service that provides endpoints like /weather/{city} to
retrieve weather information for a specific city and /forecast/{city} to get a weather
forecast.

Developer Portals

● Developer Portals are web-based platforms that provide developers with

resources, documentation, and tools for consuming APIs.
● Portals typically include API documentation, getting started guides, code
samples, SDKs, and interactive API explorers to facilitate API consumption.

Example: Github Developer Portal: https://github.com/topics/developer-portal

The GitHub Developer Portal offers comprehensive documentation, tutorials, and API
reference guides for developers integrating with GitHub's APIs.

Rate Limiting and Quotas

● Rate Limiting and Quotas control the number of requests an API consumer can
make within a specific time frame to prevent abuse and ensure fair usage.
● Rate limits are typically enforced based on factors such as API keys, user
authentication, IP addresses or subscription plans.

47
 Source: https://systemsdesign.cloud/SystemDesign/RateLimiter

Example: Implementing rate limiting for a social media API to restrict users to 1000
requests per hour to prevent spamming and ensure server stability.

Code Snippet: Implementing rate limiting using Flask and Redis:

from flask import Flask, jsonify, request

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
from redis import Redis

app = Flask(__name__)
limiter = Limiter(
app,
key_func=get_remote_address,
default_limits=["1000 per hour"]
)
redis = Redis(host='localhost', port=6379)

@app.route('/api/resource')
@limiter.limit("10 per minute")
def get_resource():
return jsonify({'data': 'Resource data'})

if __name__ == '__main__':
app.run(debug=True)

48
 Lab Exercises - Solution

Exercise 1: Overview of SOA: Implement a REST Web Service

Code Example: Develop a simple web service using a framework like Flask (Python),
Spring Boot (Java), or Express (Node.js). Demonstrate how clients can consume this
service to retrieve or manipulate data.

REST Web Service - Python Implementation (GET and POST Methods)

Prerequisites:
● Python Installation version 3.X
● Install Flask - use pip or pip3 based on your installation of python
● Update host firewall (if configured) to allow
● curl command

Install Flask using pip:

pip3 install flask

# Save the following a file called webserver.py

# Create a flask application

from flask import Flask, jsonify, request

app = Flask(__name__)

# Sample data
books = [
{"id": 1, "title": "Book 1", "author": "Author 1"},
{"id": 2, "title": "Book 2", "author": "Author 2"},
{"id": 3, "title": "Book 3", "author": "Author 3"}
]

# Endpoint to get all books

@app.route('/books', methods=['GET'])
def get_books():
return jsonify(books)

49
# Endpoint to get a specific book by id
@app.route('/books/<int:id>', methods=['GET'])
def get_book(id):
book = next((book for book in books if book['id'] == id),
None)
if book:
return jsonify(book)
else:
return jsonify({"error": "Book not found"}), 404

# Endpoint to add a new book

@app.route('/books', methods=['POST'])
def add_book():
data = request.json
new_book = {
"id": len(books) + 1,
"title": data['title'],
"author": data['author']
}
books.append(new_book)
return jsonify(new_book), 201

if __name__ == '__main__':
app.run(debug=True)
```

Run the application using python

python app.py

The Flask application should be running. Invoke the service using You can consume
this service using HTTP client such as curl

To get all books, this demonstrates GET method of Web Service

curl http://localhost:5000/books

To get a specific book by id:

curl http://localhost:5000/books/1

To add a new book:

50
 curl -X POST -H "Content-Type: application/json" -d
'{"title":"New Book","author":"New Author"}'
http://localhost:5000/books

Alternate command

curl -X POST -H "Content-Type: application/json" -d "{\"title\":\"New Book\", \"author\":\"New

Author\"}" http://localhost:5000/books

REST Web Service - Spring Boot (Java) Implementation

​ First, make sure you have Spring Boot installed. Prerequisites:

● Install Spring Boot:
https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html
#getting-started.installing
● Install Maven: https://maven.apache.org/
● Install TomCat server: https://tomcat.apache.org/download-10.cgi
● Configure Spring Boot and Tomcat
https://www.baeldung.com/spring-boot-configure-tomcat
● Add Spring Boot dependencies to Maven by creating pom.xml:

// Create pom.xml

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>

// Create Java code

import org.springframework.boot.SpringApplication;
import
org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.*;

import java.util.ArrayList;

import java.util.List;
import java.util.Optional;

51
@SpringBootApplication
@RestController
public class Application {

private List<Book> books = new ArrayList<>();

public static void main(String[] args) {

SpringApplication.run(Application.class, args);
}

@GetMapping("/books")
public List<Book> getBooks() {
return books;
}

@GetMapping("/books/{id}")
public Book getBook(@PathVariable int id) {
Optional<Book> result = books.stream().filter(book ->
book.getId() == id).findFirst();
return result.orElse(null);
}

@PostMapping("/books")
public Book addBook(@RequestBody Book book) {
book.setId(books.size() + 1);
books.add(book);
return book;
}
}

class Book {
private int id;
private String title;
private String author;

// Getters and setters

public int getId() {

return id;
}

public void setId(int id) {

this.id = id;
52
 }

public String getTitle() {

return title;
}

public void setTitle(String title) {

this.title = title;
}

public String getAuthor() {

return author;
}

public void setAuthor(String author) {

this.author = author;
}
}

​ Run the application. Spring Boot will automatically start an embedded Tomcat server
on port 8080 by default. You can now access the service using “curl” HTTP client.

// To get all books:

curl http://localhost:8080/books

// To get specific book

curl http://localhost:8080/books/1

// To add a new book:

curl -X POST -H "Content-Type: application/json" -d

'{"title":"New Book","author":"New Author"

53
Exercise 2: Principles and Concepts of SOA
- Code Example: Implement a basic service demonstrating loose coupling by using
asynchronous messaging (e.g., RabbitMQ or Kafka). Create a publisher service that
sends messages to a message broker and a consumer service that receives and
processes these messages independently.

Pub-Sub: Demonstrate a Publisher-Subscriber message exchange using

RabbitMQ.

Terminology

● A message broker is an intermediary service that helps reliable exchange

messages from one service called “producer” or “publisher” to another service
called “consumer” or “subscriber”.
● RabbitMQ is an open-source message-broker software that originally
implemented the Advanced Message Queuing Protocol (AMQP).
● One of the real time use cases of a message broker is for “communication
(comms)” service used in banking, ticketing and e-commerce applications to
post SMS or WhatsApp message to users about a transaction (e.g. credit / debit
amount, order booking, shipment details, etc), In this case, a order booking
service will post a message to “comms” service via message broker, this allows
asynchronous and non-blocking communication between producer and
consumer.

Prerequisites:
● Install Erlang
○ Erlang is a programming language developed by Ercisson in 1986. Erlang
is the programming language used to code WhatsApp
○ RabbitMQ is written in Erlang
○ Erlang Installation:
■ Windows Installer:
https://github.com/erlang/otp/releases/download/OTP-26.2.3/otp_wi
n64_26.2.3.exe
54
 ● Install RabbitMQ
○ https://www.rabbitmq.com/docs/install-windows#installer

RabbitMQ tutorial - "Hello world!"

● This consists of two programs in Python; a producer (sender) that sends a single
message and a consumer (receiver) that receives messages and prints them out.
It's a "Hello World" of messaging.
● https://www.rabbitmq.com/tutorials/tutorial-one-python

55
Exercise 3: Demonstrate a Content Delivery Network (CDN)

Design a simple Content Delivery Network (CDN) using Python with focus
on distributing content efficiently to users from multiple edge servers

Tech Stack:

● Python programming language

● Flask framework (for building HTTP servers)
● Requests library (for making HTTP requests)
● Create a folder called content and store a short video file or an image.

Step 1: Setup Edge Servers

# edge_server.py

from flask import Flask, send_file

import os

app = Flask(__name__)

@app.route('/content/<path:path>')
def serve_content(path):
content_dir = 'content'
file_path = os.path.join(content_dir, path)
return send_file(file_path)

if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)

Step 2: Load Balancer

# load_balancer.py

from flask import Flask, request, redirect

import random

app = Flask(__name__)

edge_servers = ['http://localhost:5000', 'http://localhost:5001',

'http://localhost:5002']

56
@app.route('/')
def load_balancer():
# randomly select one of the servers
selected_server = random.choice(edge_servers)
return redirect(selected_server)

if __name__ == '__main__':
app.run(host='0.0.0.0', port=8000)

Step 3: Run Edge Servers and Load Balancer

● Open three terminal windows and run the edge servers:

python edge_server.py

● In another terminal window, run the load balancer:

python load_balancer.py

Step 4: Accessing Content through CDN

● Open a web browser and access http://localhost:8000/content/image.jpg

● Refresh the page multiple times to observe content served from different edge servers.

Sample Results:

● When accessing content through the load balancer, you'll notice that the requests are
redirected to different edge servers randomly, demonstrating load balancing.
● Each time you refresh the page, the image file (image.jpg) will be served from a different
edge server, showcasing content distribution.
● You can add more content to the content directory and access them through the CDN to
observe the distribution of different content files.

This basic setup demonstrates the concept of a Content Delivery Network (CDN) using Python and

Flask, focusing on load balancing and content distribution among multiple edge servers.

57
Exercise 4: Build a AI-driven Customer Sentiment analysis service

Design a simple AI driven Customer Sentiment analysis service using ML

models and integrate it into a SOA application.

To build a simple AI-driven service using machine learning models and integrate it into a
Service-Oriented Architecture (SOA), you can follow these steps and use the following
tools and code snippets:

1. Objective: Develop a sentiment analysis service that analyzes customer reviews

and provides feedback on product sentiment.
2. Machine Learning Models: Use a pre-trained natural language processing (NLP)
model for sentiment analysis. For this example, we'll use the Hugging Face
Transformers library with a pre-trained BERT mode (Bidirectional Encoder
Representations from Transformers)
3. Refer: https://huggingface.co/docs/transformers/en/model_doc/bert
4. Tools:
● Python3 for coding
● Hugging Face Transformers library for NLP models
● Website: https://huggingface.co/docs/transformers/quicktour
● Flask for creating the web service
● Docker for containerization
5. Implementation:
● Install libraries: pip3 install transformers flask
● Create a Python script for the sentiment analysis service
(sentiment_service.py)
● Code: save this code as sentiment_service.py

from transformers import pipeline

from flask import Flask, request, jsonify

app = Flask(__name__)
nlp = pipeline("sentiment-analysis")

@app.route("/analyze_sentiment", methods=["POST"])
def analyze_sentiment():
data = request.json
text = data["text"]
result = nlp(text)[0]
return jsonify({"text": text, "sentiment": result["label"],
"confidence": result["score"]})

58
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)

● Above script defines a Flask application with a single endpoint

/analyze_sentiment that accepts POST requests. When a request is
received with a JSON payload containing the text to analyze, the
sentiment analysis model is invoked to analyze the text, and the result is
returned as JSON containing the analyzed text, sentiment label, and
confidence score. RESTful API endpoint server is accessible via HTTP.
● Create a Dockerfile to containerize the service save it as: Dockerfile
FROM python:3.9-slim
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
CMD ["python", "sentiment_service.py"]

● Build and run the Docker container:

docker build -t sentiment-service .
docker run -p 5000:5000 sentiment-service

6. Integration with SOA:

● Use ‘curl’ to invoke sentiments API:

Input: (Good Sentiment)

curl -X POST http://localhost:5000/analyze_sentiment \
-H "Content-Type: application/json" \
-d '{"text": "I like this product! It's awesome."}'

Output:
{
"text": "I like this product! It's awesome.",
"sentiment": "POSITIVE",
"confidence": 0.9998
}

Input: (Bad Sentiment)

curl -X POST http://localhost:5000/analyze_sentiment \
-H "Content-Type: application/json" \
-d '{"text": "This product is bad! Don’t buy it."}'

Output:
59
 {
"text": "This product is bad! Don’t buy it.",
"sentiment": "NEGATIVE",
"confidence": 0.9985
}

Reference Articles

1. Why Amazon Retail Went to SOA Architecture

https://highscalability.com/why-amazon-retail-went-to-a-service-oriented-architect
ure/
2. Hugging Face:
https://huggingface.co/docs/transformers/quicktour

60