This document aims to explain how the human task module should look after applying some refactorings which were the results of several experiments.

You can more about this experiments here: https://github.com/Salaboy/human-task-poc-proposal

The following sections describe how the module will look like after the refactorings

APIs and Service Structure

All the Services Proposed by this refactoring are CDI managed beans. For the ones not familiar with CDI, you need to think about it as JPA for Dependency Injection frameworks. So we can say

that CDI is to Spring/Guice/Weld what JPA is to Hibernate/Top Link. CDI propose some very cool out of the box features that we definitely want to use to make our services more clear, robust, easy to maintain. Some of the things provided by CDI that I'm using in the experiments are:

• Configuration based on annotations: We can inject services instances without needing to specify the implementation, so we keep it pluggable and decoupled all the time.
  Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/impl/TaskInstanceServiceImpl.java
  As you can see there, we can define at service level which characteristic the service implementation will need to be injected inside a service, but then we can provide several alternatives
  for that implementation and configure them for different environments. The CDI container will do the rest for us, it will choose wisely the implementation that fits with all the characteristic required and it will inject the services implementation when it's need.
  
  
• Event Producers and Observers
  Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/internals/lifecycle/MVELLifeCycleManager.java#L246
  and: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/lifecycle/listeners/JPATaskLifeCycleEventListener.java
  As you can see a simple and out of the box (and defined by an specification) Event mechanism is provided, allowing us to keep our Event Producers completely Decoupled from our Event Observers. We can also configure the obsevers to be instantiated by teh CDI container or we can decide how many instances of our observer do we need for a particular use case.
  
  
• Decorators/Interceptors:
  We can use both to improve a specific technical or business policy should be applied to the execution of our service methods.
  Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/internals/lifecycle/UserGroupLifeCycleManagerDecorator.java
  Decorators and Interceptors can be enabled and disabled based on configurations, which give us once again a great flexibility to add or remove things based on what we want to achieve.

At the end of the day we have a set of services which can leverage the power of the CDI container. We can also hide that we are using CDI/Weld (weld is the implementation of the CDI interfaces/spec), look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/test/java/org/jboss/human/interactions/NewAPITest.java#L259

We can use it internally and if the user wants to get access to the container he/she can.

The next section describe more advantages about using the CDI/Weld proposed programming model to keep our services simple and take out all the code that is not related with Human Interaction logic.

Services Working Together

The following image shows how the interactions with the human task module will happen. The diagram shows the interfaces and implementations required to interact with a TaskInstance

https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-2-19050/450-252/TaskInstanceServiceSimplified.png

The previous figure shows all the components interacting when we want to interact with a task instance that was already created.

So let's say for example that we want to start a task. From the client perspective he/she can use the TaskServiceEntryPoint to

start the task. This TaskServiceEntryPoint will delegate the calls to the different service implementations. In this case if we are

starting a task the TaskInstanceService implementation will delegate the action to the LifeCycleManager. As you can see

the LifeCycleManager, no matter the implementation is being decorated by an UserGroupDecorator which in charge of handling the

resolution of the identities associated with the operation. The LifeCycleManager is also an Event Producer, which means that is in charge

of generating events to communicate to the external world the LifeCycle changes of each task. We can then attach external listeners to

Observer these events to audit what is happening or as callback mechanisms to execute actions when a task is completed for example.

Classes and Interfaces to look at this point:

https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/api/TaskServiceEntryPoint.java

https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/impl/TaskInstanceServiceImpl.java

https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/impl/TaskDefServiceImpl.java

https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task-core-cdi-experiment/src/main/java/org/jboss/human/interactions/internals/lifecycle/MVELLifeCycleManager.java

Shared Persistence Context and Transactional Behavior

If you take a look at the previous links you will notice that all the Services, for example TaskInstanceServiceImpl and TaskDefServiceImpl are all using an Inject EntityManager.

And there is no code related with transactions or loading and merging detached entities (em.getTransaction(), ut.begin(), em.merge()).

The EntityManager that is being injected is being managed by Seam Persistence (ASL 2.0) (http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/) which give us a transparent

way of having all the advantages of the unified programming model of being in Managed and Transaction Persistence Context without the hassle of taking care of how to share different

instances of an EntityManager or demarcate the transactions based on what is available in our context. Seam Persistence provide us a declarative way to deal with all this topics, and take all the code

related with these tasks out of the Human Task Module. This also give us the possibility to integrate with Spring only configuring our environment and not changing our code

(http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html)

Integration with the Outside World