Free MuleSoft CONNECT Keynote & Expo Pass Available!

Register now+
Nav

Shared Resources

Mule can define selected connectors as common resources and expose them to all apps deployed under a same domain. These resources are known as shared resources. To host them, you must create a Mule Domain Project and then reference it from each of the projects that use the elements in it. Once defined, any Mule app associated with a particular domain can access resources in this file. Note that Mule apps can be associated with only one domain at a time.

Shared resources allow multiple development teams to work in parallel using the same set of reusable connectors. Defining these connectors as shared resources at the domain level allows the team to:

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

  • Share the connection to persistent storage.

  • Share services between apps through a well-defined interface.

  • Ensure consistency between apps upon any changes because the configuration is only set in one place.

Prerequisites

This document assumes that you are using Anypoint Studio 7 with Mule runtime 4, or that you are building your apps using Studio 7 and deploying them to Mule 4 Standalone runtime. 

Limitations

Defining flows, subflows, or any message processors as shared resources is not supported. Domains are not meant to share behavior. They are meant to share resources only.

Basic Anatomy

Studio Project

The following files are key within the Mule Domain Project:

/src/main/mule/mule-domain-config.xml

This is the shared resources configuration file. This file must have the mule-domain-config.xml file name.

pom.xml

This is the dependencies file descriptor. It is a Maven POM file with required plugins for domains projects.

/mule-artifact.json

This file is a descriptor for the domain artifact.

Domain Artifact

You can find the following files when you package a domain into a JAR file:

mule-domain-config.xml

This is the shared resources configuration file. This file must have the mule-domain-config.xml file name.

/repository

A Maven-like repository with all the dependencies of the domain.

/META-INF/maven/groupId/artifactId/pom.xml

Artifact Maven descriptor file.

/META-INF/mule-artifact/classloader-model.json

Internal Mule file used for dependency management.

/META-INF/mule-artifact/mule-artifact.json

This file is a descriptor for the domain artifact.

Configuration

To use shared resources in your apps, you must complete the following tasks.

  1. Create a new domain.

  2. Define one or more shared resources in that domain.

  3. Associate applications with the domain.

  4. Reference shared resources in your applications.

  5. Deploy the domain and the applications with shared resources. Note that you can also deploy domain and apps together in a domain bundle.

The sections below describe the procedure for each of these steps.

Creating a New Domain

To create a new domain in Anypoint Studio:

  1. In the top menu bar select, File > New > Mule Domain Project.

    new+domain

  2. Fill in the same fields as you would with a regular Mule Project:

    create+new+domain

    • Provide a name for the project, and select a Mule runtime version.

Defining Shared Resources

You can configure the Domain Project by defining shared resources in your mule-domain-config.xml file. You can define multiple resources in this configuration file. In Anypoint Studio, you can edit this file in a couple of ways:

  • Configuration file: Through the XML similar to the XML configuration file for a Mule app, for example:

    
                 
              
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    <?xml version="1.0" encoding="UTF-8"?>
    <domain:mule-domain
            xmlns="http://www.mulesoft.org/schema/mule/core"
            xmlns:domain="http://www.mulesoft.org/schema/mule/ee/domain"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
            xsi:schemaLocation="
                   http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
                   http://www.mulesoft.org/schema/mule/ee/domain http://www.mulesoft.org/schema/mule/ee/domain/current/mule-domain-ee.xsd">
    
        <!-- configure here resource to be shared within the domain -->
    
    </domain:mule-domain>
  • Global Elements: This view provides a graphical interface for defining shared resources.

You can add module or connector dependencies to you domain project so you can use them as shared resources.

Associating Apps with the Domain in Studio

Note that apps can only be associated with one domain at a time.

To associate an existing app with a domain:

  1. In the Project Explorer or Package Explorer view, double-click the Mule app.

  2. In the menu that opens, click Properties.

  3. From Properties, click Mule Project.

  4. From the Domain field, select a domain for your project.

    assign+domain

    Note that when you select a domain, the Server Runtime for your project will match the domain’s Server Runtime automatically.

The domain will appear in the pom.xml for your project, for example:


          
       
1
2
3
4
5
6
7
8
9
10
<dependencies>
  ...
  <dependency>
      <groupId>com.mycompany</groupId>
      <artifactId>mymuledomain</artifactId>
      <version>1.0.0</version>
      <classifier>mule-domain-SNAPSHOT</classifier>
      <scope>provided</scope>
  </dependency>
</dependencies>

Associating Mule Apps with a Domain (Outside Studio)

When creating a Mule app outside Studio, you need to include the domain property in the mule-artifact.json file to associate the domain your app:

domain: <name of domain folder>

Example: 

domain: mule-test-domain

Referencing Shared Resources

In the following example, mule-domain-config.xml, an HTTP connector is defined as a shared resource.


          
       
1
include::_sources/shared-resources_1.xml

Any Mule application associated with the domain can make use of the shared resource by referencing it within the configuration, just as you would reference a resource within the project itself. In the example below, the HTTP listener connector references the shared resource named HTTP_Listener_Configuration


          
       
1
2
3
4
5
6
<mule>
   <flow name="httpService">
      <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
      <set-payload value="success" />
   </flow>
</mule>

In Studio’s visual editor, you can simply pick the shared resource out of the dropdown list in the Connector Configuration field of the connector’s properties editor:

pick+resource

Deploying with Shared Resources

In Anypoint Studio, when you deploy an application that is associated to a domain, by default Studio deploys both the application and the domain together. Also, when deploying a domain project, by default Studio deploys every application associated to it, as well. You can change these default behaviors by changing the Run Configuration for the domain. In fact, you can deploy any set of applications in your workspace together, even if they don’t share the same domain.

To set this in Studio, open the drop-down menu next to the play button and select Run Configurations.

run+configurations+1

Then pick the General tab, and tick or untick the boxes next to the projects that you want to always deploy together with the application that is currently selected on the navigation menu to the right.

run+configuration+3

The steps below describe how to deploy your domain project and the applications outside Studio, to Standalone Mule.

  1. In Studio, select File > Export. Then in the folder named Mule, pick Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata). This creates a .zip file that you can deploy to Standalone Mule.

    export

    If you’ve created your Domain outside Studio, Zip the components of your domain project by selecting the mule-domain-config.xml file and, if you have one, the lib folder with its contents, and compressing them into a single zip file. Name this zip file with the name of the domain. Copy the zip file to MULE_HOME/domains

    Note that right clicking the a folder and selecting Compress results in additional folders being added to your folder structure when Mule unzips your file, which causes deployment problems. Use the command line to zip your files recursively, or package your app as a zip file from Studio.

  2. Save, zip, and copy the zip file for each application that references this domain into the MULE_HOME/apps folder.

  3. Start Mule via the command console.

    When Mule starts, it first deploys any domains found in the MULE_HOME/domains folder, then it deploys the applications in the MULE_HOME/apps folder, so that all domains are fully started before the applications start.

Deploying Domain Bundles

You also have the option of bundling the applications associated with a domain in your domain folder, then deploying the entire folder as a bundled unit. To do this, include an apps folder in your domain folder structure and place the zip files of your applications there.

domainBundle

The deployment behavior is the same as deploying a domain and apps separately: Mule first deploys the domain itself, then the applications. Deploying domain bundles simplifies the deployment mechanism for teams by removing the manual step of deploying applications separately.

Example Mule Domain Projects

The following code examples show sample mule-domain-config.xml files, each configured to share a single resource. Note that you can define multiple shared resources in your mule-domain-config.xml file.

HTTP

Sharing an HTTP connector within a domain allows you to reuse the same port within all the applications that belong to the domain.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_02.xml[]

HTTPS

Sharing an HTTPS connector within a domain allows you to reuse the same port within all the applications that belong to the domain.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_03.xml[]

VM

Enterprise

Sharing a VM connector allows multiple Mule applications within the same domain to communicate through VM queues. Defining a VM connector as a shared resource is a best practice for consuming services provided by other Mule applications within the same container.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_04.xml[]

JMS 

Sharing a JMS connector creates a common connection to the broker between multiple applications, minimizing the number of client connections to the broker. 


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_05.xml[]

JMS Caching Connection Factory

Mule provides a caching connection factory for JMS connections to improve JMS resource utilization.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_06.xml[]

Database Configuration

Sharing a db configuration creates a common connection to a database between multiple applications, minimizing the number of client connections to the database.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_07.xml[]

TLS Context

Listener configurations can share the same TLS configuration. Additionally, all data (including passwords) would only need to be visible at the domain level, so app developers could use the certificates without having to access other critical data.


          
       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?xml version="1.0" encoding="UTF-8"?>
<domain:mule-domain
        xmlns="http://www.mulesoft.org/schema/mule/core"
        xmlns:domain="http://www.mulesoft.org/schema/mule/ee/domain"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:spring="http://www.springframework.org/schema/beans"
        xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
        xsi:schemaLocation="
               http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
               http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
               http://www.mulesoft.org/schema/mule/ee/domain http://www.mulesoft.org/schema/mule/ee/domain/current/mule-domain-ee.xsd">

<tls:context name="customContext">
        <tls:trust-store path="trustStore" password="mulepassword"/>
        <tls:key-store path="clientKeystore" keyPassword="mulepassword" password="mulepassword"/>
</tls:context>

</domain:mule-domain>

WMQ 

Enterprise

Sharing a WMQ connector creates a common connection to the broker between multiple applications, minimizing the number of client connections to the broker.

To share a WMQ connector as a shared resource, you need to remove the mule-transport-wmq-ee-<mule-version>.jar from $MULE_HOME/lib/mule/per-app/ folder and remove native wmq jars from your application’s $MULE_HOME/apps/<my-app>/lib/ directory. Place all these jars in the $MULE_HOME/domains/<my-domain>/lib/ folder instead.

For example:

Before After

$MULE_HOME/lib/mule/per-app/mule-transport-wmq-ee-<mule-version>.jar

$MULE_HOME/domains/<my-domain>/lib/mule-transport-wmq-ee-<mule-version>.jar

$MULE_HOME/apps/<my-app>/lib/com.ibm.mq-7.0.jar

$MULE_HOME/domains/<my-domain>/lib/com.ibm.mq-7.0.jar

$MULE_HOME/apps/<my-app>/lib/com.ibm.mq.jmqi-7.0.jar

$MULE_HOME/domains/<my-domain>/lib/com.ibm.mq.jmqi-7.0.jar

$MULE_HOME/apps/<my-app>/lib/com.ibm.mqetclient-7.0.jar

$MULE_HOME/domains/<my-domain>/lib/com.ibm.mqetclient-7.0.jar

$MULE_HOME/apps/<my-app>/lib/com.ibm.mqjms-7.0.jar

$MULE_HOME/domains/<my-domain>/lib/com.ibm.mqjms-7.0.jar


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_08.xml[]

JBoss Transaction Manager 

When you define JMS connectors and db configurations as shared resources in your domain, you may have to use XA transactions in your applications. In this case, you must define the XA transaction manager in your domain configuration as well. 


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_09.xml[]

Bitronix Transaction Manager

Enterprise

When you define JMS connectors and db configurations as shared resources in your domain, you may have to use XA transactions in your applications. In this case, you must define the XA transaction manager in your domain configuration as well. 


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_10.xml[]

The Bitronix module integration also provides a JMS connection factory pool and a datasource pool to be used when using a datasource with XA transactions. You can define either or both of them as shared resources.


          
       
1
Unresolved directive in shared-resources.adoc - include::_sources/shared-resources_11.xml[]

Tips

  • If you have existing applications that you created in Studio and you want to modify them to use shared resources you can follow all the same steps above.

  • Connectors defined at the domain level are automatically used as the default connectors for the applications deployed in those domains. When only one connector of a specific type is defined at the domain level and the application doesn’t explicitly contain a reference to another connector of the same type, then the one defined at the domain level is used as the default connector for that application. In such case the connector-ref or config-ref attribute to use the shared resource is optional.

  • Note that although shared resources is limited to the selected connectors and libraries covered in this document, there are ways to share other configuration fragments in Mule. Refer to Sharing Custom Configuration Fragments for details.