Digging a Little Deeper
Messages enter or exit the ESB via Line of Business (LOB) adapters (SQL, SharePoint, MSCRM, SAP, etc.), Web service endpoints, or direct API calls, and are routed to their destination via a publish/subscribe mechanism, as shown in Figure 3. The ESB ensures the messages are delivered to the appropriate endpoints (one or many), using the specified protocols, security contexts, transactions, etc. In addition, the ESB may also execute components that transform, enhance, or augment the message to generate appropriate messages for specific consumers.
Neuron is unique in the industry in that it allows the user to specify the transport protocol used to deliver messages between parties. This subtle, but important detail allows users to select the Quality of Service (QoS) that exactly meets their needs, while juggling the many tradeoffs of any engineering decision. For example, the solution may require all messages be accounted for and their delivery guaranteed end to end in a transactional manner, or it may allow messages to simply be fire and forget where there is no guarantee of delivery. Clearly message throughput and latency (as well as other QoS characteristics) are affected by these and many other choices, and in the case of the first scenario it is reasonable to expect a lower message throughput than in the second scenario. Neuron provides the necessary flexibility for the user to configure the system to support a multitude of different transport QoS’s simultaneously. It is also important to note that the transport protocol (and resulting QoS) can be changed at any time through the Neuron Explorer tool with a simple dropdown box selection; no code or configuration file changes are required, and there is no impact to client code, it is completely transparent.
Neuron is an extraordinarily lightweight solution with little to no footprint required on external systems. The Neuron Server forms the heart of the product and consists of a single Windows service that hosts a number of application domains for core services as well as services required to support a specific configuration (e.g. adapter endpoints, service connectors, client connectors, etc.) Figure 4 illustrates the major Neuron components and their relationship to specific servers.
Installing Neuron is simple and straightforward, requiring less than 15 minutes to bring a server online. Installation on client machines is only required if the client software uses the Neuron API. Neuron components are not required for Web services, or most LOB applications. The exception to this are LOB applications that utilize Neuron adapters to generate and publish events to the ESB, these components generally require installation on the LOB server. Neuron is self hosted and does not require WAS or IIS.
Messages flow over Topics in Neuron and are published and subscribed to by Parties. The Neuron Topic controls not only the path of messaging in Neuron but also the Quality of Service (QOS) which is configured by choosing a specific Transport for the Topic.
Neuron ships with 5 transports for Topics
- TCP – This transport is based on the WCF NetTcp binding and is often used by the Parties hosted in Client Connectors and Service Connectors. It is the most used transport by Neuron customers and offers ordering and session reliability as options. It is not a durable transport so message loss can occur if no subscribers are online when a message is published.
- Named Pipe – This transport is based on the WCF NetNamedPipe binding and is used in most request/reply scenarios where there aren’t any remote clients sending messages over this topic to Neuron. It is not a durable transport so message loss can occur if no subscribers are online when a message is published. This transport is very similar to TCP, but it is easier to configure (no ports) and provides faster message throughput.
- MSMQ – This transport is based on the WCF NetMsmq binding. It is a durable and transactional transport so parties that are not online when a message is sent will receive messages when they reconnect. It is the second most popular transport chosen by Neuron customers. This transport cannot be used to send messages greater than 4 MB in size.
- RabbitMQ – This transport is based on RabbitMQ, an implementation of the AMQP standard. It is a durable and transactional transport with similar capabilities as the MSMQ transport. The main differences between MSMQ and RabbitMQ are that RabbitMQ does not have a 4 MB message size limitation, and the RabbitMQ queue creation process is completely automated by Neuron – the user only needs to create topics and parties, and Neuron will handle the rest.
- Peer – This transport is based on the WCF NetPeerTcp binding and uses a custom resolver. It is ideal for real time communications in which speed is paramount and some message loss may be tolerated. This channel may be used to scale Neuron messaging to 1000’s of desktops and provide rich client apps with real time updates.
Neuron is a self hosting application. This means it does not require IIS or WAS being installed to run.
A Party may subscribe to 1 or more Topics. A Party may also optionally manipulate the message it is sending or the message it receives. This manipulation occurs via a Process. More than one Process may be used by a Party and conditions may be set inside or outside of the Process to control Process execution.
The relationship between Parties, Topic and Processes is depicted below.
It is important to understand Processes are connected to Parties and not Topics. In fact, a Process may be used to alter the Topic of a message and thus alter the message flow. A Party may also be hosted in your own executable. This means that Process logic attached to those Parties is inherently distributable while being centrally maintained. This allows Neuron to be used in ways not available to server only products and thus allows Neuron to function as a complete Service Oriented Architecture (SOA) platform.