In a previous interview with David Dossot, we touched upon some of the ways patterns have been used with Mule ESB. In this interview we take a further look at patterns related to Mule ESB – talking to Magnus Larsson the founder of the Soi-toolkit project.
Magnus, from Callista Enterprise AB, is an architecture and governance specialist with a focus on Java EE, SOA and Integration. Magnus is also working on the development of open source projects and is an active member on Mule Forge.
Our thanks to Magnus and now on to the interview…
PBE.NET: What is the Soi-Toolkit?
Magnus: Soi-toolkit helps you get started with Mule ESB in no time using plain Eclipse and Maven. The Soi-toolkit provides a pattern based source code generator (as an Eclipse plugin) that can generate:
- Projects with a structure and content that supports an efficient development process based on Maven.
- Skeleton source code for services and integrations by selecting a high-level pattern (request/response, one-way or publish/subscribe).
- jUnit based test code is also generated to help you both with unit- and integration-testing of the services according to Test Driven Development.
- The generator also generates proper setups for handling logging and tracing, configuration through property files, creation of projects for WSDL and XML Schemas, automatic creation of deployable files (war or zip) and more…
More details are available at: http://code.google.com/p/soi-toolkit/ – What_is_soi-toolkit?
PBE.NET: What are the benefits of using the Soi-Toolkit?
Magnus: Some of the benefits of using the Soi-toolkit include
- Reduces time from decision to initial implementation
- Well proven structures that helps the projects to start quickly and without hitting the wall when growing later on. Common component model, code structure and dependency management based on Maven.
- Great time saver and quality improver!
- Test Driven Development and well-defined and automated procedures for build, release and deploy minimize both risks and time to change and improve the overall quality of the services.
- SOI-toolkit can be customized in a number of ways to fit
in an organization’s existing environment.
For more details see http://code.google.com/p/soi-toolkit/wiki/Overview – Values_of_soi-toolkit.
PBE.NET: What patterns are currently available in the Pattern Catalog within the Soi-Toolkit?
Magnus: Soi-toolkit generates skeleton code for integrations and services that are based on high-level patterns for either request/response based interactions or one-way based interactions (a.k.a. “fire and forget” and “store and forward”). We have also plans for supporting various types of publish/subscribe pattern in the future.
Each high-level pattern supports a number of relevant transports for inbound and outbound endpoints. Soi-toolkit generates source code for handling important aspects such as transformation, logging and error handling (e.g. transactions, reconnect and retry logic) and configuration.
Soi-toolkit also generates source code for supporting both automatic and manual tests and Maven build-files for automated build and release handling (typically used by an continuous integration product such as Jenkins).
PBE.NET: Are there additional patterns encapsulated within the Soi-Tookit?
Magnus: Once the code is generated any of the patterns supported by Mule ESB can be added to the generated code such as typical EIP-patterns, e.g. routing, wire- tapping, enrichment, splitting/aggregation…
PBE.NET: What is the scope of the solution generated by the patterns? Did the scope grow\evolve over time?
Magnus: The scope is to give a kick-start for development of service and integrations following one of the high level patterns (request/response or one-way) supporting the most common transports, and requirements of logging, error handling, configuration, automated test and build/release handling.
PBE.NET: How did you recognize the opportunity to use patterns?
Magnus: From implementing a large number of integrations at a number of customers in various industries using various integration platforms, both commercial and open source based. Over time we identified solutions that repeatedly were reused across integration platforms, customers and industries. Based on that observation we started to form high-level patterns that could support these types of common solutions but still provide the flexibility for the developer to adopt them to the specific needs per integration or service.
PBE.NET: How did you automate patterns within the Soi-toolkit?
Magnus: Through a template based source code generator. The developer supplies some basic information, e.g. regarding type of pattern, name of the integration or service, and selects incoming and outgoing transport either by a GUI (Eclipse Wizard) or at the command prompt (Maven Plugin). The Soi-toolkit tool then use this information to populate a model that controls all naming conventions and hands it over to a generator that applies the model to a number of templates that produce the source code.
The model is customizable and some customers use it to adapt the source code that Soi-toolkit generates to comply with their reference architecture regarding for example naming conventions and source code structures.
Over time we would like to open up the generator so that customers can define their own templates as well.
PBE.NET: What has been the benefit of automating the patterns?
- A very short startup time.
Specifically for a customer that has not been using Mule ESB et al before. No time needs to be spent on figuring out how to use the various open source products together in a good way. Instead the customer can rely on the best practices that are built into the Soi-toolkit generators and templates and use it as a starting point.
This includes aspects of:
- Common file structure and coding conventions.
- Headstart on writing unit tests and integration tests for services and integrations
- Headstart on getting error handling, logging, configuration and setting up build files right from the start.
- Standardized structure, naming and use of Mule ESB et al.
Instead of having each developer inventing their own way of solving a specific problem all developers are writing code in a very similar way. Projects can deliver solutions faster, less expensive and with higher quality. Even more important, maintenance and enhancements become much less dependent on individual developers and can be done faster, more cost effective and with higher quality.
PBE.NET: What challenges did you encounter in using patterns?
Magnus: Finding a good balance between streamlining (standardizing) development based on patterns and at the same time providing enough flexibility for the developer so that they can add specific features required for specific integrations and services without rewriting everything.
…and at the same time keep the complexity in the Soi-toolkit tools low to be able to evolve them without getting stuck in an over complex construction of the tools.
PBE.NET: Looking forward, how do you see patterns evolving?
Magnus: The top priority for us right now is to adapt the generated code to the upcoming Mule Studio. This will make it possible for the developers to use Soi-toolkit to create source code as a starting point and then enhance the source code as required using the graphical editors in Mule Studio.
PBE.NET: What advice do you have for someone getting started in using patterns?
Magnus: Not rush too fast in defining the patterns, instead really ensure that they understand the specific problem domain. Do a number of projects initially in the problem domain without patterns to be sure that the most common and repeating requirements in the domain are clearly understood. Then in the next step start to design the patterns based on commonalities that can be standardized but at the same time provide enough flexibility to allow developers to add the more specific parts of the solution that is not covered by the patterns.