Hi guys,

Having looked through the architecture of the Human-Task module in the last month or so, I've become fairly pessimistic about it.


The biggest problem I'm seeing is that the "wheel is reinvented" a couple times -- and the "reinvented wheels" that are present in the Human-Task service will be a pain to maintain/troubleshoot.

The "reinvented wheels" are things like the following:
  1. The server logic                                        
    1. BaseJMSTaskServer, TaskServerHandler, etc.
  2. The client logic
    1. TaskClientHandler, the ResponseHandler and all it's children classes)
  3. The asynchronous/concurrency logic
    1. AbstractBlockingResponseHandler{.waitTillDone(long) } and every class that uses that method (and every class that uses the class that uses that method.. etc.)

 I think my frustration with this can best be expressed by the fact that jBPM is a process engine project -- it's not a server project, it's not a (service) client project, and it certainly isn't a project that supports asynchronous communication. And yet, we're implementing all 3 in the module. :/


Lastly, the human-task module code is the reason that the jbpm builds (on hudson.jboss.org) have been failing for the last month or so. And the tests are not failing because the tests are wrong: the tests are failing because there's a race condition in the code, and it occurs when you run the human-task code on a 1. heavily loaded server that's experiencing 2. lots of network traffic. Which is what the hudson.jboss.org is.


I guess I'm wondering what other people's opinions about this are!


Thanks,
Marco

-- 
jBPM/Drools developer
Utrecht, the Netherlands