Skip to content

[3.5 M1][CORE] Mule Container Resources

Jump to bottom Edit New page
Ken Geis edited this page Jun 17, 2014 · 27 revisions

Jira: MULE-7001

Forum discussion:

Motivation / Context

Several mule users have requested the capability to share resources between applications that are deployed within the same container. The main reason for the request is that they want to create an application that is a composition of mule applications. This allow them to have different teams working independently.

Another request is the capability of consuming services between mule applications deployed in the same container using VM. This allow mule applications to make use of services deployed in other mule applications in a really easy and performant way.

We are going to provide such capabilities through the definition of resources at the container level and exposing them to all the applications deployed in the container.

Use cases

As an architect I have different teams working on different parts of an applications. I want them to work as independent units but they must:

  • share the same security mechanism
  • be able to share expose all the services through the same port
  • share the connection to the persistent storage
  • share services between each other through a well defined interface

Design

Provide an xml configuration file at the domain level in which users can define the mule components that they want to share between mule applications. Components defined in this file can be referenced from a mule application that belongs to that domain and make use of it.

** Mule already has the concept of domain. Having a domain in mule allows to share jars loading by having a common parent class loader between a set of mule applications**

shared resources deployment diagram

Configuration

Configuration file for the container

A new folder named domain inside MULE_HOME will be created. Inside users can define different domains. Each domain will be a folder inside MULE_HOME/domains folder. MULE_HOME/domains/mulesoft-api defines a domain named mulesoft-api. It can contain:

  • shared resources contained inside jar files in the directory MULE_HOME/domains/mulesoft-api/lib
  • an xml file named mule-domain-config.xml placed in MULE_HOME/domains were users can configured mule component to be shared between applications that belong to mulesoft-api domain.

Example of configuration file mule-domain-config.xml for shared mule components

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:http="http://www.mulesoft.org/schema/mule/http"
             xsi:schemaLocation="http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">

    <http:connector name="sharedHttpConnector"/>

</mule-domain>

Any mule application within that domain can make use of the shared mule component by just reference it from the app's configuration

<mule>
   <flow name="httpService">
      <http:inbound-endpoint host="localhost" port="8080" connector-ref="ApiConnector"/>
      <set-payload value="#['success']" />
   </flow>
</mule>

Mule currently allows to define shared jars between application by placing them in MULE_HOME/lib/shared/domain-name. To avoid breaking backward compatibility jar files located in this folder will still be managed as shared resources between applications.

Connectors defined at the domain level will be used as the default one for the applications deployed in those domains. This is not only useful but also consistent with the mule app behavior

Connectors defined at the domain level will be used as the default one for the applications deployed in those domains. This is not only useful but also consistent with the mule app behavior

Supported shared resources

HTTP connector

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

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:http="http://www.mulesoft.org/schema/mule/http"
             xsi:schemaLocation="http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">

    <http:connector name="sharedHttpConnector"/>

</mule-domain>

HTTPS connector

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

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:https="http://www.mulesoft.org/schema/mule/https"
      xsi:schemaLocation="
               http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.mulesoft.org/schema/mule/https http://www.mulesoft.org/schema/mule/https/current/mule-https.xsd">

    <https:connector name="sharedHttpConnector">
        <https:tls-client path="clientKeystore" storePassword="mulepassword"/>
        <https:tls-key-store path="clientKeystore" keyPassword="mulepassword" storePassword="mulepassword"/>
        <https:tls-server path="trustStore" storePassword="mulepassword"/>
    </https:connector>

</mule-domain>

JMS connector

Sharing a JMS Connector will allow you to share the connection to the broker between multiple applications thus minimising the number of client connections to the broker.

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:jms="http://www.mulesoft.org/schema/mule/jms"
             xmlns:spring="http://www.springframework.org/schema/beans"
             xmlns:util="http://www.springframework.org/schema/util"
             xsi:schemaLocation="
               http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
               http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-current.xsd
               http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd">

    <spring:beans>
        <util:properties id="providerProperties">
            <spring:prop key="queue.jndi-queue-in">in</spring:prop>
            <spring:prop key="topic.jndi-topic-in">in</spring:prop>
        </util:properties>
    </spring:beans>

    <jms:connector name="sharedJmsConnector"
                   connectionFactoryJndiName="ConnectionFactory">
        <jms:default-jndi-name-resolver
                jndiInitialFactory="org.apache.activemq.jndi.ActiveMQInitialContextFactory"
                jndiProviderUrl="vm://localhost?broker.persistent=false&amp;broker.useJmx=false"
                jndiProviderProperties-ref="providerProperties"/>
    </jms:connector>

</mule-domain>

JMS Caching connection factory

Since 3.5 Mule provides a caching connection factory for JMS connection factories. This improves JMS resource utilisation.

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:jms="http://www.mulesoft.org/schema/mule/jms"
             xmlns:spring="http://www.springframework.org/schema/beans"
             xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

               http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd">

    <spring:bean name="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
        <spring:property name="brokerURL" value="vm://localhost?broker.persistent=false&amp;broker.useJmx=false"/>
    </spring:bean>

    <jms:caching-connection-factory name="cachingConnectionFactory" connectionFactory-ref="connectionFactory"
                                    cacheProducers="false" sessionCacheSize="1"/>

    <jms:activemq-connector name="sharedJmsConnector"
                            connectionFactory-ref="cachingConnectionFactory"
                            specification="1.1"
                            validateConnections="true"
                            maxRedelivery="-1"
                            numberOfConsumers="1"/>

</mule-domain>

DB config

Sharing a DB config will allow you to share the connection to the database between multiple applications thus minimising the number of client connections to the database.

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:db="http://www.mulesoft.org/schema/mule/db"
             xmlns:spring="http://www.springframework.org/schema/beans"
             xsi:schemaLocation="
               http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
               http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
               http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd">

    <spring:bean id="jdbcDataSource" class="org.enhydra.jdbc.standard.StandardDataSource" destroy-method="shutdown">
        <spring:property name="driverName" value="org.apache.derby.jdbc.EmbeddedDriver"/>
        <spring:property name="url" value="${database.connection}"/>
    </spring:bean>

    <db:generic-config name="dbConfig" dataSource-ref="jdbcDataSource"/>

</mule-domain>

JBoss Transaction Manager

As you can define JMS connectors and DB configurations in your domain you may have to use XA transactions in your applications. In such case you can define a shared transaction manager within the domain. It is mandatory that you define the xa transaction manager in your domain configuration if you defined the JMS connector or DB config at the domain level.

Configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule-domain xmlns="http://www.mulesoft.org/schema/mule/domain"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:jbossts="http://www.mulesoft.org/schema/mule/jbossts"
             xsi:schemaLocation="
                http://www.mulesoft.org/schema/mule/domain http://www.mulesoft.org/schema/mule/domain/current/mule-domain.xsd
                http://www.mulesoft.org/schema/mule/jbossts http://www.mulesoft.org/schema/mule/jbossts/current/mule-jbossts.xsd">

    <jbossts:transaction-manager/>

</mule-domain>

How to manage domain configuration

A maven artifact for creating domain configuration will be created. Such artifact must contain:

  • Domain specification
  • Domain shared classes and files
  • Domain configuration with shared resources

This artifact can easily be used as dependencies in Maven by those applications that belong to that domain. That allows to:

  • Versioning of domain configuration
  • Relate mule application with specific domain configuration version
  • Run mule application test cases including domain configuration
  • Use of profiles for using different domain configurations for different environemnts
  • Identify within studio to which domain an application belongs and during deployment of the application also deploy the domain resources
  • Create a deployable archive that can be deployed in mule as a domain by dropping the file to lib/domain or by using MMC

A maven artifact for creating a complete domain deployment archive (Probably this is supported by maven already without needing a custom artifact). This will allow to define different modules which can be mule applications artifacts + a mule domain artifact. Such artifact can contain:

  • The domain deployable archive
  • The set of applications that belong to the domain

This will allow to deploy a complete domain to a mule container including the domain configuration and domain apps. Such artifact can be used to work in studio with a complete domain in the workspace.

What resources won't be configurable as shared

  • Flows, subflows and any construct that is used for message processing.
  • TBD after a deeper analysis of each mule component.

Acceptance criteria

Mule domain configuration

  • mule-domain-config.xml configuration file should only be loaded from MULE_HOME/domains/domain-name/mule-domain-config.xml. If it's present in a jar file then it should not be loaded
  • By default there should be a default domain named default. This means that there should be a folder MULE_HOME/domains/default. All applications that do not specify a domain are part of the default domain.

Http connector sharing

  • Different applications must be able to share the same port
  • Different applications can't be configured to use the same host port path combination. When they do the last one to be deployed must fail

VM connector sharing

  • When using a shared connector it must be possible to send message between mule applications
  • There can't be two applications using the same vm queue path

Other requirements

  • As a DevOps I want to prevent an application from joining a domain. This feature may involved explicitly defining (optionally) in the domain configuration a list of allowed applications.

Risks

We need to take into consideration that with the current threading implementation we are going to start reusing thread across different applications.

Mule Studio Impact

We need to find a way to, for every applications, allow the definition of the container shared resources file so Studio can load it when it deploys the application.

We can also think of creating a new project structure that represents the set of applications that belongs to the same container and the file with the shared resources.

MMC Impact

We must add support for the shared resources and show it status as we currently do for connectors.

CH Impact

Initially there's no impact since CH only uses one application for AMI and by default there will be no shared resources.

Service Registry Impact

No impact.

Migration Impact

No impact yet.

Documentation Impact

Requires a new documentation section for this functionality.

Add a custom footer
Add a custom sidebar
Clone this wiki locally