We are implementing the event mesh feature right now. In my previous organization, we used the event mesh. Solace DMR, which is its dynamic message routing, and their event mesh capability is one of their unique selling points. It's a stand-out, a distinctive capability and a differentiator. It is a great feature and, honestly speaking, it is one of the biggest differentiators they bring to the table, compared to many of the message broker platforms or event broker platforms that I have used in the past.

In my assessment of Solace against other products — as I was responsible for evaluating various products and bringing the right tool into companies in the past — I worked with multiple platforms like RabbitMQ, Confluent, Kafka, and various other tools in the market. But I found the event mesh capability to be a very interesting, as well as fulfilling capability, towards what we want to achieve from a digital-integration-strategy point of view. It's distributed, yet it is intelligently connected. It can also span and I can plug and play any number of brokers into the event mesh, so it's a great deal. That's a differentiator.

It is completely self-sufficient when it comes to connecting the brokers together because it uses a proprietary protocol over the TCP layer. It is a Solace messaging protocol and it is not very difficult to configure it and use it. It is easy to use, easy to configure brokers and to connect them all together. 

From an administration point of view, Solace gives us a visual view of all the brokers in there. The capability of spinning up a broker and connecting it visually is still in progress in their roadmap. But, technically speaking, if somebody knows the administration of Solace very well, they can actually spin up a broker easily, either on a cloud or on-premises, on Kubernetes or on Docker, and can quickly connect them all together, and it starts showing up in their portal. It is pretty straightforward and pretty easy to implement. Here, we have been able to quickly set up the basic mesh architecture for the sandbox environment. It's straightforward and pretty cool as well.

Another feature and selling point of Solace is that it promotes and uses open standard protocols like SOAP or REST. We use AMQP in some scenarios and there are multiple other ways that we could connect as well, including JMS and TCP. There are five or six different ways that we could integrate with other inter-operating, distributed applications within our enterprise. Since Solace supports all of these open, standards-based protocols, it is pretty easy to connect.

It is also pretty simple to manage. The two major standout points are a very simple architecture and that it's a lightweight middleware platform. You just spin up somewhere and connect. On the top layer there is a single pane of glass to monitor and to keep the checks and balances in place, and also to administer from a cloud platform. That's a pretty simple, straightforward setup, like any cloud-based or middleware platform. The model that I have for MuleSoft in my company is the same thing for Solace as well. I would rate it as simple and straightforward.

I would rate Solace's ease of management better than competitive or open-source solutions, because they have brought thought leadership to the table for looking at event management and building a complete life cycle view of an event. Right from the time an event starts in the company, until the time that the event has to be retired, it goes through a life cycle. That includes discovering an event, designing the event, adding certain rules to it, configuring it, and deploying it. Finally, you'll want to monitor and operate it. The whole life cycle is completely manageable using Solace's UI. That is a great deal. None of the competition has brought that view to the table yet. This is another distinctive differentiator that Solace has.

In terms of the solution's topic hierarchy there are two ways to look at it. One is that there are particular topics that we set up and that are very static in nature because we know about their data already. For any other areas that are fixed, it is pretty straightforward because the topic taxonomy is already agreed on. It is already aligned with the stakeholders and it is easily implementable in Solace.

The other side is that if a publisher chooses to dynamically post a topic  — a new topic — if they know what the topic taxonomy model looks like for our company, then it is also possible to dynamically put the topic in place and publish it, as it is. 

It also gives you wildcard-based routing rules. Based on the topic taxonomy and hierarchy, I am able to route a message or use the wildcards that are placed in the higher topic hierarchy to even put in security. If a particular group shouldn't see a particular message coming in on a topic, I can control that as well using the right topic taxonomy or the topic hierarchy. In Solace, that is also pretty straightforward because their topic taxonomy definition and the way that they promote it and the way that we have understood it from them is pretty easy.

Kafka has a different way of doing that. RabbitMQ is very similar to the JMS-type of message platforms. Solace is very similar and it supports both dynamic and static. The solutions are even, from that perspective.

The most useful features has been the WAN optimization and probably the HybridEdge, which requires some third-party adapters or plugins. The idea that we can position Solace as a protocol-agnostic message transport fabric is key to our company having all manners of asynchronous messaging protocols from MQ, Kafka, JMS, etc. I really like the WAN optimization: Send once over a WAN, then distribute locally as many times as there are subscribers.

I don't think we have yet unleashed the full potential of topic wildcarding. That is a silver bullet that we haven't yet maximized the value on because we don't have a ton of subscribers yet. Coming up with a topic naming convention in our large company has been difficult. However, once we start forking data over to some of our data lakes, enterprise data hub, and security event depositories, it will become a useful feature in the future.

I've been running messaging systems for most of my career, for over 17 years. The most valuable feature is the ability of the appliances to cope in a way that I haven't seen other vendors do. You always get into types of message-loss states that can't be explained with some other products that are out there. You raise tickets with the vendors and they'll give you an explanation. But in the 10 years that we've been in production with Solace, we've never had something that cannot be explained. I've got tickets open with the likes of IBM that have never been resolved, for years. The Solace product's stability is absolutely essential. 

There is also the ability to have so many things laid in, where we're doing guaranteed messaging and direct messaging laid into the same appliance.

There is also the interoperability. We've built a lot of products into it and it's been quite easy to feed market data onto the systems and put entitlements and controls around that. That was a big win for us when we were consolidating our platforms down. Trying to have one event bus, one messaging bus, for the whole globe, and consolidate everything over time, has been key for us. We've been able to do that through one API, even if it's across the different languages. We support a wrapper on top of the vendor's API and we enforce certain specifications for connecting to our messaging environment. That way, we've been able to have that common way of sending and sharing data across all the groups. That has been very important for us. 

In terms of ease of management, from a configuration perspective you can have all your appliances within one central console. You can see your whole estate from there. And you can configure the appliances through API calls so you can be centrally polling and managing and monitoring them, and configure them as you need to. There are certain things where that's a little more tricky to do, but at a general level we have abstracted things like user-commissioning into other systems. So we just have a front-end where we change the commissioning and push it to the appliance in whatever region and it updates the commissioning. From a central management and configuration point of view, it's been extremely easy to interact, operate, and support.

When it comes to granularity, you can literally do anything regarding how the filtering works. It has a caching product that sits on top of that, so depending on the region that you're trying to filter, caching level can make it a bit more difficult than the real-time streaming. But from a real-time stream, you can pretty much filter at any level or component and it's extremely flexible in that regard.

We like the seamless flexibility in protocol exchange offering without writing a code. This is probably the most useful feature of Solace apart from the structural Topic segments. 

Solace PubSub+ has understood and implemented the best features of multiple PubSub brokers. I have seen segmenting of topics in IBM MQ PubSub and have used that feature a lot. With such versatility, Solace has implemented one the most demanding PubSub broker, hence a PubSub+. It is a simple portal for event-driven architecture driving the entire microservices framework.

The valuable feature of PubSub+ Event Broker is the speed of processing, publishing, and consumption. 

The most valuable feature of PubSub+ Event Broker is the scaling integration. Prior to using the solution, it was done manually with a file, and it can be done instantly live.

PubSub+ Event Broker has a nice dashboard to see the domains and has good asynchronous API documentation. If you are a small or medium-sized company and not very rigorous on the compliance side, and you don't go for production issues on your own cloud, it's a very good tool to reuse.

Performance and stability were a absolutely key areas for us. Having a rock-solid appliance-based architecture with the support that goes behind it from Solace is the most valuable aspect of this solution. From our perspective, it's the background of Solace as certain network devices that have very low error. Tolerances are key for us. What separated them from other vendors, at least initially, was that the appliance option versus the commodity hardware was definitely a very important distinction for us. From a management standpoint being able to have a system, we can manage internally, and have access to keep that within our engineering group is key. We isolate it from our standard infrastructure and commodity hardware group.

If we had to deploy to a messaging platform that uses commodity hardware or converged infrastructure, the costs would be much higher for us, especially due to the certain internal cost. The appliance-based architecture is, at least initially, absolutely a big advantage for Solace. And on the other side, the support that we experienced with Solace as a company has been very positive.

Our background is primarily on the market data side where we deal with a lot of different vendors from Reuters, Bloomberg, very big systems as well as vendor appliance hardware. The support we receive from Solace is by far much better. It is the top of the market. The level of expertise in troubleshooting or identifying issues is absolutely key. 

Our messaging platform is the largest thing on our internal network, as the last messaging spike was close to 10 billion messages a day. We're very large consumers on the network. We need to have key exposure to everything that's going on within our platform. And when we do need to get Solace on the line, they know more than our network team does about troubleshooting; where our constraints are in the system and what's going on. I think those are the key advantages for us. Solace support is the best that I've experienced amongst any of the vendors that I deal with. The competitors I am referring to are TIBCO, Kafka, MQ, and EMS. They are messaging platforms that are on the ultra-low latency side, like Dell. We have various small installations and pockets of those various technologies everywhere, but compared to other vendors and database companies, Solace's response time is better. The depth of knowledge and the consistency of knowledge are far and away better than any other vendor partner that we deal with.

In terms of the ease of management, we have a very large deployment. We've globally deployed dozens of appliances in various data centers across North America, Europe, and Asia Pacific. Being able to manage that, we do require an organized team, good infrastructure, and support structure. Solace, as a partner, helped us in the initial installation to get to the point of doing the leg work and initial analysis to give us space to be successful with our deployment. It's a complex messaging platform. It is not a simple thing to do, but the tools and the support you get from Solace definitely enable you to be successful with that installation.

The topic hierarchy in terms of how dynamic and flexible it is is one of the initial definite benefits of Solace compared to other legacy systems. The ease of doing in-service upgrades and in-service deployments without affecting the environment was less key, coming from more legacy platforms where deploying any new topics, topic structures, and publishing structures wouldn't be allowed. It would force you to do system-wide restarts and involve every user on the platform. Whereas, with Solace being able to not only deploy up-to-date changes without any issues but being able to do so without impacting clients is an advantage. Similarly, upgrades and patches and things of that sort are much more seamless compared to the legacy systems that we supported in the past. Reuters to EMS were the systems that were displaced by Solace.

In terms of the granularity of the topic filtering feature, Solace was heavily involved from a professional services standpoint to help us define our topic structure and our topic hierarchy with ourselves and our architects for the initial deployment, being able to get that structure and helping define that structure. Only recently did we make some structural updates to enable more agile, cross-business sharing. But for the most part, it's been a very successful deployment of the topic hierarchy. It is flexible enough to allow us to use subscriptions and publishers. We have a strong process to make sure that folks are conforming to those topic structure formats but Solace was involved in the development of that structure initially and we have been pretty successful with it.

We do have Kafka deployed to serve some use cases in capital markets. We've evaluated it and continue to evaluate it. But from our perspective, the performance and scale that we have in Solace preclude a large scale deployment. It's also a platform that requires a significant commodity hardware installation along with that we are always going to be licensed while we use open source software and platforms. We always make sure that we're fully licensed from the support perspective. From a regulatory and risk perspective, it's something we always operate. It doesn't make a lot of sense to move there, also, given the layer of investment and performance that we have currently. In cases where certain vendors have out-of-the-box plugins with Kafka, we build connectors to allow them to publish onto our platform and that's worked seamlessly for us.

The most valuable thing for us is being able to publish a message, then have the ability to subscribe it on the fly. We want to democratize the usage of this going forward.

We are currently using the basic platform, and as we become more mature, I am particularly excited about using the Event Catalog. This was launched recently. There are certain features like event visualisation and event discovery which we want to see in action. It will take some time for us to make more events published on Solace. 

The software has been very good because:

1. You can spin off a Solace instance very quickly. 
2. Based on your requirements, there are various size levels, similar to t-shirt sizing. 
3. When we went to add another installation in our private cloud, it was easy. We received support from Solace and the installation was seamless with no issues. 

After publishing, we have seen the solution’s topic filtering go into approximately six levels, which is quite granular. These many levels are good enough. Also, the business payload lookup is supported.

The way we can replicate information and send it to several subscribers is most valuable. It can be used for any kind of business where you've got multiple users who need information. Any company, such as LinkedIn, with a huge number of subscribers and any business, such as publishing, supermarket, airline, or shipping can use it.

• The ability to publish data events in real-time to the broker.
• The ability to add multiple subscribers seamlessly to topics and queues using different formats and protocols.
• The Solace Admin Utility is pretty intuitive and flexible.

E.g., if you have to configure these manually, then the publisher of each event would have to manually configure these events to the topics, provide access, and do monitoring. All these activities would have to be done manually without a Solace Admin. The Solace Admin provides you a UI where any publisher with appropriate access can create their own topics and queues. It can also provide access to subscribers so they can administer their own events.

There is another feature where subscribers can easily discover different topics to consume. If they can find it, then they can, get access to it through the workflow in the Solace.

An advantage of Solace is the way they define their topic hierarchy. With the whole filtering on the topic, we are able to publish data to multiple systems without creating new topics fragments. For instance, if you didn't have that flexibility of the topic hierarchy and ability to do filtering, then you would have to create new topics for a different combination of data sets. This filtering ability creates a lot of flexibility in creating generic topics, where subscribers can just do a filter and consume whatever data they need. That's a powerful feature.

It's very granular. If you can define your topic schema with some order, then you can pretty much do whatever data set at the lowest level. It does provide a lot of flexibility that way without making any changes upstream.

The solution’s topic filtering, in terms of the ease of application design and maintenance, provides us flexibility. The solution makes it easier to consume data on same topic but also change the logic or filtering. E.g., if you want column one, two, and five from a topic schema today, but then you may decide the next day that you need column four and seven.

The solution's event mesh has the ability to make a network of brokers look/seem like a single broker. E.g., if you have consumers in on-prem, AWS, and Azure, along with some SaaS providers, external customers, or partners, you could have brokers deployed for AWS, Azure, and outside for external customers, respectively. If the publisher is publishing an event from on-prem, then they just publish the one event to the broker deployed on-prem. The on-prem broker will route the request to the AWS broker, Azure broker, and the external broker seamlessly. This is transparent to the publisher and consumers, which is a positive feature.

The event portal and the diversity of deployment options in a hybrid landscape are the most valuable features.

PubSub+ capabilities make it all work. 

Guaranteed Messaging allows for us to transport messages between on-prem and the cloud without any loss of data.

The solution’s topic hierarchy is pretty flexible and works well. It does require some engineering thought in the beginning to ensure that the hierarchy works and you don't shoot yourself in the foot. But if that is architected well, it allows for very nice filtering and subscription based on what you are interested in. 

The topic hierarchy's application design and maintenance works very well.

• Everything is good in this solution. We only use the PubSub feature. We use a minimum of topics to publish and they are consumed through the Solace message broker.
• We have a standard template for any new configuration, so it's very easy to manage.
• The topic hierarchy is pretty flexible. Once you have the subject defined just about anybody who knows Java can come onboard. The APIs are all there.
• Topic filtering is easy to use and easy to maintain. Sometimes we go into a lot of detail on the content and it can be affected at a higher level. So it's very flexible.

As of now, the most valuable aspects are the topic-based subscription and the fanout exchange that we are using.

It was easy to set up and implement.