D
dbeavon
Guest
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.
Continue reading...
Continue reading...