XRMI Distributed computing through AOP

We had this interesting project at work: design and implement a Thrift-like code generator but for RESTful services. Thrift uses IDL files where you can define the contract of a service, including the data structures (or entities) it accepts and returns. Thrift will generate code of the client and the service in programming language of choice. The only problem is that it’s not RESTful and that’s what we needed.

The task was interesting but it got me thinking that it would be nice to avoid code generation. I tried to get to the roots of why we needed the microservices architecture in the first place. Usually, the reasons are:

1. Isolation of resources consumption and fault isolation. Scalability.
2. No dependency on single technology stack. Every individual service can be written in a different programming language/framework.
3. Encourages decoupling of code and better modularity.

Many development teams and software companies use certain tools because they are “modern” or “trending”. To give you an example, a company may be upgrading from Zend Framework 1 to Symfony 2 simply because it’s newer and not for Symfony2’s specific features. That is actually an okay approach because often you don’t have time to solve all problems yourself or even realize that you have problems. By using modern technologies you rely on experience of larger community.

However for an engineering department to have a competivie edge and be on top of the game it’s important and very much achievable to understand the exact reasons for choosing one architecture over another. Following that thought I came to the conclusion that more often than not only the first item is why micro service architecture is used:

• Encourages decoupling of code and better modularity.

That should be handled on a separate level, by creating abstractions, packages and modules. This is why we have OOP and Encapsulation. Separate VCS repositories should exist with appropriate permissions for owning development teams.

• No dependency on single technology stack. Every individual service can be written in a different programming language/framework.

This is a valid reason, but from my experience this is often not needed, especially for internal APIs. Using different languages has its cons also, for example you will need to port and maintain all infrastructural code.

Isolation of resources consumption and fault isolation. Scalability.

There is an otherwise great application, properly designed, loosely coupled, flexible and a breeze to maintain. The only issue is that we need to isolate and scale parts of it independently. I felt like this was a cross cutting concern that could be addressed by applying Aspect Oriented Programming. I implemented a proof of concept and a demo application that are available on GitHub: xrmi, xrmi Demo.

The demo is an online store application with classes ShoppingCartService, CustomersService and WarehouseService. At some point the load on WarehouseService forces us to scale it independently and use a cluster of machines with lots of operating memory. By using XRMI and AOP the demo application directs all calls to the WarehouseService to a remote instance:

public void configure() {
    if (warehouseServiceAddress != null) {
        // in this example all calls to warehouse service will be directed to the remote instance
        // however method interception could be used here, so individual methods can be distributed separately
        bindInterceptor(
                Matchers.subclassesOf(WarehouseService.class),
                Matchers.any(),
                new RemoteCallInterceptor(warehouseServiceAddress)
                );
    }
}

all that happens transparently for the application.