Their main product is an Enterprise Service Bus, a piece of technology that is supposed to help make it easy for software developers to integrate with multiple disparate third party solutions (and potentially internal solutions). So you can get a "Connector" for SAP, and another for Salesforce and consolidate, transfer or do practically whatever with the data in both systems, without having a bunch of developers working on an in-house solution to consume the requisite APIs.
My one criticism of them would be they focus very heavily on cloud, and their on-premises offering is woefully anaemic, lacking fundamental functionality, such as messaging.
Catchy, but no. Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern; these flows then execute in in a runtime that uses SEDA [1]. They give you some built-in components that help in creating APIs, and this design is a good fit for APIs and data munging, but it can be used as "just" a runtime for event-driven code. For a clearer example, see my other post here [2]. Their other products include an API proxy and a client-facing API gateway.
> Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern
I hope I don't sound too snarky here, but from bird's-eye view, this description sounds like business-speak for:
"It could have been normal programming with external services, with all perils and pitfalls. But in addition to the common pitfalls, you get a badly designed domain-specific language (DSL), using XML syntax to make it even harder to understand, with the promise that you can hand it over to non-programmers, except that you need programmers to extend the DSL with custom components anyway, to make it actually work for you."
Hoping this superficial judgement is wrong: How does the real product deviate from that snarky description?
Apart from the non-programmers bit, you're not wrong.
I've been using the open source version on a project between 2013 and 2015 and it was exactly as you described: it essentially was a very convoluted and un-debuggable way of attacking a class of trivial problems, on which it failed miserably.
Basic functionality (watch a directory for incoming files, apply some processing, move the files to a second directory) would fail without any useful error message. You could "program" it by writing XML files with an Eclipse plugin, but anything non-trivial would involve hundreds of lines of "magic" XML.
Worked with the on-premise version, and I'd avoid it like the plague. Badly designed mix of XML and old-school Java, if it wasn't for political reasons we would have kicked it out.
XML/Java is very much it's ancestry. Back in the day, it competed eye-to-eye with ServiceMix and Camel. Both of those have remained firm Apache products. Mule ESB was heavily commercialised, for better or worse.
