Some designs require that a message be passed from one process to another. For example, a process might receive a message on a protocol, process it, and then desire another listener (thread) to complete the message operation. Frequently, such messages are stored in the file system using the File emit service, and then picked up using the File listener.
As an alternative, iWay Service Manager offers the Internal Queue listener. Messages are stored in memory by the Internal emit service and held until picked up by the Internal Queue listener. Messages can be made to persist in the event that the server fails or is terminated before all held messages are processed.
Each listener is associated with one internal queue that has been assigned a name. The flow that is required to store a message in the queue configures an Internal emit service to that assigned name. The listener picks up the stored messages by First In, First Out (FIFO) method, and passes them for execution.
As the queue grows and shrinks, the Internal Queue listener can manage the listeners feeding the queue to maintain an average, desirable size. This is referred to as rubber banding or back pressure. The low and high mark configuration values control this.
A common use of the internal emitter is to pass a message to one or more work flows that operate asynchronously. For example, each Internal Queue listener flow may update a different database or may access records from a single database based upon a computed modulus key.
As with all protocols, it is possible to either emit to the protocol following completion of the message flow or to emit immediately using an emit service (com.ibi.agents.XDInternalEmitAgent) within the flow, which can be configured using a Queue object for Internal Emit. If the service approach is used, then the handling of the message by the Internal Queue listener can proceed asynchronously with the flow that originated the message.
Once a message has been passed to an Internal Queue listener, it is separated from its originator and the originator can neither await its execution or obtain response values.
The following is a list of additional scenarios where Internal Queue processing can be implemented: