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