How to build Fat Jars

Today is the world of serverless deployments and computing. Many times to make your application serverless you have to use different dependencies/jars and which may be available on your local enviornments but when deploying as cloud functions (AWS Lambda or IBM Openwhisk) those dependencies/jars are not present in the run time environments.

So to overcome this solution we do have the concept of Fat Jars (which means your local deployable artifact like jar will have all the dependent jars as part of one consolidated Fat Jar). This is possible using Gradle build tool

What is Mulesoft and its advantages

  1. MuleSoft provides the Anypoint Platform to help your organization create integrations and APIs, simplifying the task of connecting multiple data sources.
  2. Anypoint Platform is MuleSoft’s integration application and API suite. It comprises a unique toolset that enables organizations to create, integrate, model, build, and deploy services, APIs, and Mule applications.
  3. Mule ESB : Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.
  4. Anypoint Studio is MuleSoft’s Eclipse-based integration development environment for designing and testing Mule applications. You can deploy the application and run it on your Mule server.
  5. Runtime Manager is the Anypoint Platform tool used to deploy and manage all of your Mule applications from one central location, whether your apps are running in the cloud or on-premises. Runtime Manager is designed specifically for handling Mule applications, and deploying them to the available Mule runtime instances in a CloudHub virtual worker or a Mule server on-premises (server group, cluster, etc.). The Servers tab in Runtime Manager enables you to view a list of the servers, server groups, and clusters that have been created in an environment. From this tab, you can also perform actions related to these components.
  6. Mule Management Console (MMC) centralizes management and monitoring functions for all your on-premise Mule ESB Enterprise deployments, whether they are running as standalone instances, as a cluster, or embedded in application servers.
  7. API Sync : When you create a Mule application using an API definition from Anypoint Platform, API Sync holds that reference and compares its local version (the one from Anypoint Studio) with its remote version (the one in Anypoint Platform).
  8. Anypoint Connectors : These are extensions for Mule that allow you to operate as you would normally in external systems such as Salesforce, Google Contacts, ServiceNow, Workday, Facebook, Twitter or MongoDB to integrate information from these systems to create something new. Connectors simplify the interaction with the SaaS providers’ APIs, providing methods for most or all of the available operations.
  9. Anypoint Exchange : It helps you create API developer portals, view and test APIs, add mocking services to APIs, create assets, and use API Notebooks that describe and test API functions. You can use Exchange private or Exchange portal to share Mule XML example code, templates, connectors, APIs, and custom information assets. Sharing assets helps your organization model and reuse code and APIs for ease of access and to provide a repository.
  10. Design Center : It is a development environment for Mule applications and API definitions in the cloud.







Deployment Strategies:

Runtime Manager allows you to deploy your Mule applications to Mule runtime instances in several ways, depending on your Mule runtime server topology. These are the different deployment strategies available to date.

  1. Runtime Manager to CloudHub Deployment
  2. Cloud Console to Your Own Servers (Hybrid)
  3. On-Premises Console On-Premises Deployment
  4. On-Premises Console to Pivotal Cloud Foundry Deployment


Mule RunTime Key Concepts:

  • Mule EE with Anypoint Studio – Anypoint Studio bundled with an embedded Enterprise runtime with a 30-day Enterprise trial license.
  • Mule EE or CE Runtime – For either Community (CE) or Enterprise (EE) versions of Mule runtime.
  • Mule Runtime runs as a standalone server on operating systems that support one of the required Java versions. An application server is not required; however, Mule Runtime can run under one. Mule Runtime does not require a database unless you need to access a data store.
  • We can configure Mule to run as a Linux or Unix daemon, a Windows service, or from a script.
Software Version
Operating systems MacOS 10.11.4, HP-UX 11i V3, AIX 7.2, Windows 2012 R2 Server, Windows 8.1, Solaris 11.3, RHEL 7, Ubuntu Server 15.04 and 16.04
Application servers Tomcat 7 and 8, WebLogic 12c, WebSphere 8, WildFly 8 and 9, Jetty 8 and 9
Databases Oracle 11g, Oracle 12c, MySQL 5.5+, IBM DB2 10, PostgreSQL 9, Derby 10, Microsoft SQL Server 2014
Browsers for working on Anypoint Platform Firefox or Chrome (latest), Internet Explorer 10 or later; minimum screen resolution of 1024×768


Mule works by responding to events (such as the receipt of a message) that are initiated by external resources. This follows the concept of Event Driven Architecture (EDA).

  • At the simplest level, Mule applications accept and process events as messages through several message processors.
  • Message processors are arranged into a flow (or several of them).
  • Essentially, every Mule flow contains a series of message processors and message sources that accept and process messages. External clients trigger various message sources through various communication protocols and methods, such as JMS, HTTP, FTP, JDBC, or File.
  • Every message source translates a particular communication protocol or method into a standard message format, which is then passed down to the flow’s message processors. Flows can also use connectors to make outbound client requests to other external resources and services, or to other Mule applications.


  • A flow is the most versatile and powerful integration mechanism available in Mule.
  • A flow is the construct within which you link together several individual processors to handle the receipt, processing, and eventual routing of a message. You can connect many flows together to build a complete application which you can then deploy on premise, on Mule or another application server, or in the cloud.
  • At the simplest level, flows are sequences of message processors. A message that enters a flow may pass through a wide variety of processors.
  • Anypoint Connectors facilitate integration of Mule applications with third-party APIs and standard integration protocols, providing a means to access web services and resources. Use our connectors within your Mule flows to send and receive data over a protocol or using an API. These connectors receive or send messages between Mule and one or more external sources, such as files, databases, or Web services


Message sources in Mule are usually Anypoint Connectors, elements which provide connectivity to a specific external source, either via a standard protocol (such as HTTP, FTP, SMTP) or a third-party API (such as, Twitter, or MongoDB.)


Message Processors:

In Mule, message processors are grouped together by category.

  • Mule transformers are the key to exchanging data between nodes, as they allow Mule to convert message payload data to a format that another application can understand. Mule also enables content enrichment of messages which allows you to retrieve additional data during processing and attach it to the message.
  • Mule uses components to conduct backend processes for specific business logic such as checking customer and inventory databases. Components route messages to the correct application, such as an order fulfillment system. Mule uses Staged Event-Driven Architecture (SEDA) for core asynchronous message processing in flows. Importantly, components don’t have to have any Mule-specific code; they can simply be POJOs, Spring beans, Java beans, Groovy scripts, or web services containing the business logic for processing data. Components can even be developed in other languages such as Python, JavaScript, Ruby, and PHP. Mule’s catalog of flow elements support the most commonly used Enterprise Integration Patterns.
  • Within many of the fields of the message processors of your flow, you can use Mule Expression Language to extract information about the message or its environment and instruct Mule to make processing decisions based on that information.


Mule Runtime High Availability (HA) Cluster:

A cluster is a set of Mule runtimes that acts as a unit. In other words, a cluster is a virtual server composed of multiple nodes. The nodes (Mule runtimes) in a cluster communicate and share information through a distributed shared memory grid. This means that the data is replicated across memory in different physical machines.



Deploying to Production Environments:

Anypoint Studio comes bundled with the latest runtime for deploying and testing your applications. This server, however, is not meant for production as uptime restrictions apply. To deploy an application to your production environment you can either use:

  • The Runtime Manager, to deploy to a cloud or a local server/server-group/cluster
  • A standalone local Mule server
  • The Mule Management Console to manage local servers (which will be deprecated in the future)

How to configure Load Balancer with Glassfish

We need to configure :

  1. Web Load Balancer using cluster environment.
  2. HTTP Load Balancer

Lets start with the details here :

  1. Create the Cluster using the Glassfish Admin Console.
  2. Create 2 Nodes one in Config mode and one in SSH mode(This is for Remote instance)
  3. Configure the MQ changes. These has been to be done before creation of instances and we have to use the default settings. Here is the command for the same:asadmin configure-jms-cluster –clustertype=conventional –configstoretype=masterbroker Vartopia-Cluster
  4. Create 2 instances. Here are some of the commands:
      1. C:\Glassfish4\glassfish-4.1\glassfish4\bin>asadmin –host –port 4848 create-local-instance –cluster Vartopia-Cluster
      2. Enter the value for the instance_name operand> app1-Instance
      3. C:\Glassfish4\glassfish-4.1\glassfish4\glassfish\lib>nadmin start-local-instance –node Jackson-App –sync normal app1-Instance
      4. For now I have set the password as admin/secretC:\glassfish-4.1\glassfish4\glassfish\bin>asadmin –port 4848 change-admin-password
      5. C:\glassfish-4.1\glassfish4\glassfish\bin>asadmin –host –port 4848 enable-secure-admin
      6. C:\glassfish-4.1\glassfish4\glassfish\bin>asadmin update-node-ssh

5.  Configure the JDBC Datasource for the cluster. Dont use the TimerPool EjbTimer for Cluster environment. Instead use the Derby Pool EJB Timer. Use the following commands for the same:

  1. asadmin set configs.config.Vartopia-Cluster-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default
  2. asadmin start-database

6. Make the changes in Instance domain.xml to use the default DB name for EJB Timer. Sometime it takes the IP or doesn’t use correct database. Make the chane in main domain.xml also to persist the change on server restart.

7. Make the datasource changes for default datasource so that it can use the XA datasource. For more details :

8. Download Apache for Windows. On windows Apache can be installed through the XAMPP.

9. Download XAMPP . Then make the changes in E:\XAMPP\apache\conf\httpd.conf file:

<VirtualHost *:80>

ServerName jackson-app2

ServerAlias jackson-app2


ProxyRequests Off

<Proxy *>

Order deny,allow

Allow from all


<Proxy balancer://mycluster>

#BalancerMember http://jackson-app2:28181//RequestWebservice/RequestReceiver

BalancerMember http://jackson-app2:28080

BalancerMember http://Jackson-App:28080

ProxySet lbmethod=byrequests


ProxyPass /RequestWebservice/RequestReceiver balancer://mycluster/RequestWebservice/RequestReceiver

ProxyPass /RequestWebservice/TalendService balancer://mycluster/RequestWebservice/TalendService

ProxyPass /RequestWebservice/SfdcService balancer://mycluster/RequestWebservice/RequestReceiver/SfdcService

ProxyPass /RequestWebservice/AuthenticateService balancer://mycluster/RequestWebservice/AuthenticateService


It will configure the HTTP Load Balancer. You can access the Load Balancer by using the URL : http://jackson-app2/balancer-manager

12. Once the HTTP Load Balancer is configured then make the changes in web.config file in .Net side for using the correct endpoints like http://jackson-app2/RequestWebservice/RequestReceiver

13. Here are some of the useful links for reference:

Click to access ha-administration-guide.pdf