[huddo121]

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.

[emmelaich]

I'd say their support for on-promises deployments is anaemic too.

For an open source product in the same niche, have a look at http://servicemix.apache.org/ which includes http://camel.apache.org/ and other bits.

[phonon]

I would also look at https://zato.io/ which is a really nice Python based one.

[orthoganol]

So basically an API for APIs?

[niftich]

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.

[1] http://dl.acm.org/citation.cfm?id=502057

[2] https://news.ycombinator.com/item?id=13673158

[vog]

> 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?

[quicksilver03]

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.

I consider myself lucky enough to have moved on.

[charlesdm]

It's an API for APIs, that collects and connects everything in one place (incoming and outgoing events, data, etc) with it's own specific language.

[MrBuddyCasino]

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.

[kitd]

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.