SOA – Service Oriented Architecture

SOA – Service Oriented Architecture

 Service provider publishes service description (WSDL), e.g. on a service

broker
 Service Requester finds service (on service broker) and dynamically binds
to service
 Enables ad-hoc collaboration and Enterprise Application Integration
(EAI) within web- based information systems
 SOA is about how to design a software system that makes use of services
of new or legacy applications through their published or discoverable
interfaces. These applications are often distributed over the networks.
 SOA also aims to make service interoperability extensible and effective.

 It prompts architecture styles such as loose coupling, published interfaces

and a standard communication model in order to support this goal.
 Properties of SOA

 Logicalview
 Message orientation
 Description orientation
 Logical view

 The SOA is an abstracted, logical view of actual programs, databases,

business processes.
 Defined in terms of what it does, typically carrying out a business-level
operation.
 The service is formally defined in terms of the messages exchanged
between provider agents and requester agents.
 Message Orientation

 The internal structure of providers and requesters include the

implementation language, process structure, and even database
structure.
 These features are deliberately abstracted away in the SOA
 Using the SOA discipline one does not and should not need to know
how an agent implementing a service is constructed.
 The key benefit of this concerns legacy systems.

 By avoiding any knowledge of the internal structure of an agent, one

can incorporate any software component or application to adhere to
the formal service definition.
 Description orientation

 A service is described by machine-executable metadata.

 The description supports the public nature of the SOA.
 Only those details that are exposed to the public and are important for
the use of the service should be included in the description.
 The semantics of a service should be documented, either directly or
indirectly, by its description.
 SOA Realization (Two ways)

 XML - SOAP Based Web Services

 Extensible Markup Language (XML) is a markup language designed as
a standard way to encode documents and data
 SOAP is an acronym for Simple Object Access Protocol. It is an XML-
based messaging protocol for exchanging information among
computers
 RESTful Web services
Service Oriented Architecture model
implemented by XML Web Services
WSDL – Web Services Description Languages

Provides a machine-readable description of how the

service can be called, what parameters it expects, and
what data structures it returns.
Used in combination with SOAP and an XML
Schema to provide Web services over the Internet.
 UDDI – Universal Description, Discovery
and Integration
White Pages — address, contact, and known
identifiers;
Yellow Pages — industrial categorizations based on

standard taxonomies;
Green Pages — technical information about services
exposed by the business
 Representational State Transfer (REST)

APIs are for software components; a way for

software to interact with other software.
Web Services are a set of rules and technologies that
enable two or more components on the web to talk to
each other.
Not every API is a web service.
REST API is a web service.
REST API is an API that follows the rules of REST
specification.
 A web service is defined by rules:

How software components will talk?

What kind of messages they will send to each other?

How requests and responses will be handled?

 HTTP and REST

HTTP is an application layer protocol for sending

and receiving messages over a network.

REST is a specification that dictates how distributed

systems on the web should communicate.

REST is a way to implement and use the HTTP

protocol.
 REST and Systems of Systems

SOA focuses on loosely coupled software applications running

across different administrative domains, based on common
protocols and technologies, such as HTTP and XML.
SOA is related to early efforts on the architecture style of large
scale distributed systems, particularly Representational State
Transfer (REST).
REST still provides an alternative to the complex standard-
driven web services technology.
Used in many Web 2.0 services.
REST is a software architecture style for distributed systems,
particularly distributed hypermedia systems, such as the
World Wide Web.
 REST and Systems of Systems

Applications:
Google, Amazon, Yahoo, Facebook and Twitter

Advantage:
Simplicity
Ease of being published and consumed by clients.
 REST and Systems of Systems

A simple REST interaction between user and server in HTTP specification

 REST Principles

The REST architectural style is based on four principles:

Resource Identification through URIs

Uniform, Constrained Interface

Self-Descriptive Message

Stateless Interactions
Resource Identification through URIs

 The RESTful web service exposes a set of resources which identify

targets of interaction with its clients.
 The key abstraction of information in REST is a resource.
 Any information that can be named can be a resource, such as a
document or image or a temporal service.
 A resource is a conceptual mapping to a set of entities.
 Each particular resource is identified by a unique name, or more
precisely, a Uniform Resource Identifier (URI).
 URI is of type URL, providing a global addressing space for resources
involved in an interaction between components as well as facilitating
service discovery.
 The URIs can be bookmarked or exchanged via hyperlinks.
 URIs provide more readability and the potential for advertisement.
 Uniform, Constrained Interface

 Interaction with RESTful web services is done via the HTTP standard, client/server
cacheable protocol.
 Resources are manipulated using a fixed set of four CRUD (create, read, update, delete)
verbs or operations:
 PUT
 GET
 POST
 DELETE

 PUT creates a new resource.

 The resource can then be destroyed by using DELETE.

 GET retrieves the current state of a resource.

 POST transfers a new state onto a resource.

 Self-Descriptive Message

A REST message includes enough information to

describe how to process the message.
This enables intermediaries to do more with the
message without parsing the message contents.
In REST, resources are decoupled from their
representation so that their content can be accessed in
a variety of standard formats
Eg:- HTML, XML, MIME, plain text, PDF, JPEG,
JSON, etc.
REST provides multiple/alternate representations of
each resource.
 Self-Descriptive Message

Metadata about the resource is available and can be

used for various purposes.
Cache control
Transmission error detection
Authentication or authorization
Access control.
 Stateless Interactions

The REST interactions are “stateless”

Message does not depend on the state of the
conversation.
Stateless communications improve visibility,
reliability and increases scalability
Decrease network performance by increasing the
repetitive data
 REST - Advantages

RESTful web services can be considered an

alternative to SOAP stack or “big web services
Simplicity
Lightweight nature
Integration with HTTP
REST Architectural Elements