Re-use: Accomplished! Configuration Patterns Catalog for Mule

motif

If you follow this blog or what’s happening in Mule 3, you’ve heard about the newly introduced configuration mechanism based on patterns. In the coming releases of Mule, we will keep adding new patterns based on users feedback and requests.

But this doesn’t mean your experience with  patterns will be limited to the ones that come with Mule distributions: we have made it easy for you to create your own patterns and, even further, your own pattern catalogs.

mule-catalog

Creating a configuration patterns catalog can be a strategic move when the Mule projects you’re running start to reach a certain size. Similarly, if you’re working with multiple teams that have different levels of command of Mule, creating a patterns catalog can help you.

Indeed, such a catalog would allow you to:

  • Promote re-use by encapsulating complex or repetitive configuration bits into specific and consumable configuration elements.
  • Improve communication thanks to the common lingo that the patterns will provide across teams and projects.
  • Lower the bar for less experienced developers by providing them building blocks tailored to the business activities and best practices of your company.

For that matter, we’ve created the Catalog Maven archetype, which simplifies the creation of pattern catalogs and configuration patterns within these catalogs.

To use the Catalog archetype, you’ll need Mule 3.0.1 or above. At the time of this writing, Mule 3.0.1 is available as a development release.

The archetype is fully documented on Mule’s user guide (free login required). In essence, it supports two modes of operation:

  • Creating a new pattern catalog, which is, for the connoisseur, a standard Mule module (like, for example, the XML module). Here is the command to run to create a new catalog:

  • Creating a new pattern in an existing catalog (or module, for that matter):

The archetype supports four principal types of patterns: you’ll need to pick one based on the level of flexibility you’ll need your pattern to have in its inbound and outbound phases.  Here is an overview of the supported types:

  • Message ProcessorThe pattern is a pure message processor designed to be used within a flow alongside other message processors. It doesn’t support an inbound source of message like an endpoint or a router.
  • Message Source – The pattern receives messages from any kind of message source, like endpoints or routers.
  • Single Inbound Endpoint – The pattern receives messages from a single inbound endpoint. It can optionally be configured with inbound transformers. The Simple Service pattern is of this kind.
  • Single Inbound & Outbound Endpoints – The pattern receives messages from a single inbound endpoint and dispatches to a single outbound endpoint. The BridgeValidator and Web Service Proxy patterns are of this kind.

Using the archetype to create configuration patterns will also allow you to share them easily with the rest of the world or contribute them to Mule’s codebase, should you decide to do so.

As always, we welcome your feedback: please share your experience with this archetype or patterns in general in the forum we’ve created just for that.


We'd love to hear your opinion on this post