topic Re: Process event bus, extracting the pvm and persistence in Alfresco Archive

Process event bus, extracting the pvm and persistence

tombaeyens — Mon, 05 Jul 2010 09:30:56 GMT

This post summarizes my thoughts (after a weekend of reflection 🙂 ) on the discussions about Process event bus, extracting the pvm and persistence that we had on friday afternoon in the Activiti Community Kickoff Meeting.Ordered by priority:1) persistence. If the runtime data can't be properly pe

Re: Process event bus, extracting the pvm and persistence

cstettler — Mon, 05 Jul 2010 09:43:16 GMT

Related to the naming discussion in 2): to my understanding, the event bus is not one-way only (at least not from the point of view of other components plugged into the bus), as e.g. a task assignment module could listen to new task events being fired by the pvm, but could in turn also fire own task assigned events via the event bus. So it is not only the pvm that fires events and thus, other components are not only listeners.

Re: Process event bus, extracting the pvm and persistence

micha_kiener — Mon, 05 Jul 2010 11:05:12 GMT

In my opinion, the naming is essential to start expressing the powerful concept behind the process event bus, so process events and listeners don't express that in its fully extend. The PEB should also be part of the PVM, as the most generic events are generated by the PVM itself, however, the PVM is not the only component creating events.

Second, if extracting the PVM is easy and doable, we should do it as it helps with a clear separation of concerns and modularization as well as additional value to be used on its own. I have doubts that we can really talk of a PVM, if too many things are just woven into it as this is currently the case.

Re: Process event bus, extracting the pvm and persistence

tombaeyens — Mon, 05 Jul 2010 13:42:23 GMT

I still have trouble to see where we put the PEB. The PEB listeners should be configured. Configuration is engine and not pvm. So that part of PEB should go into engine. Whereas on the other hand, the process events are constructed and fired in the pvm. So event creation should go in PVM.

How do you see people subscribe to PEB events in the plain PVM (without the engine) ?

Re: Process event bus, extracting the pvm and persistence

micha_kiener — Tue, 06 Jul 2010 12:56:41 GMT

The PEB itself is part of the PVM, however, it only supports bindings of subscribed components through an API, whereas configuration based binding is only supported within the engine. There is a set of basic events being known and fired by the PVM itself, though not limited to this basic set of event types.
In other words, when I want to use the PVM only (maybe to support my own, simple DSL on top of it), I can subscribe to PEB events by adding my listener through the PEB's API or I could come up with an own configuration handler on top of the PVM and my extensions.

Within the engine, I basically see three options for PEB subscribers:
- registering my own component through the configuration (e.g. Spring namespace handler supporting this feature)
- registering my own component through a plugin mechanism (we still would have to discuss its architecture though)
- during runtime, by adding my own component to the PEB through its API

Re: Process event bus, extracting the pvm and persistence

tombaeyens — Mon, 19 Jul 2010 13:49:56 GMT

when I want to use the PVM only (maybe to support my own, simple DSL on top of it), I can subscribe to PEB events by adding my listener through the PEB's API

Would this come down to a static object/method?
Or would the listeners subscription methods be available on a ProcessDefinition?
Or some other way?