Hypermedia and dependency injection: a lesson not to be forgotten

Posted on 01. Oct, 2010 by Guilherme Silveira in java, restful, soa

Developers always desire to break their system into components, which typically comes with a tendency to identify those components by names. Well known unique identification is vital, one thinks

With the Internet growing fast in the 21th century, distributed systems started to use URIs to identify components on the network instead of simple IDs. That was the beginning of a new era of decoupling, one where Service Locators lowered your coupling to the server, while still keeping the coupling to each and every component’s URI and method interface.

Back then, each EJB provided its own interface, and a name bound to a URI as a configuration in the client side. The downside of Service Locators and custom interfaces for each EJB component was that every time there are changes to the server, they needed to be reflected on each client too.

EJB hell ocurred when all products adopted a strategy to create multiple projects:

Interfaces, utility jars, abstract beans, framework or even full components that were shared through the myproject-commons project were clear evidence of the tight coupling between clients and services.

Moreover, all clients had to know every URI that identified a bean: another coupling.

The following example shows the process of processing an online order request and payment to a supplier using EJBs:

Service Locator when integrating: tighter coupling than more modern solutions.

The same can be accomplished using POX or SOAP:

Sample pox or soap that can be used in a web services approach, which is also service locator based: coupling++.

Around the same time Inversion of Control (IoC) and dependency injection were not as popular and understood as they are nowadays. In early 2006, PicoContainer, a dependency injection container had a big influence in the design of VRaptor, a rest based framework since 2004.

In code, Dependency Injection and IoC aid us by instead of looking up for tightly coupled URIs, receiving our requirements through our object’s constructor. Using the web as our infrastructure, instead of SOAP or EJBs common usage, allows us to receive hypermedia links in our resources, and thus remove that coupling again.

Those patterns aid us in distributed systems as they did with the engineering process: allows easier testing, mocking and spying. They also provide a new level of decoupling: servers are now able to change their links without breaking any current existing clients.

Using hypermedia, our xml could look like the following:

Simple hypermedia example supporting a payment relation.

From the previous example, if our server decides to start using paypal instead of processing the payments themselves, they can do it by changing a single link:

A link change shall not affect your clients the way it did before

Now our clients will react accordingly, becoming aware of its matching service only during runtime.

Dependency Injection in distributed systems allows you to change providers without clients realizing the change. Clients are still aware it is a network process.

Some http rest concepts built the basis to a more robust and elegant VRaptor 3 in early 2009 while in november hypermedia support was added to it.

How far is your “distributed components/webservice” project away from breaking all clients with every single update?

Our systems can be easily improved by making use of hypermedia, and real distributed system integration is just one link away from our current web services approach. Why not start it today?

This is the basis for my workshop and talk at QCon SFO 2010. If you plan to attend the event, do not forget to use the promotional code for 100 dollars discount “SILV100″ and get in touch with us for some code samples.

Tags: dependency injection, design, di, ejb, hypermedia, inversion of control, ioc, service locator, web services, webservices