
Neuron ESB is an extremely robust ESB engine. It supports all of the most important core ESB vernacular and concepts - publish-subscribe, scatter-gather, and a wide variety of transports, including any major queue transport, and every variety of synchronous transport you might need.
But the benefits rise to new levels. The development environment is really a very close facsimile of the Microsoft Visual Studio environment. This means that if you're a .NET shop, your developers are going to be productive and everything will be familiar.
Unlike the other-integration-engine-on-Win32-which-shall-go-unnamed, Neuron is intuitive to setup and configure. I was up and running later the same day I installed the trial. And I don't mean with a trivial implementation - I was up and running forwarding calls into an external service.
Extending Neuron is a wide open playground - the options are vast. You've got Processes, which are literally dynamically compiled C# program-lets which allow you to inject classes, or you can even write your own glue code in regular old .NET assemblies. For the heavy-weight situation where you need to write a full fledged actor in the ESB backplane, you've got Adapters - arguably one of the most powerful features of Neuron, and probably one of the least used.
Overall, Neuron isn't a Cadillac Usually when we say that we mean that there might be some bloat and certainly some "poor gas mileage". Neuron is more like a top end Porsche. It's not a Maserati, but it's definitely better than almost all other high performance vehicles and yet the price is within reach. It's a great balance of features for the price. Review collected by and hosted on G2.com.
I feel like Neuron could do a little more in terms of real-time monitoring. Realizing that this is ultimately not a core feature, still this would be the one feature I would like to see, and I think if Neuron had real-time monitoring, it would essentially but a perfect product.
Shadow copying would also be a great feature. When you deploy a build of an external assembly, you're going to have to shutdown the Neuron Explorer and any local development instance of the ESB Service itself. That becomes slightly annoying during development and unit testing. This then causes you to want to factor you solution as in-process black box code which you test in an external test harness, thereby reducing the number of restart cycles with the ESB and its compliment of tools.
Finally, the ability to save test contexts within the process test feature. Due to the restart issue, you'll end up having to keep flat files of input messages lying about (not a bad idea anyway) and you'll end up hand keying input arguments to simulate a request many times over. AutoSaving the context would be even better. Review collected by and hosted on G2.com.