Maciej, we are really moving this conversation forward.<div>Nothing is set in stone, but the more that I analyze this topic the more I think that this is the correct way to go.</div><div>See some comments inline<br><br><div class="gmail_quote">
On Wed, Jun 27, 2012 at 6:28 PM, Maciej Swiderski <span dir="ltr"><<a href="mailto:mswiders@redhat.com" target="_blank">mswiders@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 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></div></blockquote><div>Yes, sure, there are several:</div><div>1) The Rule Engine</div><div>2) The form builder </div><div>3) any other application that wants to start a human interaction. This is just a personal opinion based on my experience, but I believe that explaining to new people (including developers) how to use these projects, the steps are a) Human Tasks / Human interactions / task List oriented interfaces, b) Processes c) Rules d)Events</div>
<div>4) Self Service approach from Mark P, where you can build your application based on rules and processes, where ad hoc processes and the task independence is vital.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.</div></blockquote><div><br></div><div>Wait wait wait here! :) We are not talking about implementation here, we are talking about APIs. About the implementation I agree 100% with you. At least we are in the same page with that, if we provide one implementation of the Task Def Service will be using Guvnor as a repository for sure. Adding the interface to the Human Task project only make the project responsible to handle these definitions. Placing this interface in another module is like trying to remove the forms definitions from the form builder project. In my opinion there is no better place to put this interface, because is closely related with the Human Task concepts. A different implementation if the users wants to be Guvnor agnostic is to place the Task Definition in a database as an entity or using a different representation, it could be a JSON file as the form builder or an XML. I'm ok if we decide to unify this, but the interface and the functionality should be there. When you start analyzing the component in conjunction with the form builder this functionality is a must. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> 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></div></blockquote><div>For the local task service, we can provide three implementations (for all the components we should provide this): one file based, one using the database and finally one against Guvnor. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<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></div></blockquote><div>What do you mean with configuration? Like ports, paths, configuration files, properties, etc? Those should be defaulted for sure. </div>
<div>I was thinking about how the injection mechanism will work when the user wants to create these services, I think that I can create a PoC to show this in action. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<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></div></blockquote><div> The module should be environment agnostic (that's why I'm pushing for CDI), we can agree that in EE (AS) is JMS and in SE is a lightweight framework like camel or switchyard</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<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></div></blockquote><div>That's the TaskInstanceService, why do we need another facade? All the other clients from the module will require the same mechanisms to interact with the tasks, I'm not trying to hide the human task component from the process engine, I'm making sure that it's generic enough to support all the other clients in the same way.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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></div></blockquote><div>CDI will do the work for all the environment, that's the most important part, and then moving between a EE and an SE environment is just matter of implementations of the same services, but the APIs, how the resources are injected and how everything is configured is the same.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Let's encourage others here to speak up as we need more votes on
this refactor.<br>
Maciej <br><div><div class="h5">
<br></div></div></div></blockquote><div>That's why is in the jbpm-dev :) </div><div>I will be completing the Wiki page with more details, hopefully I can provide a PoC showing some concepts in action.</div><div>As mentioned in the wiki page the main objective is modularity and simplicity. I would like to keep each service decoupled and as simple as possible being focused in the Local Task Implementation and as a second steps the transports. </div>
<div><br></div><div>Any other idea is more than welcome!</div><div>Thanks a lot again!</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div><div class="h5">
<br>
On <a href="tel:27.06.2012%2020" value="+12706201220" target="_blank">27.06.2012 20</a>:17, Mauricio Salatino wrote:
</div></div><blockquote type="cite"><div><div class="h5">Thanks Maciej for the questions. I've included
comments between the bullets
<div><br>
</div>
<div>
<p>"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>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><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>
</p>
<p>Would
be really nice to see how this is going to be utilized from
following perspectives:</p>
<ul>
<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 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 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 href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a>
<div> - Co-Founder @ <a href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a 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 href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a>
<div> - Co-Founder @ <a href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br>
<br>
- Salatino "Salaboy" Mauricio -</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
jbpm-dev mailing list
<a href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br> - MyJourney @ <a href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a><div> - Co-Founder @ <a href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br> <br> - Salatino "Salaboy" Mauricio -</div><br>
</div>