|
|
|
|
|
|
by vog
3412 days 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? |
|
|
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.