An enterprise environment is typically heterogeneous, often spanning across organizational boundaries. Building such systems require tools that promote intrinsic interoperability and provide ease of integrating over boundaries. It also needs to use technology that promotes simplicity and is easy to handle. Resource oriented architecture (ROA) supports this by focusing on entities and interactions for effective enterprise integration. This session will first give an overview of resource oriented computing and the advent of ROA. It will then focus on what it means to have a ROA in your organization – both externally and internally. It will finally discuss how WSO2 technology can help you built your enterprise system in a resource oriented manner.

1. Moulding your Enterprise with
Resource Oriented Architecture
Shiroshica Kula:lake
Solu:ons Architect
WSO2

2. Agenda
• Needs of a Connected Enterprise
• Resource Oriented Architecture - Concepts
• How Resource Oriented Architecture complements
a Connected Enterprise
• Building a Resource Oriented Enterprise
Architecture with WSO2

3. Fulfilling the Needs of a Connected Enterprise

4. Needs of a Connected Enterprise
• Distributed
– Built on many interac:ons u:lizing strengths of the
connected network
– Connects across several boundaries
• Ubiquitous
– Accessible via many end devices
– Accessible from any loca:on
– Use of public modes for access e.g. Web
• Agile
– Flexible interac:ng with mul:ple partners
– Flexible in adap:ng to changing requirements
– Time to market is very low

5. How would an Enterprise Achieve these Needs

6. By crea=ng an Enterprise Architecture Vision

7. Defining Enterprise Architecture
An enterprise architecture (EA) is a conceptual
blueprint that defines the structure and opera=on of
an organiza=on.
The intent of an enterprise architecture is to determine
how an organiza:on can most effec:vely achieve its
current and future objec:ves.

8. From an Enterprise Architect’s POV
• Distributed
– Integrate seamlessly with exis:ng and new systems
– Ease of crea:ng new services and composites
– Ease of exposing created services in a secure manner
• Ubiquitous
– Ease of accessing exposed services in a secure manner
– Create applica:ons/mashups which are lightweight
– Make use of common Web Technology
• Agile
– Easy to learn and use technology
– Able to design and build in a short :me period

9. Defining an Enterprise Architecture

10. Resource Oriented Architecture
- The Concepts

11. Resource Oriented Architecture
• Each and every interactable item in an enterprise is
represented as a Resource
• Representa:onal State Transfer (REST) is the paVern
which is used to achieve this
• The complete system is modeled in a logical manner
• Loose Coupling is advocated
• State is determined based on the ac:ons performed
on the resources and the representa:ons

12. ROA : Unique Naming
• Resource names are unique in a global context
• URL is the unique iden:fier in ROA
• URL = URN + Context informa:on
– h"p://wso2.com/customers/apac/1123
• It will have the context (where) plus the unique key

13. ROA : Logical Representa=on
• The URL will be an indefinite constant since clients
depend on this
• It should not include
– Implementa:onal details
• hVp://wso2.com/customer.jsp?id=1123
– Contractual informa:on
• hVp://wso2.com/customers/apac/v1/1123
• Meta informa:on can be added as parameters to
the URL which would add more context and
flexibility
– h"p://wso2.com/customers/apac/1123?version:v1
• Self explanatory

14. ROA : Uniform Interfaces
• Accessing the resources should follow the same
paVern
– Ac:on : Uniform Iden:fier
• ROA is based on REST which is powered by HTTP
• For all resources the interface methods used are the
same
– GET (Query), POST (Create), PUT (Update), DELETE (Remove)
– curl GET h"p://wso2.com/customers/apac/1123
• Uniform interfaces makes dealing with these
resources much simpler for clients

15. ROA : Freedom of Form
• A resource can have many representa:ons
• Representa:on is independent of the name
• The form should be defined in the HTTP request
header
– curl -H “Accept: applica8on/json” -O h"p://wso2.com/customers/apac/1123
• The Client has total control
• The server simply responds with the informa:on in
the required representa:on

16. ROA : Loose Coupling
• The client is only bound to the URL and Resource
details that it received and not to the server
• Server implementa:on is independent and thus can
be refactored when needed provided it sends out
the same resource details
• Resource does not have any implementa:on
specifics

17. ROA : Late Binding
• The first call may not provide the actual resource -
but simply a collec:on with metadata
– curl -H “Accept: applica:on/json” -O h"p://wso2.com/customers/apac/
– [“h?p://wso2.com/customers/apac/1123” , “
h?p://wso2.com/customers/apac/1126”]
• It would be subsequently that the actual resource is
requested
• This enables the ability to do fine grained access
control

18. ROA : HATEOAS
• Hypermedia As The Engine of Applica:on State
• Applica:on state is transferred with the responses
• Applica:on state is transferred via links
• The Client needs to
– interact with the server only via hypermedia
– figure out possible ac:ons through the resource
representa:on sent
GET h"p://wso2.com/customers/apac/1123
{
“name” : “Alice Grey”,
“ID” : 1123,
“promote”: “h"p://wso2.com/customers/apac/1123/promote”
}

19. When to use Resource Oriented Architecture
• Systems which have clearly defined en::es, which
have clear associa:ons and can be logically modeled
• Systems which will evolve rapidly
– Growth in en::es
– Change in server implementa:on
• Systems where the client needs to use lightweight
web technologies
• Systems which can be developed quickly

20. ROA in a Connected Enterprise
• Distributed
– Mul:ple en::es(Systems and Things) with context and
associa:on
– Loosely coupled
– Not bound to contracts / services
– Can evolve easily into a large ecosystem
• Ubiquitous
– Works on technology that supports ubiquity
– Secure - OAuth, OpenID Connect
– Lightweight with low overhead
• Agile
– Easy to design
– Simple yet powerful technology

21. Building a Resource Oriented Architecture with
WSO2 Products

22. Steps to Build a Resource Oriented
Enterprise Architecture
• Iden:fy the en::es (nouns) in the system and their
rela:onships
– Design the resources
– Design the access methods (which verb ac:on)
– Determine security
• Iden:fy how state can be represented via responses
– Define addi:onal resources plus links for state
• Design granularity
– Determine metadata for resources
– Iden:fy security at each level of granularity
• Implement with REST

23. What does WSO2 offer ?

24. PlaTorm of PlaTorms

25. PlaTorms which are well Integrated

26. Expose Base Services
- SOAP services
- REST services
- REST services - SOAP services
- REST services
- OData services

27. Integrate Systems and Data

28. Expose Managed APIs

29. Provide Tools to Manage

30. Summary
• ROA in essence would be considering all en==es as
resources which are connected in a logical manner
• With ROA an enterprise can aim to be distributed,
ubiquitous and agile
• This fits in well with the needs of a Connected
Enterprise
• WSO2 middleware is capable of moulding your
enterprise to be a connected one !

31. References
1. hVp://searchcio.techtarget.com/defini:on/enterprise-architecture
2. hVp://inspire.ec.europa.eu/reports/Implemen:ngRules/network/
Resource_orientated_architecture_and_REST.pdf
3. hVp://www.infoq.com/ar:cles/roa-rest-of-rest
4. hVp://wso2.com/library/webinars/2015/09/resource-oriented-
architecture/
5. hVps://www.ics.uci.edu/~fielding/pubs/disserta:on/
rest_arch_style.htm
6. hVp://wso2.com/library/webinars/2015/12/wso2-year-end-technical-
update-webinar/

32. Thank You