Solace makes it easy to implement production-ready microservices using Spring Boot and Cloud Foundry.
Write Once, Run Anywhere (WORA) was a slogan coined by Sun Microsystems to illustrate the cross-platform benefits of Java.
While in many cases Java lived up to this promise, today we need to Write Once, Deploy/Scale Anywhere.
The bane of many developers (including myself) is the inability to inject operating environment properties into applications. This problem becomes even more pronounced when trying to develop production-ready microservices in the most agile way possible.
Why? Simply put, there are external dependencies (such as messaging) whose information can only be known at runtime.
Imagine creating a simple Spring Boot application that runs on your laptop. This application receives product information from a JMS Queue, does an inventory query and republishes the data to a JMS Topic. Everything works fine so it’s time to integrate it into your Cloud Foundry development environment and let it live in the broader enterprise ecosystem.
I’ll explain by way of example. A few weeks ago I was developing some microservices. I had all the JMS connection properties in a configuration file (application.xml) but needed them to be dynamically injected at runtime by Cloud Foundry (VCAP_Services). Since I was using Solace as my message broker, I was able to use Solace’s Spring Cloud Connectors to look up these values in runtime.
Perfect right? Not quite.
Later that week, I was flying to a customer engagement and the airplane WiFi was so slow I couldn’t use Cloud Foundry. I needed to make progress on my Spring Boot application, so I turned back to my laptop development sandbox which did not have Cloud Foundry… 30 minutes of code modifications later, I was back to using the Solace Spring Boot Starters and able to develop again, but faced a nasty conundrum:
Do I write my application to use properties files or Cloud Foundry?
This deployment dependency revelation had shattered my Write Once, Deploy Anywhere dreams.
All I wanted was to fall back to using a properties file if I was not deployed to Cloud Foundry… and of course not have these time-wasting code changes ever again!
The Solace development team took this feedback and made my dreams come true!
Our Spring Boot Starters now have support for not just properties files, but also Spring Cloud Connectors. Essentially, we check for the existence of VCAP_Services and if it does not exist we fall back to looking for a properties file which defines our URI, Username, Password, etc.
If it does exist, we take advantage of Spring Cloud Connectors to look up these values out of VCAP_Services. All of this is done under the covers in our solace-jms-spring-boot-autoconfigure (or solace-java-boot-autoconfigure if using our jcsmp API).
Pretty slick since it realizes the dream of Write Once, Deploy/Scale Anywhere!
The other key benefit the solace-jms-spring-boot-autoconfigure option provides is the ability to seamlessly integrate into Spring’s JMS framework so that you can focus on writing business value (not JMS boilerplate).
All you have to do is have the requisite Spring (spring-jms) and Solace (solace-jms-spring-boot-autoconfigure) libraries in your classpath and use the @Autowired annotation for a JmsTemplate for sending messages or @JmsListener annotation for receiving.
These new capabilities in our Spring Boot autoconfigure implementation are key to our upcoming support for Spring Cloud Streams.
Stay tuned for that announcement and know that Solace has your back if you’re a developer working to create production-ready microservices!
***
Learn on-the-go with our latest guide about event-driven microservices:
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.