Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Resource Oriented Architecture (ROA)

Resource Oriented Architecture (ROA)

Any given business or an organization entity is built with resources. It can be human capital, digital assets, services and products. These activities often interact with each other creating a value network. Human resources interacting with digital assets to perform a service is a good example. We as computer scientists were trying to simplify this interaction flow for a quite sometimes. Field of distributed systems and semantic web are dedicated to solve problems in this domain. With RESTful services and the ecosystem around it now have simplified this interaction to a great level. Being able to interact with a resource with basic actions in a secure manner is a great achievement. This webinar will discuss the of history on ROA, current landscape, ROA and microservices and some new developments around the architecture pattern.

Nuwan Bandara

July 31, 2015
Tweet

More Decks by Nuwan Bandara

Other Decks in Programming

Transcript

  1. 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
  2. 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”
  3. 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)
  4. 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
  5. 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)
  6. 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)
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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)
  15. 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
  16. 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
  17. 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
  18. 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