In a wide ranging discussion on the past, present and future of enterprise application integration patterns, noted author Gregor Hohpe said that a new set of architectural techniques could help designers to better understand the various tradeoffs in elaborate conversation patterns that are seen more often these days in computing.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Hohpe, a Google staff engineer and author of Enterprise Integration Patterns, talked about the evolution of design pattern abstractions, and their implications for the future of application development, at the ESB-specialist FuseSource-backed CamelOne Conference in Arlington, Va.
Over the last decade, Hohpe's book created a paradigm shift in the programming community that allowed developers to think in terms of higher level patterns using object-oriented programming techniques. However, Hohpe said that these initial ideas about design did not translate well into components in the object-oriented world.
This lead to an evolution toward higher level abstractions of design patterns around messaging, which do translate into components - more precisely, it led to messaging design patterns, which were formalized in Enterprise Integration Patterns., These succeeded because their composition model was simple and easy to formalize. Domain specific languages helped address the translation from designs into components.
In his CamelOne keynote, Hohpe said that, because messages are stateless, messaging design patterns are limited in their ability to represent higher level abstractions like conversations, workflows, and events. He is now focusing on how to bring the same formalism to describing conversation patterns.
Conversation patterns and messaging patterns
Conversation patterns are harder to express than messaging patterns, according to Hohpe. It is not always easy to express all of the rules about a conversation. Systems architects have turned to choreography description languages, but they have gotten little adoption, because they were not intuitive enough. Hohpe believes that a better set of design patterns could help understand the various tradeoffs in elaborate conversation patterns.
He acknowledged that thinking on this is in early stages. ''This is in flux. But we feel like there is a pattern language again here,'' he said. ''This is a work in progress.''
''The goal is not to find ... interesting patterns. The goal is to frame them into a language that fits together just like messaging patterns have,'' he said.
''The notation is a little tricky and looks like a mix of an IP book with a bit of modern art. But people can relate to it,'' said Hohpe. ''They can see that it is like two people talking, or me leaving a message and expecting a call back. It is not like we are inventing new stuff. It is giving people a vocabulary for something they have to build and then showing them subsequent paradigms or problems.''
The idea of a design pattern was first introduced in 1977 by Christopher Alexander as an abstraction for thinking about construction and city planning. The basic idea was to uncover a vocabulary for talking about how buildings affect people, rather than just talking about components that go into a house. In 1994, the Gang of Four -- Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides -- introduced the concept of design patterns into the programming world with the publication of Design Patterns: Elements of Reusable Object-Oriented Software. Hohpe's work built on this work. The open source Camel integration tools that were at the center of CamelOne, in turn, seek to drive Hohpe-style design patterns for easier development. The presence of Hohpe as a keynoter at the FuseSource-backed event comes as little surprise – FuseSource being a notable supplier of commercial Camel tools and support.
In the short run, Hohpe plans to focus on conversation patterns. He said, “I would love there to be an Enterprise Integration Patterns Two that talks about the conversation. It would be amazing to see if having a language like this could trigger a spate of open tools that make it easy to think about these kinds of problems, but also make it easy to translate into something that is executable, like Apache Camel has done.”