In the previous article I have described how to share common functionality encapsulated in flows and subflows. This time I will focus on common configuration that should be shared among our applications. Mule has offered domain application that can solve that. You will see how can we use this in bran new Mule version 4.
Each application that you will create has relationship with default domain project. This domain does not share anything with your application. It just exists! Like in the diagram above. We have three deployed applications, that were developed separately but still they have default domain attached.
When you create your very own domain project you may chose which applications should use it. As you can see below, in our environment we can have applications that have default domain but also other applications related to other non-default domain applications.
So what exactly does domain project do?
I have two applications that would listen on port 8081 but on different paths. When I develop two applications and test them, everything should work as design. The problem starts when we would try to deploy them on application server. We will receive port binding error.
Only one application listening on given port is allowed. Completely normal and obvious situation. But would that mean that we need to give different port for all our services?
The answer is no.
Using domain project we may share global configuration and properties. In our case all we need to do is to create HTTP Listener configuration with our specif port. Then in each application related to our new domain we may choose this configuration item.
When we bind our application to custom domain we automatically get not only shared common configuration and properties but also dependent libraries. Of course we can have our own common mule library that we attach only to specif applications – like in the diagram above. But we may, as well, attach it to domain project. As a result all applications within this domain would gain this dependency.
How to create domain?
So let us begin with an empty domain.
- In Anypoint Studio choose New > Mule Domain Project
- Name the project and choose runtime
Dependency to Mule module
We may choose to use same version of mule modules like HTTP or JMS. So let’s see how to do it.
- Open mule-domain-config.xml file
- Click Manage Modules button on right hand side
- In Properties window click Add Module
- Then search for specific modules like HTTP, JMS
- Click Apply and Close
Remember to remove duplicate dependencies from your applications if applicable. For example HTTP module is added by default. If you decide to include it in domain, make sure that it won’t appear in application. Otherwise your application will not start.
As you can see dependencies have been download and attached to the project.
Our projects may share same configuration properties. Instead of duplicating them, we can embed them into Mule domain project.
We do it, like in the standard Mule project. We create file with extension yaml and place there properties. We may use them in global configuration in domain project but also in Mule applications within that domain.
Sample yaml file:
http: port: "8091" profit: info: "ProfIT domain application"
The logic is the same like with the standard Mule application. When you open mule-domain-config.xml file you will see two tabs instead of three.
The reason for this is simple, you are not allowed to define flow and subflows in domain project. You can do this using separate library, but that I have already described.
Domain project is always used either default or custom one. In order to create that project you use separate option in menu of Anypoint Studio. This feature allows to share global configuration and properties. It is a good place to share other dependencies as well for example mule modules, custom java libraries and our own custom library with reusable flows.
In the next article I will describe how to include given application into a custom domain.