SOA - Introduction
Srikanth Gunturu
Lets begin with a simple question…
What is a service ?
Service Oriented Architecture (SOA)
Service Oriented Architecture (SOA)
A Service Oriented Architecture (SOA) is a form of distributed systems
architecture that is typically characterized by the following properties
Logical view
Message Orientation
Description Orientation
Granularity
Network Orientation
Platform Neutrality
Multiple methodologies are used to implement SOA
Remote Procedure Call (RPC)
Arbitrary Web services (SOAP/XML)
RESTful Web services
Apache Thrift
Messaging protocols (RabbitMQ, JMS etc.)
OPC Unified Architecture (OPCUA)
Web service – defined…
“A web service is a software system designed to support interoperable
machine-to-machine interaction over a network.” – W3C glossary
“It [Web Service] has an interface described in a machine-processable
format (specifically WSDL). Other systems interact with the web service in a
manner prescribed by its description using SOAP-messages, typically
conveyed using HTTP with an XML serialization in conjunction with other
web-related standards.” – W3C basic definition, 2002
Web service - redefined !
“An even more constrained architectural style for reliable Web applications known
as Representation State Transfer (REST) has been proposed by Roy Fielding and has
inspired both the W3C Technical Architecture Group's architecture document [Web
Arch] and many who see it as a model for how to build Web services [Fielding]. The
REST Web is the subset of the WWW (based on HTTP) in which agents
provide uniform interface semantics -- essentially create, retrieve, update and delete --
rather than arbitrary or application-specific interfaces, and manipulate resources only
by the exchange of representations. Furthermore, the REST interactions are
"stateless" in the sense that the meaning of a message does not depend on the state
of the conversation.
We can identify two major classes of Web services:
REST-compliant Web services, in which the primary purpose of the service is to
manipulate XML representations of Web resources using a uniform set of
"stateless" operations; and
arbitrary Web services, in which the service may expose an arbitrary set of
operations.”
-W3C refined definition, 2004
Arbitrary WS vs RESTful WS
Arbitrary Web services (SOAP WS) RESTful Web services
Exposes services as individual operations, each to Representational State Transfer is an architectural
achieve a specific business objective. style for defining interoperability in terms of
resources or concepts
Introduced in W3C draft for web services in 2002 Introduced in W3C extended revision in 2004
Uses Simple Object Oriented Protocol (SOAP), a REST supports SOAP/XML/JSON or any other
variant of XML for data transfer data protocol supported by HTTP
Service contract definition is specified via Web Service contract is defined via resource or concept
service description language (WSDL) endpoints and HTTP methods (POST/ GET/ PUT/
DELETE) defined on them
JAX-WS is the binding protocol used JAX-RS is binding protocol used
Imposes a rigid structure for service definition and Does not impose any specific structure – any
request/response format supported by HTTP is accessible
Requires more footprint and bandwidth, resulting in Light-weight formats (like JSON) require less
performance issues at large scale footprint there by improving performance
Defines its own security, as defined by SOAP-WS Inherits security measures from the underlying
security transport protocol (TCP, UDP etc.)
REST – Architectural Constraints
Client-server model - “Servers and clients may also be replaced
and developed independently, as long as the interface between
them is not altered”
Statelessness - “No client context shall be stored on the server
between requests. Client is responsible for managing the state of
application.”
Cacheability – “Well-managed caching partially or completely
eliminates some client–server interactions, further improving
scalability and performance”
Layered system – “Client need not be aware of underlying layers
managed by the service provider”
REST – Architectural Constraints
(contd.)
Code-on-demand (optional) – “..when you need to, you are free to return
executable code to support a part of your application..”
Uniform interface – “Once a developer become familiar with one of your
API, he should be able to follow similar approach for other APIs”
Resource identification in requests
Resource manipulation through representations
Self-descriptive messages
Hypermedia As The Engine Of Application State (HATEOAS)
Statelessness
Doesn’t mean your applications can’t have state
It means that there is no client session data stored on the server
The server only records and manages the state of the resources it exposes.
If there is session specific data, it needs to be held by client and transferred
to the server with each request as needed.
Lot easier to scale as it doesn’t need to maintain client sessions.
As it has to do a lot fewer expensive replications in a clustered environment.
All you have to do is to add machines.
Uniform Constrained Interface
You stick to the finite set of operations of the application protocol you are
distributing your services upon. Which means that you don’t have action
“Parameter” in the URI and use the methods of HTTP for your web services.
HTTP has a small fixed set of operational methods.
Create - POST
Retrieve - GET
Update - PUT
Delete - DELETE
POST
Is the only Non Idempotent
Unsafe Operation of HTTP
Each POST method is allowed to modify the service in a unique way
You may or may not send information with the request
You may or may not receive information from the response
Returns 201 when successful
GET
Read Only Operation
Used to query the server for specific information
Idempotent and Safe operation
Idempotent means no matter how many times you apply the operation,
the result is always the same
Act of reading a document shouldn’t change the document
Safe means that invoking a GET doesn’t change the state of the server at
all.
Which means other than request load, the operation won’t affect the server
Returns 200 or 302 when successful
PUT
Requests that the server store the message body sent with the request
under the location provided in the HTTP message
Usually modelled as Insert/Update
Idempotent
When using it, client knows the identity of the resource it is creating or
updating.
Sending the same PUT message more than once has no effect on the
underlying service
Example: Saving a word document n no of times doesn’t change it every
time
Returns 200 for just update, 201 if new data is created (not recommended)
DELETE
Is used to remove resources.
Idempotent as well
Returns 204 if successful
Service Representation
Each service is addressable through a specific URI and representations are
exchanged between client and service.
With GET you are receiving the representation of the current state of the
resource.
With PUT/POST, passing the representation of the resource to the server so
that underlying resource’s state can change.
In a RESTful system, the complexity of the client-server interaction is within
the representations being passed back and forth. It could be XML,YAML,
JSON or any format you can come up with.
Service representation - URI
Unique identifier to represent a resource in a system without ambiguity
Generic Notation -
<scheme>://host:port/resource-rel-path?queryString
Scheme is the protocol – like http
Host is DNS name or address of the server
Port is the address of the application local to the server
Resource-rel-path is relative path of the resource in the application
Query String (optional) is used to specify query parameters if any (GET method
only)
http://example.com/customers?lastname=saha&zipcode=560029
HATEOAS
Hypermedia As The Engine Of Application State
Document centric approach with added support for embedding links to other
services and information within that document format.
One of the uses of hypermedia and hyperlinks is composing complex sets of
information from disparate sources.
It could be within a company intranet or dispersed across internet
It allows us reference and aggregate additional data without bloating our
responses.
<order id=“111”>
<customer>http://customer.myintranet.com/customers/3456</customers>
………
<product>http://products.myintranet.com/products/234</product>
HATEOAS (Contd.)
Aggregation is not the full concept of HATEOAS, rather it’s the Engine
It’s different because with each request returned from server it tells you
what new interactions you can do next, as well as where to go to transition
the state of your applications.
Example:
<products>
<link rel=“next” href=http://abc.com/store/products?startIndex=5/>
<products>
<link rel=“previous” href=http://abc.com/store/products?startIndex=0/>
<link rel=“next” href=http://abc.com/store/products?startIndex=10/>
