Reducing Bottlenecks in the JEE Stack

• By Matt Stephens
• January 28, 2007

This article at JavaLobby provides some good insight into the issues faced when creating distributed enterprise applications. The article focuses on Java technologies, but the issues faced are primarily about network overhead using any platform.

These days, it’s almost a “given” that communication between enterprise server nodes will involve an Object Request Broker (ORB) of some sort for remote method invocation (e.g. Java's built-in RMI mechanism). An ORB handles marshalling and de-marshalling of objects being sent between nodes. The ORB acronym even seems old-fashioned now, as their use has become ubiquitous in the enterprise. It’s a bit like saying “I’m going to fly in a mono-wing jetliner”: hardly worth making the distinction. Well duhh, of course you’re going to use an ORB, so why even specify it?

So if some (not all!) enterprise architects virtually take for granted that an ORB will be used, then the question of network performance tends to get brushed over, or even ignored altogether. As the JavaLobby article suggests, though, network traffic (specifically, remote method invocations) can be a major bottleneck in a distributed application. All those objects flying back & forth can bring the network to its knees.

One possible solution (as suggested in the article) is to use the quasi-open source Terracotta library in place of Java’s built-in RMI. Terracotta uses a clustering approach, which sets it apart from the traditional ORB approach (more about that in a moment).

The messages following the article, while threatening to degrade into a battle of open-source license pedantry, do pose some interesting questions. But the nature of the questions also highlights the point that distributed objects are so common nowadays that architects almost don’t question the wisdom of distributing objects at all. It’s worth remembering Martin Fowler’s (in)famous law of distributed object design: don’t distribute your objects!

Luckily though, Terracotta is a step in the right direction, as it’s primarily a clustering solution: it works by maintaining a separate copy of the same object graph on each server node. So, crucially, method invocations are local. (This is also what Fowler recommends as a superior alternative to distributed objects). If an object changes within the context of a lock, the delta (not the whole object) is propagated across the cluster.

This is an altogether more sensible solution than the traditional and naïve ORB approach of having remote objects “talk” to each other via method invocations across a network, in which every object parameter must be serialized and sent. “ORB-happy” enterprise developers still in doubt should devour the JavaLobby article and take a peek at Terracotta.