Status of Apache Camel integration proposal

[Giacomo <gi...@tirasa.net>]

Hi all,

*After some weeks of work I noticed that is better to keep *discussing 
here**on this ML in order to*states what's going on.***This 
discussion**is related to this proposal [1]. If you are interested and 
If you have not yet done so, please read the related slides at [2]*.**As 
indicated in the discussion ,the result of this work consist in a Proof 
Of Concept (POC), that you can find on *[3]*.****
**
**

*Now *I*would like to go deeper on what *I*'ve done so far. In this work 
*I**'*m focusing on two main IDM concepts: User and Role. My goal is to 
decompose both UserController and RoleController from their control 
logic: *I*would like to configure the IDM in such a way that control 
strategies can be easily added/modified*/removed.
By*"control logic/strategies" *I*refer to the set of operations inside 
the controllers: for example, in the create() method of UserController, 
a fixed set of operation are perfomed, like creating internally the user 
(via workflow adapter) and propagate the created user to 
*external*resource. What if we want to apply a different sequence of 
operations? A solution can be represented by overriding this method, but 
as you can see, this isn't a flexible solution.****
*In this way, what I've in mind consists in a redefinition of both the 
UserController and the RoleController. In my solution, I delegate main 
operations to a new component, the Provisioning Manager. Both 
controllers will delegate main operations to the provisioning manager. 
This component deals with Camel context definition and route management: 
as you know, user/role control logics now have to be defined by routes.

**


In the previous weeks I pushed at [3] an initial definition of 
provisioning manager and I attached this new component to the syncope 
context. Now I'm trying to move all operations involved in user creation 
(inside user controller) into the provisioning manager.
I have been discussing some implementation aspects with Hadrian (from 
Camel team) which shown his interest in this proposal.


Fundamentally, the whole work can be seen like replacing static 
statements sequence in User/Role controller methods with definitions of 
specific routes,**outside the controllers.


*Moreover, consider that all previous definition are trial (like the 
provisioning interface), so everything I've done so far can be easily 
changed: I will be very happy of any suggestion!


WDYT?

[1] 
http://syncope-dev.1063484.n5.nabble.com/Proposal-An-Apache-Camel-Integratation-Proposal-td5714531.html
[2] http://www.slideshare.net/giacomolm/camel-proposaltirasa
[3] https://github.com/Tirasa/SyncopeCamel
**

-- 
Giacomo Lamonaco

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

Re: Status of Apache Camel integration proposal

[Francesco Chicchiriccò <il...@apache.org>]

On 12/12/2013 14:32, Hadrian Zbarcea wrote:
> Hi Giacomo,
>
> The idea looks sound to me. I am still not familiar enough with 
> syncope to understand all the consequences of a change and confidently 
> suggest a path or another.
>
> That said, I believe that what you just described already exists in 
> syncope. The UserController (which I spent more time understanding 
> than the Role one) already uses an adapter: uwfAdapter. This is a bean 
> defined in workflowContext.xml but the actual implementation class is 
> defined in workflow.properties. There are actually two incarnations of 
> the UserWorkflowAdapter: the Activiti based one and NoOp one used for 
> tests.
>
> In my mind the best path for now would be to define a 
> CamelUserWorkflowAdapter and go from there (which is what I am 
> experimenting on my branch). I am not aware of any lifecycle 
> management for services in syncope (start/stop), that would help with 
> the CamelUWA, but that shouldn't be a blocker now. One more thing 
> that's needed is a convention for routes names or something that would 
> simplify autodescovery/wiring.

Hi Hadrian,
actually, this was not the purpose of Giacomo's PoC.

Any [User|Role]Controller method roughly performs the following:

1. create / update / delete [user|role] into the internal storage via 
[User|Role]WorkflowAdapter
2. propagate such information to external resources

That's just fine, and we have enough abstraction, as you point out 
correctly above.

What if one wants to implement the following (very common use case):

1. attempt to create user on Active Directory
2. if successful, create user into the internal storage
3. create user on other external resources

?

Currently, since this involves the Java statement execution order in all 
[User|Role]Controller's methods, the only way is to override the whole 
controller class or to extend and override the single method.

Take UserController#doCreate as example:

         WorkflowResult<Map.Entry<Long, Boolean>> created = 
uwfAdapter.create(actual);

         List<PropagationTask> tasks = 
propagationManager.getUserCreateTaskIds(
                 created, actual.getPassword(), actual.getVirAttrs());

What I expect from Camel is to be able to delegate this block above to a 
specific route.
This will allow cleaner and easier behavior extensions on specific 
deployments: instead of providing a new UserController.java, I will only 
need to provide a new userCreateRoute.xml (or like so).

Further improvement would be the change to expose some RESTful methods 
to update the existing routes, allowing runtime behavioral extensions. Wow.

Hope this clarifies.
Regards.

> On 12/12/2013 04:36 AM, Giacomo wrote:
>> Hi all,
>>
>> *After some weeks of work I noticed that is better to keep *discussing
>> here**on this ML in order to*states what's going on.***This
>> discussion**is related to this proposal [1]. If you are interested and
>> If you have not yet done so, please read the related slides at [2]*.**As
>> indicated in the discussion ,the result of this work consist in a Proof
>> Of Concept (POC), that you can find on *[3]*.****
>> **
>> **
>>
>> *Now *I*would like to go deeper on what *I*'ve done so far. In this work
>> *I**'*m focusing on two main IDM concepts: User and Role. My goal is to
>> decompose both UserController and RoleController from their control
>> logic: *I*would like to configure the IDM in such a way that control
>> strategies can be easily added/modified*/removed.
>> By*"control logic/strategies" *I*refer to the set of operations inside
>> the controllers: for example, in the create() method of UserController,
>> a fixed set of operation are perfomed, like creating internally the user
>> (via workflow adapter) and propagate the created user to
>> *external*resource. What if we want to apply a different sequence of
>> operations? A solution can be represented by overriding this method, but
>> as you can see, this isn't a flexible solution.****
>> *In this way, what I've in mind consists in a redefinition of both the
>> UserController and the RoleController. In my solution, I delegate main
>> operations to a new component, the Provisioning Manager. Both
>> controllers will delegate main operations to the provisioning manager.
>> This component deals with Camel context definition and route management:
>> as you know, user/role control logics now have to be defined by routes.
>>
>> **
>>
>>
>> In the previous weeks I pushed at [3] an initial definition of
>> provisioning manager and I attached this new component to the syncope
>> context. Now I'm trying to move all operations involved in user creation
>> (inside user controller) into the provisioning manager.
>> I have been discussing some implementation aspects with Hadrian (from
>> Camel team) which shown his interest in this proposal.
>>
>>
>> Fundamentally, the whole work can be seen like replacing static
>> statements sequence in User/Role controller methods with definitions of
>> specific routes,**outside the controllers.
>>
>>
>> *Moreover, consider that all previous definition are trial (like the
>> provisioning interface), so everything I've done so far can be easily
>> changed: I will be very happy of any suggestion!
>>
>>
>> WDYT?
>>
>> [1]
>> http://syncope-dev.1063484.n5.nabble.com/Proposal-An-Apache-Camel-Integratation-Proposal-td5714531.html 
>>
>>
>> [2] http://www.slideshare.net/giacomolm/camel-proposaltirasa
>> [3] https://github.com/Tirasa/SyncopeCamel

-- 
Francesco Chicchiriccò

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

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: Status of Apache Camel integration proposal

[Hadrian Zbarcea <ha...@apache.org>]

Hi Giacomo,

The idea looks sound to me. I am still not familiar enough with syncope 
to understand all the consequences of a change and confidently suggest a 
path or another.

That said, I believe that what you just described already exists in 
syncope. The UserController (which I spent more time understanding than 
the Role one) already uses an adapter: uwfAdapter. This is a bean 
defined in workflowContext.xml but the actual implementation class is 
defined in workflow.properties. There are actually two incarnations of 
the UserWorkflowAdapter: the Activiti based one and NoOp one used for tests.

In my mind the best path for now would be to define a 
CamelUserWorkflowAdapter and go from there (which is what I am 
experimenting on my branch). I am not aware of any lifecycle management 
for services in syncope (start/stop), that would help with the CamelUWA, 
but that shouldn't be a blocker now. One more thing that's needed is a 
convention for routes names or something that would simplify 
autodescovery/wiring.

WDYT?
Hadrian



On 12/12/2013 04:36 AM, Giacomo wrote:
> Hi all,
>
> *After some weeks of work I noticed that is better to keep *discussing
> here**on this ML in order to*states what's going on.***This
> discussion**is related to this proposal [1]. If you are interested and
> If you have not yet done so, please read the related slides at [2]*.**As
> indicated in the discussion ,the result of this work consist in a Proof
> Of Concept (POC), that you can find on *[3]*.****
> **
> **
>
> *Now *I*would like to go deeper on what *I*'ve done so far. In this work
> *I**'*m focusing on two main IDM concepts: User and Role. My goal is to
> decompose both UserController and RoleController from their control
> logic: *I*would like to configure the IDM in such a way that control
> strategies can be easily added/modified*/removed.
> By*"control logic/strategies" *I*refer to the set of operations inside
> the controllers: for example, in the create() method of UserController,
> a fixed set of operation are perfomed, like creating internally the user
> (via workflow adapter) and propagate the created user to
> *external*resource. What if we want to apply a different sequence of
> operations? A solution can be represented by overriding this method, but
> as you can see, this isn't a flexible solution.****
> *In this way, what I've in mind consists in a redefinition of both the
> UserController and the RoleController. In my solution, I delegate main
> operations to a new component, the Provisioning Manager. Both
> controllers will delegate main operations to the provisioning manager.
> This component deals with Camel context definition and route management:
> as you know, user/role control logics now have to be defined by routes.
>
> **
>
>
> In the previous weeks I pushed at [3] an initial definition of
> provisioning manager and I attached this new component to the syncope
> context. Now I'm trying to move all operations involved in user creation
> (inside user controller) into the provisioning manager.
> I have been discussing some implementation aspects with Hadrian (from
> Camel team) which shown his interest in this proposal.
>
>
> Fundamentally, the whole work can be seen like replacing static
> statements sequence in User/Role controller methods with definitions of
> specific routes,**outside the controllers.
>
>
> *Moreover, consider that all previous definition are trial (like the
> provisioning interface), so everything I've done so far can be easily
> changed: I will be very happy of any suggestion!
>
>
> WDYT?
>
> [1]
> http://syncope-dev.1063484.n5.nabble.com/Proposal-An-Apache-Camel-Integratation-Proposal-td5714531.html
>
> [2] http://www.slideshare.net/giacomolm/camel-proposaltirasa
> [3] https://github.com/Tirasa/SyncopeCamel
> **
>