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

Tue Nov 1 14:57:49 EDT 2011

Sure let's find time to discuss that in the IRC. Please ping me and let's
have a meeting about that

On Tue, Nov 1, 2011 at 1:19 PM, Kris Verlaenen <kverlaen at redhat.com> wrote:

> **
> (Took me a while to find the time to look at this, sorry for the delay)
>
> I think you should consider the jbpm-human-task module as a combination of
> several components (and we're actually trying to split it up a little
> following this structure):
>
>  - a simple java component, based on the concepts in the WS-HT spec. that
> allows you to manage the life cycle of tasks (we've now introduced a simple
> API that this service exposes)
>  - tests for the functionality of that component
>  - communication/transportation code that exposes this service to remote
> clients (e.g. using Mina or HornetQ)
>
> Having the component as a simple component (and not always as a web
> service for example) is necessary, as you can then just embed it as part of
> your application and use local communication rather than WS invocations
> (which might be important for performance.  We're actually probably going
> to deploy the task service locally next to the jBPM engine in the
> jbpm-console for the next service.
>
> I definitely agree that jBPM is not a server project or anything related
> to that, it is a BPM project.  So a Java component that manages the life
> cycle of tasks makes sense in this context.  Developing our own
> client-server communication mechanism doesn't.  But we do want to make sure
> that this service can actually be used of course.  To do that, we need to
> make it accessible remotely.  So, from my point of view, our goal is to use
> existing technologies in combination with our task service component so we
> can expose it remotely.  That means not reinventing the wheel but reusing
> existing technologies that exist in this area and applying them /
> configuring them to our use case.
>
> The tests in the human task service project are indeed starting to annoy
> me as well.  No matter what the reason is, we should solve them (and yes, I
> mean "we", not "you" ;)).  Let's try to find some time to discuss on irc
> what we need to improve to solve these issues.
>
> Let's focus on the HornetQ impl. first (as that's the one we recommend for
> use in production).  We should just be able to set up / configure HornetQ
> so it can be used to send messages from client to server.
>
> I also support the idea of being able to just run this as a simple war,
> there's even a prototype impl. that already does that, but even then
> there's still the question of what communication mechanism to use.
>
> Currently the human task service is part of the jbpm project, although I
> agree that it could be used in a broader context as well, but I think it
> makes sense to keep it there until we see more pressing reasons to create a
> separate project for it.
>
> Kris
>
>
> On 10/20/2011 12:19 PM, Marco Rietveld 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 listjbpm-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>
>
> _______________________________________________
> 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/20111101/b686cb95/attachment.html 