Pipelines
Montova™ Integrator relies heavily on the concept of pipelines, in which a number of tasks (called operations) get executed in sequential order: the output from one operation simply becomes the input for the next. These operations perform small, specialized tasks, making them easy to develop, document and maintain.
Moreover, an operation can in itself be a pipeline, or contain multiple pipelines which are executed depending on some condition. Arbitrarily complex applications can thus be created.
Getting messages
Messages find their way into the system by either being picked up by a polling component or by being actively presented by some outside impulse. The former principle, i.e. polling some data store for messages, is performed by a so-called ”monitor”, while the latter as called a ”service”. Montova™ Integrator uses this simple terminology to distinguish between these two very different principles.
Monitors
A monitor is a thread which executes a pipeline of operations on messages received from its source message location and puts the result on its destination message location.
However, not all of these components need to be present: you can define an application with only a source and destination message location, in which incoming messages are simply copied to the destination without transforming them. Adding to this simple concept, are the “on-failure”, “on-success”, “pre” and “post” pipelines. They allow to handle errors, perform operations after a successful run, and before/after the run.
For each configured and enabled monitor, the main process will start a separate thread which will:
- fetch a message from its source message location
- execute the operations in its main operation pipeline
- put the resulting message to its destination message location
- execute the operations in its success operation pipeline
Should an error occur while during the retrieval/processing of an incoming message, the operations in the “on-failure operation pipeline” will be executed. This pipeline can be used to e.g. send alerts, or back up the message so that it can be discarded. If the source message location supports the two phase commit protocol, the monitor can either backout the current message or commit (and thereby discard) it. After this, it can either halt or continue running.
Services
A service is triggered by some kind of connection from a client, possibly on another system. When a client connects to the service, a new thread is spawned, which will execute its defined message flow on any messages the client presents. The result is returned to the client.