Mailing-List: contact dev-help@syncope.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@syncope.apache.org
Subject: Re: Creating events for changes and spi for transport of events
Reply-To: dev@syncope.apache.org
References: <CAH6_LN=P73kW_xZ1NCS+zBZhe_Lws4g_3J5abO0OGfpXsbMgAA@mail.gmail.com>
 <c29162ec-d74c-7511-1067-2b59bac72ded@apache.org>
To: dev@syncope.apache.org
From: =?UTF-8?Q?Francesco_Chicchiricc=c3=b2?= <ilgrosso@apache.org>
Message-ID: <35c1c12d-54c2-6408-f3ba-94baf92468ff@apache.org>
Date: Mon, 21 Nov 2016 11:59:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <c29162ec-d74c-7511-1067-2b59bac72ded@apache.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Mon, 21 Nov 2016 10:59:26 -0000

On 21/11/2016 11:52, Francesco Chicchiriccò wrote:
> Hi Christian,
> nice to read you here again!
>
> Please find my replies embedded below.
>
> Regards.
>
> 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].

Missing information: [3] and [4] are triggered via AOP by [5].

> 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", though.
>
>> 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 dependencies.
>
> 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, 
> naturally).
> I am also available to help with rewrite of [3] and [4] once 
> broker-api and broker-java are done.
>
> [1] 
> http://syncope.apache.org/docs/reference-guide.html#notification-events
> [2] http://syncope.apache.org/docs/reference-guide.html#audit-events
> [3] 
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/notification/NotificationManagerImpl.java#L257
> [4] 
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/AuditManagerImpl.java#L48
[5] 
https://github.com/apache/syncope/blob/2_0_X/core/logic/src/main/java/org/apache/syncope/core/logic/LogicInvocationHandler.java

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/