Service Oriented Architecture (SOA)

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
perform the patient registration task.

Advantages of SOA
 Service reusability: In SOA, applications are made from existing services.
Thus, services can be reused to make many applications.
 Easy maintenance: As services are independent of each other they can be
updated and modified easily without affecting other services.
 Platform independent: SOA allows making a complex application by
combining services picked from different sources, independent of the
platform.
 Availability: SOA facilities are easily available to anyone on request.
 Reliability: SOA applications are more reliable because it is easy to debug
small services rather than huge codes

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. 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 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. This way, if you modify a service, it won’t significantly impact the
client applications 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.

Reusability

Designed as components, services can be reused more effectively, thus reducing

development time and the associated costs.

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 builds 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 using 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, maintains, 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 can
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, organizations, 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.

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.
REpresentational State Transfer (REST)
REST is a software architectural style that defines the set of rules to be used for
creating web services. Web services which follow the REST architectural style
are known as RESTful web services. It allows requesting systems to access and
manipulate web resources by using a uniform and predefined set of rules.
Interaction in REST based systems happen through Internet’s Hypertext Transfer
Protocol (HTTP).

A Restful system consists of a:

 client who requests for the resources.
 server who has the resources.
It is important to create REST API according to industry standards which results
in ease of development and increase client adoption.
Architectural Constraints of RESTful API: There are six architectural
constraints which makes any web service are listed below:
 Uniform Interface
 Stateless
 Cacheable
 Client-Server
 Layered System
 Code on Demand
The only optional constraint of REST architecture is code on demand. If a service
violates any other constraint, it cannot strictly be referred to as RESTful.
Uniform Interface: It is a key constraint that differentiate between a REST API
and Non-REST API. It suggests that there should be an uniform way of
interacting with a given server irrespective of device or type of application
(website, mobile app).
There are four guidelines principle of Uniform Interface are:
 Resource-Based: Individual resources are identified in requests. For
example: API/users.
 Manipulation of Resources Through Representations: Client has
representation of resource and it contains enough information to modify or
delete the resource on the server, provided it has permission to do so.
Example: Usually user get a user id when user request for a list of users and
then use that id to delete or modify that particular user.
 Self-descriptive Messages: Each message includes enough information to
describe how to process the message so that server can easily analyses the
request.
 Hypermedia as the Engine of Application State (HATEOAS): It need to
include links for each response so that client can discover other resources
easily.
Stateless: It means that the necessary state to handle the request is contained
within the request itself and server would not store anything related to the
session. In REST, the client must include all information for the server to fulfill
the request whether as a part of query params, headers or URI. Statelessness
enables greater availability since the server does not have to maintain, update or
communicate that session state. There is a drawback when the client need to
send too much data to the server so it reduces the scope of network optimization
and requires more bandwidth.

Cacheable: Every response should include whether the response is cacheable or

not and for how much duration responses can be cached at the client side. Client
will return the data from its cache for any subsequent request and there would be
no need to send the request again to the server. A well-managed caching partially
or completely eliminates some client–server interactions, further improving
availability and performance. But sometime there are chances that user may
receive stale data.

Client-Server: REST application should have a client-server architecture. A

Client is someone who is requesting resources and are not concerned with data
storage, which remains internal to each server, and server is someone who holds
the resources and are not concerned with the user interface or user state. They
can evolve independently. Client doesn’t need to know anything about business
logic and server doesn’t need to know anything about frontend UI.

Layered system: An application architecture needs to be composed of multiple

layers. Each layer doesn’t know any thing about any layer other than that of
immediate layer and there can be lot of intermediate servers between client and
the end server. Intermediary servers may improve system availability by enabling
load-balancing and by providing shared caches.

Code on demand: It is an optional feature. According to this, servers can also

provide executable code to the client. The examples of code on demand may
include the compiled components such as Java applets and client-side scripts
such as JavaScript.