With this interview in our Voices series, we chat with David Dossot who has been a professional software developer for 16 years and a programmer for twice that long. He loves distributed and asynchronous architectures. He recently co-authored Mule in Action for Manning Publications. He leads a few open source projects and commits on a few others. He is also a judge for the Jolt Product Excellence Awards and has written several articles for the late SD Magazine.
Our thanks to David, and now on to the interview…
PBE.NET: How has the use of patterns benefited the creation of Mule?
David: Mule has borrowed its core concepts from the Enterprise Integration Patterns (EIP). As such, these patterns have provided the definition of the essential moving parts of Mule.
The latest versions of Mule have added support for more advanced configuration patterns. These patterns are in fact meta-patterns in the sense they encapsulate lower level finer grained integration patterns in order to ease repeated configuration tasks.
PBE.NET: How has the use of patterns benefited Mule users?
David: Because most Mule users have some familiarity with EIP, the semantics of Mule’s configuration feels familiar to them.
The advanced configuration patterns are very beneficial for Mule users because of the reduction of the amount of configuration needed.
PBE.NET: Did Domain-Specific Languages played any role in developing Mule?
David: One can consider the XML configuration of Mule as its DSL because it expresses the semantics related to the domain of application integration on which Mule focuses.
This said, many would frown at the idea of considering XML as a good support for a DSL. Recognizing this, an effort has been made to back all the advanced configuration patterns with Java constructs, opening the door to a DSL implementation that will be more palatable to developers.
PBE.NET: How did you recognize the opportunity to use patterns?
David: The main driver for using patterns is the familiarity of concepts for Mule end users.
PBE.NET: How do you manage your patterns?
David: Patterns are discussed in an internal wiki. When deemed interesting they are quickly implemented and exposed to the community of users. The wiki is used as a stem for the official documentation page, which is a public wiki.
PBE.NET: How did the use of patterns impact your application quality?
David: Because they encompass a predefined composition of core constructs, Mule configuration patterns entail a deterministic behavior that can be unit and integration tested, eventually leading to an increased quality of the application.
PBE.NET: Did you use pattern specifications, implementations, both?
David: Patterns are loosely specified in a wiki then reified and offered to the end user in the open source distribution of Mule. Feedback from the community drives the refinement and evolution of the configuration patterns.
PBE.NET: If you used pattern implementations, where did the idea to use pattern implementations originate? Were there challenges in convincing others that this was the right path forward?
David: Users demand was the driving force behind the creation of advanced configuration patterns.
PBE.NET: Looking forward, how do you see patterns evolving? What about DSLs? MDD?
David: We’re expecting Mule’s configuration patterns to be a community/user driven process where actual needs will yield requests for new patterns.
We’re also expecting that users will need patterns specific to their own businesses and will not want to share these patterns in the open. This is why we have created technical facilities to allow Mule users to create their own pattern catalog on top of our infrastructure. This will encourage reuse within an organization using Mule.
PBE.NET: For you what is the main impediment to the spreading of patterns?
David: The lack of a pragmatic approach can be an impediment to spreading patterns. The use of simple pattern management practices backed with tools that developers can seamlessly use in their daily activities