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(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev