[go: up one dir, main page]
Scribd
Upload
78 views20 pages

SOA - Introduction: Srikanth Gunturu

A Service Oriented Architecture (SOA) is a distributed systems architecture characterized by logical view, message orientation, description orientation, granularity, network orientation, and platform neutrality. Multiple methodologies like RPC, RESTful and messaging protocols are used to implement SOA. RESTful web services use HTTP methods like GET, POST, PUT, DELETE to manipulate resources represented in XML, JSON or other formats. They are more lightweight and scalable than arbitrary SOAP web services.

Uploaded by

srikanthgs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
78 views20 pages

SOA - Introduction: Srikanth Gunturu

A Service Oriented Architecture (SOA) is a distributed systems architecture characterized by logical view, message orientation, description orientation, granularity, network orientation, and platform neutrality. Multiple methodologies like RPC, RESTful and messaging protocols are used to implement SOA. RESTful web services use HTTP methods like GET, POST, PUT, DELETE to manipulate resources represented in XML, JSON or other formats. They are more lightweight and scalable than arbitrary SOAP web services.

Uploaded by

srikanthgs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

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/>

You might also like