INTRODUCTION TO SERVICE-

ORIENTED ARCHITECTURE (SOA)

T M P - D E L I N S T I T U T E O F T E C H N O L O G Y
 OUTLINES

What & why SOA

SOA Principles

SOA Components

SOA vs. Non-SOA

A Glance of Enterprise Service Bus (ESB)

A GLANCE OF
WEB SERVICE
• Web Service (WS) was introduced by Hewlett-Packard
e-Speak in 1999.

• WS is a service offered by an electronic device (mainly

server) to another electronic device, communicating
with each other via the World Wide Web (HTTP
protocol) - Wikipedia.

• HTTP is used for transferring machine-readable file

formats such as XML and JSON.

• There are two messaging protocols used by WS over

HTTP, such as SOAP (Simple Object Access Protocol)
and REST (Representational State Transfer).
WEB SERVICE CRITERION
• Interoperability - allow various applications to talk to each other and share data and services among
themselves regardless what programming language/technology is used (app platform and
technology independent).
• Standardized Protocol - web services use standardized industry standard protocol for the
communication which gives the business many advantages such as a wide range of choices,
reduction in the cost due to competition, and increase in the quality.
• Low Cost Communication - WS use SOAP or REST over HTTP protocol, so it can use an existing low-
cost internet for implementing web services (compared to EDI/B2B).
• XML-Based - WS eliminates any networking, operating system, or platform binding.
• Loosely Coupled - software systems more manageable and allows simpler integration between
different systems.
• Coarse-Grained - WS should be coarse-grained that accesses the right amount of business logic.
SOAP WEB
SERVICE
HOW IT WORKS (SOAP)
 WSDL
EXAMPLE
W H AT & W H Y
SOA
• SOA: a style of software
design/concept/paradigm to make software
components reusable via service interfaces,
through a communication protocol over a
network.
• Service interface has little or no knowledge (loose
coupling) about how the integration is
implemented underneath. This Photo by Unknown author is licensed under CC BY-SA.

• These services are exposed using

standard network protocols, e.g.: SOAP/HTTP or
JSON/HTTP - to send request to read or change
data.
W H AT & W H Y
SOA (CONTINUE)
• The 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).

• It is also black-box for its consumers, and may

consist of other underlying services.

• SOA offers greater business agility, which means

This Photo by Unknown author is licensed under CC BY-SA.

efficient in assembling applications from reusable

service interfaces, rather than rewriting
and reintegrating with every new development
projects.
W H AT & W H Y
SOA (CONTINUE)
• SOA enables developers easily take functionality
'locked' in one computing platform/environment
and extends it to new environments and markets.

• In an SOA, services can be defined in business

terms (e.g., 'generate insurance quote'
or 'calculate capital equipment ROI'). This enables
business analysts to work more effectively with This Photo by Unknown author is licensed under CC BY-SA.

developers to get important insights.

SOA PRINCIPLE
• Standardized service contract - services adhere to a
standard communications agreement, as defined collectively
by one or more service-description documents within a given
set of services.

• Service reference autonomy (an aspect of loose coupling) -

the relationship between services is minimized to the level
that they are only aware of their existence.
• Service location transparency (an aspect of loose coupling) -
services can be called from anywhere within the network that
it is located no matter where it is present.

• Service longevity - services should be designed to be long

lived. Where possible services should avoid forcing
consumers to change if they do not require new features, if
you call a service today you should be able to call the same
service tomorrow.
SOA PRINCIPLE
(2)
• Service abstraction - the services act as black boxes, that is their
inner logic is hidden from the consumers.

• Service autonomy - services are independent and control the

functionality they encapsulate.

• Service statelessness - services are stateless, that is either return

the requested value or give an exception hence minimizing
resource use.

• Service granularity - a principle to ensure services have an

adequate size and scope. The functionality provided by the service
to the user must be relevant.
SOA PRINCIPLE
(3)
• Service normalization - services are decomposed or consolidated
(normalized) to minimize redundancy. In some, this may not be
done. These are the cases where performance optimization, access,
and aggregation are required.

• Service composability - services can be used to compose other

services.

• Service discovery - services are supplemented with

communicative meta data by which they can be effectively
discovered and interpreted.

• Service reusability - logic is divided into various services, to

promote reuse of code.

• Service encapsulation - many services which were not initially

planned under SOA, may get encapsulated or become a part of
SOA.
SOA
COMPONENTS
• Service - the central pillar of SOA is the service which
provides a distinct business function, and should be a coarse-
grained piece of logic. One of the characteristics of service is
service autonomy, means that the service should be mainly
self-sufficient.

• Contract - the collection of all the messages supported by the

service is known as the service's contract. This provides a
closed set of messages that flows in one direction, and also
might be able to exchange messages with a predefined group
of components. In object-oriented design, service can be
analogous to interface.

• Endpoint - an endpoint is a universal resource identifier (URI),

such as an address or a specific place, where the service can
be found. A specific contract can be exposed at a specific
endpoint.
SOA COMPONENTS (2)

HTTP GET messages.

Message - the unit of communication in
Simple Object Access Protocol (SOAP) messages.
SOA is the message. Messages can Java Message Services (JMS) messages.
come in many different forms, such as: Simple Mail Transfer Protocol (SMTP) messages.

Policy - is differentiator between SOA and OO design. A policy defines terms

and conditions for making a service available to consumers. A policy can be
security (encryption, authentication, authorization), auditing, SLA, and so on.

Service Consumer - the software components that interact with a service via
messaging. This can be either client apps or other devices and they should
adhere to SOA contract.
 SOA VS.
NON-SOA
 SOA VS.
NON-SOA
 This Photo by Unknown author is licensed under CC BY.

A GLANCE OF ENTERPRISE
SERVICE BUS
A GLANCE OF ENTERPRISE
SERVICE BUS (ESB)
• An enterprise service bus (ESB) is a middleware tool used to distribute work among
connected components of an application.
• Designed to provide a uniform means of moving work, offering applications the ability
to connect to the bus and subscribe to messages based on simple structural and
business policy rules.
• In an ESB, applications and event-driven services are tied together in an SOA in a
loosely coupled fashion, which allows them to operate independently from one
another while still providing value to a broader business function.
• In the realm of SOA, events are represented in an open XML format and flow through a
transparent pipeline that’s open to inspection.
A GLANCE OF ENTERPRISE
SERVICE BUS
ANY QUESTION