[jbpm-dev] Human-Task module problematic..

[Mauricio Salatino]

Hi Marco,
My opinion about it is good, I mean, we need to improve the transport layer
of it, but the rest of the code is ok. If you take a look at one of my last
pull requests, it was related with the fact that we need a synchronous
interface to simplify all the interactions and to hide all the boilerplate
of async communications.

If you want to simply things to start having more smaller and controlled
pieces I suggest you to take a look at this other pull request:
https://github.com/droolsjbpm/jbpm/pull/28
Which aims to split the logic that we currently have inside the human task
module into several modules with their own dependencies. That will allow us
to do internal changes, api changes as well as transport changes in a more
manageable way.

I really like the idea of having this human task module completely decoupled
from the rest of the project and I'm willing to help as much as I can to
improve it because I found that not only jBPM can leverage the power of it.

Let's keep this discussion open so we can gather more requirements from the
people that is using it.

Cheers

On Thu, Oct 20, 2011 at 7:19 AM, Marco Rietveld <mrietvel at redhat.com> wrote:

>  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
>
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>


-- 
 - CTO @ http://www.plugtree.com
 - MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20111020/5b8d45c9/attachment.html