Resource Oriented Architecture July-31-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 entities, “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/