iWay Service Manager (iSM) provides channels that link processes within iSM to other processes in the same or another instance of iSM. This contrasts with channels that acquire messages from external media, such as a File or FTP connection. These channels divide the message execution process into stages for application purposes, such as:

• Exchanging messages with other servers.
• Dividing the application into more manageable portions.
• Changing threading models based on specific sections of the application.
• Performance tuning.

Cross-channel message exchanges can be used to facilitate application modularization. In addition to simplifying application development and maintenance, an application that is composed of modular sections provides horizontal and vertical scaling. The modular sections can be executed:

• within the same JVM, which facilitates the selection of the appropriate threading model for that portion of the application.
• across JVMs on the same computer to take advantage of the dispatching mechanisms that belong to this computer.
• across computers, which allows several computer systems to work on the application simultaneously.

The mechanisms that support cross-channel message exchanges provide opportunities for workload balancing and backup/recovery when used in appropriately designed applications.

The application design that is best oriented for the use of cross-channel distributions is called the multi-channel architecture, which is a common architecture for iSM-based applications. For example, consider the following modularized breakdown of a typical application:

1. A message arrives from an external source. This message is examined and transformed, routed to a section of the application that processes the payload, and then passed to a section that emits the final result.
2. A special error handler is configured to report on application issues that are not handled specifically in other portions of the application.
3. An error handler channel receives messages through the errorTo facility of each channel using an internal emitter to direct the error messages that are not handled within the application channel.

The following channel types are available:

• Internal. Passes messages between channels for asynchronous or synchronous execution. For more information, see Internal Queue Processing.
• Ordered. Passes messages between channels for asynchronous execution, maintaining execution order and batch control. For more information, see Ordered Queue Processing.
• Reverse Invocation (RVI). Exchanges messages between two or more instances of iSM, with support for reverse connections. This allows full protection of the iSM instances behind outbound-only firewalls. For more information, see Reverse Invocation Queue Processing.
• Asynchronous Forward Transfer Invocation (AFTI). Marshalls and unmarshalls messages and their context to be exchanged over protocols other than the existing cross-channel protocols that are provided by iSM. For more information, see Asynchronous Forward Transfer Invocation Queue Processing.

All of the cross-channel links pass messages and full execution context. Additionally, all messages and contexts can be compressed and encrypted for secure processing.