Technical decisions in Tractis

Choice of Framework: Rails and Java

A while ago, we described our decision to use Ruby on Rails to develop Tractis and stated that we were happy to have chosen rails instead of Java. We also mentioned that, given the deficiencies of Ruby, we opted to employ Java Web Services for the digital signature back end.
Back then we were very happy with our choice of rails and we still are. The framework has given us a lot of agility and it’s fun to work with. Anyone who follows the blog has seen that we even participate whenever possible at Rails events to show our satisfaction.

So, what of the development we’ve done in Java?

Re-reading that post, it sounds like we’re developing in Java because there was no other choice – that if we’d had the necessary Ruby libraries we wouldn’t have any Java code and we’d be even happier. With the appearance of JRuby there are those who ask us if we’d not rather run the application in JRuby on Rails and therefore have access to the Java libraries that we need, eliminating our need for web services.

Without doubt, that decision was not just about frameworks but was also an application design choice.

The design choice: web services architecture

As we said, when we selected the framework, we also chose the architecture. We decided that we wanted to develop various specific applications other than one that encompassed everything, in the pure UNIX style.

The truth is that, looking back, we’re very happy to have opted for a Rails front end but we’re also very happy to have chosen a web services architecture. So, just like when we discussed the advantages of choosing Rails, now we want to share with you the advantages of using web services.

Another buzzword

This type of architecture is fashionable and even has it’s own buzzword: SOA (Service-Oriented Architecture). So you can now have your SOA application, done in Rails with a lot of AJAX.

If, on the contrary, you are like us and you are not motivated by buzzwords, read on

Quality

As we said earlier, the idea to design smaller and more specific applications that make up a larger application follows the UNIX philosophy.

If we stop and think about it, this is the philosophy that makes UNIX so powerful and one of the reasons why we like it so much. You have a load of specific programs: ls, grep, sed, awk… these programs do specific things but they do them very well.

Working with specific applications that have to resolve a concrete problem, we can concentrate much better on the problem at hand. You might think that to achieve task isolation it would be enough to develop libraries instead of applications – and you would be right. Having said that, developing distinct applications connected by web services allows us to have a totally language, framework and deployment-agnostic architecture. If, in the future, there are better tools in C++ or .NET for the validation of signatures, we can migrate just this application without impacting the rest of the system. Developing specific applications we can employ the best tools in each case.

In addition to the improved implementation quality, we have also discovered improvements at execution time – on one hand for scalability reasons which we’ll discuss in the next section, and on the other the flexibility to redeploy or deactivate a specific service without having to shut down the rest of the services.

Scalability

When we talk about scalability, we refer to scalability of technical resources as well as human resources. On the technical side, it’s very simple. At the start, you can have all the services on the same machine and if one becomes a bottleneck, you just move it to a dedicated machine. Additionally, if the service is share-nothing, you can deploy it on as many machines as you need to give a high level of service. This will be clear to anyone who works with Rails

On the human side, a service-based architecture allows us more room to scale our development, meaning we can move from managing a single larger team to assigning a smaller team per service. This way, as we grow and require more developers, it won’t be necessary to have a bigger and bigger team but rather a group of small, agile teams that are in charge of one or more services.

In future posts

In future posts we hope to talk in more detail about the our architecture, the services that compose it and what they are used for.
Bye for now!

By Ernesto Jiménez
Saved in: Programming, Technology, Tractis | No comments » | 28 January 2008