Neuron ESB and BizTalkWe have worked on a large variety of integration projects for the last 15 years using various platforms dating back to BizTalk 2002. And the last 7 years this has pretty much been divided 50/50 between projects based on Microsoft BizTalk and Neuron ESB.

Both products have their strengths and weaknesses and we thought it would be a good idea to try and summarize some of our own experiences. Originally we thought about creating a scoreboard matrix, but it varies to much depending on the actual needs to be useful and as always, the devil is in the detail.

Instead we try to sum it up in various usage scenarios and areas.

Service mediation and routing
This is an area where Neuron ESB excels. In no time you are able to route service calls based on a number of parameters and most importantly this can be done with very little overhead depending on your need for QoS. This way you can quickly bridge protocols or ensure a common security model, central logging and monitoring or whatever you needs may be.

Of course this is also possible with BizTalk, but the big caveat is, that you never get rid of the messagebox and this can be a huge overhead when all messages need to be stored on a SQL server. There are various options for tuning, but basically it is hard to get it to perform really well.

Workflows and processes
With BizTalk you use Orchestrations to implement logic and long-running statefull processes and pipelines which can perform pre- or post-processing of messages. With Neuron ESB you have Processes which are stateless, sequential and are processed in-memory and Workflows which are statefull, long running, fault tolerant and support more complex logic and are based on Windows Workflow Foundation (WF).

You get more choices with Neuron ESB and it is easier and quicker to work with Processes and Workflows. Also, while the XLang engine used in BizTalk orchestrations has not really changed in the last 12 year, there is still a lot of development going into Workflow Foundation. Workflow foundation also supports workflows that are a bit more complex. So there is probably a slight advantage to Neuron ESB when it comes to workflows and processes but both products support this feature.

Developer experience and -onboarding
With both products you need to have a C# developer background and know of XML, XSL, services and SQL. You also need to learn a new discipline since you are working with messages, events, correlations and transformations.

Our experience is that the onboarding of existing developers is easier with Neuron ESB. The tools you are using and the concepts are closer to .Net, WCF and the entire experience is more complete. Developers are pretty much up to speed after a 3 days course. With BizTalk you need to learn more tools and quirks and it is not as easy to explain how it is all glued together. Usually people need to have been working on a couple of projects before they are truly self-running.

Development as such is quicker with Neuron ESB. You hit save, update the configuration and then it is basically ready for testing. With BizTalk, you need to perform more steps with building the necessary DLLs, add them to the GAC etc. Usually you end up with you own command lines that build, GAC and restart the BizTalk host or use various plugins and this helps a bit, but it still takes more time to develop and test.

Other areas

Adapters: Both products have a huge amount of adapters. BizTalk has a longer history and this also means a much larger amount of special adapters. But then again, the list is not exactly short for Neuron ESB, so this is something you should investigate. If it is important to be able to connect to SAP and use iDocs you could be better off with BizTalk and the SAP adapter. But even a lot of older applications are being service enabled with web services or REST and then you are well of with either product.

EDI: Only Microsoft BizTalk has support for EDI and this has been done really well. There is support for a huge amount of schemas and we have not had a single EDI project without need for customized schemas which is also pretty easy to create. And once this is in place, you are basically mapping XML which makes it easy to work with.

Exposing web services: Neuron ESB hosts its own services. So once you have configured the service, specified a URL and hit save, the WCF service is already up and running. And once you deploy Neurons XML configuration to a new server, all services are created and started automatically.
With BizTalk you need to run a separate tool specifying the classes to expose and then a service is generated and hosted in IIS. Then you also get a configuration XML which can be used from a command line in your automated scripts. And if you change your classes, you need to update the configuration XML. So this is much more complicated with BizTalk. An advantage though, is that the service contains auto-generated WSDL which makes it easier to consume directly. With Neuron you can choose not to expose WSDL, reuse an existing WSDL-file or point to a different service, but cannot have it auto-generated. And many might argue, that an ESB should not expose WSDL, but in reality it often helps in development and/or testing. We had a Neuron-project where the testers requested WSDL for easier testing and this was solved by creating a little WSDL-generator.

Performance: We have not had a single BizTalk project, where performance was not an issue. When everything has to be persisted in the DB a number of times it is simply hard to get low latency. And this is by design because “BizTalk never loses a message”. So really need to be aware of persistence points, correct use of atomic shapes and probably tune and throttle hosts to make it perform acceptable.
With Neuron ESB this is much more configurable. Very often it is quite okay to run a process entirely in memory and throw a fault if something goes wrong without persisting anything. And in other cases you might prefer a more loosely coupled architecture, where a message is delivered to Neuron which then guarantees delivery. But usually you would use MSMQ for this which is much quicker than storing and retrieving data from a SQL database. So performance wise, Neuron is much faster.

Documentation and Community Support: There is no doubt that there is much more documentation for BizTalk and that the entire BizTalk community is much larger. Also BizTalk has been used much more and more people know it. There are support forums for Neuron but they are not nearly as large. But it is not all that black and white. For instance, much of Neuron ESB is built on top of Microsoft Windows Communication Foundation (WCF) and Workflows are basically Windows Workflow Foundations (WF) hosted in Neuron. And both are excellent and well documented frameworks. Processes are more specific to Neuron ESB, but basically you are working with a single C# class which quickly should be familiar to any C# developer. All in all, support is better with BizTalk, but it should not scare you off.

Customer support: We feel we need to highlight this area, because the customer support for Neuron ESB from Neudesic is pretty outstanding. We have had several feature requests which have all been incorporated in the product. The record was receiving a new beta build within a couple of hours with added functionality for XSLTs. To be honest, we have not attempted something similar with Microsofts BizTalk team, but we feel confident, that it would not be as easy.

Deployment: As a product Neuron ESB was built to be an ESB and it is easier to build a complete package with all logic, services and custom DLLs. Basically all you are doing is an XCopy. This is not as easy with BizTalk. DLLs have to be GACed, you have to export IIS webservices seperatly and generally do a bit more plumbing. We have developed deployment frameworks for both BizTalk and Neuron using Powershell, so in our case it would not be that different. But if you are starting from scratch, things are more complicated with BizTalk. Especially if you are using the ESB Toolkit.

So to try and summarize, Neuron ESB is a newer and more lightweight product that was built to be an ESB from the ground up and in most cases it is easier and faster to work with than BizTalk. On the other hand, BizTalk has been around almost twice as long and if you have special needs, this might be more suitable.

Hope this was useful and let us know if you have any questions.