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-refs or using VM connectors; most recent examples use the flow-refs. However, flow-refs are a Mule 3 addition; in Mule 2, VM connectors were used to chain flows.
Given this background and with flow-refs 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-refs 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 the effect of the transport barrier on a Mule message here.
So when would one prefer to use a VM transport over a flow-ref?
First, VM endpoints enable message redelivery strategies to be configured in your exception handling blocks, which is not possible with flow-refs. VMs are able to 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 5 times, and this 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 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 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.