Mule – design considerations

Emerging Tech Series E: Knowledge Management automation of impacts

Mule Design Considerations

-RajeshKumar

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

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

Receiving thread

Non-functional design considerations

Synchronous vs asynchronous

Single-threaded vs multi-threaded

Transactionality options

High throughput vs reliability

Receiving thread

Infrastructure design considerations

Single runtime vs multiple runtimes vs cluster

High availability

Fail over

Load balancing

Bare-metal vs virtualization vs containers

Receiving thread

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

Receiving thread

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

Receiving thread

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

import other files using Spring

Can be used simultaneously

All configuration files are loaded in the same context

THANKS

Click to edit Master title style

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

1/1/2017


Click to edit Master subtitle style

1/1/2017



Second level

Third level

Fourth level

Fifth level

1/1/2017



1/1/2017



Second level

Third level

Fourth level

Fifth level


Second level

Third level

Fourth level

Fifth level

1/1/2017




Second level

Third level

Fourth level

Fifth level



Second level

Third level

Fourth level

Fifth level

1/1/2017


1/1/2017

1/1/2017



Second level

Third level

Fourth level

Fifth level


1/1/2017


Click icon to add picture


1/1/2017




1/1/2017



1/1/2017




1/1/2017



1/1/2017








1/1/2017











1/1/2017



Second level

Third level

Fourth level

Fifth level

1/1/2017



Second level

Third level

Fourth level

Fifth level

1/1/2017

Technology

Mule – design considerations