Service-oriented architecture (SOA) is a software design approach that focuses on building

functional, scalable software systems from individual components, called services. Services
can interact with one another to perform tasks, such as allowing someone to sign in once
and access a variety of business applications. In SOA, the emphasis is on modularity,
reusability, and interoperability —when businesses break complex applications down into
smaller, more manageable building blocks, the result is greater fl exibility and scalability.

Services aren’t hard-coded into applications. Instead, services are a published to a registry,
and when an application wants to use a service, it asks the registry to find the latest
version. In this way, services can be easily c hanged or updated by people without detailed
knowledge of the application. An SOA approach makes it easier to adapt to changing
business needs and to integrate systems that provide related functionality.

With SOA, individual services are loosely coupled an d can communicate and transmit data
as needed. For example, taking an SOA approach to developing cloud software creates
benefits, including:

Faster development cycles. By integrating and repurposing existing services, developers

are freed from the need to build many functions from scratch.

Easier maintenance. SOA allows individual services to be independently maintained

without creating a cascading impact on a larger pr oject. Debugging and troubleshooting
can be isolated for greater uptime.

Adaptability. SOA both preserves backward compatibility and facilitates future planning.
Developers can bring older services into a newer environment or even replace dated
services with newer versions that take advantage of updated hardware and cloud
infrastructure.

Scalability. Services can be monitored by the SOA management layer, and if performance
dips too low because of increased demand, new instances of a service can be started to
improve performance. Applications that use the service won’t know about the new
instances, they’ll just see that operating levels remain acceptable.

Examples of service-oriented architectures include:

Sites and apps with universal logins: Many companies seek to create application
environments where employees need only one password to access the applications they
need. An SOA architecture lets authentication management be handled by a set of services
that are then used by the company’s applications.

Applications offering in-app AI or analysis: One key advantage to running systems in the
cloud is that it’s a simple matter to use cloud services to improve the functionality of an
application. Cloud services can be simple, such as creating a graph from a set of data. They
can also be complex; think letting developers add AI functionality to an application through
a set of service calls.
Online retailers: SOA allows for easier development and management of ecommerce sites
through the use of services that fetch inventory data, track purchases, make secure
payments, and fetch AI-generated data such as “customers also like” recommendatio ns.

What Is SOA (Service-Oriented Architecture)?

A service-oriented architecture (SOA) is a design paradigm that creates or supplements

applications with self-contained, reusable building blocks —services—that provide specific
functions and can be invoked o ver a network. Each service has a defined scope and can be
accessed by other components or services within the architecture to enhance the overall
functionality and performance of the system.

Examples of services in a service -oriented architecture include a payment processing

service, a customer management service, or a product recommendation service that can
be embedded in an ecommerce site. Other services can be far simpler, like one that
provides the current time in a city on the other side of the globe. As an example of a
powerful benefit of using SOA, switching payment processors can be done without altering
applications that need to use the service.

SOA makes for a modular and flexible software infrastructure, where individual services
can be developed, tested, and deployed independently. Two key benefits are ease of
maintenance and scalability.

SOA works by loosely coupling services within the framework of an application. Each
service works as a module capable of delivering the input/output requested. The
application doesn’t need to know the version of the service it’s using. Instead, it checks a
registry and finds the most current service offering the functionality needed. Consider the
following workflow of a retailer’s website built with an SOA model.

A shopper inputs a single-sign-on login using a recognized email address and password.
The retail application sends this login to the authorization service for authentication and
loads the customer profile when the login is verified.

The shopper then searches for a specific product. The item listing is connected to an
inventory service, which pulls data for availability at brick -and-mortar locations local to
the customer and at fulfilment centers for shipping.

The customer checks out using an integrated ca rt service, which then connects to a
payment processing service for a secure transaction.

Once the transaction is complete, the buyer can pull up the order status using other
services to fetch data from inventory and shipping logistics services.

SOA speeds development of this sort of site by allowing integration of services in an off -
the-shelf manner. In this example, the retailer is not only spared the burden of developing
each of those modules individually but it’s also freed from needing to tra ck service
updates. IT can simply use vetted services with proven functionality, security, and
availability.
The key to SOA development is to think modularly and understand where opportunities
exist for service integration. Applications developed in the cl oud can easily take advantage
of huge arrays of SOA-style services implemented as web services.

What is service-oriented architecture?

Service-oriented architecture (SOA) 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.

For example, multiple business processes in an organization require the user

authentication functionality. Instead of rewriting the authentication code for all business
processes, you can create a single authentication service and reuse it for all
applications. Similarly, almost all systems across a 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 per form the
patient registration task.

What are the benefits of service-oriented architecture?

Service-oriented architecture (SOA) has several benefits over the traditional monolithic
architectures in which all processes run as a single unit. Some major benef its of SOA
include the following:

Faster time to market

Developers reuse services across different business processes to save time and costs.
They can assemble applications much faster with SOA than by writing code and
performing integrations from scratch.

Efficient maintenance
It’s easier to create, update, and debug small services than large code blocks in
monolithic applications. Modifying any service in SOA does not impact the overall
functionality of the business process.

Greater adaptability
SOA is more adaptable to advances in technology. You can modernize your applications
efficiently and cost effectively. For example, healthcare organizations can use the
functionality of older electronic health record systems in newer cloud -based
applications.

What are the basic principles of service-oriented

architecture?
There are no well-defined standard guidelines for implementing service -oriented
architecture (SOA). However, some basic principles are common across all SOA
implementations.

Interoperability
Each service in SOA includes description documents that specify the functionality of the
service and the related terms and conditions. Any client system can run a service,
regardless of the underlying platform or programming language. For instance, business
processes can use services written in both C# and Python. Since there are no direct
interactions, changes in one service do not affect other components using the service.

Loose coupling
Services in SOA should be loosely coupled, having as little dependency a s 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. This way,
if you modify a service, it won’t significantly impact the client app lications and other
services using the service.

Abstraction
Clients or service users in SOA need not know the service's code logic or implementation
details. To them, services should appear like a black box. Clients get the required
information about what the service does and how to use it through service contracts and
other service description documents.

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.

What are the components in service-oriented

architecture?
There are four main components in service -oriented architecture (SOA).

Service
Services are the basic building blocks of SOA. They can be private —available only to
internal users of an organization —or public—accessible over the internet to all.
Individually, each service has three main features.

Service implementation
The service implementation is the code that bui lds the logic for performing the specific
service function, such as user authentication or bill calculation.
Service contract

The service contract defines the nature of the service and its associated terms and
conditions, such as the prerequisites for usin g the service, service cost, and quality of
service provided.
Service interface

In SOA, other services or systems communicate with a service through its service
interface. The interface defines how you can invoke the service to perform activities or
exchange data. It reduces dependencies between services and the service requester.
For example, even users with little or no understanding of the underlying code logic can
use a service through its interface.

Service provider
The service provider creates, main tains, and provides one or more services that others
can use. Organizations can create their own services or purchase them from third -party
service vendors.

Service consumer
The service consumer requests the service provider to run a specific service. It c an be
an entire system, application, or other service. The service contract specifies the rules
that the service provider and consumer must follow when interacting with each other.
Service providers and consumers can belong to different departments, organi zations,
and even industries.

Service registry
A service registry, or service repository, is a network -accessible directory of available
services. It stores service description documents from service providers. The description
documents contain information about the service and how to communicate with it.
Service consumers can easily discover the services they need by using the service
registry.

How does service-oriented architecture work?

In service-oriented architecture (SOA), services function independen tly 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.

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)

• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java Message Service (JMS)

You can even use more than one protocol in your SOA implementation.
What is an ESB in service-oriented architecture?
An enterprise service bus (ESB) is software that you can use when commun icating with
a system that has multiple services. It establishes communication between services and
service consumers no matter what the technology.

Benefits of ESB
An ESB provides communication and transformation capabilities through a reusable
service interface. You can think of an ESB as a centralized service that routes service
requests to the appropriate service. It also transforms the request into a format that is
acceptable for the service’s underlying platform and programing language.

What are the limitations in implementing service-

oriented architecture?
Limited scalability
System scalability is significantly impacted when services share many resources and
need to coordinate to perform their functionality.

Increasing interdependencies
Service-oriented architecture (SOA) systems can become more complex over time and
develop several interdependencies between services. They can be hard to modify or
debug if several services are calling each other in a loop. Shared resources, such as
centralized databases, can also slow down the system.

Single point of failure

For SOA implementations with an ESB, the ESB creates a single point of failure. It is a
centralized service, which goes against the idea of decentralization that SOA advocates.
Clients and services cannot communicate with each other at all if the ESB goes down.

What are microservices?

Microservices architecture is made up of very small and completely independent
software components, called microservices, that specialize and focus on one task only.
Microservices communicate through APIs, which are rules that developers create to let
other software systems communicate with their microservice.

The microservices architectural style is best suited to modern cloud computing

environments. They often operate in containers —independent software units that
package code with all its dependencies.

Benefits of microservices
Microservices are independently scalable, fast, p ortable, and platform agnostic —
characteristics native to the cloud. They are also decoupled, which means they have
limited to no dependencies on other microservices. To achieve this, microservices have
local access to all the data they need instead of remo te access to centralized data that
other systems also access and use. This creates data duplication which microservices
make up for in performance and agility.

SOA compared to microservices

Microservices architecture is an evolution of the SOA architectura l style. Microservices
address the shortcomings of SOA to make the software more compatible with modern
cloud-based enterprise environments. They are fine grained and favor data duplication
as opposed to data sharing. This makes them completely independent with their own
communication protocols that are exposed through lightweight APIs. It’s essentially the
consumers' job to use the microservice through its API, thus removing the need for a
centralized ESB.

How does AWS help you implement microservices?

AWS is a great place to build modern applications with modular architectural patterns,
serverless operational models, and agile development processes. It o ffers the most
complete platform for building highly available microservices to power modern
applications of any scope and scale. For example, you can do the following:

• Build, isolate, and run secure microservices in managed containers to simplify

operations and reduce management overhead.
• Use AWS Lambda to run your microservices without provisioning and managing
servers.
• Choose from 15 relational and no n-relational purpose-built AWS databases to support
microservices architecture.
• Easily monitor and control microservices running on AWS with AWS App Mesh.
• Monitor and troubleshoot complex microservice interactions with AWS X-Ray.

Microservices on AW S help you innovate faster, reduce risk, accelerate time to market,
and decrease your total cost of owne rship. Get started with SOA and microservices on
AWS by creating an AWS account today.
What's the difference Between SOA and
microservices?
Service-oriented architecture (SOA) is a method of software development that uses
software components called services to create business applications. Each service
provides a business capability. They 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. Microservices
architecture is an evolution of the SOA architectural style. While each SOA service is a
full business capability, each microservice is a much smaller soft ware component that
specializes in a single task only. Microservices address the shortcomings of SOA to
make the software more compatible with modern cloud -based enterprise environments.
Read about SOA »
Read about microservices »

What limitations of monolithic architecture does SOA

architecture solve?
In monolithic architecture, developers write code for all service functions in a single
code base. W ith service-oriented architecture (SOA), developers can address the
challenges of the monolithic architecture, such as the following:

Scaling challenges that require the entire application to scale, even if only a specific
component needs additional resources.

The inability to add or modify features flexibly, as functionality is distributed across the
code base.
The inability to reuse components across different applications.

Limited fault tolerance. Failure in one component can pote ntially bring down the entire
system.

The challenge of adopting new technologies or integrating with external systems that
use different technologies.

Monolithic architectures also centralize ownership and development teams responsible

for the entire application. They face challenges with continuous delivery and DevOps
practices due to the size and complexity of the architectures.

With SOA, developers break down the software functionalities into service provider and
service consumer layers. These laye rs communicate and exchange data through an
enterprise service bus (ESB). Developers use SOA to simplify complex applications into
multiple reusable services.
What limitations of SOA architecture does the
microservices architecture solve?
While service-oriented architecture (SOA) might work well for building large enterprise
applications, it needs more flexibility to scale smaller, business -specific applications.
These are some limitations of SOA:

The enterprise service bus (ESB) connects multiple services together, which makes it a
single point of failure.

All services share a common data repository. This makes the services difficult to manage
individually.

Every service has a broad scope. So, if one of the services fails, the entire business
workflow will be affected.

So, developers turn to microservices architecture for a more fine -grained approach to
building applications.

The microservice model divides an SOA service into smaller services. Each microservice
operates within its bounded context and run s independently from other services. In
short, the microservices architecture has limited or no interdependencies between
individual services and reduces the risk of system -wide failure.

Architectural differences: SOA vs. microservices

Service-oriented architecture (SOA) encompasses a broader enterprise scope. Different
business units collaborate efficiently on a common data -sharing platform. In contrast,
microservices apply to a narrower scope.
For example, inventory management would be an SOA service of an ecommerce system.
But the microservice approach would break inventory management down into smaller
services, such as availability checker, fulfillment, and accountings.

Implementation
The SOA implementation involves integrating different types of services into an
application. It uses an enterprise service bus to connect service types, like these:
Functional services to support specific business operations
Enterprise services to expose a particular business functionality to other services
Application services used by developers for building and deploying applications

Infrastructure services to manage nonfunctional features, such as authentication and

security

In contrast, the microservices architecture is a more granular and indep endent

implementation of SOA. Microservices do not share resources like SOA services do.
Each microservice operates independently to provide very specific functionalities.
Communication
In order to access remote services, the SOA architecture uses a centralized enterprise
service bus (ESB) to connect diverse services with multiple messaging protocols. Some
of these protocols include SOAP, Advanced Messaging Queuing Protocol (AMQP), and
Microsoft Message Queuing (MSMQ). If the ESB fails, all SOA services will be impacted.

Meanwhile, microservices architectures use simpler messaging systems, such as

RESTful APIs, Java Message Service (JMS), or publish -subscribe (pub/sub) event
streaming. These methods don’t require the microservices to maintain an active
connection when they exchange data.

APIs are a common tool for microservices architectures. An API allows two or more
microservices to exchange data directly without going through a central ized channel.
However, it can create complex data pathways among dozens of microservices, which
developers monitor and manage.

Data storage
The SOA environment comprises a single data storage layer shared by other connected
services. Different enterprise a pplications access and reuse the same data in SOA
implementations, which optimizes the value of data repositories.

In contrast, each microservice has its own data storage. In microservices architectures,
data independence is more important than reusability .

Deployment
It can be challenging to deploy SOA services because they’re coupled to a certain
degree. For example, developers must rebuild the entire application if they modify or
add a new service. Besides, SOA applications cannot take full advantage of
containerization, which abstracts the application from operating systems and hardware.

Meanwhile, microservices are easier to deploy as they are designed to scale in the cloud
environment. Each microservice is an independent applicaiton that developers ca n
containerize and deploy on the cloud.

Key benefits: microservices vs. SOA

Both service-oriented architecture (SOA) and microservices allow development teams
to build, deploy, and manage modern applications efficiently for cloud environments.
That said, microservices offer certain advantages over SOA deployments.

Reusability
One of the principles in SOA designs is an emphasis on reusability and component
sharing. In this architecture, multiple front -facing applications use the same SOA
services. For example, an invoicing and order-tracking dashboard can access the same
service to retrieve customer details.

Meanwhile, microservices take a different approach. They apply data duplication instead
of sharing common resources. This way, a microservices -based application performs
more efficiently and isn’t confined to the data operations of other services.
Speed
SOA might offer decent speed in simple implementations, but data latency increases as
developers add more services to the system. All services compete f or the same
communication resources and data capabilities.

In contrast, microservices architectures remain agile and responsive as the system

scales because they don’t share overlapping resources. Developers can assign and
increase compute resources to a specific microservice if traffic demand grows. This
allows a microservice-based application to run at an acceptable speed at all times.

Governance flexibility
SOA-based applications provide consistent data governance across common
repositories used by different services.

However, developers working with microservices can decide on different governance

policies for independent data storage units. Development teams collab orate more
efficiently and have freedom to determine data governance mechanisms.

When to use: SOA vs. microservices

Service-oriented architecture (SOA) and microservices provide different ways for
organizations to migrate from a monolithic architecture to cloud environments.
Depending on certain factors, one might be more suitable than the other in practical use
cases.

SOA
Organizations with legacy or stand -alone enterprise applications benefit from the SOA
architecture. SOA simplifies conventional softwar e programs into smaller modular parts.
It also pools shared resources to streamline business functionalities. Rather than
building overlapping and redundant services, developers can reuse existing SOA
services to implement more business solutions.

Microservices
Microservices architecture is the better option to support agile development teams.
Developers can make rapid and incremental code changes without affecting the
application’s stability by using continuous integration and continuous delivery (CI/CD)
tools. Microservices are better when developers have these goals:

Use different programming languages, libraries, or frameworks to build a single

application
Combine individual services built with different software frameworks
Provision compute resources and scale individual services in real time

With microservices, companies can benefit from modern cloud capabilities and deploy
hundreds of microservices with ease.

Summary of differences: SOA vs. microservices

 SOA Microservices

Implementation Different services with Independent and purpose-specific

shared resources. smaller services.

Communication ESB uses multiple APIs, Java Message Service, Pub/Sub

messaging protocols like
SOAP, AMQP, and MSMQ.

Data storage Shared data storage. Independent data storage.

Deployment Challenging. A full rebuild is Easy to deploy. Each microservice can

required for small changes. be containerized.

Reusability Reusable services through Every service has its own independent
shared common resources. resources. You can reuse
microservices through their APIs.

Speed Slows down as more Consistent speed as traffic grows.

services are added on.

Governance Consistent data governance Different data governance policies for

flexibility across all services. each storage.

How AWS can help with your microservices

requirements?
Build modern applications on Amazon Web Services (AWS) with modular architectural
patterns, serverless operational models, and agile development processes. We offer the
most complete platform for building highly available microservices to power modern
applications of any scope and scale.
Here are ways you can work with microservices on AWS:

Build, isolate, and run secure microservices in managed containers to simplify

operations and reduce management overhead. Read more at Containers at AWS.
Use AWS Lambda to run your microservices without provisioning and managing servers.
Choose from 15 relational and non -relational purpose-built AWS Cloud databases to
support microservices architecture.
Easily monitor and control microservices running on AWS with AWS App Mesh.
Monitor and troubleshoot complex microservice interactions with AWS X-Ray.
Microservices on AW S help you innovate faster, reduce risk, accelerate time to market,
and decrease your total cost of ownership. Get started with microservices on AW S
by creating an account today.