Gregor's Ramblings

Of Boxes and Lines

Feb 25, 2006

Gregor Hohpe
Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also a technical director in Google Cloud's Office of the CTO.

Wow, it's been a while since my last post... I guess typing on an airplane is more productive than on a shuttle bus bouncing up and down 101. Winter also tends to be busy because slide material for the developer conferences in Spring are due. I am going to be teaching 2 sessions at SD West and 3 at TheServerSide Java Symposium in March. And I was able to squeeze in an article for ObjektSpektrum in Germany. But let's talk about messaging...

Raising a Structure

Traditional application design using object-oriented methods tends to focus on the structural aspects of the solution over the modes of interaction. This is no surprise considering that object-orientation provides for rich compositional constructs such as inheritance and aggregation. Classes tend to be rather fine-grained so that the structure composed of the individual elements is often the key design artifact. Lifecycle control is a close second, manifesting itself in creational patterns such as Factories and Singletons and structural concepts such as aggregation vs composition (which one was the solid diamond again?). The specific type of interaction between two individual components appears to be less interesting than the nature of the relationship between them. This observation also explains why UML Class Diagrams tend to be more popular then Collaboration Diagrams. Because I tend to rant about people who portray their own opinions as facts, let me substantiate my claim with some hard, scientific evidence! In the second edition of UML Distilled (yeah, I still live in the "UML<2" world) Martin Fowler dedicates two chapters with a combined 46 pages to Class Diagrams while he speeds through Interaction Diagrams (combining Sequence and Collaboration Diagrams) in a mere 12 pages. Now who would want to argue with Martin Fowler? His opinions are facts :-)

Interaction gets Attention

The focus on structure over interaction is generally quite appropriate for most systems that exist in a single memory space and are under the control of a single development team. Method calls are pretty cheap and any issues related to the interaction of two objects are easily resolved. Still, traditional object-oriented design does not ignore interaction altogether. Some of the classic design patterns presented in GOF do concern themselves with the way objects interact. For example, the Mediator "encapsulates how a set of objects interact" while the Observer "notifies all dependent objects of a state change". Both patterns elevate the interaction between objects from their shadow life to become first class players in the object model. These patterns give us a hint that looking at the way components interact can be more interesting than might at first appear.

In distributed systems the significance of interaction increases dramatically:

  • Most obviously, the cost of interaction between components goes up significantly as data has to be serialized, sent over the wire, and put back together at the other end. Add a little routing, some transformation into the mix and soon the cost of a method call increased by a few orders of magnitude. Suddenly it matters a lot whether one component sends a single message or a series of small messages...
  • Distributed systems also introduce uncertainty into the mix. For example, if one component does not receive acknowledgment for a message it sent, more than one possible scenarios might have occurred. The request message might have been lost, the other component might have failed, or the response message might have been lost. Suddenly, even simple interactions have to deal with these eventualities. For example, is the sender allowed (or expected) to resend the request? How many times? How long does the sender have to wait? What happens if the resending is also unsuccessful? These questions rarely come up in the world of synchronous, object-oriented applications.
  • Additionally, loose coupling brings variability and lack of control. When dealing with a remote entity (assume for example a B2B scenario) the two communicating entities are typically developed by separate parties. Therefore, nailing down the rules of the interaction is important to make sure (potentially high value) transactions can be executed predictably and reliably.

At the same time structural aspects can move into the background as distributed systems often do not provide for rich structural mechanisms such as inheritance, polymorphism and the like. For example, this shift of attention from structure to interaction is at the heart of many of the debates on service-oriented computing. Service-oriented architectures have rather simple composition rules but pay close attention to loosely coupled interaction between systems.

Of Boxes and Lines

Ralf Westphal summarized this shift nicely when he concluded that we "turn the lines into boxes". He was referring to the usual diagram that depicts each component as a box and each interaction as a line between two boxes. Now that we are more interested in the interaction we turn the line (i.e. the interaction) into a first class citizen, i.e. a box. This metaphor works especially well in the world of messaging where we have a message object that represents a portion of the interaction. So even an OO class diagram would depict that message class (or object) as a box.

Even the OMG took Notice

It is a popular hobby to poke fun at the OMG. A friend of mine, who was involved in the CORBA spec work, once claimed that the "OMG takes over good work and ruins it". Hmmm... that sounds a little like the acquisition strategy used by Sun, so maybe misery loves company. Oh well, this is not the bile blog so let's focus on the bright side of life.

The weakness of sequence diagrams have long been the number one target in the UML specification. Sequence diagrams only depict one possible way for components to interact. This leaves a lot to be desired from the standpoint of a precise specification ("execute that, my friend!"). I am not sure whether it was this oft cited weakness or the realization that interaction is stepping in the foreground, but UML 2.0 introduces a series of additions to the good old sequence diagram. These extensions allow us to specify the actual rules of the interaction.For example, we now have interaction operators such as option, parallel, weak sequencing and so on. Sadly, the notation is rather hideous. Could this be the reason that "UML 2.0 in a Nutshell" banishes interaction diagrams to Chapter 10?


Of course, where there is something new, there are always a pattern or two to be found :-) While the p word has been abused pretty badly (apparently it helps sell stuff -- hey this would make good geek trivia "what do patterns and sex have in common?") focus on a new part of the application design does warrant a new set of patterns. Commonly occurring problems when designing interactions are inherently different from the problems you encounter when designing structures. If this is true, we should be seeing some new pattern languages around interaction and conversations. And I can back up my claim once again. Marlon Dumas and Arthur ter Hofstede (with the help of SAP) maintain a very nice collection of interaction patterns at And reliable sources also tell me that we might be seeing integration patterns focused on conversations soon. To give you a hint, my talk at SD West is titled "Conversations between Loosely Coupled Services".


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is a technical director in Google Cloud's Office of the CTO. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices across many different technologies.