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

  4. Deployment Scenarios

Deployment Scenarios

The table below lists the ways in which you can deploy Mule ESB on premise, 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 auto-discovery or server restarts.

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 runs on 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.