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:
- 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.
- A special error handler is configured to report on application
issues that are not handled specifically in other portions of the
application.
- 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.