I recently wrote a series of blog posts that introduced the elements of Solace messages including message header properties and how to encode data in the payload. Now I’d like to dig a little deeper and talk about using text messages in Solace. Text messages offer more than just simple string transfer: common formats such as JSON and XML allow the transfer of complex data as strings with readily available libraries to write, read and parse the data for you.… Read the rest
An incident at one of our investment banking customers prompted me to write this blog. Solace was recently called for help when one of their application silently died. Solace has made High Availability (HA) & Disaster Recovery (DR) very simple and built into the product itself. The objective of this blog is to help the reader understand those capabilities, how to set them up including configuration of things like reconnection attempts and timeouts.
I have used Java as the programming language. If you’re using another programming language you’ll want to refer to the appropriate user manual.
What is HA and DR?
- High availability (HA) Two Solace message routers can be configured as a redundant pair, so that if one of the two is taken out of service or fails, its mate automatically takes over responsibility for its clients. This redundancy is largely transparent to clients and other Solace message routers in the network.
In an earlier post, I provided an overview of logging in applications using Solace messaging, different types of logging facilities available in Solace as well some recommended events to log in your application.
To recap, Solace provides implicit logging facilities in terms of API logging and Solace message router logging. As an application developer, you should equip your code to handle and log the following:
- Asynchronous Events
- Solace Exceptions
In this post, I will cover those in more detail along with code snippets to handle them. I will use JMS and Java APIs for illustration. These are, however, not complete class definitions. Please refer to the sample code bundled with the Solace API package for working samples.
Some of the code snippets and sample events discussed here may require a deeper understanding of Solace concepts. I will cover some basic Solace concepts as the discussion topic requires. You can learn more about the core concepts and features of Solace technology on the Technology page.… Read the rest
In the first post of this series I introduced the structure of Solace messages, and in part two I talked about how Application Header and User Defined Properties can be used to decorate messages to aid processing the message data. Now it’s time to talk about how the data itself is structured – how to put the payload in the message.
Don’t I Just Add the Data?
At first glance this question seems trivial: don’t I just put the data in the message? That’s the point of a data agnostic messaging system, surely? Well, yes… and no. I hope you weren’t expecting a different answer!
Solace Message Routers will transport whatever data you choose to put in your message (provided it fits within the maximum message sizes, 64MB for direct and 30MB for guaranteed) But there are other considerations:
- Is your network heterogeneous? For instance, are mobile devices part of your messaging infrastructure?
Logging is an important element of the application development process, but not always given the attention it deserves. As a developer, there are various types of logs that you will need to handle in the application such as: logs related to business events, operational conditions, user interaction, exceptions, debug logs, etc. In this blog post I will discuss logging related to Solace messaging and how to handle them effectively in your application.
I will present a general overview of application logging in the context of Solace messaging first, followed by other implicit and external logging facilities available in Solace. I will follow this up with another post with code snippets and config files to handle logging in the application.
This post assumes working familiarity with basic messaging concepts and Solace features. You are encouraged to visit the Solace Developer portal to familiarize yourself with Solace concepts.
To log or not to log, that is the question!… Read the rest
The first post in this series introduced the basic elements and properties of a Solace message. As explained in that post, Header Properties are manipulated by API functions. Some header properties are used by Solace message routers when routing messages, the most obvious being Destination.
Application properties are used to help applications process message payloads or to provide a way of exchanging header properties between different messaging protocols – from JMS to Solace Message Format (SMF), for instance.
Other application properties within the header provide a very easy and simple way to add often used data to a message. There is also the option of adding user-defined message header fields to a message.
And, of course, normally you would put the data in the payload- more details on payload encoding in my next post.
This post briefly reviews which header properties are available, and then talks about when you should put data in a header property versus the payload. … Read the rest
One of the main advantages of Guaranteed Messaging (a.k.a. Persistent Messaging or store-and-forward messaging), is that a receiver does not have to be available for the publisher to send messages as the Solace Message Router will persist the messages until the receiver becomes available again. The publisher is guaranteed that a message is successfully persisted by the Solace Message Router once it receives an acknowledgement for the message it sent. Persistence increases reliability but does add some overhead compared to Solace’s Direct Messaging, which provides no acknowledgments to the publisher.
Despite this overhead and the round trip times of acknowledgements, Solace Message Routers provide a high throughput rate for Guaranteed Messaging publishers. This high performance is enabled in the SMF protocol through the use of a Publish Window. In this post, I will introduce you to the concept of Publish Windows and their sizes, and how acknowledgements affect these windows. We will also look at when and how to adjust the sizes of the Publish Window using Solace’s Java API.… Read the rest
It’s a fairly obvious statement that a message contains a header and a payload, the header being used to direct a message to its destination(s) with the payload being the data to be consumed.
Some message formats (for instance Solace Message Format, SMF) allow user properties to be added to the message, along with the header, or for structured data types to be added to the message. When should these be used, and how? How should the payload be encoded? As a developer, how do I access message properties?
This series of blog posts will examine some of these details, looking at message structure, user-defined header properties, options for payload encoding with things like JSON, Google Protocol Buffers and Solace options like structured data types. … Read the rest
In this blog post I will take you through the steps necessary to get a Cloud Foundry application up and messaging through a Solace messaging router. To keep it simple, I’ll use a Cloud Foundry user provided service to feed the application the Solace message router credentials. And for this post, I’ll use a Java based Spring Boot application, however the concepts are transferable to any language.
I’m going to assume you’re a little familiar with application design for Cloud Foundry. If you’re not then a reasonable place to start is the online Cloud Foundry Developer Guide. It walks through the basics of preparing a cloud application, deploying and managing this application, and how to use services to access application resources.
I’m also going to assume you’re also familiar with the basics of Solace messaging. If you are new to Solace messaging, you can check out the Get Started guides for a walk through of basic Publish/Subscribe and much more.… Read the rest
This blog post continues from my previous post where I introduced the On-Behalf-Of (OBO) subscription manager application architecture. In this post, I’ll show you the basic code required to get this application pattern working. To do this I will show you a basic client application and a subscription manager application which can subscribe on behalf of this client. The picture below gives you an overview of this pattern as a refresher. Jump back to my previous post if any of this is new to you.
To get the most out of this blog post you should be familiar with the following things:
- You are familiar with Solace core concepts.
- You are familiar with the mechanisms of publishing and consuming direct messages as detailed in the publish/subscribe tutorial.
- You have read my blog post explaining the purpose of an OBO Subscription Manager.
- You have access to a running Solace message router with the following configuration:
- Enabled message VPN