[jbpm-dev] Human Task Module API and DataStructures Proposedchanges
Mauricio Salatino
salaboy at gmail.com
Fri Jun 29 07:49:44 EDT 2012
Hi there,
I will continue filling the wiki page, if someone wants to create a more
structured document about that, I'm OK with that.
Cheers
On Thu, Jun 28, 2012 at 10:07 PM, Carlos Crosetti <
carlos.crosetti at mostar.com.ar> wrote:
> **
> I like this content, however is a little difficult to follow, would be a
> good idea writing Scrum-like user stories?
>
> ----- Original Message -----
> *From:* Mauricio Salatino <salaboy at gmail.com>
> *To:* Marco Rietveld <mrietvel at redhat.com>
> *Cc:* jBPM Dev List <jbpm-dev at lists.jboss.org>
> *Sent:* Thursday, June 28, 2012 8:07 AM
> *Subject:* Re: [jbpm-dev] Human Task Module API and DataStructures
> Proposedchanges
>
> Hi Marco,
> Thank you very much for your feedback, it really helps to move this
> forward in the right direction.
> Some comments inline:
>
> On Thu, Jun 28, 2012 at 4:00 AM, Marco Rietveld <mrietvel at redhat.com>wrote:
>
>> Hi Mauricio, Maciej,
>>
>> +1 on configuration.
>>
>> +5 for " facade for process interactions that hides some of the steps and
>> expose very simple API to interact with."
>> In essence, we don't want the process engine (or anything else) to trust
>> the HT component at all -- and vice versa.
>>
>> The APIs exposed should be that. Like the current TaskService interface,
> only operations. I would like to know that we are on the same page about
> the interfaces. I'm interested to expose similar interfaces to the one
> exposed by the specification, which are extremely similar to the
> TaskService interface. On top of that I would like to promote some
> decoupling which enable us to provide different implementations for
> features which are required to integrate against a Content Repository, or
> something similar.
>
>
>> 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).
>>
>> 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 *was
>> initially designed as a demo* -- but has grown far beyond that. Luckily,
>> it has an API which means we can change the underlying implementation.
>>
>> The idea of the interfaces that I've created and described in the
> document is that. Behind those interfaces we can implement a very straight
> forward infrastructure like for example: Interface -> Implementation ->
> Database. As mentioned in another email, the Task*Service Services should
> be as stateless and as simple as possible.
>
>
>> 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).
>>
>
> On top of the very simple local implementation we can build the transport
> layers or reuse an existing framework like camel/switchyard. If we are in
> an EE environment we can instantiate the Local/Simple configuration and
> plug the transports provided by the container. One of the advantage of CDI
> is that it will make our life easier from the testing perspective and also
> from the pluggeablity and configuration perspective.
>
>>
>> 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.
>>
> The APIs that I've propose doesn't care about those topics, that's one of
> the main points. In some way the structures that the API is proposing
> affects how the persistence entities will look like, but I want to have
> clear interfaces that exposes the semantic of the work that we want to do
> with the module: Human Interactions.
>
>>
>> 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.
>>
>> They are all interfaces, we cannot force to the users to use one
> implementation. I'm pushing CDI forward to guarantee standards ways for the
> user to plug their own implementation if they want.
>
> I will be adding more details to the wiki page today to clarify some of
> the points that were mentioned in this thread.
> Unfortunately, I will be side tracked tomorrow with the form builder, but
> as soon as I can get back with this topic I will try to upload a very
> simple PoC to show how the interfaces will look like and
> the responsibility of each service.
>
> 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..
>>
>> Regards,
>> Marco
>>
>
> Cheers
>
>>
>> 27-06-12 23:28, Maciej Swiderski:
>>
>> 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.
>> 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?
>> Same applies for task delegation service, as this kind of information
>> could come from another place - repository and be utilized by tooling.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> For CDI, I am not expert here but what about standalone adoptions, like
>> swing, or other desktop frameworks, will CDI fit into that?
>>
>>
>> Let's encourage others here to speak up as we need more votes on this
>> refactor.
>> Maciej
>>
>>
>> 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 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 listjbpm-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev
>>
>>
>>
>>
>> _______________________________________________
>> jbpm-dev mailing listjbpm-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev
>>
>>
>>
>> --
>> jBPM/Drools developer
>> Utrecht, the Netherlands
>>
>>
>
>
> --
> - 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
> 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/20120629/196efc13/attachment-0001.html
More information about the jbpm-dev
mailing list