The document discusses decomposing a complex Mule flow into smaller parts using VM components. The VM transport allows breaking a large, complex flow into smaller pieces connected by queues for better control and performance. This helps control each event queue, reduces flow complexity, and prevents resources from being overcommitted. The example shows exposing a CXF web service by breaking the flow into two parts connected by a VM queue. It stores the outbound properties before sending to the VM to protect them, as properties may be lost passing through a VM.

1. VM example n Mule

2. We all know how to expose a CXF based SOAP web services in Mule.
How about exposing the web service by decomposing a complex flow into smaller
part with VM component ??

3. Mule supports VM transport, which by default uses in-memory queues but can
optionally be configured to use persistent queues.
The VM transport has often been used to implement complex integrations, where the
flow is big and complex and need to be broken into smaller parts for better control.

4. One main reason to use this architecture, is that we can fragment the logic into
smaller pieces and can connect it and decouple each event, and is done mainly for
high performance and high control.
So now, we will see how easy it is to configure and expose a CXF web service with VM
component in Mule.
And for this we need to have 2 separate flow to expose the web service.

5. Advantage with breaking the flow with a queue :-
• Help to control on each event queue
• It also reduce the complexity in the Mule flow, where there is a large Mule flow
with different functionality.
• The service can be well-conditioned to load
• Preventing resources from being over committed when demand exceeds service
capacity.
• The message flow will be faster compared to other queue services like ActiveMq.

6. So, let’s create our flow to expose a CXF web service by breaking the flow into 2 parts
connected with VM components as follows :-

7. You can see that we have used a set property after CXF component to store the
method name which is actually SOAP action here as the message properties generally
get lost if passed through a VM queue.

8. Our Mule config will be following :-
You can see in flow2 the SOAP action stored is provided as entry point for web service
implementing java class

9. Now, we can test our web service in SOAPUI and see that the web service is
generating a response which means it is working perfectly

10. So, if we are exposing a web service using VM endpoints the first thing we should keep
in mind is to store the outbound properties of the message before sending the
message to the VM outbound endpoint .
The main reason of doing is to protect the properties and get it in our next flow, since a
message may loose it’s outbound properties while passing through a VM.

11. In my next slide I will bring some other techniques of implementing VM endpoint in
our flow.
Hope you have enjoyed this simpler version.
Keep sharing your knowledge everywhere and let our mule community grow 
So, Happy coding …