5 ms·

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

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 10y ago
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/ http://servicemix.apache.org/ which includes http://camel.apache.org/ http://camel.apache.org/ and other bits.
- phonon 10y ago
  I would also look at https://zato.io/ https://zato.io/ which is a really nice Python based one.
orthoganol 10y ago
So basically an API for APIs?
- niftich 10y ago
  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 http://dl.acm.org/citation.cfm?id=502057 [2] https://news.ycombinator.com/item?id=13673158 https://news.ycombinator.com/item?id=13673158
  - MrBuddyCasino 10y ago
    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 10y ago
      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.
  - vog 10y ago
    > 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?
    - charlesdm 10y ago
      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.
    - quicksilver03 10y ago
      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.

emmelaich 10y ago

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/ http://servicemix.apache.org/ which includes http://camel.apache.org/ http://camel.apache.org/ and other bits.

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

orthoganol 10y ago

So basically an API for APIs?

niftich 10y ago
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 http://dl.acm.org/citation.cfm?id=502057 [2] https://news.ycombinator.com/item?id=13673158 https://news.ycombinator.com/item?id=13673158
- MrBuddyCasino 10y ago
  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 10y ago
    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.
- vog 10y ago
  > 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?
  - charlesdm 10y ago
    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.
  - quicksilver03 10y ago
    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.