Service oriented architecture mixing Ruby and Java can provide benefits by separating applications into independent components that communicate over APIs. The document discusses a case where splitting a monolithic Rails application into separate document management and processing apps improved development by allowing independent deployment and reduced test time. Key aspects that enabled this included using Resque for job queuing between apps, RESTful JSON APIs, and storing processed files in S3. However, clear documentation and coordination were needed to integrate the separate teams working on each app.

1. Service oriented
architecture mixing Ruby
and Java
Maurício Linhares

2. WHO?
Software Developer da OfficeDrop.com
@mauriciojr
https://github.com/mauricio

4. SOA isn’t bad, the
implementations we get
from hungry consultants
are

5. SOA is building
independent apps that
do one thing well and
leave everything else to
others
Feels like something you have heard before?

6. Write programs that do
one thing and do it well.
Write programs to work
together. Write programs
to handle text streams
because it is an
universal interface.
Doug Mcllroy – The UNIX philosophy

7. Blame the
messenger, not the
message

9. Old Rails app
(2.x), large, with a
growing team working
on it

10. Running all tests took too
long…

11. We used the database as a queue

12. We had long QA periods

13. Everything happens in a
single app, where
everyone change code
Why?

14. How can we solve this?

15. Ah, the divorce!

16. Two zones
Documents
management
Documents processing

17. Documents
management stays on
the webapp, processing
documents migrates to a
new app

18. If it’s a new app, can we
change technology?
How do we integrate
both?

19. resque as our work
queue
our jesque fork is at - https://github.com/mauricio/jesque

20. API REST with JSON
for communication

21. S3 to store the results

22. Client sends a file to the app server
Worker
signals that it
has finished
the job
A worker accepts the job

23. Did it work?

24. The two apps started
evolving in separate

25. The backend system
started to have smaller
cycles, independent of
the webapp, with many
deploys a day

26. Less code meant that
there were less tests to
be run
The backend didn’t have to run webapp tests, the webapp didn’t
have to run the backend tests

27. There were no direct
dependencies between
the apps, they didn’t
have to be deployed
together anymore

28. Auto-contained
messages – the
backend had all
information needed at
the message level

29. WHERE DID WE

30. Separate applications
caused communication
problems between the
teams
We’re all on the same boat, open the discussion of stuff that affects
both ends

31. Not everyone did run all
apps and the
documentation wasn’t
always up to date

32. Jesque’s code isn’t as
simple as it could be and
most of the resque
plugins are of no use

33. Public and private API’s
should not be mixed.
Make sure they’re
completely separate.

34. Many apps in different
environments will
complicate your
deployment and team
building

35. What did we learn?

36. Build small, focused
apps

37. All communication
should be done over the
API and from nowhere
else

38. Define clearly what each
application should do

39. Create a minimal
communication interface
with that you need today.
It will change.

40. Don’t mix model
representation with your
model code
Look for solutions like Roar - https://github.com/apotonick/roar

41. Separe fontes/bancos
de Separate
databases/datasources
for the different apps

42. Plan and build stuff
expecting failure

43. Build to fail

44. Rails Engines? Maybe?

45. Where are we today?

46. HTML5 front end
independent of the
current webapp, all API
based

47. Auto-scaling cluster and
independent of the
environment for the
backend is on the way

48. THEY SAID SOA WAS BAD
THEY DON’T SAY IT ANYMORE

49. THE END
Thank You 