Comparison of Architectures
The bus architecture is an efficient compromise between point-to-point architectures, which are too decentralized, and hub-and-spoke architectures, which are too centralized. The bus architecture provides the benefits of logically centralized configuration and management but its parts are physically decentralized.
Figure 1: Comparison of Architectures
The infrastructure is comprised of services. Those services can be physically distributed to avoid bottlenecks and to provide redundancy in the event of failure.
Publish-Subscribe Communication
Internally, the ESB connects applications using publish-subscribe communication. Messages are distributed using logical topic names instead of physical addresses. One or more applications will receive copies of that information if they subscribe to that topic.
Topics are an internal bus mechanism. Topics do not require you to change how existing applications communicate. Instead, applications connect to the bus using their native protocols and messaging patterns.
Consider the figure below. When a new order is received from a customer, the Order Generation application publishes a message to the ESB on the topic "orders.new". Two applications receive a copy of that message, Order Approval and Order Processing, because they both have subscriptions to "orders.new".
Figure 2: Publish-Subscribe
If another application needs to listen to new order notifications, a new subscription will be created to the topic "orders.new." Existing applications do not need to be modified to allow the new application to be integrated.
Publish-subscribe topic names can be simple text strings like "orders" or a series of dotted names like "orders.new" or "inventory.west.reorders". The dotted syntax allows a hierarchy of topic names to be created.
A subscription is a topic name that indicates what types of messages an application is interested in receiving. A subscription can use the asterisk character for wildcards, for example "orders.*" which would receive messages sent to the orders topic and any subtopics ("orders", "orders.new", and "orders.cancelled" in this example).
A subscriber is the name of a party that sends and/or receives messages over a topic. In the ESB, all applications and services have party IDs (logical names) defined for them. Applications can also perform point-to-point and request-reply communication over the ESB using these logical names.
Bus External Design vs. Internal Design
Externally, the bus is concerned with making it easy to connect diverse enterprise applications, services, and legacy systems. Internally, the bus is concerned only with publish-subscribe messaging.
Figure 3: Bus External View vs. Internal
External Bus View
The figure below shows the bus architecture from an external perspective. The ESB provides a common messaging fabric that connects several categories of endpoints through a publish-subscribe messaging system.
Business endpoints include in-house applications, services, legacy systems, and line-of-business applications.
Integration services perform useful EAI functions that can be applied to messages as they are en route, such as transforming a message or executing a set of rules.
Infrastructure services implement the ESB, providing endpoint connections, security enforcement, configuration management, message routing, and operations monitoring.
Figure 4: External View - Connections
Internal Bus View
Internally, the bus contains multiple networks. Each network is responsible for providing publish-subscribe infrastructure for a particular topic.
The Neuron ESB supports multiple communication technologies called Transports for topic networks:
Named Pipe
TCP
MSMQ
RabbitMQ
Peer
Each topic network is separately configured, and determines the quality of service for a category of messages. The figure below shows an ESB with a mix of channel types. The ability to run several different qualities of service in parallel allows the appropriate quality of service to be chosen for each business conversation.
Figure 5: Internal Bus View - Topic Networks
Messages can be shared across topic networks through the use of bridges. Bridges receive messages on one topic and pass them on to another topic. Bridges can be used within the same zone or across different zones.