Your current filters are…
In typical service oriented architectures, monolithic applications are sliced along domain verticals to create several independently evolving 'services' that can be used in combination to achieve various outcomes.
Rails applications lend themselves to this architecture beautifully and are slowly making inroads in big organisations for this reason. One of the big problems with this approach is that analyzing and managing large quantities of data from multiple services to produce a result becomes very hard. What was originally a relatively simple task when all data sat in the same database as part of a monolithic application, becomes, when split into multiple services, a whole different beast.
This talk will focus on our experiences building a system involving about a dozen rails based services integrated over HTTP and XML and the issues we had to deal with when working with large data sets. We will talk about:
* Various problems we faced while building RESTful APIs which demanded asynchronous communication between two services
* Places where this asynchronous communication was needed to be initiated by the server, essentially a push mechanism instead of pull
* Different approaches to this solution
** Sharing a database using read-only 'remote models'
** Creating read only local caches at each consumer
*** Propagating updates by having the producer explicitly update each consumer
*** Propagating updates using a message queue and the pros and cons of integrating with them in Ruby
by Sean Cribbs
Over the past 5-6 years we have seen a lot of changes in the way that Ruby apps speak HTTP -- from Rails' "REST" conventions, to the brilliantly simple Sinatra, to the modular Rack abstraction -- but we haven't yet unlocked the entire subtle power of HTTP. We know HTTP is so much more than verbs and URLs that correspond to CRUD, and yet it's still too hard to do conditional requests, content negotiation, and then return the right type of response.
What if, instead of forcing HTTP into our MVC-shaped applications, we shaped our applications like HTTP? Instead of forcing a resource into seven controller actions or verb/URL-specific methods, what if the resource itself was the abstraction? A whole world of subtle and powerful programming patterns emerge.
This is the world of Webmachine, a toolkit for building HTTP applications and a port of the Erlang toolkit of the same name. I will introduce Webmachine's unique programming model and demonstrate how to easily expose rich HTTP behavior in a few short lines of Ruby code.
29th September to 1st October 2011