Asynchronous Forward Transfer Invocation Overview

The cross-channel protocols that are described in the previous chapters of this documentation are completely managed by iSM. Sometimes an application requires a cross-channel structure that must use another protocol, such as MQ Series, MSMQ, FTP, or any other protocol that is not specific to iSM. To support this requirement, it is necessary to marshall the message and its context for transmission into a format that iSM can support. Asynchronous Forward Transfer Invocation (AFTI) allows a service to transfer a message and its context across a channel using a protocol that is not specific to iSM. There is no restriction on the type of protocol that can be used.

In iSM terms, marshalling refers to the serialization of the current message and its context (special registers) for saving or transmission purposes. Unmarshalling takes a marshalled serialized message and restores its content and context.

AFTI is accomplished through the use of a provided service within a process flow. To send a context and a message to another party, configure the Marshall preemitter (com.ibi.preemit.XDMarshall). When the message is received by an iSM channel, it is automatically unmarshalled. The message context is reestablished and the message flows through the standard channel functionality.

Additionally, the Marshall service (com.ibi.agents.XDMarshallAgent) is available, which can be positioned to marshall the message and its context before it is passed to an emit service.

The following image shows that the Queue (Out) object was added to the process flow, renamed as Send to MQ, and that a message queue type is being specified from the Select Action drop-down list.

On the receiving side, a simple process flow can deposit the unmarshalled message into the desired internal queue. A best practice can be to put the name of the desired queue in a Special Register (SREG) if the process flow can deposit into different queues.

AFTI offers optional data compression and encryption through AES. Encryption is offered, since the marshalled message may reside on an intermediate media (for example, a file system). Any message-bearing protocol can be used. If the marshalled message will never be serialized to external media, then encryption is probably not required. While decompression is handled automatically by the receiving channel, the encryption key must be supplied to the receiver. This is the purpose of the AES Key parameter, which is available for all iSM listeners.