Migrating to Mule 3: Service or Flow


Flow has transformed Mule and provides a very powerful way to configure many types of integration scenarios.  However, I wanted to make it clear  The <service> model from Mule 2 is not being deprecated or removed.  If you already use Mule 2.x you may be wondering whether to stick with <service> or go with the <flow>.

When to use Flow

Flow is our recommended approach for new applications in Mule 3, but flow is not at complete feature parity with service yet with the following limitations:

  • Outbound-origin transactions are not supported, this means you cannot initiate a transaction from an outbound router, but the transaction is supported on the individual endpoint.  Most of the time you will originate transactions on an inbound endpoint and commit across one or more outbound endpoints, and this is supported with <flow>.
  • Async Request/Reply router not supported in Flow yet.  This router allows asynchronous requests to be made with a response sent back to the caller once a response is received from the asynchronous request.
  • You can’t use inside a service model.  A model is used to add common behaviour to all services in the model.  The most common use case for this is adding a common exception strategy for a set of services in the model

You’ll notice in the Mule 3 documentation that all the examples are being migrated to use flow instead of <service>. We recommend that  all new users start with Flow since it is easier to grok, has more capabilities and much less verbose.  And our forthcoming MuleStudio uses Flow and will not be supporting the service model.

When to use the Service model

If you already use Mule 2.2 then you have already written your Mule applications using the service model, you can continue to the Service model in Mule 3.  Our recommended migration path from Mule 2.x to Mule 3 is to continue to use services, so that users don’t spend a whole lot of time converting their application XML files to use Flow since the behaviour will be exactly the same. Furthermore, you can mix Flow and services in the same application and even the same application XML file.

Migration Examples

While there is no need to migrate to Flows, I figured I would show a couple of examples so you can see some of the differences.

File to JMS

Mule 2.2.x

Mule 3.1

Jersey JAX-RS web service

The jersey support in Mule has been changed from being configured as an endpoint to what is called a message processor in Mule 3. The following shows how the configuration changes.

Mule 2.2.x

Mule 3.1

CXF Web Services

The major migrational change in Mule 3 was with the way CXF Web Services are configured.  In Mule 2.2 configuring Web Services could be complicated in certain scenarios, so we refactored web services to make it easier to control the request and response at any point during a flow.

Mule 2.2.x

Mule 3.1

You can see from the examples above that the changes in Flow don’t seem too radical. However, Flow really reduces the amount of application XML you need to write when creating a Mule application.

For illustration the image on the right  shows how Flow reduces the amount of code needed to create an identical application in Mule 2 (the example shown is the Loan Broker that ships with Mule 2 and Mule 3). Also the Flow model is a lot more flexible allowing users to chain routers such as content based or multicast, create pipelines of transformers and filters and callout to sub flows.

We have a migration tool under development to help Mule users make the leap to Mule3 and we’ll be releasing it as a service shortly. In the mean time you can find more information about about migrating to Mule 3 here:

Migrating from Mule 2.2 to Mule 3.0 and 3.0 to 3.1 – this guide provides a complete list of changes from Mule 2.2 to mule 3.

Mule Migration Guides – a comprehensive list og guides from moving from almost all versions of Mule.

Migration Manual – Highlights the changes to the Mule configuration that will not be handled by the migration service.



We'd love to hear your opinion on this post

11 Responses to “Migrating to Mule 3: Service or Flow”

  1. It could be mentioned that JAX-RS resources and JAX-WS web services are efficiently configured with the simple-service configuration element, which is even simpler than flow.

    See: http://www.mulesoft.org/documentation/display/MULE3USER/Simple+Service+Pattern

  2. Hi David,

    Thanks for interjecting, the configuration patterns introduced in Mule actually cover all three scenarios that I choose, since the first can be expressed using the Bridge pattern: http://www.mulesoft.org/documentation/display/MULE3USER/Configuration+Patterns

  3. Nice post. We have tried to start using flow in new integrations but it is a pity that flows cannot reside inside model. We like to create own models for different integrations and specify common exception handler for that model. If we use flows we must copy exception-strategy in every flow.

  4. Ari, Good point, I didn’t mention that, I’ll update the post

  5. Inheritance (a la Spring parent/child bean) is the mechanism that has been chosen for sharing common configuration properties between configuration patterns (simple-service, bridge….) instead of dropping elements in a model, because it is more deterministic.

    I thought that flows were supposed to eventually support inheritance like configuration patterns do? They may support it already?

  6. Ross. Are there any plans to allow flows inside a model? Flows seem to be nice way to configure integrations but model is an important abstraction layer.

    I have additional improvement to flows. I would like configure splitters in a flow a bit differently than nowadays. Currently splitter is configured just adding message processors after another:

    More natural way (at least for me) would be:

    Nowadays it is awkward to continue processing after splitting because there is no way to define “end” for the splitting-scope. Are you planning to modify flow configuration to more hierarchical way?

  7. Hi Ari,
    Your example XML didn’t come through in the comment can you post a link to a gist or pastebin?

  8. Hi David, Flows don’t support inheritance right now, but it seems like a trivial addition

  9. Oh. Here is the current way http://pastebin.com/YfsqNn94 and the proposed way http://pastebin.com/1WA69j5C

  10. Hi ,

    i am using mule 3.2.1. i need one clarification in Mule 3.2.1.

    I am having mule logger project with flow, another project having mule business, could i call logger project instance in mule business project.


    i need a generic way to implement logging interceptor in mule.

  11. Hi Ross, also, I can’t seem to find a way to monitor (via JMX) the queue size, queued events when we converted our services to flows? That feature was pretty useful for troubleshooting performance issues. Thanks.