Like prospectors of old, enterprise developers need a trusty Mule, and so the enterprise service bus Mule 3.0 was released today, bringing new features for integrating with external services and clouds.

Mule 3.0 adds Cloud Connect, a set of features for helping the enterprise break out of the restrictions from the firewall to integrate and work with other data sources.

Ross Mason, CTO and founder of MuleSoft, said that the Mule ESB is morphing into a next-generation services bus.

“Mule Cloud Connect is comprised of a few different things,” he said. “At its core, we’ve added native REST support to the Mule ESB itself. Given how much people are moving to REST, I find the adoption cycle seems to be growing a lot quicker than messaging and Web services.”

Another big focus for Mule 3.0 was integration with JavaScript. “There’s been a shift in the way people are building enterprise applications,” said Mason. “They want to use things like JavaScript, jQuery and JSON. We see a lot of folks turn to these JavaScript-based widget libraries for supporting applications.”

Mule 3.0 provides better support for hooking directly to those applications using AJAX support to bind with the frameworks, but it uses standard AJAX support for publishing to the ESB itself, he said. “If you want to bind to these frameworks, you’ve traditionally had to go through an application server, and there’re many times where that’s not necessary.”

These new features are indicative of a new approach at Mule: one of simplicity. “If you look at the way the industry has gone around integration and ESBs, it tends to be very feature-oriented,” said Mason.

“In Mule 3.0 we’ve introduced a new concept around pattern-based configuration. We talked to hundreds of our users and customers about what they’re doing with our ESB product. We boiled it down into well-defined discrete patterns. It makes the ESB available to a wider audience. Once you start moving things around an ESB application, you can provide larger building blocks.”

One thing that was too complicated for Mule 3.0 was OSGi. Mason said the team at MuleSoft initially looked at OSGi as a way for allowing dynamic loading of libraries and updated code. But in the end, the programming model this would require from users was too complex, said Mason.

Instead, the Mule team built its own dynamic class-loading capabilities that provide similar functionality to OSGi without the need to use the complex OSGi programming model.

For the future, Mason said MuleSoft is working on a new manager console, and new features that give what he called unparalleled monitoring and management capabilities for an open-source ESB.