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 flows 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.
