syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <>
Subject Re: Creating events for changes and spi for transport of events
Date Mon, 21 Nov 2016 10:52:54 GMT
Hi Christian,
nice to read you here again!

Please find my replies embedded below.


On 20/11/2016 08:11, Christian Schneider wrote:
> I was listening to Colm´s presentation about customizing syncope with camel
> rotues. It sounds like a very powerful combination as you can influence all
> changes.
> For some simple cases like just listening to changes in syncope the camel
> routes look a bit complicated though.
> So I wonder if it would make sense to create some central event hub inside
> syncope that gets notified of all changes and allows to easily attach
> messaging systems.
> I could imagine something like this:
> interface EventBroker {
>    sendEvent(String topic, Object event)
> }
> There could be different event classes for each type of change. If those
> events have JAXB annotations it is very easy to create xml or json from
> them.
> The syncope classes where the events happen would just inject the
> EventBroker interface and send their events.
> The EventBroker would then forward the events to all EventListeners
> present. An EventListener would look like that:
> interface EventListener {
>    onEvent(String topic, Object event)
> }
> So we could provide some implementations of EventListener like for ActiveMQ
> and Kafka. Additionally users could also implement the interface and attach
> additional messaging systems.
> What do you think? Does something like this already exist?

Syncope has, since 1.0 so essentially since it entered the Incubator, a 
mean to define events [1][2] and to associate notifications and / or 
audit messages that are triggered when such events happen.
In Syncope 2.0 this is performed by [3] and [4].

The current mechanism, with assistance of the admin console, allows to 
graphically select events and to associate them with notifications and / 
or audit.

IIUC, what you are proposing is somewhat overlapping, but seems also 
general enough to allow rewriting [3] and [4] under the new mechanism. A 
strong requirement would be to keep allowing easy insertion of 
notifications and audits, tough.
I would also consider adding more structure to the base "Object event", 

> Would it make sense to add this mechanism to syncope?
> If there is interest I am willing to create the Broker as well as ActiveMQ
> and Kafka impls. I am not familiar enough with the individual source for
> the events to do the integration but I think it should be very easy for any
> syncope core developer to add them.

With reference with the current code organization in the master branch, 
I would see the following new modules:

1. core/broker-api
2. core/broker-java
3. ext/core-broker-activemq
4. ext/core-broker-kafka

The first module will define the interfaces (and we will need to some of 
the existing components to depend on that, naturally).
The second module will be the default in-memory implementation.
The third and the forth will be the ActiveMQ and Kafka implementations, 
placed as extensions since they will likely require to introduce new 

I'll bring a big +1 if you could go ahead and create an issue on JIRA 
about this and start a feature branch for that (forked from master, 
I am also available to help with rewrite of [3] and [4] once broker-api 
and broker-java are done.


Francesco Chicchiriccò

Tirasa - Open Source Excellence

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

View raw message