View
6.989
Download
0
Category
Tags:
Preview:
DESCRIPTION
Citation preview
Developing Distributed Web Applications, Where
does REST fit in?Dr. Srinath Perera
Senior Software Architect, WSO2 Inc.Visiting Faculty, University of Moratuwa
What is a Distributed Web Application?
• Users access a one server (or he thinks he does) while really the app is composed of many machines.
Why “Distributed”? – for scaling. Single
machine can not handle the load
– High availability
photo by arvind grover on Flickr, http://www.fotopedia.com/items/flickr-3154212659
Google as a Distributed Web Application
• Google crawls the Web and stores all (well most of ) the Web• It builds indexes for included words and incoming links for each
document• When a user sends a query, it applies the Page Rank Algorithm
and returns the most relevant results. • It is a distributed application that built using few 100k servers
Programming Distributed Web Applications
• There are two primary architectural models– SOA (Service Oriented Architectures) : based on
processing units (verbs)– ROA (Resource Oriented Architecture): based on
data(nouns)photo by Qole Pejorian on Flickr, http://www.fotopedia.com/items/flickr-184160623
• Essentially (Web) applications deal with state (data) and operations (executions or processing units)
• Users talk to applications and either retrieve data or make changes to the current state.
SOA (Service Oriented Architecture)• There are many stateless processing units (often grouped as
services)• Users provide data to processing units, and they either return
data after processing or change the system wide state (e.g. stored in the database).
• A SOA based architecture includes a main storage (e.g. database) and many stateless processing units, and an application combines and composes those processing units together.
• E.g. Google has its indexes etc., and one main operation “search” that accepts a search query as a input and returns matching documents. – Also implementation has many internal
services
photo by L. Marie on Flickr, http://www.flickr.com/photos/lenore-m/312319615/
ROA (Resource Oriented Architecture)
• There is a resource structure• Each resource supports four
operations, PUT, GET, POST, DELETE
• Users retrieve information through GET and change system state through POST, DELETE, and PUT
• The architecture is based on resources (nouns) and processing is represented through four verbs on the resource.
photo by Svadilfari on Flickr, http://www.flickr.com/photos/22280677@N07/2435832518/ (CC)
ROA vs. SOA• There are lots of fights, which I am not going to discuss
in detail. • Argument is Web uses ROA, and it works. • SOA is much closer to the programing models we used
to with languages like C or Java. So that is natural to us.
photo by hans s on Flickr, http://www.flickr.com/photos/archeon/2359334908/
• I would say, they are two useful styles, and we have to know both and use them where it naturally fits.
• I will focus more on ROA for this discussion.
REST (Representational State Transfer)• ROA is realized with REST services or HTTP services (Good
intro to REST, http://www.infoq.com/articles/rest-introduction)
Photo by paraflyer on Flickr, http://www.fotopedia.com/items/flickr-386529128
• Main principles of REST– Give everything an ID (URI)– Things (resources) refer to each other – All interactions are done through
four verbs (PUT, GET, DELETE, POST) on resources
– Resources can return multiple formats (choosed based on content negotiation)
– All communication are stateless (each request has all the information need to serve the request)
Example: Web App to Manage a Network
• Assume we want to build a Web app to manage networks. Users can view, query, and change the network configurations through this Web App.
Photo by sylvia duckworth on Flickr, http://www.geograph.org.uk/photo/956353
Lets see how this would look with both SOA and
REST
With SOA• Architecture will include a database to hold network
data and services supporting following operations– ListNetworks()– NetworkData GetNetworkData()– ApplyNetworkData(NetworkData quearyParams)– SearchNetworks(String queryParams)
• Notice Each operation is a Verb, users combine those verbs to do what he needs
• Message formats are defined through a WSDL and each service supports one message format.
With REST• Give everything a ID (URI)
– http://uom.lk/Networks– http://uom.lk/Networks/ENT – http://uom.lk/Networks/Civil
• Things (resources) refer to each other – Retrieving a network will return something like <Networks>
<cse ref=“http://uom.lk/Networks/CSE”/>….
</Networks>• All interactions are done through four verbs (PUT, GET, DELETE,
POST) on resources– GET on http://uom.lk/Networks/CSE : Getting network data – POST on http://uom.lk/Networks/CSE: update the network config.– DELETE on http://uom.lk/Networks/CSE can delete the network etc.
With REST (Contd.)• Resources can return multiple formats– Results can return multiple formats, XML, Jason, Binary
or several XML formats etc. – Clients send the header Accept: text/json, text/xml+foo
defining supported formats, and the server returns result in a format client supports. This means a resource can support multiple formats at the same time. Also we can use this to support new formats later.
• All communication is stateless – this is same for SOA and ROA
• System can use HTTP style caching
Implementing REST Services• Define the resources structure • Define many URLs for different types of
resources• Use a REST engine to attach code to each
URL patterns, they support four verbs (e.g. see http://www.sinatrarb.com/intro)– Code segment is for URL, verb, content type– Example
http://…/Networks:On GET text/xml do….end
Photo by Kevin Dooley on Flickr, http://www.flickr.com/photos/pagedooley/2201791390/
REST Anti-patterns• Verbs in URLs
– http://uom.lk/SearchNetworks?pattern=foo– This is doing SOA using HTTP, not REST
• Ignoring status codes on responses • Not including references in responses
<Networks><cse>
<nodeCount>..</nodeCount><subnetmask> ..</subnetmask>
<cse></Networks>Use references whenever that makes sense, do not copy data in to response. Remember the underline linked resource structure.
REST, is it the Architecture to solve them all?
• Messaging – does not talk about eventing/ messaging aspects. May be need a SUBSCRIBE verb added.
• Asynchronous invocations and reliability• What about composition and transactions
etc. mostly things come from WS-* • Does error messages are enough?
• Does the REST a silver bullet for all problems– This is the source for most fights, the answer looks “No”.
Some examples.• It does not have a contract (Lack a WSDL)
Photo by Playadura on Flickr, http://www.flickr.com/photos/playadura/1401756881
So when to use it?• Use when REST is the natural
choice – It is very good at representing
resources – Not that good with processes/
executions • Same for SOA• Is it OK to mix it?
– I would say yes, but not too much– WSO2 use REST for registry API,
while SOA for many other places.
Photo by QUEEN YUNA on Flickr, http://www.flickr.com/photos/queenyuna/5710802864/ (CC)
Conclusion
• What is a Distributed Application? • SOA and ROA as solutions • Detailed looked at ROA with a Example• It is the architecture that solves everything?
“Look like we need both”
For more information
• Stefan Tilkov: A Brief Introduction to REST, http://www.infoq.com/articles/rest-introduction
• Stefan Tilkov: REST Anti-Patterns, http://www.infoq.com/articles/rest-anti-patterns
• More articles here http://en.wikipedia.org/wiki/Representational_State_Transfer
• Sanjiva Weerawarana: WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies, http://wso2.org/library/2818
Questions?
Recommended