Workflows with JMS messaging

Workflows with JMS messaging

Last several years there is a lot of buzz about Apache Kafka, Apache Pulsar and in general about event streams. But looking into lots of organizations they are in many case still relying on "old good traditional messaging". To give one example of that, IBM MQ is very popular within small, medium and big enterprises to realize messaging between systems.

While event streams are starting to play bigger role in integration, there are still big opportunities to build systems and services based on traditional messaging. In Java world, JMS is an excellent solution to that. Majority (if not all) Java frameworks for building services have support for JMS such as Spring, Quarkus, Jakarta EE application servers and many more.

Automatiko introduced support for messaging from the very begining where Apache Kafka and MQTT were the first ones. Next support for Apache Camel has been added and with latest release (0.11.0) AMQP and JMS joined the club. The good thing about messaging support in Automatiko is that it is hidden behind the workflow abstraction. Regardless what messaging you want to use you work with them exactly the same from workflow definition perspective. Of course there will be additional options available depending on connector used (e.g. MQTT will allow to dynamically select topic where to publish message etc) but overall way of working is the same.

JMS is no differnt in this conctext, actually JMS support was added based on real life project that expressed a need for that. A typical integration scenario for JMS can be sumarized like this:

System A is master data for Part information, System B is driving after sales portal that requires access to latest part information. Part as entity is described with XSD schema as part of the cannonical data model and is part of the overall data management of the organization. System A publishes information about new or updated parts on a JMS destination (queue or topic) then System B receives these messages and updates its own data store. Messages are in XML format based on XSD schema.

So this is really a simplifed example of the use case but it is not uncommon to deal with such integrations. Workflows are starting to gain traction to cover this use cases because they are not only used to consume or produce messages but associate these messages with entities of the system that they are part of. For example each part in System B is an entity that has defined life cycle, this life cycle is actually defined as workflow definition. Meaning each and every part will be driven by a workflow instance. This clearly identifies what can happen to the part and at any point in time can be viewed about history of the changes to given part - as simply as looking at the workflow instance execution trace.

JMS comes with various features like message properties, priority of messages, selectors and many many more. All of these can be easily used from within the workflow definition to gain more control how messages are produced and consumed. One of the most interesting features are message selectors. It can be easily defined on the message event of the workflow definition and by that it will only consume messages that match this criteria.

Similar on the producer side, messages can be associated with custom properties or different priority can be set on the message.

Additional information about JMS messaging support can be found in Automatiko documentation

Lastly, a short video about JMS messaging with workflows in action can be watched below.

The source code of shown example in the video can be found here

Thanks for reading and make sure to drop us feedback or ask questions about this article.

Photographs by Unsplash.