SolGateway

SolGateway is an application that must be used when IPC applications also want to communicate with other applications through a Solace PubSub+ event broker.

The SolGateway application allows IPC applications running on a host to communicate with an event broker and interact with other applications in Solace PubSub+ through the Solace message bus.

As shown in the figure below, SolGateway allows a number of applications residing on the same host to directly communicate with each other. It also provides those applications a gateway to the platform for communication with other applications.

SolGateway allows an application to maintain the single-session view of communications with other applications and make applications more portable.

SolGateway bridges traffic from the IPC applications to the event broker or from the event broker to the IPC applications behind the gateway. SolGateway does not route messages between IPC applications. If two IPC applications want to communicate directly with each other on the host, you must establish an IPC channel between them.

Using a Single Session for Event Broker and IPC Peer Communications

As an alternative to using SolGateway, you can have each IPC application connect directly to the event broker. However, if this is done with a single session using SolGateway, then the application can receive traffic from both its direct‑connected IPC peer and from the event broker because the subscriptions are replicated on each transport channel underneath a session.

As shown in the figure below, you can have an application use a separate session to connect to the event broker and then control which subscriptions are sent to peer applications and which are sent to the event broker.

SolGateway Using Separate Sessions for Event Broker and IPC Peer Communications

With this communication model, the application is controlling what traffic flows over which sessions, which provides more application control. However, at the same time, to communicate to all other applications, it is a less portable model than the “single session” model.

SolGateway Operation

SolGateway provides the following services:

1. Creates a connection to the event broker.
2. Accepts incoming connections from IPC peers (using either TCP or shared memory communications).
3. Forwards received subscriptions from IPC peers to the event broker. This causes any matching messages on the event broker to be attracted to SolGateway.
4. Sends, by default, a “>” and a “#P2P/>”subscription to each connected IPC peer so that all messages published by peer applications are sent to the SolGateway. This behavior can be changed through a command line option.
5. Routes all messages received from the event broker to IPC peer applications that want the messages (according to the subscriptions received by SolGateway from the IPC peer applications).
6. Sends all messages received from peer IPC applications to the event broker so that they can be received by other applications in the platform that are interested.

SolGateway Command Line Options

To view the command line options available for SolGateway, run the SolGateway application from the command line with no parameters.

SolGateway Limitations

SolGateway can send topic subscriptions received from IPC peers to the event broker to attract matching messages from other applications in Solace PubSub+. It can also publish messages generated by local applications to the event broker. As a result, you must take care to ensure that a local application does not receive the same message from both an IPC peer and from the event broker (that is, reflecting a message published by SolGateway, back to SolGateway and onwards to an IPC peer).

If IPC applications are subscribing to one topic and publishing on a different topic, then this issue cannot occur. However, it can occur if IPC applications behind SolGateway are subscribing to the same topics that they are also publishing on. For example, in theUsing a Single Session for Event Broker and IPC Peer Communications, Application A has a subscription to topic “foo” and is receiving matching messages published by Application B over the IPC connection between the two applications. SolGateway also receives the subscription topic for “foo” and subscribes to this topic from the event broker. SolGateway also forwards published messages by Application B to the event broker. The event broker then sends this message back to SolGateway, which routes it to Application A, causing it to receive two copies.

To prevent this scenario, you can:

• provision subscription ACLs on the event broker for the SolGateway connection to block subscriptions for which traffic does not need to be received from Solace PubSub+
• use the No Local Delivery (-nl) SolGateway command line option. When this option is specified messages published on the session cannot be received on the same session even if the client has a subscription that matches the published topic.