Today, we released Mule 4 beta, which adds vastly more power, higher speeds, and greater simplicity into the famously small footprint of Mule – the industry’s leading all-purpose engine for building application networks. I couldn’t be more excited. With Mule 4, we’ve delivered a simplified language for connectivity, transparent data access and streaming, automatic performance tuning and smoother upgrades. It’s a major evolution of the core runtime of Anypoint Platform.
Why Mule 4?
Mule 3 achieved amazing popularity in the 7 years since 3.0 was released. It is used by over 1100 enterprise customers located in more than 60 countries across every major industry, and has a community of over 175K developers. So, as we looked to Mule 4, we knew it needed to live up to Mule 3’s strong reputation.
As we started planning Mule 4, we really went back to the fundamentals of how to make your life easier. How do we make Mule even easier to use? How do we simplify common tasks? How do we ensure the runtime runs at its best, without manual tuning? And how do we reduce long-term maintenance costs by simplifying operations and upgrades?
Mule 4 has to deliver on these innovations, while keeping all the things users love about Mule 3 – including its lightweight runtime and extensibility. With this release, whether you’re a new user, or long time Muley, I think you’ll see that it delivers.
So, how did we do this? We’ll be doing a series of in-depth blog posts on Mule 4 features and benefits, but I’ll summarize the highlights here:
- Simplified core concepts and language
- Transparent data access and streaming
- Non-blocking, self-tuning runtime
- Simplified error handling and introduced a new ‘Try’ scope
- Frictionless upgrades
- Revamped core connectors such as FTP, File, Email and JMS
We’ve also put significant work into our tooling around Mule. With Mule 4, there’s a new release of Studio 7 which introduces many new improvements:
- Improved palette user experience, including the ability to save favorites
- Holistic Exchange experience, making APIs and Mule connectors/modules more accessible
- Deeper Maven integration
- Quick navigation between XML and visual views
- Collapsable scopes
- Improved metadata support, making it easier to commit and merge
Alright, so let’s get into more of the details!
Simplified core concepts and language
We’ve evolved the core language to make it easier to learn and do common tasks:
- Mule 4 introduces a simplified Event and Message model. The Mule 4 Message can hold payloads and attributes. The payload is the main thing being processed – HTTP body, file contents, etc. Attributes are the metadata about the payload – query parameters, file size or last modified date. Messages simplify many common tasks since you can now save not just the payload, but also attributes in variables.
- Message collections now are much simpler – they’re just an array of Messages. This means you can easily transform them or store them in a variable.
- Enrich in fewer steps – for any given connector/module operation, it is now possible to define a target, which saves the result directly in a variable. No need for enrichers anymore.
- All connectors now follow the same model of operations and connector configurations
- Revamped File, FTP, JMS, and Email connectors
- Transformations can be embedded directly in connector operations, removing unnecessary steps in your flow or the need to put data in temporary variables.
Transparent data access and streaming
There are incredible improvements in the way that Mule 4 enables you to process, access, transform and stream data. First, DataWeave is now the expression language in Mule 4. Combined with the new automatic streaming capabilities, this simplifies many common tasks:
- Events can be routed based on payload data, without first needing to convert to Java objects.
- Binary data can easily be queried from an expression anywhere in your flow (i.e. when logging).
- Larger than memory access to data happens transparently.
- Data can be read multiple times or accessed randomly with the DataWeave expression language without side effects.
- Data can be sent to multiple places, without the user caching that data in memory first.
Beyond this, we’ve also enhanced DataWeave to make it simpler to learn and provide deeper integration with the Java ecosystem.
Non-blocking, self-tuning runtime
There’s a new execution engine in Mule 4 that is based on a non-blocking, reactive runtime. This is a task-oriented execution model allowing you to take advantage of non-blocking IO calls and avoiding performance problems due to incorrect processing strategy configurations.
Each Mule event processor can now inform the runtime if it is a CPU intensive, CPU light, or IO intensive operation. This allows the runtime to self-tune for different workloads dynamically, removing the need for you to manage thread pools manually. As a result, Mule 4 removes complex tuning requirements to achieve optimum performance.
Simplified error handling and new ‘Try’ scope
Mule 4 includes a simplified way to manage errors. Instead of dealing with Java Exceptions directly, there is now an ‘error’ concept built directly into Mule. Furthermore, Mule Modules and Connectors declare what errors may occur for any given operation. This makes it easy for you to discover possible errors at design time and catch them.
Exception strategies are replaced by error handlers allowing you to catch errors based on both type and arbitrary expressions. You can configure your error handlers to catch errors so that the flow can keep processing, or the errors can be re-propagated.
There is also a new ‘try’ scope, This allows you to catch errors in the middle of a flow, without having to create a new flow, specifically to catch that error.
In Mule 4, we wanted to make it easier for you to get new enhancements with little to no work on your part. In Mule 3, if you were using Mule’s internal Java libraries, this could be difficult, as libraries often changed from release to release.
- There is classloader isolation between your application, the runtime and connectors, so that any library changes that happen internally will not affect your app.
- Connectors are now distributed outside the runtime, making it possible to:
- Get connector enhancements and fixes without having to upgrade your runtime.
- Upgrade your runtime version without breaking compatibility with other modules.
- There is now a well defined Mule API, so you can be sure you’re using supported APIs.
We think you’ll also find the following resources helpful as you get started:
Finally, be sure to check out our webinar on the new Mule 4 release where you’ll see Studio 7 and Mule 4 firsthand.