In this post I will show the differences between chaining flows with a VM transport versus using a flow-ref. When I need to divide my Mule flows into re-usable units I often break them into smaller flows and then chain them together in a main flow.
Flows can be chained together using flow-ref’s or using VM connectors, most recent examples use the flow-ref’s. However flow-ref’s are a Mule 3 addition and in Mule 2 VM connectors were used to chain flows.
Given this background and with flow-ref’s looking like the recommended approach, is there a scenario when VM connectors are preferred over flow-refs? The short answer is Yes ! but admittedly flow-ref’s are preferred over the VM transport in most cases and here is why.
- VM connector creates a transport barrier in the flow: On a transport barrier your mule message goes through an entire serialization and deserialization process which results in a new mule message with the same payload.Read about effect of transport barrier on a mule message here
When to Choose a VM Transport Over a Flow Reference
One way VM endpoints enable message redelivery strategies to be configured in your exception handling blocks, this is not possible with flow-ref’s. VM’s are able to do this because they internally use a queue to hold messages while flow-ref’s are similar to simple method calls.
Look at the sample flow below, here the message will be redelivered 5 times and this is enabled by the use of VM inbound.
Contrast that to a private flow and chaining with flow-ref’s, if an exception occurs in the called flow and we have a rollback strategy configured it will NOT be executed because there is no internal queue involved.
To summarize use a flow-ref by default but don’t hesitate to use VM transports if you need re-delivery of messages.
There are also differences in the use of thread pools between private flows and VM’s but I will leave that for another post.
The sample source code for this post is available on Github.