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/
