<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Completely agree, discussion is starting to bring attention and
hopefully we'll get more comments/ideas.<br>
<br>
For the cases that you enlisted I think that simple (even single)
interface would be desired especially for the most common
interactions (creating task, completing task etc) and I believe the
task instance could be this one. As the other would be more
important for task UI systems. I think that rule engine, self
service stuff, etc could use same way as processes, wdyt?<br>
<br>
Not getting task def service at all after your last comment here :(
so you would like to have a task component to talk to guvnor (most
likely that will be the recommended way for ootb) to gather task
definitions when creating task instances? I am looking at this from
process engine point of view where task definition is already stored
in the bpmn file so I am not really sure why we shall duplicate such
definition. I can find that useful for cases where processes are not
used at all then some task definitions are required but for default
(in my opinion default is use from process) this is not mandatory.<br>
What you mean for local task service we can provide three
implementation? How would you deploy task definition to a local task
service? I mean how we will access it...<br>
<br>
I thought form builder creates task forms based on bpmn userTask
information and then they are stored in repository (for instance
guvnor) next UI component would look it up but I am not sure it will
be human task module, I don't see it as UI provider. So if you could
put more details on form builder and ht module interactions I would
appreciate.<br>
<br>
By configuration I meant to have simplified (factory based) way of
getting ht module configured, there are several stuff that are
configurable (and probably with more services there will be even
more). For instance deadline handler, user group callback,
transports, events, access to external services such as email
server, etc. I would like to see this as single configuration point
maybe even with some configuration files as defaults but still
allows it to be configured over API too.<br>
<br>
Isn't CDI part of EE spec? And what about spring stuff, does that
fit it there too (I hope it does but want to address this at the
very beginning to avoid some of unexpected issues ;)).<br>
<br>
Last but not least, what about backward compatibility that we
discussed the other day? One thing is to change data model that is
relatively easy to upgrade but changing the API will force
users/customers to rewrite part of the system they have since many
of them use jBPM as embedded component that can be quite
challenging. That is especially valid in terms of BRMS 5.3 being out
now.<br>
With that in mind, is there even an option to keep current
TaskService as TaskInstanceService instead of providing brand new?
Of course there is a big need to refactor implementation behind it
but would be really great to keep that available at least for
process interactions. That I believe aligns with WS-HT spec that
defines single interface with all operations.<br>
<br>
Maciej<br>
<br>
On 28.06.2012 01:30, Mauricio Salatino wrote:
<blockquote
cite="mid:CANzbnyVUp-64N1jVUL-Y0wOAj50R-+fO+iOnej1L-ukDV5wv5g@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
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></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
jbpm-dev mailing list
<a moz-do-not-send="true" href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</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>
</blockquote>
<br>
</body>
</html>