What do you like best?
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.
What do you dislike?
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.
Recommendations to others considering the product
Get a trial and build something with it. That's huge, and give it a chance. Like any new product it may take a day or two to get used to the semantics of it. But it is easy to use and it will surpirse you rapidly with the ease of use and fluidity with which you can make real integration effects come to life.
What business problems are you solving with the product? What benefits have you realized?
Our number one objective is decoupling and parallelization. That is, we wanted control over external vendors such that we could bring online better versions of existing services, try them out, and then run them in parallel for a period of time on the road to phasing out the original.
We also wanted monitoring, resiliency and as much monitoring as we could possibly get.
The main benefit we have gained is transparent pub-sub, and a development platform for routing and manipulating service payloads. The familiarity of the environment to our extremely .NET oriented shop will also pay dividends in years to come.