Resource-Oriented Architecture (ROA)
-
Upload
wso2-inc -
Category
Technology
-
view
1.039 -
download
0
Transcript of Resource-Oriented Architecture (ROA)
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/