Shared Resources and Mule Domain Project

What is Mule Domain Project?

This blog provides insight into Mule domain project and its implementation.

Domain project is implemented to add common configurations to be shared among different projects deployed under the same domain. Mule applications can be associated with only one domain at a time where domain project and associated applications must be in the same workspace. The figure below shows how both File Sys API and ODS Sys API share common resources from the Sys Domain Project on the premise server.

When you deploy Mule on premises, you can define global configurations, such as default error handler, shared properties, and connector configurations, to be shared among all applications deployed under the same domain. Whatever you want to keep common for Mule applications, you put that information on the domain project. Remember, there is no code present in the domain project.

Why is Mule Domain Project beneficial?

The advantage of sharing resources is it allows multiple development teams to work in parallel using the same set of connector configurations, enabling teams to:

• expose multiple services within the domain through the same port.

• share the connection to persistent storage

• share services between mule applications through a well-defined interface.

• ensure consistency between mule applications upon any changes because the configuration is only set in one place.

The purpose of having a domain project is to have the common configurations in one place with the ability for reuse. The benefit of this is decreased maintenance. If there are many projects based upon the domain project, it is difficult to change the configuration of each project when needed. Instead, it is easier to change the configurations from the domain project. So, you will have less maintenance and time with a domain project implementation.

What are the requirements to implement Mule Domain Project?

This guidance is primarily focused on the implementation of Mule domain project in Mule 4, so it requires Anypoint Studio 7.1 or newer with Mule runtime engine 4.1.2 or newer, and Mule runtime engine run On Premises.

What are the limitations to implement Mule Domain Project?

You cannot define flows, sub-flows, or any message processors in a Mule domain project. Domain project is not supported on the CloudHub; it works only On Premises. Each application you deploy on the CloudHub runs as a separate instance (i.e. there is only one application per runtime).

Creating and Configuring a Mule Domain Project

Go to File -> New -> Mule Domain Project, give a project name, and then click Finish.

A domain project has a lot less folders than the normal Mule projects. For example, there is no test folder under a domain project. A domain configuration.xml file will be created automatically, and it is where you add a common configuration. If you do not want to keep configurations, HTTP Listener Config for example, in each application running on local server, you should have a domain project and put all the common configurations in there. In this case, a domain project called hab-sys-domain was created from which the two sys APIs i.e. hab-trades-file-sys-api and hab-trades-ods-sys-api can share resources.

In this case the base path is different for each project, so whatever different you do not put it on the domain project. Instead, you must include them on project level.

Now we have a domain project with one shared HTTP Listener, and we also have a property file with

Then to use the domain project on the project level:

• We have to right click on the project -> Properties ->Mule project then i) select the server runtime ii) select the domain then click on Apply and Close.

• Then we should check whether we are getting the domain configuration listener on the project’s connector configuration.

When we run the project, we make sure that both the projects in this case, hab-trades-file-sys-api and hab-trades-ods-sys-api, run on the same environment. To do that right click on the project -> Run As -> Mule Application (configure) then specify the environment where the projects should run, so that both projects will pick dev.properties file.

Copy and include whatever different in the HTTP Listener config into the projects and then delete the HTTP Listener configuration from the global configuration elements of both hab-trades-file-sys-api and hab-trades-ods-sys-api. This is because two applications cannot use the same port at the same time and both the applications should use configuration from the domain project.

Also, add configuration property elements in the domain project and specify where it should read the property files, for example ${env}.properties.

In this instance, the runtime doesn’t know the value of the environment so either we should set it in run configuration or add a global property in the domain project and specify the environment.

After you check the version compatibility of the mule-socket-connector from the pom.xml file of the domain project, then run the project.

Conclusions

When one needs to share resources among various projects running on premises, Mule domain project will come into picture. Domain projects ensure consistency between mule applications upon any changes because the configuration is only set in one place, with the added benefit of decreased maintenance and time.

References

https://docs.mulesoft.com/mule-runtime/4.3/shared-resources

https://dzone.com/articles/mule-domain-project-and-deploying-domain-project-i