Architecture

The ESB conceptual architecture is represented in the image below.

ESB Conceptual Architecture

ESB is composed of 4 main components:

1. ESB Server Logic (ESB Logic)

2. RabbitMQ MQTT broker (RMQ)

3. Elastic Search Logging & Reporting engine (ELK)

4. Apache ActiveMQ broker

ESB Components

ESB Logic

ESB Logic is the main component responsible for all incoming and outgoing traffic (except publishing of MQTT messages). ESB Logic processes incoming messages, translates them based on pre-defined requirements and distributes them to the relevant sub-systems.

ESB is a generic solution for connectivity of transportation IT equipment. Therefore, its internal structure is defined in a generic way using 3 components, as described in the info-graphic below.

ESB Functional Diagram

Connectors

Connectors are the entities required to communicate with the external systems. A connector configuration will include the information to participate in the communication. A connector can be of type client or server.

A server connector is one that ESB receives messages on. These are reactive components, waiting for an outside entity to trigger them by sending ESB a message.

A client connector is one that ESB sends a message on. In this case ESB initiates the message sending to an outside entity.

Actions

When a message is processed in ESB, ESB may need to perform some action to fulfill the use case. Actions can be hooked to the forward direction of a path flow or reverse direction.

Forward direction actions are performed after ESB receives the message from the server connector, and before it transfers it to the client connector(s).

Reverse direction actions are performed on the message that is returned by the client connectors to the server connector.

Paths

Paths are the glue that connects everything. A path implements an ESB use case while utilizing:

• A server connector (Mandatory)

• One or multiple client connectors (One is Mandatory)

• One or more forward actions (Optional)

• One or more reverse actions (Optional)

Paths “scope” the connectors they use to narrow the connector to only what is relevant for this path. Scoping information includes:

• URL paths and messageID fields

• Topics for MQTT/JMS protocol

• Internal storage bucket

See below info-graphic for a general path flow.

Path Flow

Multiple client connectors may exist on one path. In this case the flow will send the request to all clients. A typical use case is synchronous distribution of a message to multiple receivers.

Per configuration, the path may auto return an OK reply to the “External Side A” member, in opposed to the normal handling which returns the reply received from “External side B”.

The actual Connectors, Paths and Actions vary from project to project and may require customization of ESB. Eventually the “scoping” of the connectors and paths is defined in a configuration file – per project.

RabbitMQ MQTT broker

RabbitMQ acts as a general purpose MQTT broker, thus any traffic can be dynamically published/subscribed to it – should the project need this functionality.

Elastic Search

This module boasts the ESB with extensive logging of all messages passing through it. The messages are displayed clearly with all their fields, whether the message is XML/JSON/Other. The messages can be searched by fields and textual values.

ESB uses Elastic Search for logging/searching the operational messages going to/from the ESB, but also for following internal logging of the ESB processing (INFO, WARNING, DEBUG messages).

The Elastic Search module has a powerful web UI, Kibana, in which all log searching is done. In addition, any kind of report can be crafted via Kibana. For example, graphs of message distribution by type and by time frame.

Apache ActiveMQ broker

Apache ActiveMQ acts as a JMS broker. It supports OpenWire transport over TCP/IP. At the time of writing this doc, the version used is ActiveMQ 6.0.1.