I was having a bit of trouble with the "JMS generic adapter" today.
It set me to wondering if anyone has any experience with the "in-process" hosting of a messaging client within an ABL process (eg. _mproapsv). Perhaps this could be done with the help of the "CLR bridge"? For example, if I have the AMQ client libraries for .Net from nuget, then I should be able to load them directly into an ms-agent process and start sending messages straight to an AMQ broker.
This would be a nice improvement over "broker-connect" whereby you need the "broker-adapter-thingy". That thing runs as a separate process and, based on my understanding, it accomplishes little more than provide an independent hosting process for the JMS client libraries. It also introduces complexity during configuration and deployment. It also adds an additional point of failure. I've never been a huge fan of that thing.
Please let me know if anyone has ever used an "in-process" messaging client from ABL that communicates directly to a messaging broker. It doesn't seem too far out of reach. I'd rather not re-invent this from scratch if someone has already done it. We are using RedHat AMQ for our broker.
|
|
||||
|
Brian Maher
|
||||
|
Principal Engineer, Technical Support
|
||||
 |
||||
|
Progress
|
||||
|
14 Oak Park | Bedford, MA 01730 | USA
|
||||
|
||||
|
if it's a abl client, then there are several stomp adapters available using sockets . They can also be used in classic webspeed agents. They, cannot however, be used in classic appserver or PSOE because they do not respond to events. They _can_ be used to send messages though ..
Thanks Brian, for a moment I forgot how much work is done using independent threads. For example, a simple message listener callback may often be executed from a different thread than the one that initially installed the listener. You are right that this would introduce some complexity for async message receipt. (But it might not be so bad when it comes to sending messages.)
Perhaps that "broker-adapter-thingy" is adding a bit more value than first meets the eye.
Still, I think it would be nice if someone worked on a variation of the generic adapter that ran within the CLR bridge. Unfortunately the .net equivalent of JMS isn't a real standard. (I think Sonic and AMQ both implement an API with similar patterns as JMS, but they don't share any formal interfaces like what we have in JMS).
Perhaps if someone worked on a solution that involved the CLR bridge, it should be based on stomp, or it might even be based on the new "AMQP" wire standard. Something like that might not have a huge target audience - unfortunately I don't hear of that many ABL programmers who integrate their stuff with messaging brokers.
There is a very good alternative to JMS. Kafka. https://kafka.apache.org/. It is very well served across multiple languages and platforms, including java, .net, and others. There are even adapters available for to interop with JMS. There is a project called "kafka-pixy" github.com/.../kafka-pixy that provides a REST endpoint for both send/receive messages. You can use the ABL HTTP client to talk to the kafka pixy REST api.
I can't find a stomp adapter for kafka. And no one has written an ABL client yet that I can find ...but the network protocol is well documented so it it is possible.
Is there anything on the OE backlog to do messaging "natively" within an ABL session? If so, what would the first "native" client be? Stomp? AMQP? Kafka?
I think JMS is pretty solid, but it is a java-based API rather than a wire protocol. I'm a bit surprised that Progress locked onto that so firmly. Especially considering that, by definition, it will never be used as a native messaging client within an ABL process. I suppose the decision to use JMS for all ABL messaging is one that pre-dates Stomp, AMQP, and Kafka.
Maybe the reason nobody is working on this within ABL is because there are too many possible alternatives, and too many people would argue about the direction. ;)
It is interesting to read about kafka. I can tell it is a very active community. But I think my first choice would still be to use the amqpnetlite nuget package from the CLR bridge, as long as I don't run into too many technical challenges. It seems appealing to send messages directly from an ABL process to the broker, without any intermediate hoops to jump thru.
