The requirement here I think is similar to how a Servlet is registered with HttpService via the whiteboard pattern. So in Job case a JobConsumer can be registered with a Filter which list the job attributes it can process. Then JobSubSystem would work on the whiteboard pattern and registers the JobConsumer with the matching queue based on the filter.
> Message Queue -> QueueConsumer -> JobSubSystem -> JobConsumer Not sure about the distinction between QueueConsumer and JobSubSystem. May be you are distinguishing between a whiteboard impl which listens for queue ( QueueConsumer) and another whiteboard impl which listens for JobConsumer (JobSubSystem). Chetan Mehrotra On Tue, Apr 12, 2016 at 2:10 PM, Ian Boston <[email protected]> wrote: > Hi, > Under [1] I am working on a PoC to implement a distributed Jobs sub system > that works using message passing as the underlying concept. The PoC uses > JMS provided by ActiveMQ. I have a question that I have not answered in the > implementation and would like to discuss. > > A tiny bit of background: Jobs are queued by sending messages to a Queue. > The messages are dequeued and the Jobs are executed. There is an API [2], > JobConsumer, that Jobs would implement. For more background have a look at > the README.md files in the branch referenced by [1][2]. > > I am wondering the best way to connect the Queue to the JobConsumer, hence > this email. > > Currently, I am thinking a component uses OSGi DS to maintain a list of > active JobConsumer implementations. That component registers the > JobConsumers with the Queue implementation and calls JobConsumer.execute as > messages are dequeued. Its the registration part that worries me. > > A JobConsumer has an OSGi property listing the queues it wants to be > registered against. I am worried that that doesn't provide sufficient > decoupling between what the JobConsumer does, and how it gets its messages. > Queues should, I think, be flexible and not bound to the Job being > executed, but be able to be configured to suit a deployment. > > Perhaps rather than: > Message Queue[3] -> JobSubSystem -> JobConsumer > where the JobConsumer directly subscribes to a named queue. > > it should be: > > Message Queue -> QueueConsumer -> JobSubSystem -> JobConsumer > Where the JobConsumer advertises a type of job it can execute. > The JobSubsystem maintains a registry of JobConsumers to which it > dispatches on type of job. > The deployment configures 1 - n QueueConsumers with varying configuration > which consume messages from named queues. > > On the other hand, having configurable QueueConsumers might be overkill and > something that a implementation of [3] could handle internally via > configuration (ActiveMQ probably can). > > Even if QueueConsumers did almost nothing, I am leaning towards that > additional layer of indirection. > > wdyt? > > Best Regards > Ian > > > 1 https://issues.apache.org/jira/browse/SLING-5646 > 2 > https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/core/src/main/java/org/apache/sling/jobs/JobConsumer.java > 3 > https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/mom-api/src/main/java/org/apache/sling/mom/QueueManager.java
