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:
- The server logic
- BaseJMSTaskServer, TaskServerHandler, etc.
- The client logic
- TaskClientHandler, the ResponseHandler and all
it's children classes)
- The asynchronous/concurrency logic
- 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