Messaging with a generic JMS provider using client-connect

Posted by dbeavon on 07-Dec-2015 09:31

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.

All Replies

Posted by David Cleary on 07-Dec-2015 09:54
The reason we did ClientConnect and ServerConnect for the MQ Adapter was to support fault tolerant functionality in SonicMQ. Since that functionality can not be supported in the generic adapter, there is little reason to support these modes in regards to the effort to develop, test and support this.
 
Thanks
Dave
 
Posted by dbeavon on 07-Dec-2015 10:37

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:

  • ensure that a version of the Java runtime installed that is compatible with your JMS client libraries,
  • put the JMS client libraries in the classpath,
  • optionally tweak [Adapter.CC] in JavaTools.properties if needed, and we're off ! ...
  • (... this is based on my recollection of the the Sonic MQ provider, and there may be a bunch more setup work I'm overlooking for your new generic JMS)

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. 

Posted by David Cleary on 07-Dec-2015 11:29
Your best bet would be to work with Product Management (Rob Straight) to get it on the roadmap.
 
Thanks
Dave
 
This thread is closed