Mule – design considerations
2 likes165 views
The document discusses design considerations for Mule applications, including: - Mule applications are Java-based apps deployed to a Mule runtime on-premise or in the cloud. They consist of flows stored in XML files. - Design considerations include the application type (real-time vs batch), modular vs monolithic structure, and whether it is cloud, on-premise, or hybrid. - Other factors include security, synchronous vs asynchronous processing, single-threaded vs multi-threaded, and infrastructure like using single or multiple runtimes.
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