Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
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...
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 :-)
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:
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.
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.
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 www.serviceinteraction.com. 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".