Service-Oriented Architecture

​

including HTTP, SOAP, REST

K. V. Raghavan

Indian Institute of Science

HTTP

HTTP

Is a stateless, connectionless, synchronous (i.e., request-response) protocol

• That is, the protocol itself does not maintain any state about the request-responses so far between the the same client-server pair

​

HTTP Request

• A request consists of
• a mandatory “start line”, followed by optional “header” lines, followed by an optional “body”.
• The header lines and body are separated by a blank line
• Start line contains request method, request-path (or URI), and HTTP version
• e.g., GET /cities/bangalore HTTP/1.1
• Request-path can include key=value pairs, called request parameters, after the path
• e.g., GET /city/bangalore?weather=sunny&season=summer HTTP/1.1
• Notes:
• The common request methods are GET, POST, PUT, and DELETE
• The URL and port are not in the request. Rather, the request is sent to the URL:port
• Browser address bar shows only URL, port, request-path, request params

​

HTTP Response

A response consists of

• a mandatory “status line”, followed by optional “header” lines, followed by an optional “body”
• Status line consists of HTTP version, status code, and reason phrase
• e.g., HTTP/1.1 200 OK
• Browsers typically show only the body

SOA

What is Service Oriented Architecture (SoA)?

• A way of making software components/applications interact over the network using standard protocols such as HTTP
• Each software component
• Implements and provides a set of services
• In its implementation, may invoke services provided by other components
• A service is a collection of end-points
• A service is usually reachable at a URL:port
• Often, each end-point is identified by a unique request-path (e.g., /hello, or /hello/1)
• Clients send requests to end-points
• End-point returns requested data, after performing the operation (if any) that was requested by the client on the internal data of the software component

Main characteristics of SoA

• The different components/applications may be implemented using different languages/technologies
• A component cannot directly access code or data of another component -- it can only invoke services provided by other component
• Services are similar to libraries/APIs, with additional requirements:
• No dependence on language/technology
• Accessed over network (no assumption that provider and client on same machine)
• Usually services provide business-level or domain-level operations/resources, not implementation-level or fine-grained

Reasons why SoA is popular

• Enables reuse of existing functionality
• Decoupling of distinct business concerns
• Each component can evolve separately in its internal data layouts, implementation details, etc. as long as functional view of pre-existing services is maintained (new services can be added)

A toy example (services, and their end-points)*

Customer:

Cust GetCustDetails(int custId)

Bool DeductFromWallet(int custId, int amount)

Inventory:

Bool DeductFromInventory(int productId, int count)

void AddToInventory(int productId, int count)

int GetPrice(int productId)

Orders:

Bool PlaceOrder(int custId, int productId, int count)

-- its implementation will invoke DeductFromInventory, GetPrice, DeductFromWallet

* Omitted above the URL:port of each service, and request-path of each end-point

More about SoA

• No constraint that one application/component should provide only one service
• Same “monolithic” application could have provided all three services above
• Or, different applications for the different services

​

• Two main flavours of SoA
• SOAP+WSDL -- Simple Object Access Protocol, Web Services Desc. Language
• REST -- Representational State Transfer

SOAP+WSDL

Main features of SOAP

• This is a standard protocol (https://www.w3.org/TR/wsdl.html)
• devised by a standards body
• Every end-point provides a set of operations, each with an input message and a response message
• All messages are in XML (in SOAP format)
• Header and payload
• Header indicates how message ought to be processed/interpreted, while payload is the actual content of the message
• Header format is standardized, and can contain optional instructions related to
• security, routing, authentication, whether the request is to be processed as a transaction, quality of service, etc.

WSDL

BPEL (Business Process Execution Language)

UDDI

• A schema that defines the input message format and response message format for each operation

• An XML based language use to implement a higher-level operation (e.g., Inventory.PlaceOrder) by invoking other services in a given order and by communicating data between them.

• A standard protocol for applications to advertise services that they provide, and for clients to discover service providers by searching

Summary of components [from Hwang, Fox, and Dongarra]

Examples of SOAP usage

• Amazon Simple Storage Service (S3) SOAP API
• https://docs.aws.amazon.com/AmazonS3/latest/API/APISoap.html
• Paypal SOAP API
• Toy example in https://octoperf.com/blog/2018/03/26/soap-vs-rest/#soap

​

Advantages and disadvantages

Advantages

• Rich features (via headers)
• important for correctness and robustness in enterprise context
• Own security layer (on top of https)
• Due to WSDL, syntax of messages gets checked and enforced

Disadvantages

• Complexity of implementation
• Inflexibility (only XML messages supported)

REST

Main ideas behind REST

• Each service is conceptually thought of as maintaining a set of resources/documents
• e.g., orders, customer records, items
• Each resource has a Unique Resource Identifier (URI)
• Each end-point typically refers to a resource and returns that resource
• an end-point may also update one more resources before returning its resource
• update is based on the payload/content that accompanies the request to the end-point

​

Main ideas behind REST - II

• Typically, works using HTTP only
• URI is encoded as request path
• Whether the end-point only reads or also updates is determined by HTTP request method
• Resources can be of any type: e.g., text, HTML, JSON, XML
• No WSDL, no standards, no specification of message formats, no headers in the protocol itself (other than HTTP header). Only based on informal documentation.

​

Main ideas behind REST - III

​

• Each resource ideally includes hyperlinks to all related resources
• So that client need not construct or remember URIs
• Can generate new request simply by “chasing” a link it desires from within the resource returned for the previous request, by choosing the right type of HTTP request method while chasing the link based on what the client needs to do (i.e., create/read/update/delete), and by supplying the correct “body” data in case of PUT and POST requests.
• REST is an architectural style or a set of recommendations, and not a standard
• Different implementers may adhere to recommendations to different extents
• Note, REST is inspired by hyperlinked WWW
• web pages become resources (although WWW links there do not normally update page contents)

Detailed look at a simple example

• Example: https://spring.io/guides/tutorials/rest/
• First, look at the following initial requests
• curl -v localhost:8080/employees, curl -v localhost:8080/employees/99
• curl -X POST localhost:8080/employees … -d '{"name": "Samwise Gamgee", "role": "gardener"}'
• -X specifies request method to use, with default being GET
• -d specifies body of request
• curl -X PUT localhost:8080/employees/3 -H 'Content-type:application/json' -d '{"name": "Samwise Gamgee", "role": "ring bearer"}'
• curl -X DELETE localhost:8080/employees/3
• Why it is not ideal RESTful style so far
• Client needs to know how to construct URIs (there are no hyperlinks in the returned resources)

Example continued

• Then look at “RESTful representation of a single employee” and “RESTful representation of a collection of employee resources”
• every resource has within it links to related resources

​

Web Sessions

• “A web session is a series of contiguous actions by a visitor on an individual website within a given time frame”
• Session state:
• Server keeps information about the session in its memory
• Example, user preferences

Main ideas behind REST - IV

​

• REST services need to be stateless
• Meaning of stateless service:
• No in-memory session state in the software component that provides the service
• State of the service is completely encapsulated in current contents of resources (and resources are in databases)
• Two back-to-back read requests would return the same resource contents, whether they are from same client or different clients, even if the the service shut down and restarted in between
• State can be simulated using cookies. But these are to be sent with every request.
• Pure REST discourages cookies as well, as they are not related to the resources
• Authentication:
• Stateless services can support authentication. Each request has to include username+passwd or token. Usernames, passwords and tokens to be stored in databases on the server-side.

Main ideas behind REST - V

• REST lets the user view the server logically as a folder structure, with resources and/or subfolders in each folder
• REST does not say anything about underlying database tables
• Each resource may map to a tuple in a table, or it may be more complex (e.g., each resource is a join of tuples from multiple tables)
• Hence, resources are logical, and do not necessarily map to tuples one-to-one

​

Main ideas behind REST - VI

​

• Correspondingly, an end-point’s controller can have arbitrary logic:
• A GET end point may need to perform JOINs, etc., rather than just look up a single tuple from a single table
• A POST may update multiple tuples in multiple tables. For example, the controller that receives a POST of a new Order may issue a GET request to check if the customer exists, a PUT request to update the inventory, etc.

​

Usage of REST in practice

Many popular web-based services provide REST APIs (in addition to web-based UI applications and mobile apps) these days

• For e.g., Twitter REST API, Wordpress REST API
• Suggested uses of twitter API: https://developer.twitter.com/en/docs/twitter-api

Advantages and disadvantages

Advantages of REST

• Simple to implement
• Messaging can be efficient
• Flexibility (message need not be XML only)
• Repeated requests →can serve responses from cache

Disadvantages

• Does not have sufficient features for enterprise or transaction-oriented services
• No syntax checking of messages -- errors possible
• No WSDL, so no machine-readable documentation of services

Required reading on SoA

• https://en.wikipedia.org/wiki/Service-oriented_architecture
• Chapters 5.1.1 and 5.1.2 of Hwang, Fox, Dongarra book
• https://spring.io/guides/gs/rest-service/
• https://spring.io/guides/tutorials/rest/
• Understanding how the Spring code works in this tutorial is not so important. Understanding the content sent in each response to each request is important, as that defines the REST architecture.
• https://raygun.com/blog/soap-vs-rest-vs-json/
• https://octoperf.com/blog/2018/03/26/soap-vs-rest/