Interface queues, input queues, and message dispatching
- Interface queue
- This
is the queue known to and used by applications and by other services.
There is one interface queue for each combination of
FTM SWIFT instance, message flow,
and OU that is to use the service. The name of an interface queue
reflects this: the name consists of the instance, OU, and service
names, delimited by periods (for example, INST1.BANKA.DNI_R_AUDIT.
It is the presence of an interface queue that allows an OU to use
a particular service.
You can use a security profile of an external security manager (ESM) such as RACF® to protect interface queues, so that only certain user IDs are allowed to put messages into these queues. Interface queues are get-disabled, to prevent the messages that they contain from being retrieved directly.
- Input queue
- This queue
is the target of an interface queue, and is the queue from which a
service retrieves the requests and responses that it processes. This
queue must be defined in the queue manager associated with the broker
in which the service runs. Because input queues are accessed by means
of alias queues and not directly, input queues do not need to be made
known within a cluster. You can use a security
profile of an ESM such as RACF to protect input queues,
so that only the user ID of the message broker in which the service
runs is allowed to get messages from these queues. An input queue has a name of the form prefix.messageFlowName, where prefix represents a queue prefix that is specified during customization. This prefix makes it easier to:
- Distinguish the input queues from other queues
- Protect the input queues, for example, by implementing a generic security profile in an ESM such as RACF
- Restrict access to a service to only certain OUs. You do this by providing input queues only for those OUs that are to use the service.
- Change a service for one or more of the OUs that use it, while leaving it unchanged for the other OUs that use it. You do this by creating a new input queue and service, and associating the appropriate interface queues with this new input queue.
For example, Figure 1 shows a configuration in which an application uses the service Service1 to process messages for three different OUs (BANKA, BANKB, or BANKC). Because only these OUs have interface queues for this service, other OUs cannot use this service.
At some point in its processing, the application passes each message to the service Service1. To do this, the application puts each message into the interface queue of the corresponding OU. From this alias queue, the messages are routed to the input queue of the service.
If, at some later time, BANKC requires a special implementation of Service1, a new service can be created. This service has its own input queue. The messages for BANKC can be routed from its existing interface queue to this new input queue, where they are processed by the new service. The application continues to run unchanged and to use the same interface queue, as shown in Figure 2. It does not even need to be made aware that anything has changed.
