Design considerations in MULE ESB

1. Design ConsiderationsDesign Considerations
1

2. About Mule applicationsAbout 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 considerationsBasic 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 considerationsNon-functional design considerations
 Synchronous vs asynchronous
 Single-threaded vs multi-threaded
 Transactionality options
 High throughput vs reliability
4
Receiving thread

5. Infrastructure design considerationsInfrastructure 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 practicesDevelopment 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 applicationsStructuring 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 filesOrganizing 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:importresource=”creditchecks-config.xml" />
 <spring:importresource=”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