<html><head></head><body bgcolor="#FFFFFF"><div>I think we should offer human task service as part of the bpm, but agree it should be a war to deploy along with the bpm. </div><div><br></div><div>Bpm is more than just an embeded process library these days. Competition will offer bam, task services, and form management in their toolsets, and we should too. </div><div><br></div><div>I am for using apache cxf for the task service. That way we can expose it as soap, soap over jms, or any of the other endpoint adapters with little more than configuration. </div><div><br></div><div>Brad</div><div><br><br></div><div><br>On Oct 20, 2011, at 8:17 AM, "Marco Rietveld" <<a href="mailto:mrietvel@redhat.com">mrietvel@redhat.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
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:
<blockquote cite="mid:CANzbnyXJj5r7A_a_3HJK-ug3hbMiBU9J0=A=MtW2uYy2U5uWKw@mail.gmail.com" 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">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">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 class="im"> <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 class="h5">
<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>
_______________________________________________<br>
jbpm-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
- CTO @ <a moz-do-not-send="true" href="http://www.plugtree.com" target="_blank">http://www.plugtree.com</a>
<br>
- MyJourney @ <a moz-do-not-send="true" href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a>
<div> - Co-Founder @ <a moz-do-not-send="true" href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a moz-do-not-send="true" href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br>
<br>
- Salatino "Salaboy" Mauricio -</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
- CTO @ <a moz-do-not-send="true" href="http://www.plugtree.com" target="_blank">http://www.plugtree.com</a>
<br>
- MyJourney @ <a moz-do-not-send="true" href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a>
<div>
- Co-Founder @ <a moz-do-not-send="true" href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a moz-do-not-send="true" href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br>
<br>
- Salatino "Salaboy" Mauricio -</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</div></blockquote><blockquote type="cite"><div><ATT00001.c></div></blockquote></body></html>