<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
(Took me a while to find the time to look at this, sorry for the
delay)<br>
<br>
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):<br>
<br>
- 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)<br>
- tests for the functionality of that component<br>
- communication/transportation code that exposes this service to
remote clients (e.g. using Mina or HornetQ)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Kris<br>
<br>
On 10/20/2011 12:19 PM, Marco Rietveld wrote:
<blockquote cite="mid:4E9FF5B2.802@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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>
<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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
jbpm-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbpm-dev">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>