Editor’s Note: The VMR (Virtual Message Router) mentioned in this post is now Solace PubSub+.
Let me share with you some good news for developers interested in trying out or getting started on the JMS standard based features of the Solace Message Router with Solace JMS: After installing and starting a Solace Virtual Message Router (VMR), it will now take you less than a minute to get from zero to having a working JMS sample code fetched from GitHub, all built and running to get your first JMS message exchanged with the Solace Message Router.
With the Solace APIs Now Available via Maven Central, the build will automatically pull down the required Solace JMS client libraries. Developers can get right to productivity focusing on their messaging applications. This is all you need to do to try out the Solace JMS Getting Started Samples, assuming you have a Solace VMR running, JDK and Git installed:
git clone https://github.com/SolaceSamples/solace-samples-jms cd solace-samples-jms ./gradlew assemble ./build/staged/bin/topicPublisher <VMR_HOST> Topic Publisher initializing... Connected. About to send message 'Hello world!' to topic 'T/GettingStarted/pubsub'... Message sent. Exiting.
To achieve this, I have recently updated the basic Solace JMS samples on GitHub with a developer friendly way to dynamically create JMS administered objects.
Administered Objects, a key concept in the JMS standard, are objects containing configuration information about a JMS provider, in our case the Solace message router, to be used by JMS clients. The standard defines two objects: ConnectionFactory for creating connections and Destination for addressing topics and queues.
When using Solace dynamic mode, there is no need to administratively provision these objects on the Solace message router – it is enough to programmatically create a ConnectionFactory, Topic or Queue as Java objects in your code, set the required properties and they are ready for use for messaging.
At its heart, it is matter of instantiating the Solace implementation of a javax.jms.ConnectionFactory object and enabling dynamic creation of the necessary objects on the router:
SolConnectionFactory cf = SolJmsUtility.createConnectionFactory(); cf.setHost(“myHost”); cf.setDynamicDurables()=true; // To create physical objects on the router as needed Connection connection = cf.createConnection(); …
For developers using the Solace message router, this is a simple way to create and use a connection factory, which doesn’t require any configuration on the router side. The updated Publish/Subscribe and Persistence with Queues JMS samples provide more details.
The Solace message routers support multiple ways to create and customize connection factories to unlock unique Solace messaging features. Let me summarize further options for you and if you want to learn more, the new Obtaining JMS objects using JNDI tutorial provides all the details in an easy to consume format.
Of course, the JMS standard way of provisioning administered objects on the JMS message broker and using JNDI lookup of the pre-configured connection factories and destinations on a JNDI standard compliant server is also supported.
What the Solace message router adds here is that it has a built-in JNDI store that will publish the provisioned objects, making provisioning a one-step process and allowing the configuration and publishing of Solace specific properties at one place.
As an alternative, it is still possible to use a third party JNDI store, such as an LDAP server to lookup JMS objects.
Once the SolConnectionFactory object has been retrieved, it can be also customized to unlock Solace message router features by setting JMS properties.
Let’s start experimenting! I encourage you to start exploring by setting up your own VMR if needed, then trying out and building upon our JMS samples, which make it easy to learn basic JMS/JNDI or prototyping advanced functionality with the Solace message router.