Generic JMS provider for JBOSS AMQ

Hi David,

Apache Artemis internally uses JBOSS HornetQ messaging system which does not have setBrokerURL() method. Already this issue addressed in OE 11.7.1 release. From 11.7.1 onwards user is able to connect HornetQ and Apache Artemis brokers without any problem.

So far we have certified the following MQ Providers.

1. Apache ActiveMQ

2. Apache Artemis

3. JBOSS HornetQ

4. IBM WebSphereMQ

Hope this helps!!

Thanks,

Anand.

Thanks for the quick feedback.  

You left out Sonic MQ in your list of certified providers.  Did you kick them off the island?   You probably should, considering what they are charging for a support contract to do simple messaging. ;)

What can we do to get this into 11.6 service pack 4 that is supposed to be released shortly?  We are a couple months away from a production upgrade to OE 11.6.4 (from OE 11.3) and we aren't likely to be using 11.7 for several years.

Also, what did you change to allow for the use of Jboss?  Did you write your own custom connection factories that wrap around the "real" ones?  Or did you extend the jmsprovider configuration to allow us to specify the *method* names used for each of those different connection factories?  Or perhaps JBoss finally agreed to add your "setBrokerURL()" method to all of their JMS client libraries? ;)

It is unfortunate that messaging/integration changes like this would require a full upgrade to the installation of OpenEdge...  I understand that Progress is adopting "agile" practices for developing new versions of OpenEdge; but it really doesn't seem very "agile" at all that we can't use the Jboss qpid-jms client until after we upgrade to 11.7.1 - several years from now.  This type of change (switching messaging client versions) would not be so difficult for us to make in some other ecosystems like .Net or Java.  

Depending on what you had to do to get Jboss up and running, we would be very open to attempting a similar thing on 11.6.  Please let me know.

Many still use SonicMQ.

SonicMQ from Aurea Software is alive and well. Sometimes when we think of support for "generic" JMS providers, we overlook SonicMQ as it adds additional value like guaranteed message delivery on top of the "generic" JMS standard. But clearly it is on our list of supported JMS vendors.

We have not tested the Qpid JMS Client (we are not able to test every JMS provider in the marketplace proactively). It is based on the AMQP (Advanced Message Queuing Protocol), which specifies the wire protocol used when sending messages. It is JMS compliant, so it could/should be something that our generic JMS adapter can handle. Like other JMS providers that we have not tested but that our customers are interested in using, we will look at issues that come up and do our best to resolve them. It would be best to raise this as a bug with our Technical Support team to get this looked at "officially".

A comment on "agile"- we do follow the Agile development methodology, and we do have examples where we have rolled out new capabilities rather quickly. Our customer base in general is not interested or equipped to take on a continuous stream of new features that a pure Agile methodology could supply- we heard that loud and clear when we did 3 releases in one 13-month period (11.1, 11.2 and 11.3). While we are now on a roughly annual release schedule, we can and do put enhancements into selected Service Packs as needed by our customers. In this particular case, the issue is likely to be considered a bug vs. a feature enhancement, which gives us more flexibility in resolving the issue (including the possibility of a Hot Fix if warranted by the circumstances).

Rob, thanks for the feedback.  I really appreciate it.  

There are a variety of things that make it hard to do messaging in OE, but I see that I should probably work with tech support.  Another issue with OE messaging is that many JMS providers are only supporting the Java 8 JRE and OE 11.6 is still shipping Java 7 by default (I learned that OE system admins are allowed to upgrade to 8 on their own but I suspect many of them wouldn't or couldn't).  I think Oracle itself stopped offering Java 7 in mid 2015.

Provided that we address the Java JRE issue first, do you think a custom JDNI admin object finder would help me get "qpid-jms" up and running on 11.6?  I saw stuff about this elsewhere (community.progress.com/.../24580 ).  I think the JDNI object finder avoids the need for specially named methods like "setBrokerURL".  But this might be more work than we would want to tackle in-house, especially without full Progress support.  I really wish OE had a larger open source community where we could find existing OE/broker integrations for a larger set of JMS clients.  Or maybe Progress should start taking requests for new custom (free) messaging integrations, no matter what the version of OE is, or the back-end broker, provided that the client uses JMS.  I doubt it would get too far out of hand.

However, now that AMQP is here, I think Progress OE may want to go back to the drawing board and revisit their approach to doing messaging ( aka the so-called "generic JMS" approach).  I was never that keen on the extra hops and infrastructure that OE puts in place to allow us to do messaging from ABL.  The "adapter/ubroker" approach was particularly ugly - we constantly had weird connectivity and configuration issues with that.  IMHO that thing adds no real functionality or value.  All it adds is extra configuration/management and, as a special bonus, it gives us an extra point of system-wide failure which will create widespread problems for every ABL client in the system that is unfortunate enough to be referencing it.  On the other hand the OE "clientconnect/symbiont" is more straight-forward but it is is not without problems.  Most of the problems are there because of the Java "symbiont" process overhead (memory use, startup delays, JavaTools configuration requirements, localized failures that can arise in a single ABL client/symbiont pair, etc.)

With AMQP now available, Progress may be able to finally connect in a more native fashion to any broker that supports the protocol.  OE can finally bypass Java altogether.  It seems like a "no-brainer" for Progress to adopt AMQP, so I suppose they will get there after several more years.  I'll add it to the enhancement "ideas" list if its not already there....

One of the more significant reasons why you might want to move ahead with AMQP sooner rather than later is because I understand heard that "clientconnect/symbiont" is NOT an option with OE PAS (probably because the messaging stuff was designed before Progress had invented multi-threaded ABL processes.)  Without "clientconnect" we would have no option than to revert to that "adapter/ubroker" thing which would be a major step backwards and open ourselves back up to system-wide messaging failures again.  That weird ubroker component simply makes a complex messaging environment that much more complex because of a superfluous/additional moving part.

We’ve been asking Progress for AMQP support too. So hopefully it won’t be several years away.

>> It would be best to raise this as a bug with our Technical Support team to get this looked at "officially".

I opened a case with Progress tech support as suggested.

I haven't heard whether Progress has added support for the QPID jms client.  It seems like support for this is overdue.  Or if the jms-adapter is out of favor then Progress should offer another alternative approach for AMQP messaging.  

That AMQP  protocol is fairly popular these days (even more than it was two years ago when I had first asked about the whether Progress supports it).

>> It would be best to raise this as a bug with our Technical Support team to get this looked at "officially".

I opened a case, and I am told that the OpenEdge JMS Adapter is now "able use the Apache QPID JMS client libraries to connect to QPID Broker".

Hopefully there will be a KB to make this information available more publicly.  There are a few steps involved and it doesn't look as easy as setting up connectivity to "Apache ActiveMQ" or "Sonic MQ".

My understanding is that the QPID JMS client library will allow the generic JMS adapter to talk to any messaging broker using the AMQP protocol.  More information:

qpid.apache.org/.../index.html

A Progress KB for QPID JMS example is 000101539

It should be available in the Knowledgebase Center ( knowledgebase.progress.com ) shortly.

I suspect that a QPID JMS provider should work fine with the "generic adapter".  But my understanding is that this isn't one of the "certified" JMS providers.