A flexible and robust event broker
PubSub+ helps you build modern, cloud-native apps with whatever language, open protocols and APIs you want to use.
You’re probably used to manually connecting your apps in a point-to-point manner via REST/HTTP. This can be time consuming, complex and inefficient as your application architecture scales. PubSub+ is messaging technology that sits between your apps and microservices, enabling inter-application communication through a variety of patterns like publish-subscribe, queuing, and streaming (in addition to request-reply).
With messaging and PubSub+, you don’t have to spend time manually configuring point-to-point connections between applications and microservices. All you have to do is connect your apps to PubSub+, and the broker takes over from there.
Easily establish real-time, event-driven communication between applications running in public clouds (GCP, AWS, Azure), private clouds (Pivotal Cloud Foundry, OpenShift), and in your data center. PubSub+ provides a unified platform to integrate your entire application ecosystem, including microservices, SaaS, cloud services, legacy apps, mobile devices and the IoT.
Enabling event-driven microservices
Unlock the full potential and agility of event-driven microservices with PubSub+:
- Supports asynchronous and synchronous interactions, service decoupling, and fine-grained filtering.
- Dynamic message routing: moves published events to subscribing applications, no matter where publisher and subscriber apps run, and with no need for pre-defined/static configurations.
- Multi-protocol: native support for AMQP 1.0, MQTT, REST/HTTP, JMS, WebSocket.
- Multi-pattern: publish-subscribe, queuing, streaming, request-reply.
- Multi-environment: PubSub+ runs natively in public clouds (AWS, GCP, Azure), private clouds (Pivotal Cloud Foundry, Red Hat OpenShift), on premises, and is available as a service in all the popular public clouds.
- Replay logs: resend events to new or existing clients that request them, days or even weeks after the event was received from the event broker. PubSub+ will store persistent messages in a replay log. Replay can be performed on a queue or a topic endpoint.
Stream event-driven data between any number or variety of applications and IoT devices, linking event sources with whatever endpoints (sinks) have subscribed to receive the events they publish. With PubSub+ you can:
- Dynamically route tens of millions of events per second everywhere they’re needed, locally or around the world, via the best possible path.
- Aggregate, fan out or filter the event stream with fine-grained topics so each system gets exactly the information it needs, reducing the need to process and reject unnecessary data.
- Buffer and persist data to guarantee asynchronous delivery to recipients that are disconnected or struggling to keep up with the flow of data, so you don’t need to code acknowledgement or redelivery logic into your application.
- Replay and retrieve events weeks or even months after they were originally sent.
APIs and Protocols
Solace PubSub+ supports a variety of open standard protocols and APIs, as well as frameworks like Spring.
The Advanced Message Queuing Protocol (AMQP) is an open and standardized internet protocol for reliably passing messages between applications or organizations. [Learn More]
JMS / JCA
Solace supports JMS 1.1 and provides a JCA adapter so applications can easily migrate applications from any JMS brokers to Solace without changing any code, which reduces the cost and risk of migration. [Learn More]
Solace supports MQTT to meet the needs of connected devices and mobile applications that need an efficient way to send and receive information. Solace works with any third-party MQTT 3.1.1 compliant client API, including open source APIs via Paho. [Learn More]
The Solace REST Messaging API allows HTTP clients to send and receive messages with a Solace message router using HTTP POST requests, without needing to use any Solace-provided API. [Learn More]
Spring (by Pivotal)
Spring helps development teams build simple, portable, fast and flexible JVM-based systems and applications. Solace provides GitHub projects that make it easy to integrate Solace messaging with Spring. [Learn More]
Cloud quick starts and VM images make it easy to deploy PubSub+ software into the cloud and on-prem environments, so you can link applications, devices and microservices across hybrid cloud systems, and migrate applications at will.
You can also start a PubSub+ Cloud broker in minutes. Create your first service here.
Solace PubSub+ supports many components of the Spring Framework, including Spring Integration, Spring Boot, Spring Cloud Connectors, Spring Cloud Stream and, soon, Spring Cloud Data Flow.
Spring Cloud Connectors
Spring Cloud Connectors is an implementation of the ServiceInfo and ServiceInfoCreator interfaces to extend the Spring Cloud Connectors project to the Solace PubSub+ for PCF tile. Using this in your Spring application can make consuming the PubSub+ messaging service easier than directly parsing the VCAP_SERVICES environment variable.
Spring Boot Auto-Configuration
Solace also provides Spring Boot Auto-Configuration implementations and Spring Boot Starter POMs for the Solace Java and JMS APIs to make it easier to use them with Spring Boot auto-configuration through the @Autowired annotation. The artifacts are published to the Maven central repository so it should be familiar and intuitive to use this project in your applications.
Spring Cloud Stream Binder for PubSub+
The Spring Cloud Stream Binder for PubSub+ is an open-source binder that abstracts PubSub+ messaging capabilities so applications can easily send and receive events and information to and from other systems using a variety of exchange patterns and open APIs and protocols. The helps you build sophisticated event-driven microservices without having to know anything about the underlying messaging that makes it all possible.
How it works
Spring has defined a declarative, annotation-based interface that lets you connect Spring Cloud Stream applications “under the covers” so they are completely broker-agnostic. Using this interface, you can configure the specifics of the event broker (such as a broker host/port and credentials/certificates) and simply “bind” to the broker using Spring annotations.
The Spring Cloud Stream Binder for PubSub+ adheres to the Spring Cloud Stream Binder specification, supports input and output channels, and works with all versions for all PubSub+ event brokers – software, hardware and cloud as-a-service – so applications on other sides of the binder can take advantages of rich messaging functionality.
How it’s unique
With the PubSub+ binder, destinations and events published to one broker or a Pivotal Cloud Foundry service instance are automatically disseminated across a global event mesh so they can be consumed by applications and microservices connected to any other broker, anywhere in the world. This makes it easy to deploy or dynamically re-deploy microservices in public and private clouds and on-premise environments as your needs change.
Getting Started with Spring Cloud Stream Binder
As you scale your implementation and start to push the limits of RabbitMQ, you may experience stability, performance and/or manageability issues that convince you it’s time to migrate your apps to PubSub+.
If you’re using AMQP 1.0 or your clients are written to RabbitMQ JMS client, PubSub+ is a drop-in replacement. If you're using AMQP 0.9x with a native RabbitMQ SDK, you will need to re-factor your apps to use PubSub+ SDKs.
Solace HybridEdge can help you bridge legacy RabbitMQ brokered traffic to Solace message brokers while you migrate your apps over to Solace APIs over time. Solace HybridEdge allows you to connect Solace PubSub+ with any other messaging system that is supported by Apache Camel, including RabbitMQ , ActiveMQ, and IBM MQ. HybridEdge comes bundled with Solace JMS, RabbitMQ and ActiveMQ Camel Components. The Solace JMS Camel Component uses the Solace JMS client API and leverages the Camel JMS component. Solace HybridEdge and its associated samples can be found here. Learn more about running HybridEdge here.
Solace PubSub+ makes it easy to connect your Kafka-based apps and data streams with the rest of your enterprise, extending their reach throughout the distributed enterprise (cloud, legacy, IoT etc.), and giving them access to more data.
You can integrate Kafka clusters at the edge of Solace PubSub+ event mesh, with Solace Kafka Source and Sink Connectors.
Kafka Connect Source Connector
The Solace Source Kafka Connector for PubSub+ Connector uses the Kafka Connect API to consume Solace queue or topic data events and stream them to a Kafka topic. The Solace Source Connector uses Solace’s high-performance Java API to move Solace data events to the Kafka Broker. Solace PubSub+ supports popular messaging APIs and protocols like AMQP, JMS, MQTT, REST, WebSocket and more so the Connector can move any message to a Topic (Keyed or not Keyed) on the Kafka Broker. [Learn More]
Kafka Connect Sink Connector
The Solace Sink Kafka Connector for PubSub+ uses the Kafka Connect API to consume Kafka topic records and stream the data events to the Solace PubSub+ event broker as a Topic and/or Queue data event. Therefore, from the single Solace Sink Connector any Kafka Topic (Key or not Keyed) Sink Record is instantly available for consumption by any consumer that uses one of the Solace-supported open standards languages or transport protocols. [Learn More]
Learn About Messaging
Messaging refers to the set of concepts that lets computer systems, applications or services share information without requiring coupling or awareness of one another’s location.
- Publisher: the entity that sends or publishes the Message - Also called Producer
- Message or Event: what the Publisher wants to say to the Subscriber
- Subscriber: the ultimate receiver of the Message or Event - Also called Consumer
- A Message typically has a destination that decouples the Publisher from the Subscriber
- A destination can be a Topic or a Queue:
- Topic when the Message is intended to be consumed by more than one Subscribers
- Queue when the Message is intended to be consumed by at most one Subscriber
- The idea is that we should try to keep the coupling between classes in our systems as 'loose' as possible: hence 'loose coupling' or sometimes 'decoupling' (although in English 'decoupling' would mean 'no coupling at all,' people often use it to imply 'loose coupling' between entities)