An Apache Camel Integratation Proposal - Important updates

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

An Apache Camel Integratation Proposal - Important updates

giacomolm
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

Hadrian Zbarcea-2
Awesome work Giacomo.
Hadrian


On Friday 04 April 2014 06:07:51 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
>
Reply | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

ilgrosso
Administrator
In reply to this post by giacomolm
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 | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

Colm O hEigeartaigh
Great work, Giacomo! I wonder if this work could be continued to eventually
use Camel to drive all of the various "tasks" in Syncope? For example,
Camel could be used to drive a "notification task", which would give a huge
degree of flexibility in terms of generating notifications. Same goes for
propagation/synchronization. Interested in your thoughts on this.

Francesco, is there any compelling reason not to merge this work for 1.2
instead of 1.3? We seem to be quite some way off releasing 1.2, hence my
question.

Colm.


On Fri, Apr 4, 2014 at 3:17 PM, Francesco Chicchiriccò
<[hidden email]>wrote:

> 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/
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

Massimiliano Perrone (tirasa.net)
In reply to this post by giacomolm
On 04/04/2014 12:07 PM, 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.

Great work...BRAVO

>
> [1]https://www.youtube.com/watch?v=H25BFqaI8qw
>


--
Massimiliano Perrone
Tel +39 393 9121310

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~massi/

"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)

Reply | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

ilgrosso
Administrator
In reply to this post by Colm O hEigeartaigh
On 04/04/2014 19:18, Colm O hEigeartaigh wrote:
> Great work, Giacomo! I wonder if this work could be continued to eventually
> use Camel to drive all of the various "tasks" in Syncope? For example,
> Camel could be used to drive a "notification task", which would give a huge
> degree of flexibility in terms of generating notifications. Same goes for
> propagation/synchronization. Interested in your thoughts on this.
>
> Francesco, is there any compelling reason not to merge this work for 1.2
> instead of 1.3? We seem to be quite some way off releasing 1.2, hence my
> question.

Hi Colm,
I suggested 1.3 for Giacomo's work because AFAIK it is more like a
prototype than a finished development: we don't know, for example, if
the code is in line with latest Camel's best practices, neither we put
it under high load to understand if there could be scalability issues.
Moreover, the interesting ideas you suggest above - extending the Camel
approach to other Syncope features - might cause the 1.2.0, which
already features several enhancements - to stuck in an undefined delay.

I wish I could put some energies back again in Syncope 1.2.0, including
the M1 release as discussed [3], but I may have enough spare cycles only
in about one month time.

Regards.

> On Fri, Apr 4, 2014 at 3:17 PM, Francesco Chicchiriccò
> <[hidden email]>wrote:
>
>> 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
[3]
http://syncope-dev.1063484.n5.nabble.com/Work-for-next-major-release-1-2-0-td5714937.html

--
Francesco Chicchiriccò

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

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

Reply | Threaded
Open this post in threaded view
|

Re: An Apache Camel Integratation Proposal - Important updates

Andrea Patricelli
In reply to this post by giacomolm

Il 04/apr/2014 12:07 Giacomo Lamonaco <[hidden email]> ha scritto:

>
> 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!
>
It's a very interesting and fascinating solution! Although I'm almost fairly a newbie, I think you made, in a few months, a great work.
And you made me want to examine more accurately this argument:)
+1
Andrea
> Thanks for your attention.
>
> [1]https://www.youtube.com/watch?v=H25BFqaI8qw
>
> --
> Giacomo Lamonaco
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/