Xbus provides a pipeline declaration system one can leverage to configure the route messages have to take. How does that work?
There are several ways to configure the route messages have to take. Some imply that each application emitting data (emitter) is assigned an emitter profile related to an event type, while each application receiving data (consumer) or modifying data (worker) is programmed to receive that event type. This requires separate per-actor settings, which can get quite cumbersome.
The system implemented in Xbus is more flexible. It is based on declarative pipelines modeling data flows. These data flows are all declared through a single file (YAML format). A pipeline is made up of several nodes representing messages’ transmission steps (emitters, workers which modify data, consumers receiving it). Each node can contain several inputs and outputs. Inputs represent data flows provided by the pipeline to actors whereas outputs designate data flows generated by actors back to the pipeline.
From within the same pipeline, one can create a flow divided into several branches, i.e. forwarding messages to different consumer applications depending on specific criteria. This mechanism helps implement message routing. Implementing EIPs therefore becomes doable, as described in Gregor Hohpe and Bobby Woolf’s book entitled « Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions » as well as on the dedicated website. This routing mechanism has in particular enabled Xbus to provide the following EIPs:
Message Router: possibility to send a message to a consumer application or to another depending on certain conditions,
Content-Based Router: Message Router which leads messages to a consumer application or another depending on the content (examined by a worker), for example a country code. This splitting mechanism becomes possible thanks to outputs that a worker can send to the pipeline.
Process Manager: an Xbus component that manages message routes, especially the transmission from a consumer application to another depending on certain conditions.
Pipelines are easily reusable: While one can designate actors in a pipeline description file by name / by ID; one can also use roles assigned to multiple actors at once.
Xbus therefore provides tools to avoid any kind of coupling between emitters and consumers; that is in line with urbanization logic. This pipeline structure makes it easy to develop a specific router. CloudCrane provides this service to whomever may have such specific requirements.
As an example, for one of our clients we have built a specific Xbus router (Content-Based Router) which directs flows from a source program to one of several target programs. It would not make sense for the source program to know in advance which target program it wants to send messages to since these source and target programs are not provided by the same entities. A matching table has instead been built within the specific router to match identifiers emitted by the source program against those known by the target one. This mechanism guarantees independence between emitters and consumers, leading to a well-urbanized system as a whole.
As Xbus exposes an API, users can develop their own router. Xbus source code is available on Orus.io.
Documentation on Xbus routing: pipeline creation and management.
Iccon made by Freepik from www.flaticon.com licenced by CC 3.0 BY