Optimize Resource Utilization with Mule Shared Resources

motif

In 3.5 we introduced the concept of domains in the Mule container. You can now set up a domain and associate your Mule applications with a domain. Within a domain project you can define a set of resources (and the libraries required by those resources) to share between the applications that belong to the domain.

Within the mule-domain-config.xml you can define a JMS broker connector that can be reused by all the Mule applications that belong to that domain.

This way, you can share a jms caching connection factory and reuse jms client resources with the consequent optimization of resource consumption.

How to deploy a domain in Mule

Once you have your domain fully configured, you need to deploy it in Mule. You deploy domains in the same manner you deploy Mule applications, but using the domains folder. You can create a zip file with the domain folder content or just move the domain folder to the domains folder.

Using domain level resources from within an application

Now that we have our domain defined you can use the resources defined in that domain from your applications. To do that you need to specify in your Mule application what domain you want to use. You can only use one domain per application and you just need to specify a the domain in the application’s Mule-deploy.properties file.

Then, in the mule application you can start using the shared resources declared by the domain.

As you can see in the application configuration file we are using the jms connector sharedJmsConnector declared in the domain.

Tips & Tricks

  • By sharing a VM Connector you can consume services exposed by one Mule application from another Mule application that belongs to the same domain. This is the most performant way of consuming internal services.

  • Sharing an HTTP connector allows you to use the same port from several applications.

  • If there’s only one connector defined for a particular transport in the combination of the domain config and the app config files then you don’t need to reference them explicitly using connector-ref.

Mule ESB keeps growing and with domains we become a complete container for applications. Sharing resources is really simple and easy to use since it uses standard Mule configuration. There is no need to learn a new syntax.

There are several companies using Mule and deploying hundreds of applications within a single Mule container. With shared resources you can optimize the use of connections to jms brokers and databases or decrease the number of ports in your firewall. You can even create better service reutilization with shared VM queues.

This is only the beginning. We expect to increase the components that you can share between applications in later releases.

 

Want to learn more?

If you want to learn more about this feature you can take a look at the early access documentation for 3.5.0 or take a look at the maven archetypes and plugins that we provide to simplify domain creation.


We'd love to hear your opinion on this post


5 Responses to “Optimize Resource Utilization with Mule Shared Resources”

  1. Nice features Pablo. I’ve few below concerns
    1. Can I deploy these domains in CloudHub?
    2. Can I make shared resources secure? Is there a provision of role based access in the road map?
    3. If domains are deployed in CloudHub, should I be accessing them with the domain name or with the URL of CloudHub instance name?

  2. Is there any strategy for using this while using Studio? Looking for a simple strategy for my current client to use. The lack of support in Studio makes it harder to setup a simple fool proof setup.

    • Yes, you are right. Studio support will come shortly through an update site.

  3. Hi Pablo La Greca,
    I have been trying this example, I have one question to you :

    Is it works only when we use Mule 3.5 CE edtion only ,cant we run this on EE version ???

    • Yes it does.

      In fact EE has some extra features. The most important one is the ability to communicate between mule applications deployed in the same server using VM transport.

      Here is a link to the documentation:

      HTH, Pablo.