SOA involves breaking large applications into smaller, independent services that communicate with each other, while monolith architecture keeps all application code and components together within a single codebase; services in SOA should have well-defined interfaces and be loosely coupled, stateless, and reusable; components of SOA include services, service consumers, registries, transports, and protocols like SOAP and REST that allow services to communicate.

1. SOA and Monolith Architecture -
Micro Services
Types of software architectures

2. Software Architecture
•Designs the overall structure of the software
system
•It provides a strategic and structured approach
to building software systems

3. Software engineer & Software architect's
•Software Engineer is primarily responsible for the actual
coding or programming of the software.
•Using the software architect's design, the software engineer
translates the architectural plans into lines of code.
•A software engineer is the one who executes a plan that is
created by a software architect.
•Software Engineer utilizes an array of tools and
technologies, including programming languages like Python
or Java, development environments, version control
systems, and testing tools.

4. Software architect's
• Architects often have a broader view of the entire
system and are involved in making decisions about
technology stack, frameworks, and overall system
design

5. Real time example ( BookMyShow APP) – For Service
• BookMyShow is a popular platform for booking tickets for movies,
events, and plays.
• They often have promotional offers and deals that can help you save
money on your ticket purchases.
• Bookmyshow allows you to save your Debit/Credit card, Net
Banking, Gift Voucher, UPI or Redeem Points details under the
"Quick Pay" option. I

6. Example - Patient Management Systems
• healthcare organization, such as patient management systems and
electronic health record (EHR) systems, need to register patients.
These systems can call a single, common service to perform the
patient registration task.

7. What is Service?
• A service is a well-defined, self-contained function that
represents a unit of functionality.
• A service can exchange information from another service.
• It is not dependent on the state of another service.
• It uses a loosely coupled, message-based communication
model to communicate with applications and other services.
Service consumer sends a service request to the
service provider, and the service provider sends
the service response to the service consumer.
The service connection is understandable to both
the service consumer and service provider.

8. Service
• refers to a software functionality, or a set of software functionalities (such as
the retrieval of specified information or the execution of a set of operations)
with a purpose that different clients can reuse for different purposes,
together with the policies that should control its usage (based on the identity
of the client requesting the service
• One example is the separation of the business function "Manage Orders" into
services such as "Create Order", "Fulfill Order", "Ship Order", "Invoice
Order" and "Cancel/Update Order".
• These business functions have to have a granularity that is adequate in the
given project and domain context.

9. Service Oriented Architecture (SOA)
• In SOA, the large application is split up into multiple smaller services
that are deployed independently.
• is a method of software development that uses software components
called services to create business applications.
• Each service provides a business capability, and services can also
communicate with each other across platforms and languages.
• Developers use SOA to reuse services in different systems or combine
several independent services to perform complex tasks.
• It is an architectural design which includes collection of services in a
network which communicate with each other.
• It is a design pattern which is designed to build distributed systems that
deliver services to other applications through the protocol
• It is only a concept and not limited to any programming language or
platform.

10. Service Connections
• Services - one or more published interfaces.
• Service provider - implements a service
specification.
• Service consumer - called as a requestor or
client
• Service locator - It is a service provider that
acts as a registry. It is responsible for
examining service provider interfaces and
service locations.
• Service broker - that pass service requests to
one or more additional service providers.

11. Why to use SOA?
• SOA is widely used in market which responds quickly and makes effective
changes according to market situations.
• The SOA keep secret the implementation details of the subsystems.
• It allows interaction of new channels with customers, partners and
suppliers.
• It authorizes the companies to select software or hardware of their choice as
it acts as platform independence.

12. What are the basic principles of service-oriented
architecture?
• Interoperability-Each service in SOA includes description documents that
specify the functionality of the service and the related terms and
conditions
• Loose coupling -Services in SOA should be loosely coupled, having as little
dependency as possible on external resources such as data models or
information systems. They should also be stateless without retaining any
information from past sessions or transactions..
• Abstraction -Clients or service users in SOA need not know the service's
code logic or implementation details.
• Granularity -Services in SOA should have an appropriate size and scope,
ideally packing one discrete business function per service. Developers can
then use multiple services to create a composite service for performing
complex operations.

13. How does service-oriented architecture
work?
• In service-oriented architecture (SOA), services function independently
and provide functionality or data exchanges to their consumers.
• The consumer requests information and sends input data to the service.
• The service processes the data, performs the task, and sends back a
response.
• For example, if an application uses an authorization service, it gives the
service the username and password. The service verifies the username
and password and returns an appropriate response.

14. How does service-oriented architecture
work?
• The basic principles of service-oriented architecture are
independent of vendors, products and technologies.
• A service is a discrete unit of functionality that can be accessed
remotely and acted upon and updated independently, such as
retrieving a credit card statement online.

15. Communication protocols
• Services communicate using established rules that determine data
transmission over a network.
• These rules are called communication protocols.
• Some standard protocols to implement SOA include the following:
• Simple Object Access Protocol (SOAP) - is a way to pass information
between applications in an XML format.
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java Message Service (JMS)

16. Characteristics of SOA
• They are loosely coupled.
• They support interoperability.
• They are location-transparent
• They are self-contained.

17. Components of service-oriented architecture
Transport - the service requests from the service consumer to the
service provider and service responses from the service provider to the
service consumer.
Service Communication Protocol - It allows the service provider
and the service consumer to communicate with each other.
Service Description - It describes the service and data required to
invoke it.
Service - It is an actual service.
Business Process - It represents the group of services called in a
particular sequence associated with the particular rules to meet the
business requirements.
Service Registry - It contains the description of data which is used
by service providers to publish their services.

18. Components of service-oriented architecture
Quality of Service aspects
• Policy - It represents the set of protocols according to which a
service provider make and provide the services to consumers.
• Security - It represents the set of protocols required for
identification and authorization.
• Transaction - It provides the surety of consistent result. This
means, if we use the group of services to complete a business
function, either all must complete or none of the complete.
• Management - It defines the set of attributes used to manage
the services.

19. Business Activity
Monitoring(BAM)
used by the products
to display the runtime
details in the graphical
system.
The BAM products
includes adapters or
sensors which are used
to access the data
using the Java, PL/SQL
and other languages.
CEP stands for Complex Event
Processing which allows to
browse event streams based
on the certain pattern which
can be uncorrelated in time or
content.
ESB stands for Enterprise Service Bus which gives patterns that are
liable for the tasks and ranges from routing to reachability, allow the
interaction between message and protocol transformation and
manages the SOA environment.

20. Enterprise Service Bus (ESB)
• An Enterprise Service Bus (ESB) is a software product that provides a
platform for integrating various applications in a service-oriented
architecture (SOA) environment, managing web services, and
message brokering between them.
• ESB support the use of multiple protocols and message formats,
allowing different applications to communicate with each other
seamlessly.
• The best enterprise service bus depends on the specific needs of an
organization. Some popular ESB tools include MuleSoft, Apache
ServiceMix, and IBM Integration Bus.

21. Enterprise Service Bus (ESB)
• In a service-oriented architecture, APIs are exposed as web services made
available via specific formats and transports such as JMS or XML.
• An ESB is layered on top of those APIs to provide a more comprehensive
solution that includes message routing, transformation, mediation, security,
and so on.
• ESBs are designed for environments that involve multiple systems
communicating with each other, providing connections between services and
the clients that access them.
• ESBs are specifically designed for application integration in a service-
oriented environment.

23. Banking Examples of SOA
Internet Banking
Business Process: Stop Payment
Registry and Repository: Find Stop Payment Service, Charge Fee service
Security: Authenticate user
Manage and monitor
ESB: Routes to appropriate core system
Data Services
Process Services
Business Logic: If Customer_Status = Gold Service_Fee = $8 else
Service_Fee = $20
Orchestration:
Fee database
DDA / Current Account

26. SOA basically delivers four types of service:
Functional Service: service for business applications.
Application Services: for deploying and developing applications.
Enterprise Services: for specifically implementing functionality.
Infrastructure Service: for nonfunctional purposes and can include
security and authentication.

27. Advantages of SOA
• Easy to integrate - is a service specification that provides implementation
transparency.
• Manage Complexity - the complexities get isolated, and integration becomes
more manageable.
• Platform Independence – It can communicate with other applications
through a common language.
• Loose coupling - It facilitates to implement services without impacting other
applications or services.
• Parallel Development -, it provides parallel development. As SOA follows
layer-based architecture
• The SOA services are easily available to any requester.
• Reliable - As services are small in size, it is easier to test and debug them.

28. Disadvantages
• It requires high investment cost (means large investment on
technology, development and human resource).
• There is greater overhead when a service interacts with another
service which increases the response time and machine load while
validating the input parameters.
• SOA is not suitable for GUI (graphical user interface) applications
which will become more complex when the SOA requires the heavy
data exchange.

29. What is a Monolithic Application?
•It is a software architecture where all components
and functionalities of an application are tightly
integrated into a single codebase, executed as a
single unit, and typically deployed as a single
application.

30. What is a Monolithic Application?
•it's an all-in-one approach where everything, including
the user interface, business logic, data access, and any
other necessary components, resides within a single
application stack.

32. Monolithic application components
• Authorization: To give authorization to a user and allow them to use the
application.
• Presentation: To handle Hypertext Transfer Protocol requests and respond
with Extensible Markup Language or JavaScript Object Notation
• Business logic: The fundamental business logic that drives the
application’s functionality and features.
• Database Layer: Includes the data access object that accesses the
application’s database.
• Application Integration: Controls and manages the application’s
integration with other services or data sources.

33. Ex: Amezon Website

34. Tightly coupled and
run as a single service

35. Characteristics of Monolithic Applications
• Single Codebase: In a monolithic architecture, all parts of the application
share a single codebase. This makes it easy to manage and maintain because
there is no need to coordinate different code repositories.
• Tight Integration: Components in a monolithic application are tightly
integrated, enabling seamless communication and data sharing between
different parts of the application.
• Single Deployment: Monolithic applications are typically deployed as a single
unit, making it easier to manage deployment and scaling.
• Shared Resources: Components within the monolith share resources such as
memory and CPU, which can lead to efficient resource utilization.
• Simplified Development: Developing a monolithic application can be simpler
in the initial stages, as you don't need to deal with complex distributed
systems.

36. Advantages of Monolithic Applications
• Ease of Development
• Simplicity
• Debugging and Testing .
• Performance
• Cost-Effectiveness - For smaller projects or startups with limited
resources, monolithic applications can be cost-effective.
• The simplicity of development and deployment reduces the
operational overhead, allowing you to allocate resources more
efficiently.

37. Considerations and Challenges
• Scalability
• Maintenance: As monolithic applications become larger and more
complex, they can become harder to maintain and upgrade..
• Deployment: Rolling out updates to a monolithic application may
require downtime, impacting the user experience.
• Technology Stack: Choosing the right technology stack is critical in a
monolithic architecture. An improper choice can lead to bottlenecks
and performance issues.
• Team Size: The size and expertise of your development team should
align with the complexity of the monolithic application. Smaller teams
may find it easier to manage and maintain smaller monoliths.

38. Entirely Single
Application – any single
function is fail – totally
down
Single Application Single Application

40. When millions of users access an single application-
single instance – apply multiple VM/websites – move to
entire app ex: Amazon products – is high volume
Autoscaling-cloud

41. Microservices Architecture
• It is an architectural style that structures an application as a collection of
services that are:
• Independently deployable
• Loosely coupled
• Services are typically organized around business capabilities. Each service
is often owned by a single, small team.
• The microservice architecture enables an organization to deliver large,
complex applications rapidly, frequently, reliably and sustainably - a
necessity for competing and winning in today’s world.

42. Microservices Architecture
• Microservices allow a large application to be separated into smaller
independent parts, with each part having its own realm of
responsibility. To serve a single user request, a microservices-based
application can call on many internal microservices to compose its
response.

47. How to move from Monolithic to
Microservices?

49. Difference
SOA. MSA.
It is a huge collection of services in which services
communicate with each other.
It is general architecture that takes large number of
services and break down into small services or
shareable component.
It is used to share the data storage. It has independent data storage.
It supports various multiple protocol. It supports HTTP/REST lightweight protocol.
In service oriented architecture, there is a multi-
threaded with more handle I/O.
In Micro service Architecture, there is single-
threaded with non-locking I/O handle.
It has common platform for all services.
It has platform like Nodejs is used and application
server not used.
It uses of container is less popular Docker linux. Its container work very well.
It uses traditional database. It uses non-relational database.
It uses ESB services for communication.
It does not use ESB services. It has a simple
messaging system.
It have common governance standard. Relaxed governance with more focus on people.

50. Data Duplication: Changing data at the primary source is one of the basic purposes of providing SOA for all applications. This
can reduce the necessity of maintaining complicated data synchronization patterns. Microservice applications usually have
local access to data. This, however, means there are sometimes duplications of data in the other systems, which can cause
complexity.
Data Storage: Microservices usually have individual data storage. SOA systems normally share data storage units.
Reusability: Reusing integrations is one of the primary goals of SOA. Reusing components in microservices throughout an
application can cause dependencies that limit resilience and agility.
Speed: Sharing a basic architecture can assist SOAs when simplifying troubleshooting and ongoing development. On the
other hand, SOAs may work more slowly, which limits sharing and favors duplication.
Communication: An SOA system provides each service a basic communication mechanism. This is an ESB (enterprise service
bus). This means a single point of failure can disrupt the entire enterprise. With microservice architecture, every service is
independent of one another.
Granularity: SOA exhibits a wide range of services. These can include small, specialty services to those that are enterprise-
wide. Microservices are all specialty. Programmers create each one to carry out one particular service extremely well.
Interoperability: SOAs are open to diverse messages and protocols. Microservices keep things simple and use messaging such
as HTTP/REST.
SOA vs. microservices

51. What are the Similarities?
Both are collections that focus on performing specific
functions.
Both are smaller in overall scope than one large monolithic
architecture.
Both require decentralization in the internal culture with cross-
functional collaborative abilities.
Both allow the choice of program languages that best suit
each service.
SOA and Microservices

55. Examples of Microservices
• Amazon and Netflix, Uber - Amazon added more developers to work
on it, and the codebase became bigger. This made the architecture more complex
to modify, adding overheads to the process and slowing down the software
development lifecycle.

56. Which is Best for You?
• You would likely want an SOA if the answer is yes to the following questions:
• Do you have a large, diverse application environment?
• Do you want a system that can support multiple messaging protocols?
• Do you want a messaging system that works through an enterprise service bus?
• You would probably want microservices if the following apply to your organization:
• Do you have a smaller environment that doesn't require a strong communication layer?
• Do you need a system that provides extensive scalability?
• Do you want to build a smaller project with simpler messaging systems?

57. Examples of Microservices Frameworks for
Java
• Spring Boot. This is probably the best Java microservices framework that works on top of
languages for Inversion of Control, Aspect-Oriented Programming, and others.
• Jersey. This open-source framework supports JAX-RS APIs in Java and is very easy to use.
• Swagger. Helps you document API as well as gives you a development portal, which
allows users to test your APIs.
• Quarkus. This is a lightweight Java framework optimized for GraalVM and HotSpot, and
it’s tightly integrated with Kubernetes.
• Micronaut. It’s based on the Netty framework, which makes it well-suited for
microservices that need to handle a lot of traffic.
• Helidon. A microservices framework developed by Oracle. It is based on the MicroProfile
specification, making it interoperable with other MicroProfile-based frameworks.
• AxonIQ. A microservices framework designed for event-driven architectures. It provides
a comprehensive toolkit for building event-driven microservices, including a message
bus, event sourcing, and CQRS.

58. What do you mean by middleware?
• Middleware is software that different applications use to communicate
with each other.
• It provides functionality to connect applications intelligently and
efficiently so that you can innovate faster.
Example of middleware
• When you submit a form on a website, your computer sends the request in
XML or JSON to the web server. Then, the web server runs the business
logic based on the request, retrieves information from databases, or
communicates to other microservices using different protocols.
https://www.integrate.io/glossary/what-is-
middleware/#:~:text=APIs%20have%20become%20one%20of,access%20with%20a%20simple%20call.

59. What is DevOps in full?
• DevOps (a portmanteau of “development” and “operations”) is the
combination of practices and tools designed to increase an
organization's ability to deliver applications and services faster than
traditional software development processes.
• DevOps is a set of practices, tools, and a cultural philosophy that
automate and integrate the processes between software development
and IT teams.
• It emphasizes team empowerment, cross-team communication and
collaboration, and technology automation.

60. What is decoupling in API?
• provide a centralized place for new services to be created.
• a practice for reducing operational dependencies across different
systems
• A decoupled architecture is a broader design concept that aims to
minimize dependencies between components, while
microservices is a specific implementation of decoupling where a
system is divided into independent, smaller services.

61. Use case
In this use case, the insurance system has a sales database that
is automatically updated with the customer transaction details
after a monthly payment is made. The following illustration
shows how to build this system by using the decouple
messaging pattern.
The workflow consists of the following steps:
The frontend application calls the API Gateway with the payment information after a user makes their monthly payment.
The API Gateway runs the “Customer” Lambda function that saves the payment information in an Amazon Aurora database,
writes the transaction details in a message to the “Sales" Amazon SQS, and responds to the calling system with a success
message.
A “Sales” Lambda function pulls the transaction details from the SQS message and updates the sales data. Failure and retry
logic to update the sales database is incorporated as part of the “Sales” Lambda function.
All operations don’t need to be completed in
a single transaction, and some operations
can be asynchronous.

62. References
• https://www.tutorialspoint.com/soa/index.htm
• https://www.javatpoint.com/monolithic-applications-in-java
• https://www.w3schools.in/service-oriented-architecture
• https://www.geeksforgeeks.org/microservices/
• https://www.geeksforgeeks.org/what-is-microservice-architecture-and-why-to-use-them/
• https://www.geeksforgeeks.org/monolithic-vs-microservices-architecture/
• https://www.geeksforgeeks.org/difference-between-service-oriented-soa-and-micro-service-
architecture-msa/
• https://www.javatpoint.com/microservices
• https://www.geeksforgeeks.org/microservices/
• https://www.youtube.com/watch?v=XjpxyGEUzBs
• https://www.linkedin.com/pulse/microservices-architecture-case-study-from-various-
suryawanshi/

63. Case study
• https://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3
• https://www.codingninjas.com/studio/library/system-design-netflix-a-
complete-architecture
• https://medium.com/@narengowda/netflix-system-design-dbec30fede8d
• https://www.linkedin.com/pulse/inside-netflix-deep-dive-its-cutting-edge-
system-architecture
• https://dev.to/karanpratapsingh/system-design-netflix-3d9g
• https://interviewnoodle.com/netflix-system-architecture-bedfc1d4bce5

64. Tutorial
• https://forms.gle/JUUimeyqfD9ZxYCk8