iWay Cross-Channel Services Guide > Reverse Invocation Queue Processing > Reverse Invocation Queue Processing Overview

Reverse Invocation Queue Processing Overview

Topics:

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:

  1. Install the iWay Gateway extension on the iWay Proxy server and the execution engine.

    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 RVIRelay service are added to the design-time registry and run time configurations.

  2. Configure the RVIAttach listener on the iWay Proxy server.
  3. Add the RVIRelay service to the appropriate listener(s) configured on the iWay Proxy server.
  4. Configure the RVIGateway listener on the execution engine.

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.

Proxy Service

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.

Execution Service

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 emit service(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.

The process flow that is configured on the execution service must return only one result message. Although a process flow can be developed that returns multiple results, this practice is not compatible with the execution service.

Reverse Invocation Process

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).

  1. The iWay Proxy, or Receiving Engine, starts with the RVIAttach listener waiting for connections to be initiated from the Execution engine, as shown in the following image.
  2. The connection is initiated by the gateway listener configured on the Execution engine located in the enterprise, behind the firewall. A service name is defined in the gateway listener configuration, as shown in the following image.
  3. After the connection is established, it is added to a pool of connections and can be referenced by the service name, as shown in the following image.
  4. When a partner connects to the event listener defined on the iWay Proxy, the message is routed to the Execution engine through the relay service that is added to the event listener. The relay service is configured with the service name defined in the gateway listener configuration, as shown in the following image.
  5. After the connection between the iWay Proxy and the Execution engine is established, messages pass securely through the configuration, as shown in the following image.
  6. Multiple channels can be configured in the same way. Gateway listeners configured on the Execution engine can spawn services that the iWay Proxy can use to pass data to the configured gateway listeners, as shown in the following image.

Sample Scenario

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:

  1. The Execution engine initiates a connection with the Receiving Engine (iWay Proxy).
  2. The session is established.
  3. The trading partner initiates a connection with the iWay Proxy (the Receiving engine).
  4. The connection is established, and the iWay Proxy manages connectivity between the trading partner and the internal processes hosted by the Execution engine.

From the perspective of a trading partner, a secure connection is established, and information can safely pass through the firewall for secure processing.