<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Also, yes, javadoc in the jbpm code in
general is horrendous.. :( (I'm guilty as well). <br>
<br>
And documentation is .. sufficient, but not all that great -- we
give a high -level description followed by a few concrete
examples. <br>
Actually, seeing as throwing stones isn't all that effective, I'm
going to devote a week to making the documentation better (just
not this one. ;D but soon ). <br>
<br>
Marco<br>
<br>
28-06-12 09:00, Marco Rietveld:<br>
</div>
<blockquote cite="mid:4FEC0118.5040105@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Mauricio, Maciej, <br>
<br>
+1 on configuration. <br>
<br>
+5 for " facade for process interactions that hides some of the
steps and expose very simple API to interact with."<br>
In essence, we don't want the process engine (or anything else)
to trust the HT component at all -- and vice versa. <br>
<br>
Maurcio, I like the API's that you defined in the second
document (HumanTaskAPIAndDataStructuresProposal), but I'm
missing how they would be used with the current architecture. Do
you have idea's about that? (Actually, see the 3rd para after
this, for more ideas). <br>
<br>
Also, I think that the local human task service needs to be
pulled away from the current code base: at the moment, the local
human task service is essentially a facade that is based on an
infrastructure that was not designed for it's use that way. In
fact, the local human task service <i>was initially designed as
a demo</i> -- but has grown far beyond that. Luckily, it has
an API which means we can change the underlying implementation.
<br>
<br>
In short, I think the use case for the local task service is
sufficiently different from the rest of the use cases
(standalone/hornetq, etc.) that it should have it's own
infrastructure -- almost down to the task functional level. The
main reason for this is that persistence (especially tx's) are a
big part of the use case for the local task service -- but the
tx logic and request handling in human-task wasn't really
written with that in mind. I would like to consider rewriting
the code so that persistence and request handling could be even
more pluggable than they are (depending on local or standalone
task service). <br>
<br>
Separating the pure human task code out from the other concerns
(request handling, persistence) will probably also help to
create the API's that you define. <br>
<br>
Lastly, +10 on the API's -- but I really do want them to be
Interfaces. Where possible, I'd really like to make sure that
the underlying classes are not accessible to the user and that
there's a real focus on creating an interface that satisfies a
User's need -- instead of simply creating functionality for the
user and exposing it. <br>
<br>
Oh yeah, +1 on not forcing users to use the software a
particular way: they always end up surprising you and using it
another way. The more ways you can expose an API the better.. <br>
<br>
Regards,<br>
Marco<br>
<br>
27-06-12 23:28, Maciej Swiderski:<br>
</div>
<blockquote cite="mid:4FEB7AFA.6070904@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Mauricio,<br>
<br>
Do we foresee any use cases where task service will be used
without process engine? If so, I agree we could make it as
generic as possible but priority number 1 should be integration
with process engine to make it simple and intuitive.<br>
In general I like this separation but I am not convinced about
task definition service as to me it looks bit over designed to
the use cases I am aware of. One issue I see with this is that
we introduce task definition management in human task module
which I don't think should be concerned about. It should be only
runtime component and not repository for task definition. If we
think about storing task definitions that are reusable across
processes we should store them in guvnor rather than in
additional component (ht module). Since both designer and form
builder is integrated with it so no need for yet another
integration. This is more of tools responsibility and not
runtime component. Especially important in case of local task
service, since how we could store/deploy task definition into
local task service?<br>
Same applies for task delegation service, as this kind of
information could come from another place - repository and be
utilized by tooling.<br>
<br>
Configuration is week point in human task module currently so I
believe that this is very important element to be improved while
refactoring (or even redesiging) task module. I would see this
as single configuration service that allows to configure - in
this new way - all services with defaulting to convention over
configuration so well documented convention of configuration
points is a must.<br>
<br>
As it comes to integration between process engine and human task
it should be as simple as possible. I agree that in some cases
use of switch yard and camel makes sence but we should not force
users to include it every time. Simple interactions should be
available and in my opinion out of the box. For instance, make
use of jms provider that AS delivers instead of putting
additional frameworks in between.<br>
<br>
If you want to keep the services not aware of process
interaction then we should deliver facade for process
interactions that hides some of the steps and expose very simple
API to interact with, like addTask, completeTask, getTask,
getAssignerTasks, etc (part of this is probably in task instance
service). That will make a smooth interaction from the process
side which as mentioned already is most important, in my
opinion.<br>
<br>
For CDI, I am not expert here but what about standalone
adoptions, like swing, or other desktop frameworks, will CDI fit
into that?<br>
<br>
<br>
Let's encourage others here to speak up as we need more votes on
this refactor.<br>
Maciej <br>
<br>
<br>
On 27.06.2012 20:17, Mauricio Salatino wrote:
<blockquote
cite="mid:CANzbnyX=izTX5a_ifBfrzAXyJALo5ZKXb+XKC2_9v_fWe912gw@mail.gmail.com"
type="cite">Thanks Maciej for the questions. I've included
comments between the bullets
<div><br>
</div>
<div>
<p
style="border-spacing:0px;border-collapse:collapse;text-align:left;color:rgb(85,85,85);font-size:12px;font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;margin:0px;list-style:none;padding:0px;outline:0px;border:0px">"Mauricio,
couple of questions at the very beginning to understand
correctly your proposal:</p>
<ul
style="list-style-position:initial;border-spacing:0px;border-collapse:collapse;text-align:left;margin:0px;padding:0px
0px 0px 2.25em;outline:0px;border:0px">
<li style="color:rgb(85,85,85);font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;font-size:12px;background-color:transparent;border:0px;border-collapse:collapse;border-spacing:0px;margin:0px;outline:0px;padding:0px;list-style-type:inherit">Q:
how does task def service applies to process
interactions - when task definition will be deployed?<br>
A: I was trying to not think about the process engine
for exposing a Human Task Interactions APIs, but I
understand your question. Right now inside our
HTWorkItems we are calling the taskClient.add method
which in fact is doing a deploy and an instantiation of
a task based on the WorkItem params map. This parameters
map is created based on the userTask defined in a
process and its internal data mappings. That's from one
side. <br>
With the form builder, what can be done right now is to
"decorate" a userTask from a business process and define
a form based on it. So basically we do something like:
pick a process, get all the userTasks and for each task
we end up with a TaskForm.def this TaskForm.def can be
associated with a TaskDefinition, instead with a
TaskInstance, promoting reusability as much as we can.<br>
If we have this TaskDefService, we can make both: the
WorkItemHandlers and the Form builder to consume the
same information and reuse that as much as we can. We
can include the process designer in the loop and make
the Company Tasks Definitions available for the editor,
so the user when want to place a new UserTask inside
their process, can choose from a list of presets instead
of filling all the mappings, user assignments,
presentation details, notifications settings, etc.<br>
<br>
</li>
<li style="color:rgb(85,85,85);font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;font-size:12px;background-color:transparent;border:0px;border-collapse:collapse;border-spacing:0px;margin:0px;outline:0px;padding:0px;list-style-type:inherit"><span
style="background-color:transparent">Q: delegation
service - since that is on task def level - what about
sharing this information on concurrent task instances
since based on the same definition expressions can be
evaluated to different values<br>
A: Yes that's the idea. In the static information we
can have an expresion, in that case the expresion will
be evaluated with the TaskInstance context and the
result will be placed in the task instance context,
the task def information will not be changed, so it
can be safely shared between instances. All the
taskDef related structures should contain "templating"
information which means something for the company. All
the runtime status will be kept in the task instances.
Think about TaskDef, DelegationsDef, NotificationDef,
as shortcuts for the users to not define everything
each time that they want to instantiate a task.<br>
<br>
</span></li>
<li
style="background-color:transparent;border:0px;border-collapse:collapse;border-spacing:0px;margin:0px;outline:0px;padding:0px;list-style-type:inherit"><font
color="#555555" face="Lucida Sans, Lucida Sans
Unicode, Lucida Grande, Verdana, Arial, Helvetica,
sans-serif"><span style="font-size:12px">Q:how is this
going to be configured - per service or will there
be a configuration service as well</span></font><br>
<font color="#555555" face="Lucida Sans, Lucida Sans
Unicode, Lucida Grande, Verdana, Arial, Helvetica,
sans-serif"><span style="font-size:12px">A: good
question, we can add this topic for our board
session :) I'm not a CDI expert, but based on what
I've being reading, you can provide a default set of
services that will be automatically instantiated and
injected, and then you can provide alternatives. If
the user doesn't want the default settings he can
defined the alternatives via a vary basic
configuration file. Using CDI qualifiers we can,
with a pair of annotations, define which set
implementations (1 configuration) do we want for our
whole set of services. </span></font></li>
</ul>
<p
style="border-spacing:0px;text-align:left;outline:0px;padding:0px;min-height:8pt;border-collapse:collapse;color:rgb(85,85,85);font-size:12px;list-style:none;margin:0px;font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;border:0px"> </p>
<p
style="border-spacing:0px;border-collapse:collapse;color:rgb(85,85,85);font-size:12px;font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;margin:0px;list-style:none;padding:0px;outline:0px;border:0px">Would
be really nice to see how this is going to be utilized
from following perspectives:</p>
<ul
style="list-style-position:initial;border-spacing:0px;border-collapse:collapse;text-align:left;color:rgb(85,85,85);font-size:12px;font-family:'Lucida
Sans','Lucida Sans Unicode','Lucida
Grande',Verdana,Arial,Helvetica,sans-serif;margin:0px;padding:0px
0px 0px 2.25em;outline:0px;border:0px">
<li
style="background-color:transparent;border:0px;border-collapse:collapse;border-spacing:0px;margin:0px;outline:0px;padding:0px;list-style-type:inherit">Q:
process engine - how process engine will interact with
human task services<br>
A: This should not be a problem of this module, and I
think that this can be considered as an integration
problem, so it can be <br>
fixed with an specialized framework such as switchyard
and/or camel. I've being reading about the CDI support
for them.. and <br>
I think that we can go in that way. <br>
The Callbacks/Listener Service is intended to store
information about the Task Owners and their interest to
be notified about a tasks events. We need to think about
this a little bit more, because the Process Engine is
not the Task Owner of a TaskInstance that has being
created by a business process instance. The business
process instance is the owner of that task in that case,
so we will need to keep a reference from that process
instance inside this service. When I say, reference I
mean a business key, an ID, an endpoint or something to
be able to notify the interested ones. </li>
<li
style="background-color:transparent;border:0px;border-collapse:collapse;border-spacing:0px;margin:0px;outline:0px;padding:0px;list-style-type:inherit">Q:
task client - how to access tasks and to perform
operations on them"<br>
A: via the TaskInstanceService, its the same as our
TaskClient right now. (but restricted for TaskInstances
and TaskInstancesQueries, not add, not Comments, not
attachments, not notifications)</li>
</ul>
<div style="text-align:left"> <font color="#555555"
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande,
Verdana, Arial, Helvetica, sans-serif"><span
style="font-size:12px"><br>
</span></font></div>
<div style="text-align:left"><br>
</div>
<div style="text-align:left"> <font color="#555555"
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande,
Verdana, Arial, Helvetica, sans-serif"><span
style="font-size:12px">Cheers</span></font></div>
<div style="text-align:left"><font color="#555555"
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande,
Verdana, Arial, Helvetica, sans-serif"><span
style="font-size:12px"><br>
</span></font></div>
<br>
<div class="gmail_quote">On Wed, Jun 27, 2012 at 1:02 PM,
Mauricio Salatino <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:salaboy@gmail.com"
target="_blank">salaboy@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi guys,</div>
<div>I'm back with more wiki pages. I was thinking about
how to improve the Human Task Module and I came back
with this wiki page</div>
<div>that shows some proposals. </div>
<div>The main idea behind the proposal is to modularize
as much as we can the features provided by the human
task module. I've also included</div>
<div>into the proposal the concept of TaskDefinition
which will allow us to add a nice integration with the
form builder (in modeling and in runtime phases).</div>
<div><br>
</div>
<div>I'm trying to move towards CDI to leverage all the
mechanisms provided by the framework and the fact that
exposing CDI beans across different platforms is
extremely easy these days. </div>
<div><br>
</div>
<a moz-do-not-send="true"
href="https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal"
target="_blank">https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal</a><br
clear="all">
<div><br>
</div>
<div> I understand that the changes proposed in the wiki
looks quite heavy, but I do believe that we can fit
the current code base into that structure without
loosing functionality.</div>
<div> </div>
<div><br>
</div>
<div>The document is showing APIs and Data Structures
only. i think that we can assume that all the services
implementation will represent simple stateless
services which will </div>
<div>insert and read information from a database,
so architecturally speaking from that perspective the
service implementations should be straight forward. </div>
<div><br>
</div>
<div>I will be filling the Data Structure Sections
briefly, but I would like to share the main concepts
with you guys to gather feedback, as always.</div>
<div><br>
</div>
<div>Cheers</div>
<span><font color="#888888">
<div> <br>
</div>
-- <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>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
jbpm-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
jbpm-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</body>
</html>