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

[Kris Verlaenen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20111101/1282a916/attachment.html