Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.7)
  3. Deploying

  4. Deployment Scenarios

Deployment Scenarios

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.
This document covers the ways in which Mule runtime can be used to deploy applications as standalone. To take full advantage of the available management and monitoring features, you should deploy to your runtimes using Anypoint Platform. Read how this and other deployment strategies work.

The table below lists the standalone ways in which you can deploy a Mule runtime on premises, and some of the characteristics of each method.

Deployment Mode Container Pros Cons HA MMC

Standalone

Mule ESB

  • Uses the Mule Deployment Model

  • Can run multiple apps

  • Supports hot deployment

  • Requires minimal resources

  • Easy to install

  • Mule must be provisioned into your environment

Supported

Supported

Embedded .war file

App Server

  • Uses webapp deployment model

  • Can run multiple apps

  • Webapp contains all dependencies

  • Each web app runs own mule instance, thereby increasing the size of the webapp

App Server HA

Supported*

Embedded Java

Java App / IDE

  • Requires no external container

  • Does not support hot deployment

Not Supported

Supported*

*When Mule is embedded in some other container, the Mule Management Console cannot perform Autodiscovery or server restarts.

Learn about other deployment strategies that leverage Anypoint Platform.

Running Mule in Standalone Mode

The recommended approach is to run Mule Standalone from the command prompt, as a service or daemon, or from a script. As the simplest architecture, it reduces the number of points where errors can occur. It’s typically best for performance as well, since it reduces the number of layers and eliminates the inherent performance impact of an application server on the overall solution.

You can also run multiple applications side-by-side in a Mule instance using the Mule Deployment Model. This model supports live deployment and hot redeployment of applications. Further, Mule Standalone fully support for Mule High Availability module and use of the Mule management console.

For more information on running Mule standalone, see Mule Deployment Model.

Mule Standalone vs. Application Server

Listed below are some of the advantages of running Mule standalone vs running it as a web application deployed in an application server (Tomcat, WebSphere, JBoss, etc.)

  • Wrapper control: Mule Standalone makes use of a Java Service Wrapper which controls the JVM from your operating system and starts Mule. The wrapper can handle system signals and provides better interaction between the JVM and the underlying operating system.

  • Smaller memory footprint: Mule standalone loads only the required resources for an application; an application server adds its own resources.

  • Anypoint DataMapper support: DataMapper is supported only on a Mule Enterprise Standalone runtime; other application servers do not support DataMapper.

  • Deployment and Application Management: Through the Mule Management Console, you have full control of the applications running on Mule Standalone, allowing you to deploy/undeploy applications and restart/stop the server. Other application servers do not support this visibility.

Embedding Mule in a Java Application or Webapp

You can start and stop Mule from a Java application or embed it in a Webapp (such as a JSP or servlet). For general instructions, see Embedding Mule in a Java Application or Webapp. Listed below are links to documentation which offer application server-specifc information regarding Mule application deployment.

For details on how to support Mule hot deployment within some application servers, see Application Server Based Hot Deployment.

Note that when embedded, Mule does not support the Mule Deployment Model or High Availability. Furthermore, because the application server needs control of Mule, the Mule Management Console’s capabilities are reduced; specifically, you cannot restart the server via the Mule Management Console.

Using Spring

Mule fully integrates with Spring, allowing you to take advantage of Spring’s many features, including JNDI and EJB session beans. You can also use Spring remoting to access Mule from an external application. For details, see Using Mule with Spring.

Sharing Resources

If you’re deploying multiple applications to the same place, in whichever of the ways explained above, and those applications could share the same resources, then you can create a common domain where you can define common configurations that can then be referenced by multiple projects. This allows you to, for example, expose different services in different projects through the same HTTP host and port and be able to deploy everything without any conflicts. Read more about shared resources.

Defining the Classpath for Shared Resources

You can define where shared resources reside by editing the classpath statements in each Mule runtime’s wrapper.conf file. These statements indicate the order that folders are searched for files such as jars, property placeholder files, etc. The wrapper.conf file resides in the mule-enterprise-MuleVersion > conf folder.

You can set these statements:

wrapper.java.classpath.1=%MULE_LIB%
wrapper.java.classpath.2=%MULE_BASE%/conf
wrapper.java.classpath.3=%MULE_HOME%/lib/boot/*.jar