Mule – design considerations

1. Mule – Design Considerations
-RajeshKumar
1

2. About Mule applications
 Java based apps that must be deployed to a Mule runtime
– Either on-premise or on CloudHub
 Packaged as zip file, referred to as deployable archive
– Universal format, for both on-premise and cloud
deployments
 Consist of one or more flows, stored in one or more XML files
 Can be developed, built and packaged using Anypoint Studio or
a third party build solution (Maven, Gradle)
 Built around the standard software pattern of Input-Processing-
Output
2

3. Basic design considerations
 Application type?
– Real time vs batch, high volume vs high throughput
 Monolithic vs modular design
– Team development, development standards & best practices
 Cloud-based vs on-prem vs hybrid
 Code managed by Anypoint Studio or Maven/Gradle
– Maven/Gradle needed for setting up continuous integration
 Security considerations
– Securing messages/communications
– Properties management
– Secured services/APIs
3
Receiving thread

4. Non-functional design considerations
 Synchronous vs asynchronous
 Single-threaded vs multi-threaded
 Transactionality options
 High throughput vs reliability
4
Receiving thread

5. Infrastructure design considerations
 Single runtime vs multiple runtimes vs cluster
 High availability
 Fail over
 Load balancing
 Bare-metal vs virtualization vs containers
5
Receiving thread

6. Development best practices
 Keep applications synchronous if possible (avoid serialization)
 Store as little as possible in session variables (serialization
overhead)
 Use bean payloads whenever possible
 Prefer MEL over JVM scripting languages
 Use VM queues instead of external message brokers if possible
 Use flow references instead of VM queues if possible
 Cache aggressively
 Avoid large volumes of business events
 Consider using message compression for asynchronous apps
6
Receiving thread

7. Structuring Mule applications
 Mule applications can (and should) be modular
– Monolithic applications are difficult to read and maintain
– Modular applications are better suitable for team
development
– Modular applications encourage reusability
 A Mule application can consist of multiple Anypoint Studio
projects, to be assembled during the build process
 Design flows to be small
 Extract duplicate code into reusable (sub/private) flows
 Define global exception strategies, applied on flow via references
7
Receiving thread

8. Organizing Mule configuration files
 Separating an application into multiple configuration files makes code
easier to read, work with, test and more maintainable
 Two supported options for loading multiple configuration files
– Side-by-side: Provide a list of independent configuration files to
load
Config.resources=global-config.xml,admin-config.xml
– Imported: Have one configuration file import several others, which
in-turn can import other files using Spring
<spring:beans>
<spring:import resource=”global-config.xml" />
<spring:import resource=”creditchecks-config.xml" />
<spring:import resource=”loanprocessing-config.xml” />
</spring:beans>
 import other files using Spring
 Can be used simultaneously
– All configuration files are loaded in the same context
8

9. THANKS
9

10. THANKS
9