Getting Discovery Groups to Work Locally in Artemis

This is less a detailed post and more a PSA for setting up Apache ActiveMQ Artemis on your local machine. Specifically, if you're trying (and failing) to get Discovery Groups to work. Hopefully it saves someone out there a sleepless night or two 😀

Artemis Discovery Groups let one cluster brokers in a way that is more dynamic than manually cobbling them together using explicit IPs or hostnames. This then opens up the possibility of being able to more fluidly change your network topology rather than having to "rewire" the servers everytime something changes.

Excited?! So was I when I decided to download this example, and see discovery in action. So I set it up and ... nothing worked. The brokers couldn't find each other, no cluster, unhappy days. So what gives?

Well, one of the ways Artemis does discovery is to broadcast group information using UDP out to anyone that may be interested. This is fine when you have several distinct machines all listening for traffic, but it won't work if both brokers are on the same machine because it generally doesn't make sense for a device to listen to its own traffic. So how do we make our machine talk to itself (besides reducing its dose of anti-psychotic medication)? Simple, following this guide, you set your chosen discovery multicast address to be looped back.

#you should run this as root
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo

How Do I Know It Worked?

If you've configured your cluster correctly, and enabled the loop-back described above, then you should see the brokers in your cluster log something similar to the following:

(...other logs...)

14:21:32,104 INFO  [org.apache.activemq.artemis.core.server] AMQ221027: Bridge ClusterConnectionBridge@27cc737b [name=$.artemis.internal.sf.my-cluster.e3a0a8ca-b3bc-11e7-a812-28b2bddf2e01, queue=QueueImpl[name=$.artemis.internal.sf.my-cluster.e3a0a8ca-b3bc-11e7-a812-28b2bddf2e01, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=69705a0c-b3b6-11e7-b87c-28b2bddf2e01], temp=false]@634dabfa targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@27cc737b [name=$.artemis.internal.sf.my-cluster.e3a0a8ca-b3bc-11e7-a812-28b2bddf2e01, queue=QueueImpl[name=$.artemis.internal.sf.my-cluster.e3a0a8ca-b3bc-11e7-a812-28b2bddf2e01, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=69705a0c-b3b6-11e7-b87c-28b2bddf2e01], temp=false]@634dabfa targetConnector=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=netty-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61616&host=0-0-0-0], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@555273695[nodeUUID=69705a0c-b3b6-11e7-b87c-28b2bddf2e01, connector=TransportConfiguration(name=netty-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61617&host=0-0-0-0, address=example, server=ActiveMQServerImpl::serverUUID=69705a0c-b3b6-11e7-b87c-28b2bddf2e01])) [initialConnectors=[TransportConfiguration(name=netty-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61616&host=0-0-0-0], discoveryGroupConfiguration=null]] is connected

(...more logs...)

Connecting BusinessWorks 5.x to ActiveMQ

I was all set to detail connecting BusinessWorks (BW) 5.x to ActiveMQ, but someone got there first. My only minor edit to the tutorial would be to add that the JAR to be included in your BW project's classpath has changed from activemq-core-5.7.0.jar to activemq-all-5.xx.x.jar.

Note: ActiveMQ cannot understand Tibco EMS specific acknowledgement modes like Tibco EMS Explicit.

Why connect BusinessWorks to ActiveMQ?

As to why you would want to connect the two technologies - it can be strategic. 

Suppose your enterprise is heavily invested in both Tibco BusinessWorks and EMS, but would like to migrate to a more modern, open-source backed integration stack. Where do you start? Especially when:

• Rewriting all your BW applications takes time, money and retraining.
• The day to day business cannot be halted waiting on all application rewrites to conclude.

In these cases, often the least disruptive path forward is to realize that both EMS and ActiveMQ leverage the JMS API. Consequently, one can almost be a drop-in replacement for the other. This offers a low-risk entry point into migration: The BusinessWorks applications need only be configured to communicate with ActiveMQ rather than EMS, with all other code and messaging formats remaining constant.
Once messaging is replaced, the enterprise can take their time planning the larger task of deciding which applications to modernize, when and how.

I Transitioned From Tibco BusinessWorks to Apache Camel (And You Can Too!)

Working in technology is hard. With the multitude of languages, APIs, protocols and other buzzwords out there, it's easy to just kick back and surf the wave of complacency - unfortunately I live in the midwest and can't surf to save my life. Thus it was that after more than 11 years of working in Tibco Businessworks I became a bona fide Apache Camel developer. Of course, I was in for a rude awakening when I realized that not all integration involved dragging and dropping pretty pictures around. In my journey to learn Camel, 3 things became abundantly clear:

1. To my detriment, Tibco Businessworks had insulated me from modern integration technology & practices.
2. Apache Camel was unlike anything that I had ever seen before - in a good way.
3. Apache Camel was an incredibly powerful and significantly more versatile than anything BW had to offer at the time, and since.

During my transition, I would have given my right arm for a resource that allayed  some of the confusion I felt in learning Camel; guide posts that explained this new technology to me in terms of my beloved BusinessWorks. I never found one, so following my new found Open Source spirit, I wrote one! :)

This post is not a detailed compendium of all the differences that exist between BW and Camel, those would fill a small shipping container. Nor is it meant to supplant a good old fashioned "Hello World" tutorial. It is meant more as a highlights list, calling out the major road blocks that I encountered during my transition. I share this in the hopes that others following a similar path find their journey to be an easier one.

BusinessWorks (BW) versus Apache Camel

Lets jump right into it. Figure 1 shows the same application written in both languages, it:

1. Starts on a timer
2. Writes data to a file
3. Ends

Simple enough, but it serves as a good starting point for comparison.

Note: The images are taken from BW 6.x and Apache Camel 2.15 running on Red Hat JBoss Developer Studio (JBDS).

Figure 1: Tibco BusinessWorks vs Apache Camel

#	BusinessWorks	Camel	Notes
1	Process	CamelContext.xml	Both Processes and Camel Contexts encapsulate your integration code. However: Unlike BW, every application/project can have only one Context - all your integration workflow goes in this one file.
2	Workflow	Routes	A route is where you do the actual integration work in Apache Camel.  A given Camel Context may have multiple routes.  Routes are the closest analog Camel has to BW subprocesses.
3	Start Activity	From	N/A
4	Arrow Transition & next activity	To	N/A
5	Palettes & Activities	Components	BW has a handful of activities available with which to perform integration while Apache Camel has on the order of 200+ different ways in which to integrate. This was one those "wow" moments for me.

Additional Topics of Note

Aside from the basic differences above, there are several other aspects that I believe a developer should be comfortable with before embarking on (a) Camel.

Topic	BusinessWorks	Camel	Notes
Message Flow	Activities hold state	The message Exchange hold state	This can be a doozy for developers initially - I know it was for me. In Businessworks, your activities are isolated and stateful. n Camel, the various components pass around a message exchange, which is a stateful object that tracks changes made to it. Everything your code does happens to this one object. It is imperative that a developer become accustomed to thinking from the perspective of this exchange object. To contrast the two approaches, consider what happens when I make a web-service call from both technologies. In BW, whatever I do leading up to the web-service call is persisted in the activity (e.g. a Mapper doesn't suddenly lose its mappings just because I made a web-service call) In Camel, if I don't save my previous work and make the web-service call, all that work is lost.
Build	buildear.exe	Apache Maven	Unlike BW, Apache Camel projects are built using Maven. This part took a little getting used to for me since buildear.exe did everything explicitly, while Maven seemed to automagically know how to compile my code. If you are not familiar with Maven, I would strongly suggest familiarizing yourself with it before proceeding further. N.B: While it might be possible to intergrate BW with Maven, it isn't an officially supported configuration.
Managing Imports	Projlibs	Apache Maven	Again, the biggest challenge for me here was acclimating myself with how Maven seemingly resolved my dependencies auto-magically, rather than explicity (i.e. full path) as was the case with BW projlib files.
Coding	Tibco Designer	Any Java-friendly IDE	Take your pick: JBDS, Eclipse, IntelliJ,... Although BW 6.x has finally shifted to Eclipse, the majority of enterprise BW developers are versed in BW 5.x which only offers Tibco's own Designer tool. Be sure to also brush up on your fundamentals of Java and OOP. This is one of those areas that BusinessWorks lets you conveniently forget about since so much is done for you.
Enterprise Integration Patterns (EIP)	No concept of EIPs	EIPs are a language construct	Camel was built on a foundation of EIPs. Anyone embarking on learning it should make an effort to understand what EIPs are.
Language	Proprietary XML (code behind)	Many	Camel applications can be written in any number of actual programming languages, with arguably the most popular being Java and XML.
Development Style	Visual: Drag n' Drop	Text  (can be Drag n' Drop)	Developing in Camel is still primarily textual - no more palettes or activities. While Eclipse and JBDS offer a graphical IDE for Camel development, you'll want to switch to text as soon as your applications start growing.
Dependency Injection	N/A	Useful for XML	Dependency Injection or Inversion of Control is an interesting development paradigm that took me a while to learn. If you choose to use the XML approach for writing Camel, it is worth understanding IoC. Again, this was one of those areas where I felt staying with BusinessWorks for as long as I had put me at a disadvantage - because not Tibco technology used IoC, I never needed to learn it.
Deployment	EAR on Tibco Administrator	Many Options	You are no longer bound to bwengine.exe and Tibco Administrator. Camel applications can be deployed as standalone instances, on ESBs such as JBoss Fuse, and application servers like Jboss EAP. How you deploy will depend a great deal on the platform you're developing for.
Getting Things Done	Generally one "right way"	Multiple approaches	This was an epiphany for me personally and a theme throughout Camel: There are a myriad of ways to achieve your goal, and, more often than not there is no one over-arching correct answer. Get comfortable with this fact, and select the approach(es) that resonates with you for solving the problem at hand.

So that's it! Not at all painful right :)
Armed with this knowledge you should be able to streamline your transition from BW to Apache Camel.