Hi Giacomo,
as I've already told you in person, this is really great stuff.

Comparing to the "standard" Syncope trunk - from which the project available at [2] was forked - your code offers greater flexibility when it comes to customize the UserController / RoleController methods' behavior, since the whole application logic is now delegated to some Camel routes.

As a "serial Syncope deployer", let me remark how in most deployments a consistent part of the effort is related to adapt the standard behavior for user / role operations to customer's needs: usually working with workflow definition is enough, sometimes deeper customizations are needed, and the only option so far was to override the whole Java method in the local overlay.

Moreover, Camel routes can be dynamically changed at runtime via REST calls, and it is also possible to edit such routes via the admin console - with bare XML editor currently, but I guess some fancy Javascript editor can be put in place as well, as we did for Activiti workflow.

Again, great stuff: now, assuming you are willing to see your changes in the "official" Syncope, it's time to start discussing about the best way to handle this.

Personally, I would:

 1. copy the current SVN trunk to a a new 1_2_X branch
 2. change version to 1.3.0-SNAPSHOT on trunk
3. (since Giacomo has already a valid ICLA in ASF foundation records) ask Giacomo to open a new feature on JIRA (fix for version: 1.3.0) with attached a patch generated via GitHub from [2]

WDYT?

Regards.

On 04/04/2014 12:07, Giacomo Lamonaco wrote:
Hi all,
as you know, in the previous months I worked on an early integration of Apache 
Camel in Syncope. The original purpose was to introduce a new component, the 
provisioning manager, that deals with user and role management. We decided to 
use Camel as base of the new component: we supposed that Camel routes could be 
used to express the provisioning logic.. and maybe we were right.

In these months I simplified both the user and the role controller: every 
operation that had to do with these two concepts (i.e. user creation),has been 
moved in the provisioning manager and now it's expressed using a route. This 
means that now we have a more accurate control on what's happening in the 
provisioning process and, using the right syntax, we can define complex 
behaviour.

In the last part of the work, we decided to focus more on the Syncope Console: 
we decided to add a new REST service that allows to read the routes 
definitions, and possibly modify them. You can find this new service under the 
Configuration section. In this case, routes are expressed through Spring DSL.

We decided to extend the Syncope Console for one main reason: Camel allows to 
add/remove routes at runtime, without stopping its context. In our case, since 
Camel routes represent part of Syncope provisioning logic, we are able to 
update some provisioning behaviour by changing the route content. In other 
word, if we want to change some provisioning logic, now we don't need to stop 
Syncope and create a new classes: we can do it directly in the console, without 
stopping Syncope.

As a final result, I made a video [1] that shows how to work with the new 
component. In my case, I'm updating the user creation route at runtime: with 
this modification, every time a new user is added, an email is sent to system 
administrator.

What do you think? It make sense to integrate this work in Syncope?
Let me know!

Thanks for your attention.

[1]https://www.youtube.com/watch?v=H25BFqaI8qw
[2] https://github.com/Tirasa/SyncopeCamel

--
Francesco Chicchiriccò

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

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/

Reply via email to