Deployment Architecture

Neuron is designed to run in environments as small as a single developer machine and as large as a major enterprise.

Single-Server Deployment

In a single-server configuration, one ESB server provides the infrastructure for the ESB. Should the ESB server be taken offline, the quality of service provided by the transport will determine whether communication is still possible.

Database Functionality

The use of a database is optional in a single-server deployment.  A database will only be required if you want to enable message auditing and reporting.

Server Outage Consequences in a Single-Server Configuration

The degree of disruption to existing programs when a server outage occurs is a function of channel type as shown below. In general, new connections to the bus are not possible when the ESB server is down; however, existing clients may continue to function. Clients should resume connectivity when the ESB server is back online.

Peer	Messaging continues uninterrupted No new connections are possible while the ESB server is down. Once the ESB server is back online, new connections are possible but will not be able to communicate with previously connected clients.
MSMQ	Messages continue to be sent. If direct mode is enabled, messages will also continue to be received. No new connections are possible while the ESB server is down. If direct mode is disabled, messages will continue to be received when the ESB server is back online. Once the ESB server is back online, new connections are possible again.
RabbitMQ	Messages continue to be sent. If direct mode is enabled, messages will also continue to be received. No new connections are possible while the ESB server is down. If direct mode is disabled, messages will continue to be received when the ESB server is back online. Once the ESB server is back online, new connections are possible again.
TCP/IP	Messaging will stop. No new connections are possible while the ESB server is down. Messaging resumes when the ESB server is back online. Once the ESB server is back online, new connections are possible again.
Named Pipe	Messaging will stop. Messaging resumes when the ESB server is back online.

Server Farm Deployment

In a server farm configuration, multiple ESB servers provide the infrastructure for the ESB. Use of a server farm should be considered when high availability or high capacity is needed.

A hardware or software load balancer is required in order to take full advantage of server farm mode.

The use of a database is required in a server farm deployment.

Server Outage Consequences in a Server Farm Configuration

In a server farm configuration, multiple ESB servers provide the infrastructure for the ESB. Should an individual ESB server go down, other servers keep the infrastructure going and disruption to programs is avoided or minimized. Use of a server farm should be considered when high availability or high capacity is needed  for the publishing system itself. If the Neuron server does not maintain state then multiple Neuron servers running the same esb configuration may be configured behind a load balancer to provide HA much like you would provide redundancy with traditional web server or application servers.

An ESB server outage in a server farm configuration (where at least one other server continues to run) is minimally disruptive to applications connected to the bus. In general, operations continue unchanged when a server goes down. There may be some degree of disruption to existing programs when a server outage occurs depending on the channel type in use as shown below. In addition, if the primary server goes out of server certain primary-only functions such as bridges will stop

Peer	Messaging continues uninterrupted.
MSMQ	Messaging continues uninterrupted.
RabbitMQ	Messaging continues uninterrupted.
TCP/IP	Messaging continues uninterrupted. Messages buffered on the server will be lost.
Named Pipe	Messaging continues uninterrupted. Messages buffered on the server will be lost.