Your SlideShare is downloading. ×
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop


Published on

Presentation done at RubyConf Brazil 2012.

Presentation done at RubyConf Brazil 2012.

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Service orientedarchitecture mixing Ruby and Java Maurício Linhares
  • 2. WHO?Software Developer da
  • 3. SOA isn’t bad, theimplementations we getfrom hungry consultants are
  • 4. SOA is building independent apps that do one thing well andleave everything else to others Feels like something you have heard before?
  • 5. Write programs that do one thing and do it well. Write programs to worktogether. Write programs to handle text streams because it is an universal interface. Doug Mcllroy – The UNIX philosophy
  • 6. Blame themessenger, not the message
  • 7. Old Rails app (2.x), large, with agrowing team working on it
  • 8. Running all tests took too long…
  • 9. We used the database as a queue
  • 10. We had long QA periods
  • 11. Everything happens in a single app, whereeveryone change code Why?
  • 12. How can we solve this?
  • 13. Ah, the divorce!
  • 14. Two zones Documents managementDocuments processing
  • 15. Documents management stays onthe webapp, processingdocuments migrates to a new app
  • 16. If it’s a new app, can we change technology? How do we integrate both?
  • 17. resque as our work queueour jesque fork is at -
  • 18. API REST with JSON for communication
  • 19. S3 to store the results
  • 20. Client sends a file to the app server Worker signals that it has finished the job A worker accepts the job
  • 21. Did it work?
  • 22. The two apps startedevolving in separate
  • 23. The backend systemstarted to have smaller cycles, independent ofthe webapp, with many deploys a day
  • 24. Less code meant thatthere were less tests to be runThe backend didn’t have to run webapp tests, the webapp didn’t have to run the backend tests
  • 25. There were no directdependencies between the apps, they didn’t have to be deployed together anymore
  • 26. Auto-contained messages – the backend had allinformation needed at the message level
  • 27. WHERE DID WE
  • 28. Separate applications caused communication problems between the teamsWe’re all on the same boat, open the discussion of stuff that affects both ends
  • 29. Not everyone did run all apps and the documentation wasn’t always up to date
  • 30. Jesque’s code isn’t assimple as it could be and most of the resque plugins are of no use
  • 31. Public and private API’s should not be mixed. Make sure they’re completely separate.
  • 32. Many apps in different environments will complicate yourdeployment and team building
  • 33. What did we learn?
  • 34. Build small, focused apps
  • 35. All communicationshould be done over the API and from nowhere else
  • 36. Define clearly what each application should do
  • 37. Create a minimalcommunication interfacewith that you need today. It will change.
  • 38. Don’t mix modelrepresentation with your model codeLook for solutions like Roar -
  • 39. Separe fontes/bancos de Separatedatabases/datasources for the different apps
  • 40. Plan and build stuff expecting failure
  • 41. Build to fail
  • 42. Rails Engines? Maybe?
  • 43. Where are we today?
  • 44. HTML5 front end independent of thecurrent webapp, all API based
  • 45. Auto-scaling cluster and independent of the environment for the backend is on the way
  • 47. THE ENDThank You 