<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Mauricio, <br>
<br>
I have absolutely no problem with first packaging the human-task
project in a jar, and then <i>also</i> having it packaged as a web
application/web service -- just like Brad described. <br>
<br>
I agree with your point about architecture: if you can offer the
human-task as a jar, that makes it's inclusion into other
systems/applications much easier. And it would be very cool to have
it become a WS-HT library that is widely used. <br>
<br>
I'll write you/the list probably next week with a suggestion for how
we could achieve this: otherwise, feel free to submit a "road-map"
yourself! <br>
<br>
Lastly, with regards to your pull request/split idea: I don't think
that the human-task needs to be split. I think we just need to
delete the transport part. :) We can then refactor the "jbpm logic"
part so that it has a primary interface that the web service or
other architectures can interface with. <br>
<br>
<br>
@Brad: thanks for the suggestion about CXF. Those are exactly the
lines I was thinking along. <br>
<br>
Thanks,<br>
Marco<br>
<br>
<br>
10/20/2011 02:21 PM, Mauricio Salatino:
<blockquote
cite="mid:CANzbnyU7rOa1Jv+75G_a9UEGmf06QC2cyYwpzzNaLSP1eCwfPg@mail.gmail.com"
type="cite">A web application will limit to all the users that
wants to add the logic of the Human Task Component embedded inside
their own application which I think that is a very good use case.
For example, one of the things that I'm pushing forward is the
fact that you can create tasks from rules instead of creating
tasks just from business processes. If you want to do that having
all the logic inside a web application will complicate your
application architecture. I'm not against of having a web
application that wraps the human task component functionality but
we should provide also a simple library that can be embedded in
any environment.
<div>
<br>
</div>
<div>I agree with you on the second question, I mean.. that's why
I was trying to decouple the logic from the transport in that
pull request that breaks apart the current single module into
like 8 sub projects. The other thing that it's important to
mention is that I believe that the human task component should
go outside of the jBPM project to promote the use from different
other projects. I would love to see the human task functionality
included in JBoss AS for example as a service, but not as a web
application :)</div>
<div><br>
</div>
<div>Cheers<br>
<br>
<div class="gmail_quote">On Thu, Oct 20, 2011 at 9:16 AM, Marco
Rietveld <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mrietvel@redhat.com">mrietvel@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000"> Mauricio, <br>
<br>
Why don't you think that the module should be a web
application? <br>
<br>
And why do you want to put the code that implements the
server, client and async. nature in the <i>jBPM</i>
project??<br>
<br>
Thanks,<br>
Marco<br>
<br>
10/20/2011 02:09 PM, Mauricio Salatino:
<div>
<div class="h5">
<blockquote type="cite">Hi marco,
<div>We have implemented a project that basically
provides the bindings for the current module with
the WS Interface proposed by WS-HT standard. Doing
that we have introduced a lot of boilerplate with
the data types proposed in the standard. If you
take a look at the new interface that is called
TaskService you will see that thats the
synchronous interface with the methods that we can
expose with WS or JMS(Commands like in drools),
but I don't believe that the module should be a
Web application. If you talk with kris about this
you will find that I have a couple of pending task
related with hooking up the task service to the
JNDI tree to be able to be used by multiple
applications for example in tomcat or jboss. </div>
<div><br>
</div>
<div>I'm open to create a project in my github
account where we can play around and coordinate
that effort, I also have access to a jenkings
server to keep it blue. The main problem with the
module human task module is that is being used and
we cannot break it or change it completely. </div>
<div><br>
</div>
<div>-> <a moz-do-not-send="true"
href="https://github.com/Salaboy/human-tasks-playground"
target="_blank">https://github.com/Salaboy/human-tasks-playground</a></div>
<div><br>
</div>
<div>I've already added you Marco as a
collaborator.. </div>
<div>I think that the main idea will be to build a
proposal to see what we can do and how we can
handle the existing users.</div>
<div>Marco what do you think about that? what are
the main goals that you want to achieve?</div>
<div>If someone else is interested in this idea
please write us back.</div>
<div><br>
</div>
<div>Cheers<br>
<br>
<div class="gmail_quote">On Thu, Oct 20, 2011 at
8:58 AM, Marco Rietveld <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mrietvel@redhat.com"
target="_blank">mrietvel@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Mauricio, <br>
<br>
You know the code better than I do, but IMO,
the infrastructure code in that module is
not okay. <br>
<div> <br>
> I really like the idea of having this
human task module completely decoupled
from the rest of the project<br>
<br>
</div>
I am all for this. Would you mind hosting it
on your github, then? <br>
<br>
<br>
A lot of the <i>jBPM</i> related code seems
to be okay, it's mostly how the module is
set up that bothers me. <br>
<br>
It seems like it would be a better idea to
implement the human-task as a webservice
war. That way, we could get rid of the
server, client and asynchronous code in the
module and concentrate on the <i>jBPM</i>
stuff. The JAX-WS standard includes
asynchronous webservices, and webservices
can be coupled to JMS implementations as
well. <br>
<br>
For more information on JAX WS asynchronous
services, please see the following links: <br>
<ul>
<li><small><a moz-do-not-send="true"
href="http://today.java.net/pub/a/today/2006/09/19/asynchronous-jax-ws-web-services.html#asynchronous-computation-with-future-and-callback"
target="_blank">http://today.java.net/pub/a/today/2006/09/19/asynchronous-jax-ws-web-services.html#asynchronous-computation-with-future-and-callback</a></small></li>
<li><small><a moz-do-not-send="true"
href="http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_jaxwsclientasync.html"
target="_blank">http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_jaxwsclientasync.html</a></small></li>
<li><small><a moz-do-not-send="true"
href="http://biemond.blogspot.com/2011/02/building-asynchronous-web-service-with.html"
target="_blank">http://biemond.blogspot.com/2011/02/building-asynchronous-web-service-with.html</a>
<br>
</small></li>
<ul>
<li><small>(not especially about async
services, but gives you an idea of
what the code looks like)</small></li>
</ul>
</ul>
<br>
Thanks,<br>
Marco<br>
<br>
10/20/2011 01:27 PM, Mauricio Salatino:
<div>
<div>
<blockquote type="cite">Hi Marco,
<div>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. </div>
<div><br>
</div>
<div>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: <a moz-do-not-send="true"
href="https://github.com/droolsjbpm/jbpm/pull/28"
target="_blank">https://github.com/droolsjbpm/jbpm/pull/28</a></div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Let's keep this discussion open
so we can gather more requirements
from the people that is using it.</div>
<div><br>
</div>
<div>Cheers<br>
<br>
<div class="gmail_quote">On Thu, Oct
20, 2011 at 7:19 AM, Marco
Rietveld <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mrietvel@redhat.com"
target="_blank">mrietvel@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000"> 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 <a
moz-do-not-send="true"
href="http://hudson.jboss.org"
target="_blank">hudson.jboss.org</a>)
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 <a moz-do-not-send="true"
href="http://hudson.jboss.org" target="_blank">hudson.jboss.org</a> is.
<br>
<br>
<br>
I guess I'm wondering what
other people's opinions about
this are! <br>
<br>
<br>
Thanks,<br>
Marco<br>
<font color="#888888"> <br>
<pre cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</font></div>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>