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) on the emit service or emitter being used. 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 emitter.

The following image shows a sample process flow configuration, where a message can be sent to a queue on another configuration.

In this example, a process flow is defined and a preparser is added to reach the Marshall service.

Next, a service is defined to prepare the message, which will be sent to one of two destinations. Note that this example uses an emit object, so that the message is sent after the process flow is completed. An emit service could have also been used, which would depend on the requirements of the application.

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.