PubSub+ for Developers

Create event-driven apps and microservices on any platform with whatever language, open protocols, and APIs you choose.

Get Started with DockerGet Started with Cloud

MessagingService messagingService = MessagingService.builder(ConfigurationProfile.V1)
        .fromProperties(properties).build().connect();
DirectMessagePublisher publisher = messagingService.createDirectMessagePublisherBuilder()
        .onBackPressureWait(1).build().start();
OutboundMessage message = messagingService.messageBuilder().build("Hello World!");
Topic topic = Topic.of("solace/try/this/topic");
publisher.publish(message, topic);
topic = Topic.of("solace/try/this/topic")
messaging_service = MessagingService.builder().from_properties(broker_props).build().connect()
direct_publisher = messaging_service.create_direct_message_publisher_builder().build().start()
outbound_msg = messaging_service.message_builder().build("Hello world!")
direct_publisher.publish(destination=topic, message=outbound_msg)
topic := resource.TopicOf("solace/try/this/topic")
messagingService, err := messaging.NewMessagingServiceBuilder().FromConfigurationProvider(brokerConfig).Build()
directPublisher, builderErr := messagingService.CreateDirectMessagePublisherBuilder().Build()
outbound_msg, err := messagingService.MessageBuilder().BuildWithStringPayload("Hello world")
publishErr := directPublisher.Publish(outbound_msg, topic)
// Publish using Spring Cloud Stream
@Bean
public Supplier helloWorldSend(){
  return () -> {
   return "Hello World";
  };
}
var message = solace.SolclientFactory.createMessage();
message.setDestination(solace.SolclientFactory.createTopicDestination("solace/try/this/topic"));
message.setBinaryAttachment("Sample Message");
message.setDeliveryMode(solace.MessageDeliveryModeType.DIRECT);
publisher.session.send(message);
curl -X POST http://[HOST]:[PORT]/solace/try/this/topic \
-d "Hello World REST" \
-H "Content-Type: text/plain"
--user [client-username]:[password]
String content = "Hello world from MQTT!"
MqttMessage message = new MqttMessage(content.getBytes())
message.setQos(0)
String topic = "solace/try/this/topic"
mqttClient.publish(topic, message)
JMSContext context = connectionFactory.createContext();
Topic topic = context.createTopic("solace/try/this/topic");
TextMessage message = context.createTextMessage("Hello world!");
JMSProducer producer = context.createProducer().setDeliveryMode(DeliveryMode.NON_PERSISTENT);
producer.send(topic, message);
Topic topic = session.createTopic("solace/try/this/topic");
MessageProducer messageProducer = session.createProducer(topic);
TextMessage message = session.createTextMessage("Hello world!");
messageProducer.send(topic, message, DeliveryMode.NON_PERSISTENT,
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
PubSub+
MessagingService messagingService = MessagingService.builder(ConfigurationProfile.V1)
        .fromProperties(properties).build().connect();
Topic topic = Topic.of("solace/try/>");
DirectMessageReceiver receiver = messagingService.createDirectMessageReceiverBuilder()
        .withSubscriptions(topic).build().start();
receiver.receiveAsync(messageHandler);
topic = Topic.of("solace/try/>")
messaging_service = MessagingService.builder().from_properties(broker_props).build().connect()
direct_receiver = messaging_service.create_direct_message_receiver_builder().with_subscriptions(topic).build().start()
direct_receiver.receive_async(MessageHandlerImpl())
topic := resource.TopicSubscriptionOf("solace/try/>")
messagingService, err := messaging.NewMessagingServiceBuilder().FromConfigurationProvider(brokerConfig).Build()
directReceiver, err := messagingService.CreateDirectMessageReceiverBuilder().WithSubscriptions(topic).Build()
err := directReceiver.Start()
regErr := directReceiver.ReceiveAsync(MessageHandler)
// Consume using Spring Cloud Stream
@Bean
public Consumer helloWorldConsume(){
  return v -> System.out.println("Received: " + v);
}
subscriber.session.connect();
subscriber.session.subscribe(
solace.SolclientFactory.createTopicDestination("solace/try/>"),
true, correlationObject, 10000
);
http.createServer(function (req, res) {
console.log('Received message: ' + req.url);
res.writeHead(200);
res.end();
}).listen([PORT], '[HOST]');
console.log('Server running at http://[HOST]:[PORT]/');
mqttClient.connect(connOpts);
mqttClient.setCallback(new PrintingMqttCallback());
String topic = "solace/try/>";
int qos = 0;
mqttClient.subscribe(topic, qos);
JMSContext context = connectionFactory.createContext();
Topic topic = context.createTopic("solace/try/>");
JMSConsumer consumer = context.createConsumer(topic);
String message = consumer.receiveBody(String.class);
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Topic topic = session.createTopic("solace/try/>");
MessageConsumer messageConsumer = session.createConsumer(topic);
messageConsumer.setMessageListener( new MessageDumpListener() );
connection.start();

What is PubSub+?

PubSub+ is a platform that enables the design, discovery, streaming and full lifecycle management of events across distributed enterprises. It provides all of the tools necessary to support a modern event-driven architecture. The main components of the platform are PubSub+ Event Brokers, PubSub+ Event Portal and PubSub+ Cloud Console. Most of the content here focuses on PubSub+ Event Brokers.

Get up to speed on the core concepts here.

APIs and Protocols

Solace PubSub+ Event Brokers have built-in support for a variety of proprietary and open standard protocols and APIs, so you can create and connect apps with whatever language, open protocols and APIs you choose, without worrying about translation.

Solace messaging APIs offer uniform client access to all Solace PubSub+ capabilities and qualities of service, and are available for C, .NET, iOS, Java, JavaScript, JMS, Python and Node.js. Solace also supports popular open protocols like AMQP, JMS, MQTT, REST and WebSocket, and open APIs such as Paho and Qpid.

Diagram: APIs and Protocols

Connect Using a Supported Client Library

Select a connection point and supported client library below to start messaging.
View by:
    • Connect with Java
      Solace JCSMP, Solace Java, Solace JMS over SMF, Paho over MQTT, QPID JMS 1.1 over AMQP, QPID JMS 2.0 over AMQP
      Library
      Protocol
      • Solace Java API
        SMF
      • Solace JCSMP API
        SMF
      • Solace JavaRTO
        SMF
      • Solace JMS API
        SMF
      • Solace REST Messaging API
        REST
      • Eclipse Paho Java Client
        MQTT
      • QPID JMS 1.1
        AMQP
      • QPID JMS 2.0
        AMQP
    • Connect with C and C++
      Solace C API over SMF, Paho over MQTT
      Library
      Protocol
      • Solace C
        SMF
      • Solace REST Messaging API
        REST
      • Eclipse Paho C Client
        MQTT
      • Eclipse Paho C++ Client
        MQTT
    • Connect with Python
      Solace Python API over SMF, Paho over MQTT
      Library
      Protocol
      • Solace Python API
        SMF
      • Solace REST Messaging API
        REST
      • Eclipse Paho Python Client
        MQTT
    • Connect with Go
      Solace Go API over SMF
      Library
      Protocol
      • Solace Go API
        SMF
    • Connect with JavaScript
      Solace Javascript API over SMF, Paho over MQTT
      Library
      Protocol
      • Solace JavaScript API
        SMF
      • Solace REST Messaging API
        REST
      • Eclipse Paho JavaScript Client
        MQTT
    • Connect with Node.js
      Solace Node.js API over SMF, AMPQP10 Open Source over AMQP
      Library
      Protocol
      • Solace Node.js API
        SMF
      • Solace REST Messaging API
        REST
      • AMQP10 Open Source API
        AMQP
    • Connect with .NET
      Solace .NET API over SMF, Paho over MQTT
      Library
      Protocol
      • Solace .NET
        SMF
      • Solace REST Messaging API
        REST
      • Eclipse Paho .NET Client
        MQTT
    • Connect with Spring
      Spring Cloud Stream, Spring Boot
      Projects
      Protocol
      • Spring Cloud Stream
        SMF
      • Spring Boot Java API
        SMF
      • Spring Boot JMS API
        SMF

Use Cases

Microservices

Microservices are a software development technique in which an application is broken down into a set of services that function as a processing pipeline. Decomposing an application into multiple microservices can bring several benefits, including improved development speed, an easier to understand code base, enablement of continuous delivery, improved scalability, and better fault isolation. In many cases, application processing is kicked off by a web request via an API gateway using the request/reply pattern. Once the request is received, the microservices work in concert behind the gateway to process the request.

Microservices Diagram: Figure 1 - Orchestration

Microservices Diagram: Figure 2 - Choreography

Enable event-driven microservices

To provide business value, microservices need to effectively communicate while maintaining their independence and singularity of purpose. Your default may be to use an orchestration layer to decouple your RESTful HTTP services from your microservices, and to synchronize interactions between your microservices (Figure 1). But as your system scales and the need for your microservices to work in parallel increases, so too does your need to take an event-driven approach enabled by asynchronous, publish-subscribe messaging patterns (Figure 2). This is the approach enabled by PubSub+ Event Brokers.

The brokers sit between your microservices, enabling them to publish events to the broker and subscribe to events published to the broker by other microservices. This approach carries many advantages:

  • It’s easy to add, remove and move services within the system, without disrupting the system.
  • It’s simple to scale individual services or groups of services to handle variability in load (rather than having to scale the entire system which is often necessary when microservices are tied together with synchronous communication patterns like request-reply).
  • It’s non-blocking: asynchronous microservice threads don’t get blocked while waiting for a response (as they do with synchronous patterns).
  • It enables resiliency and error-handling: PubSub+ Event Brokers can persist all messages to guaranteed delivery, and can serve as a source of truth in the case of failures, enabling rapid disaster recovery without risk of message loss.

Event Mesh

An event mesh is to your event-driven applications what a service mesh is to your RESTful applications: an architectural layer that allows events from one application to be dynamically routed and received by other applications, across diverse systems, clouds and protocols. This layer is composed of a network of advanced event brokers. The capabilities of the brokers that compose the mesh determine the capabilities and quality of the mesh.

Event Mesh Diagram

Building an event mesh with PubSub+

An event mesh built with PubSub+ Event Brokers is:

  • Dynamic: events and other messages are self-routing, self-learning, self-healing, and built for automated and efficient event streaming between event producing and event consuming apps, wherever they run.
  • Open: natively supports multiple open standard protocols and APIs, for an open ecosystem.
  • Simple: the mesh can be created, managed and monitored through a single console.
  • Everywhere: can be deployed natively on premises, in private clouds and in public clouds (AWS, GCP, Azure), as an appliance, software and as a service.

Internet of Things

IP-addressed applications typically send and receive data to devices through an intermediary node like an IoT gateway, and the default communication pattern is request-reply over REST/HTTP (Figure 1).

IoT Diagram: Figure 1 - Basic IoT Architecture

IoT Diagram: Figure 2 - IoT with Messaging

For simple IoT projects and pilots that tend to be very focused and small scale, this will be the path of least resistance, and it will probably work just fine. But as you move from pilot to production in an enterprise environment, and as your application requirements grow more complex, the benefits of an event-driven approach enabled by event brokers and messaging patterns like publish-subscribe increase.

Build IoT apps that are flexible and scale

PubSub+ Event Brokers can sit between your applications, IoT Gateways, back-end systems and cloud services, enabling a variety of communication patterns between them (publish-subscribe, streaming, queuing and request-reply), and over a variety of open standard protocols and APIs (MQTT, AMQP, JMS, WebSockets, REST/HTTP). This carries a number of advantages:

It enables event-driven communication between diverse endpoints and networks (devices, gateways, legacy applications, cloud-based microservices, data lakes, analytics engines) without requiring you to build complex protocol translations into your applications (protocol translation is done by the broker).

  • It makes for a highly scalable system: brokers can be vertically and horizontally scaled to handle exponential increases in load and connection counts.
  • It enables efficient command and control of edge devices by back-end applications: (1) every device and application in the system is addressable through PubSub+ topic routing; (2) broker-enabled protocol translation lets back-end apps send commands over JMS while gateways/devices can receive the commands over other protocols (like MQTT, AMQP, REST/HTTP); and (3) messaging capabilities supported by the broker like fan-out and filtering enable back-end systems to send commands to individual, all, or select groups of edge devices.
  • It’s fault tolerant: PubSub+ Event Brokers enable multiple qualities of service including guaranteed delivery for IoT scenarios where every message must be delivered—even to disconnected subscribers or those that can’t handle large volumes of data at a time.

Messaging

Messaging refers to the passing of data between two applications via an intermediary broker (message-oriented middleware). Messaging communication patterns like publish-subscribe, queuing and streaming can be differentiated from other communications patterns like request-reply over REST/HTTP in that messaging enables the decoupling/loose coupling of applications (Figure 4), and messages are generally sent asynchronously, whereas point-to-point request-reply patterns tend to support synchronous interactions between applications that are tightly coupled (Figure 3).

Messaging Diagram: Figure 3 - Point-to-Point, Request-Reply

Messaging Diagram: Figure 4 - Messaging

If you’re experienced with messaging, you may be familiar with open source tools like RabbitMQ, ActiveMQ or Kafka, or a commercial product like IBM MQ, TIBCO EMS (for on-prem deployments), AWS SQS/SNS or Azure Service Bus (cloud-native). Each messaging solution has its pros and cons, but a modern event broker like PubSub+ fits the bill for enterprise use cases that demand high performance and reliability across public clouds, private clouds, and datacenters, the flexibility to deploy anywhere, and the need to leverage a variety of open standard protocols and APIs.

Leverage modern messaging

PubSub+ Event Brokers are uniquely designed to support modern development practices (microservices, reactive, polyglot) and architectures (event-driven, hybrid cloud, multi-cloud), with support for the publish-subscribe messaging pattern (along with the traditional queuing and request/reply patterns), dynamic event streaming, and a host of additional features that ensure enterprise-grade performance and reliability no matter the demands of load and scale.

Cloud

To enable communication among cloud-native applications, microservices and cloud services, your default may be to use the request-reply pattern over REST/HTTP, or to leverage messaging services provided by the public cloud you’re working in – AWS SQS/SNS, Google Cloud Pub/Sub, Azure Service Bus, etc.

If you’re working in a single public cloud and your application has little need to consume data produced elsewhere (on premises, in private clouds, or in other public clouds), one of these approaches may work just fine. But as your application requirements grow to include publishing and subscribing to data streams across multiple public clouds and/or private clouds/datacenters, the benefits of using a cross-cloud and hybrid-cloud message broker increase.

Stream data across public clouds, private clouds and hybrid clouds

PubSub+ Event Brokers support event-driven applications and architectures across hybrid-cloud, multi-cloud and IoT environments, with support for the publish-subscribe messaging pattern (along with the traditional queuing and request/reply patterns), dynamic event streaming, and a host of additional features that ensure enterprise-grade performance and reliability no matter the demands of load and scale.

Cloud Diagram

PubSub+ Event Brokers can be deployed natively in AWS, GCP and Azure, as well as in private clouds/datacenters, and the brokers can be connected to form a dynamic event mesh for event-driven communication across all environments (see Event Mesh use case).

PubSub+ Event Broker Cloud offers enterprise-grade messaging as a service, on-demand in your favorite public and virtual private clouds.

Here are some of the cloud-related capabilities and benefits you can unlock:

  • Stream data from your premises to the cloud: enable secure, reliable, real-time data movement between legacy and cloud applications over WebSocket, AMQP 1.0, JMS or REST/HTTP.
  • Stream data across private and public clouds; work inside the virtual private clouds (VPCs) offered by public cloud providers to maintain security and control.
  • Leverage WAN optimization for high throughput and low latency between cloud regions (over long-haul links) with limited bandwidth and/or round-trip times.
  • Filter data at the edge: only send events and other data to the cloud when you have applications in the cloud that are interested in the data (save $).
  • Benefit from built-in fault tolerance and replication, both with fast failover, to ensure data is never interrupted and messages never get lost.
  • “Lift and shift” existing applications directly to the cloud leveraging JMS support.