Microgateway Use Cases

The following sections describe several scenarios which are enabled through the Microgateway feature.

Traffic Management to Microservices

In this case, a REST client makes a HTTP request into the Solace PubSub+ event broker. The event broker authenticates the client using either basic authentication or a TLS client certificate. Once the client is authenticated, the method and path portions of the URI are encoded into a topic, and evaluated against the client’s publisher ACL rules to determine whether the client is authorized to access that URI using the method requested by the client. Once the client is authorized, the request is routed to the destination or destinations that are subscribed to that topic. Typically, the message is then placed on a queue serviced by a REST delivery point (RDP) for delivery to the remote microservice. The microservice processes the request and generates the appropriate response. The response from the microservice is then returned through the event broker to the REST client.

Standard Microgateway Deployment

For an example describing how to configure a standard Microgateway deployment that provides traffic management to microservices, refer to Traffic Management to Microservices Example.

Integration with Eavesdropping Applications

Using a Solace PubSub+ event broker to transport the HTTP requests and responses allows other services or event listeners to also receive the messages without any changes to the REST client or REST service providers. This allows you to introduce response time analytics, data capture for testing using real data, fault analysis and so on without recoding the client applications.

In order for the additional listeners to receive requests and responses, you need only add subscriptions to the same topics the service providers are subscribed to, and a subscription that corresponds with the reply-to topic generated by the event broker.

Microgateway Integrated with an Eavesdropping Application

For an example describing how to add an eavesdropping application to an existing Microgateway deployment, refer to Eavesdropping Application Example.

Multi-Protocol Message Delivery

The Microgateway feature also makes it possible for non-HTTP clients such as JMS or JEE applications to act as service providers. This is because the topic derived from the URI can route the message to a queue or endpoint which is serviced by any type of client using our PubSub+ Messaging APIs or Open APIs & Protocols. The HTTP header is made available to clients that are using these APIs as a single text block, in other words, the header options are not parsed out into individual name-value pairs.

Microgateway with a Connection to a Service Provider Using JMS

MQTT clients cannot be used as service providers in this solution because there is no mechanism in MQTT for getting metadata, such as the reply-topic and the HTTP header properties, to the MQTT client.

Hybrid Event-Driven Architecture

Because Solace PubSub+ event brokers support publish/subscribe architectures, you can use a Microgateway to build a hybrid request/reply and pub/sub event-driven architecture. The result is much more flexible and scalable than a traditional request/reply architecture.

The following diagram provides an example of a hybrid event-driven architecture. In this example, a front end mobile application and multiple back end microservices (including a real-time analytics application) are all connected to the Solace message bus. Both request/reply and pub/sub delivery methods are used depending on the objective of each microservice.

Hybrid Request/Reply and Pub/Sub Event-Driven Architecture

Migrating from a Request/Reply Architecture to an Event-Driven Architecture

You can add a Microgateway into an existing request/reply environment to assist with a migration to an event-driven architecture.

Under a traditional request/reply architecture, adding a new event-driven service means taxing every existing microservice to support at least two message exchange patterns (events and request/reply). Using a Solace Microgateway, you can scale your architecture without having to interfere with existing services. In addition, you can have both environments in operation until you are ready to remove the older services.

The following diagrams show an existing request/reply architecture evolving to an event-driven architecture as a new application is added using a Solace Microgateway.

Migrating from a Request/Reply Architecture to an Event-Driven Architecture using a Microgateway—Phase 1

Migrating from a Request/Reply Architecture to an Event-Driven Architecture using a Microgateway—Phase 2

Migrating from a Request/Reply Architecture to an Event-Driven Architecture using a Microgateway—Phase 3

For an example demonstrating how to add an event-driven application to an existing request/reply endpoint, refer to Migrating to an Event-Driven Architecture Example.