The table below lists the ways in which you can deploy Mule ESB on premise, and some of the characteristics of each method.
App Server HA
Java App / IDE
* 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.)
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.
- Deploying Mule to JBoss
- Deploying Mule to WebLogic
- Deploying Mule to WebSphere
- Deploying Mule as a Service to Tomcat
- Geronimo (The Geronimo application server uses ActiveMQ as its default JMS provider. For details, see ActiveMQ Integration.)
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.
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.
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.