Resource Oriented ArchitectureSep-15-2015

Nuwan Bandara

@nuwanbando Solutions Architect, WSO2

Software/Computer Systems & Humans

➡ Single most connected artificial entity to humans at present

➡ Rapidly changing and progressing

➡ Increasingly becoming a ubiquitous entity to consume information and act on it

➡ Rules are rapidly changing: Industrial revolution for the software industry is yet to happen

Human Interaction

➡ With Humans: People are Identified by a name and can be associated to a location, place of work/study, a profession etc.

➡ With objects: People identify objects by a name and can be associated to a location, type, use of, owned by etc.

➡ The interaction: Change of state - “become a friend” or “buy a caramel latte”

The Common Factor

➡ Any kind of an interaction is defined by a simple protocol

➡ You identify something (i.e: name)

➡ You associate it to something to derive meaning (i.e: location)

➡ You change the state (aka interact)

Building A Connected Information System

➡ If interaction is the key thing in any system

➡ We need to define the entities, their associations and interactions

➡ In an HR system employee is an entity, “department”, “salary”, “bio” are descriptors or associations to that entity

➡ In an abstract sense we interact with a resource based ecosystem

➡ Every entity and a descriptor can be represented as a resource

Resource Orientation Is Not A Leapfrog

➡ Object Oriented Architecture

‣ Every entity is defined as an object

‣ Objects have attributes and actions

‣ Objects have a state

➡ Service Oriented Architecture

‣ Entities are services

‣ Service has a description and a contract

‣ Interacts over the network with a defined location (address)

Resource Oriented Architecture (ROA)

➡ The rest of “REST”

➡ Foundations of the Semantic Web

➡ Building a ubiquitous computing ecosystem

➡ Describing a system as a self discoverable entity

➡ Modeling a system based on its logical form (as oppose to the technical form)

ROA Fundamentals

➡ Uses Representational State Transfer (REST) as the primary design pattern

➡ Data is independent of the server and the client - The server implementation can change over time and there can be many clients.

➡ Loose coupling is one of the objectives of the architecture

➡ “State” is treated as actions performed against the resource

URLs Are The Identifiers Of Resources

➡ Resources are uniquely identifiable

‣ Uniform Resource Name (URN) is a good example of a uniquely identifiable resource name

‣ ISBN is a classic example

➡ URN alone cannot identify a resource, there needs to be a discovery mechanism

urn:isbn:9780345376596

https://library.org/books/9780345376596

http://wso2.com/customer/fin23324

or

How A URL Should Look Like In ROA

➡ Has to be a logical representation of the resource

‣ The only requirement: A resource identifier has to be an indefinite constant

From following patterns which creates an indefinite constant ?

http://wso2.com/customer.jsp?id=fin233245

http://wso2.com/customer/v1/fin233245

http://wso2.com/customer/fin233245

Lets Examine

➡ {.jsp} is implantation detail

➡ Implementations change over time

http://wso2.com/customer.jsp?id=fin233245

http://wso2.com/customer/v1/fin233245

➡ {v1} is a contractual detail

➡ The resource format (structure) should not define the resource identifier

➡ However the version is an important detail, hence

http://wso2.com/customer/fin233245?version:v1

Identifier Information & Meta Information

➡ URL parameters as meta information

➡ Meta information do not identify the resource but add more context/flexibility for the consumer

http://wso2.com/customer/fin233245?version:v1

http://wso2.com/report/sales/2009/qtr/3?sort=ascending

Freedom Of Form

➡ The format of the resource can be of many forms

http://wso2.com/customer/fin233245/book.xml

http://wso2.com/customer/fin233245/book.json

http://wso2.com/customer/fin233245/book.html

http://wso2.com/customer/fin233245

Accept: application/json

curl -H "Accept: application/json" -O http://wso2.com/customer/fin233245

vs

Late Binding

➡ Named references (aka “Pointers” in ROA)

‣ Actual resource is not retrieved unless its explicitly asked for

‣ A reference to the resource is passed in an orchestration

curl -H "Accept: application/json" -O http://wso2.com/customers

[“http://wso2.com/customer/fin233245”, “http://wso2.com/customer/ecom233246”]

➡ This methodology allows a system built with ROA enforce granular level of entitlement

Loosely Coupled & Logically Connected

➡ Resources are identified by it’s logical meaning - URL construction (ROA 101)

‣ Independent of the server implementation - Greater flexibility for change

‣ Clients are intact - Clients are wired to the resource

➡ Following Postel's Law - Be strict in what you provide (Resource identifier, data formats etc) but be flexible when receiving (different clients should be able to send data in different formats)

Hypermedia As The Engine Of Application State (HATEOAS)

➡ Client does not have any meaningful idea about the data sent by the

server

➡ Client can only render it

➡ Client interact with the server only via hypermedia

➡ No prior contract, client will discover possible actions by understating

the resource representation sent by the server

➡ The resource representation is state-full and sent across the hypermedia

Understanding HATEOAS

➡ Listing a book in the library

GET /book/9780345376596 HTTP/1.1 Host: library.org Accept: application/json ..

HTTP/1.1 200 OK Content-Type: application/json Content-Length: …

{ "name": "the pale blue dot", "ISBN": "9780345376596", "author": "carl sagan", "borrow": "http://library.org/book/9780345376596/borrow" }

GET /book/9780345376596 HTTP/1.1 Host: library.org Accept: application/json ..

HTTP/1.1 200 OK Content-Type: application/json Content-Length: …

{ "name": "the pale blue dot", "ISBN": "9780345376596", "author": "carl sagan", "return": "http://library.org/book/9780345376596/return" }

➡ Listing a book after its been borrowed

Semantic Web & ROA

➡ Defines a structured relationship of resources (over the web)

➡ Defines the means of querying an exact resource vs arbitrary discovery

➡ Identifies resources as edges and nodes

‣ An edge represent a data element

‣ A node describe more nodes & edges

Micro-Services & ROA➡ “Micro-Services Architecture” is properly Implements SOA

➡ Micro Services complements ROA

➡ Micro service in essence is a service with the right level of granularity performing a specific business task

➡ In a high level a “micro service” is the implementation of a resource with its contextual details

‣ The library example: The book is a resource in the library, you can borrow and return a book and that encapsulate the logical book in a library which can be implemented as a micro service

References

➡ http://www.infoq.com/articles/roa-rest-of-rest#anch50927

➡ https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1

➡ https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2

➡ http://www.w3.org/standards/semanticweb/

Image References

➡ https://www.bestthinking.com/articles/computers_and_technology/software/software_architecture/designed-for-humans

➡ http://www.socialsongbird.com/2014/08/social-media-and-human-interaction.html

➡ https://jlmhenson20xs.wordpress.com/2013/10/22/a-great-interaction/

➡ http://theviewinside.me/if-you-want-peace-of-mind-defeat-your-past-by-climbing-your-own-mount-everest/