It is pretty clear when I read the new 11.6 docs that the generic JMS support is limited to "broker connect":
"Note: Generic JMS Adapter supports only the BrokerConnect mode."
Can someone help me understand why the "client connect" mode isn't supported yet and whether it is likely to be supported some day? I thought "client connect" was analogous to "broker connect" and simply launched a "symbiont" adapter for each ABL client (instead of having to work thru a centralized "adapter-broker" within the bureaucratic "Progress Explorer Framework").
IMO, the act of sending a message to a remote JMS provider should be as simple as possible. While its not perfect, the "client connect" mode of sending and receiving messages is conceptually a lot more simple and easy to manage than broker connect.
When connecting directly to a JMS provider from the ABL client via "client connect", there is one less "adapter/broker/middle-manage-er" that needs to be configured and maintained. And ultimately we end up with one less point of failure (a very, very good thing for messaging). Many years ago when we transitioned our Sonic MQ messaging from "broker connect" to "client connect" we saw overall messaging failures decrease dramatically. And when there are occasionally failures (in the JMS-aware "symbionts" ), they are NOT SYSTEM-WIDE (!!!) but local to specific ABL client(s). It means fewer urgent calls to restart the "Progress Explorer Framework (adapters/brokers/etc).
With "client connect", any JMS-related problems that come up are normally solved on their own by quitting the ABL client (triming servers on the app server agents, or whatever).
I am very hopeful that we will eventually see a "client connect" option for generic JMS messaging. This will allow us to finally migrate away from the pricey Aurea product.
Thanks for helping me dig into the reasoning for this. I didn't realize that there was a difference in the features supported by broker connect vs client connect.
But we had found many other great benefits in using client connect, as I had hinted at earlier. The prerequisites are fewer, management is easier, system is overall more resilient (ie. no system-wide outages, and feels like one less point of failure than broker connect), etc.
Regarding prerequisites for client connect:
This is off the top of my head, and I don't know if this is 100% technically accurate but it feels like the prerequisite "client connect" are simply to do as follows:
I think it is normally possible for an ABL solution to be deployed with client-connect" functionality *without* needing any configuration overhead or system-level admin privileges.
It doesn't feel right that any ABL can't simply connect directly to a JMS provider without jumping thru the intermediate hoops. The existence of a "JMS adapter" in your Progress Explorer Framework" feels extremely bureaucratic. I expect it is an optimization (reduces the initial launch time of the "symbiont ", and reduces memory utilization), but for us it certainly introduced more problems than it solved. I wouldn't want to go back to that again. If/when there needs to be any optimizations, we can do them on our own (eg. determine when ABL client programs shouldn't talk directly to a broker but go thru a database table first).
We would be very happy to start testing your generic JMS functionality right away, if we had some prospect of doing "client connect" once we get to production. We have been looking for a way to get out of the Sonic MQ product for quite a while.