New interface, similar to EventListener, to handle responses from event handlers.
Synchronous model should look like:
Method #handleEvent should return generic value.
value should be intercepted by EventListener and passed to EventRouter
EventRouter#signalEvent should return this value
That model is obviously incompatible with whole concept of event model, so we have to think about something different, like "callback events". Callback event could be possibly implemented without changing current implementation. It would be enough to introduce new type of event with correlation id: correlation id could be used to process responses.
On top of asynchronous model we could write two kind of simple utility classes:
for synchronous model: class will wait for correlated events using event locks
for callback model: class will put handle inside internal queue. It will be processed later on event receive.
We need synchronous model if we want to implement event model with rejection: e.g. veto property change.
New interface, similar to EventListener, to handle responses from event handlers.
Synchronous model should look like:
- Method #handleEvent should return generic value.
- value should be intercepted by EventListener and passed to EventRouter
- EventRouter#signalEvent should return this value
That model is obviously incompatible with whole concept of event model, so we have to think about something different, like "callback events". Callback event could be possibly implemented without changing current implementation. It would be enough to introduce new type of event with correlation id: correlation id could be used to process responses.
On top of asynchronous model we could write two kind of simple utility classes:
- for synchronous model: class will wait for correlated events using event locks
- for callback model: class will put handle inside internal queue. It will be processed later on event receive.
We need synchronous model if we want to implement event model with rejection: e.g. veto property change.
asynchronous: signal action, execute in router, signal result
asynchronous: query & response correlated by id, using (2)
asynchronous: signal action, execute in router, process result in router?
pipeline (generalization of (4))
semi-synchronous: signal & wait for response, using (2)
Functionality:
Support for many responses (we can use java collectors)
Support for pre-event & post-events for executable actions
Support for event cancelation in pre-event handlers
New models:
1. asynchronous: signal action, execute in router
2. asynchronous: signal action, execute in router, signal result
3. asynchronous: query & response correlated by id, using (2)
3. asynchronous: signal action, execute in router, process result in router?
4. pipeline (generalization of (4))
5. semi-synchronous: signal & wait for response, using (2)
Functionality:
- Support for many responses (we can use java collectors)
- Support for pre-event & post-events for executable actions
- Support for event cancelation in pre-event handlers
create EventRouter from interface/class which delegates work reflectively.
broker should use (2) to send results to other listeners
client should find router, send events to it and offer both sync/callback methods for waiting on results.
New model: client/broker.
- create EventRouter from interface/class which delegates work reflectively.
- broker should use (2) to send results to other listeners
- client should find router, send events to it and offer both sync/callback methods for waiting on results.
TaskRouter signal action, execute in router, invoke callback (by the same or another router)
TaskRouter signal action, execute in router, wait for result
TaskBroker interface producer/consumer
Required models:
(1)
(2) only internally
(3)
(4)
(5) not yet
(6)
Required functionality:
Support for many responses (we can use java collectors)
Support for pre-event & post-events for executable actions
Support for event cancelation in pre-event handlers
Implemented models:
1. `TaskRouter` signal action, execute in router
1. `TaskRouter` signal action, execute in router, invoke callback (by the same or another router)
1. `TaskRouter` signal action, execute in router, __wait__ for result
1. `TaskBroker` interface producer/consumer
Required models:
- (1)
- (2) only internally
- (3)
- (4)
- (5) not yet
- (6)
Required functionality:
- Support for many responses (we can use java collectors)
- Support for pre-event & post-events for executable actions
- Support for event cancelation in pre-event handlers
ActiveEvent can be canceled by ActiveEventListener
we can wait for ActiveEvent completion
ActiveEventListener does not allow return values
maybe we could extend ActiveEvent further to add modifiable result field (not only canceled/processed status)
Todo:
- (5) pipeline
Functionality:
* `ActiveEvent` can be canceled by `ActiveEventListener`
* we can wait for `ActiveEvent` completion
* ActiveEventListener does not allow return values
* maybe we could extend ActiveEvent further to add modifiable result field (not only canceled/processed status)
TaskRouter: can schedule and optionally wait for Runnable.
TaskRouter: can schedule and optionally wait for Supplier.
TaskRouter: callback support
TaskBroker: use interface for messaging between producer/consumer
Final functionality:
ActiveEvent: event can be canceled
ActiveEvent: we can wait for completion
ActiveEvent: we can write subclasses to deliver results
Final models:
- TaskRouter: can schedule and optionally wait for Runnable.
- TaskRouter: can schedule and optionally wait for Supplier.
- TaskRouter: callback support
- TaskBroker: use interface for messaging between producer/consumer
Final functionality:
- ActiveEvent: event can be canceled
- ActiveEvent: we can wait for completion
- ActiveEvent: we can write subclasses to deliver results
New interface, similar to EventListener, to handle responses from event handlers.
Synchronous model should look like:
That model is obviously incompatible with whole concept of event model, so we have to think about something different, like "callback events". Callback event could be possibly implemented without changing current implementation. It would be enough to introduce new type of event with correlation id: correlation id could be used to process responses.
On top of asynchronous model we could write two kind of simple utility classes:
We need synchronous model if we want to implement event model with rejection: e.g. veto property change.
New models:
Functionality:
New model: client/broker.
Implemented models:
TaskRoutersignal action, execute in routerTaskRoutersignal action, execute in router, invoke callback (by the same or another router)TaskRoutersignal action, execute in router, wait for resultTaskBrokerinterface producer/consumerRequired models:
Required functionality:
Todo:
Functionality:
ActiveEventcan be canceled byActiveEventListenerActiveEventcompletionFinal models:
Final functionality: