[jbpm-dev] Human Task Module API and DataStructures Proposed changes
Maciej Swiderski
mswiders at redhat.com
Thu Jun 28 09:47:24 EDT 2012
Completely agree, discussion is starting to bring attention and
hopefully we'll get more comments/ideas.
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?
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.
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...
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.
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.
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 ;)).
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.
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.
Maciej
On 28.06.2012 01:30, Mauricio Salatino wrote:
> 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 at redhat.com
> <mailto:mswiders at 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 <tel:27.06.2012%2020>: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 at gmail.com <mailto:salaboy at 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 list
>> jbpm-dev at lists.jboss.org <mailto:jbpm-dev at lists.jboss.org>
>> https://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 -
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120628/e49d51bf/attachment-0001.html
More information about the jbpm-dev
mailing list