Status of Apache Camel integration proposal
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
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 **
Re: Status of Apache Camel integration proposal
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: WorkflowResultMap.EntryLong, Boolean created = uwfAdapter.create(actual); ListPropagationTask 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
