Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

In the good old days of Mule 1.x, the Mule had a specific purpose related to threading or, sometimes, streaming of data. People tended to stick to the default model more often than not. This changed in Mule 2.x

In Mule 2, the model is nothing more than a logical container that lets you group services together. Seen from this perspective, beginners wonder what the point of a model is. Specifically, they wonder whether they would ever need more than one model in any Mule application.

The thing is that a model is so much more than a mere container. The best reason for having multiple Mule models in a single Mule application is the ability to have a consistent exception strategy for services.

Let’s take an example. Assume an application that has two message flows within it: one message flow that integrates a sales application with a CRM back end and a second flow that integrates a production application with the stores database. In both cases, we want errors to be sent to a sysadmin. Additionally if the error is in flow #1, the error should be copied to the Sales Manager; if the error is in flow #2, the error should be copied to the Production Manager.

Clearly, we need a consist mechanism that can catch and forward errors for each flow. If we place the services for each flow into independent models, we can then place an exception strategy on the model to make sure that this requirement is in place:

    
    	
    		
    	

    	
    	...
	

    	
    	...
    	
    

    
    	
    		
    	

    	
    	...
    	

    	
    	...
    	
    

Another good reason to have multiple models is if you wanted to group services based on the entry-point mechanism which I wrote about before. I find that this situation is less common but just as useful.

A third reason is to group services based upon their lifecycle adapters but I have never seen this being done.