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:
- myproject-common – containing the interfaces that coupled clients and servers
- myproject-service(1…n) – containing services that implement part of the interfaces provided in the common project
- myproject-client(1…n) – clients that consume the servcices provided by interface declared in myproject-common
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:
The same can be accomplished using POX or SOAP:
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:
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:
Now our clients will react accordingly, becoming aware of its matching service only during runtime.
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.