<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi guys,<br>
<br>
Having looked through the architecture of the Human-Task module in
the last month or so, I've become fairly pessimistic about it. <br>
<br>
<br>
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.<br>
<br>
The "reinvented wheels" are things like the following: <br>
<ol>
<li>The server logic </li>
<ol>
<li>BaseJMSTaskServer, TaskServerHandler, etc. <br>
</li>
</ol>
<li>The client logic</li>
<ol>
<li>TaskClientHandler, the ResponseHandler and all it's children
classes)</li>
</ol>
<li>The asynchronous/concurrency logic</li>
<ol>
<li>AbstractBlockingResponseHandler{.waitTillDone(long) } and
every class that uses that method (and every class that uses
the class that uses that method.. etc.)<br>
<br>
</li>
</ol>
</ol>
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. :/ <br>
<br>
<i></i><br>
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 <u><b><i>not</i></b></u> failing because the
<i>tests</i> 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. <br>
<br>
<br>
I guess I'm wondering what other people's opinions about this are! <br>
<br>
<br>
Thanks,<br>
Marco<br>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</body>
</html>