In this section: |
Reverse Invocation (RVI) queue (also referred to as gateway) processing links two or more iWay Service Manager (iSM) instances in a message receiver or a message executor relationship to tunnel through secure firewalls.
To configure RVI queue (gateway) processing, you must:
To install the iWay RVI Proxy, you must add the Gateway extension to your iSM instance during the iSM installation. For more information on installing iSM, see the iWay Installation and Configuration Guide.
After the Gateway extension is installed, the RVIAttach listener, RVIGateway listener, and RVI Relay service are added to the design-time registry and run time configurations.
iSM horizontal scaling through reverse invocation allows a message received by one iSM configuration to be processed on another configuration. Configurations are expected to be on separate machines, but this is not a requirement. Messages can be distributed over an arbitrary number of associated configurations to balance workload and provide for high availability of processing services.
Messages are received at a receiving engine (the iWay Proxy) and executed at an execution engine. Each message arriving at the iWay Proxy is assigned to a named service. This assignment can be configured in a fixed manner based on the receiving listener or it can be assigned using the full services of iSM intelligent routing services. Regardless of how the assignment is made, the receiving engine locates an execution engine offering the named service, and passes the message to that engine for execution.
Processing engines connect to the receiving engine on a secure, reverse channel. This enables the receiving engine to be located across a firewall, enabling execution to be carried on in a secure environment not open to outside, unauthorized access.
This is also referred to as Reverse Invocation because the execution engine connects to the receiving engine rather than the receiving engine connecting to the execution engine to pass a document.
Messages arrive at the proxy through any of the protocols that are supported by iSM. Each protocol is managed by a listener. The listener is configured to pass the message to a relay service, which selects an attached execution service and passes the message to the selected engine for execution. All other iSM capabilities are supported. For example, intelligent routing can examine the incoming message to select the appropriate relay service for execution.
The execution engine accepts relayed messages, executes them, and returns the result to the relay service, which in turn relays the result back to the configured emitter(s). Usually, ancillary emit operations are performed on the execution engines, though this is not required.
An execution engine is configured with one or more gateway listeners. A gateway is a named service that attaches to the attach point of a receiving engine. There must be one gateway for each service name offered, at each receiving engine attach point.
This section depicts the reverse invocation process in a step-by-step fashion. In this depiction, iSM is deployed to two locations, one within the enterprise and one in the demilitarized zone (DMZ).
As an example of a Reverse Invocation scenario in which the payload is an EDI document, an AS2 message is routed over the public Internet. The message must be processed securely within the enterprise, where security certificates reside. The iWay Proxy server receives the message securely within the DMZ and passes it back for secure processing to an iSM located inside the enterprise that acts as the Execution engine.
The following diagrams depict the process:
From the perspective of a trading partner, a secure connection is established, and information can safely pass through the firewall for secure processing.
iWay Software |