Mule Flow-Under The Hood
Introduction
This article is not to explain what a Mule Flow is, on the contrary it's to explain how a Mule Flow works internally. In my previous articles, I explained how to debug the Mule ESB. So, if you already know it then you are one step ahead to follow this article.
Everything is Spring
Mule ESB has excellent support for Spring Beans. It's extremely easy to declare a class as Spring Bean and later it can be used across the Mule project as a Bean. Have you ever thought why?
The answer is:
Everything in Mule ESB is Spring Bean.
Okay! Now you will ask me to prove it. Sure, I will.
Spring Libraries
In MuleESB-4.4.0/lib/opt, you can see the Spring related libraries.
The Bean Factory
High-Level Overview
Below things happen when a Mule application is deployed in the Mule runtime. In fact, a lot of internal things happen but for the sake of simplicity and brevity I am only concerned with the high level overview.
A Mule application is a .jar file which is deployed in the /apps directory of the Mule ESB. So, what happens then? The jar file is exploded and a class called DefaultArchiveDeployer will try do deploy the artifact .
Also, have you ever noticed that when a Mule application is put in the /apps directory it gets automatically deployed. Why? The answer is simple.
There is a class called DeploymentDirectoryWatcher which continuously polls on the /apps directory and if anything new is put on it it simply explodes it and deploy it.
Okay now coming back to the previous discussion. So, what happens after a Mule application (.jar) file is added to the /apps folder? Below steps happen. For this presentation , I am deploying an application called test with a Mule configuration file named test.xml and a flow called testFlow.
The exploded jar file is read and a DefaultMuleApplication is created.
It contains the information regarding what's inside the Mule application.
After that a DefaultMuleContext is created which contains hell lot of information regarding the whole runtime as well as for the Mule application.
After the context is created the actual fun begins.
Now it invokes the SpringArtifactConfigurationProcessor to configure the Mule configuration file (test.xml) so that it can be converted to a Spring Bean.
After the above process, a parser class called DefaultAstXmlParser will parse the test.xml file and converts its contents to Java objects.
After this phase, a MuleArtifactContext is created where Spring Application Context is initialized. And then inside the same object doCreateApplicationComponents method is invoked.
Note its arguments. It receives a beanFactory which is definitely a Spring Bean Factory, also receives an argument called applicationModel which contains the definitions of the components declared in the test.xml. They are a Http Listener and a Logger only for this use case.
So, after the execution of this method, the flow called testFlow is registered in the Spring Application Context. Mule runtime registers the flow as a DefaultFlowFactoryBean to the Spring Context.
Check this:
You can see that now the flow defined in the test.xml configuration file is nothing but a Spring Bean and it's managed by the Spring Framework.
It's that simple to understand what lies under the hood.
Small Discussion
In the above section, I tried to give an overview of what lies beneath a Mule Flow. It's nothing but a Spring Bean. Similarly, other components defined inside a Flow are also spring beans.
Now, you may ask where do the XSDs related to the Mule components reside. Dude, it's also simple to find it out. Open the below jar:
mule-runtime-ee-extension-model-4.4.0.jar
In the debug window you can see that there is a variable called classLoaderToUse. Its value is :
org.mule.runtime.module.reboot.internal.MuleContainerSystemClassLoader
So, this class loader will load the specific jars to the JVM for which it's configured. In the meantime, it will also load the resources (XSDs) in the jars that are found in META-INF directory.
In the above diagram you can see the loaded XSDs found in the jar called mule-runtime-ee-extension-model-4.4.0.jar. The url variable holds the jar location from where it's loading the artifacts.
Cool. Right? Similarly, the loader will load all the XSDs found in another jars also. Check the below loaded jar.
mule-runtime-extension-model-4.4.0.jar
Now just for your curiosity check mule-core.xsd found under META-INF.
Check the root <mule/> element definition.
These XSDs are the core definitions and the Mule runtime processes them to convert them to Spring Beans.
Conclusion
That's it in brief regarding the internals of a Mule flow. I minified the whole concept of Mule ESB in this personal project. It's cool.
Happy learning!
