[jbpm-dev] Human Task Module API and DataStructures Proposed changes
Mauricio Salatino
salaboy at gmail.com
Thu Jun 28 07:07:19 EDT 2012
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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120628/e8f4c63d/attachment-0001.html
More information about the jbpm-dev
mailing list