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