Maciej, we are really moving this conversation forward.
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.
See some comments inline
On Wed, Jun 27, 2012 at 6:28 PM, Maciej Swiderski <mswiders(a)redhat.com>wrote:
Hi Mauricio,
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.
Yes, sure, there are several:
1) The Rule Engine
2) The form builder
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
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.
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.
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.
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?
Same applies for task delegation service, as this kind of information
could come from another place - repository and be utilized by tooling.
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.
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.
What do you mean with configuration? Like ports, paths, configuration
files, properties, etc? Those should be defaulted for sure.
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.
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.
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
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.
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.
For CDI, I am not expert here but what about standalone adoptions, like
swing, or other desktop frameworks, will CDI fit into that?
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.
Let's encourage others here to speak up as we need more votes on
this
refactor.
Maciej
That's why is in the jbpm-dev :)
I will be completing the Wiki page with more
details, hopefully I can
provide a PoC showing some concepts in action.
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.
Any other idea is more than welcome!
Thanks a lot again!
On 27.06.2012 20:17, Mauricio Salatino wrote:
Thanks Maciej for the questions. I've included comments between the
bullets
"Mauricio, couple of questions at the very beginning to understand
correctly your proposal:
- Q: how does task def service applies to process interactions - when
task definition will be deployed?
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.
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.
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.
- 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
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.
- Q:how is this going to be configured - per service or will there be
a configuration service as well
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.
Would be really nice to see how this is going to be utilized from
following perspectives:
- Q: process engine - how process engine will interact with human task
services
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
fixed with an specialized framework such as switchyard and/or camel.
I've being reading about the CDI support for them.. and
I think that we can go in that way.
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.
- Q: task client - how to access tasks and to perform operations on
them"
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)
Cheers
On Wed, Jun 27, 2012 at 1:02 PM, Mauricio Salatino <salaboy(a)gmail.com>wrote:
> Hi guys,
> 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
> that shows some proposals.
> 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
> 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).
>
> 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.
>
>
https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal
>
> 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.
>
>
> 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
> insert and read information from a database, so architecturally speaking
> from that perspective the service implementations should be straight
> forward.
>
> 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.
>
> Cheers
>
> --
> - MyJourney @
http://salaboy.wordpress.com
> - Co-Founder @
http://www.jugargentina.org
> - Co-Founder @
http://www.jbug.com.ar
>
> - Salatino "Salaboy" Mauricio -
>
>
--
- MyJourney @
http://salaboy.wordpress.com
- Co-Founder @
http://www.jugargentina.org
- Co-Founder @
http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
jbpm-dev mailing
listjbpm-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev
--
- MyJourney @
http://salaboy.wordpress.com
- Co-Founder @
http://www.jugargentina.org
- Co-Founder @
http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -