On Jun 28, 2011, at 11:21 AM, Rubén Pérez wrote: > I realize saying I have a superficial knowledge of this topic is an > understatement, but I don't understand why, if: > > The matterhorn-conductor module, which provides our workflow operation > handlers, has all dependencies we need to communicate with (possibly remote) > Matterhorn services > then > > What we lose is the ability to listen for other kinds of events, such as > users adding annotations, or jobs failing. > > Users adding annotations are actually calling the annotation service, which > falls into the realm of "communication with Matterhorn services". Are you > saying that workflows can generate events that call services, but not > vice-versa (i.e. services cannot generate events which somehow trigger a > workflow, a part of a workflow, or another service) ?
Any service can generate events, but the event handlers will only respond to events that originate from the local JVM. That's the limitation I was trying to describe. So series, scheduling, ingest, workflow, and capture admin can all generate events, and we can respond to them with handlers that can call any other service, since we have access to all services from admin nodes. On the other hand, if text extraction generates an event, and we want a handler to deal with it, we'd need to deploy the handler to the worker nodes. Not all services are available to worker nodes currently, so you couldn't call, say, the scheduler service from a TextExtractionFailedEventHandler. All of the worker-related events I can think of could be handled via events generated by workflow operations. > > Hope I'm not asking something too obvious. Not at all... it's a good question, and gets to the heart of the main limitation of this approach. Thanks, Josh > Best regards > Rubén
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
