search

ome / omero-ms-queue

GNU General Public License v3.0
3 stars 5 forks source link

Make q provider pluggable #3

Closed c0c0n3 closed 5 years ago

c0c0n3 commented 7 years ago

The messaging API is built on top of a few primitive interfaces---classes in core.msg package. A separate queue provider package provides an implementation of those primitive interfaces using Artemis---classes in providers.q package. We should make the q package pluggable so that we can use different implementations along the current one based on Artemis.

So for example, going forward we should be able to easily add a q implementation backed by RabbitMQ or even one that uses (abuses?) Vert.x's event bus to provide an implementation of the abstract communication channels in the msg package.

joshmoore commented 7 years ago

From my point-of-view, the two top priorities for backends should cover:

Don't need to go too much farther than that initially.

c0c0n3 commented 7 years ago

Most definitely yes! In fact, I need to have the single VM install option to support the deployment model here at MRI. Re: queue distribution, this is a low hanging fruit, so we should have that too. (The default being the all-in-one option like you said.)