4:25 a.m.
Hi Guys,
I've made a brief about the refactorings that I'm planning to do based on
the experiments that I was doing based on the concepts and requirements for
a Human Task module that we all know.
I've published this wiki page summarizing the main points that I'm
targeting to cover on this refactor, so I appreciate any feedback remarks,
questions.
https://community.jboss.org/wiki/HumanTaskModuleRefactoring
Let me know if you don't understand something or if you have doubts about
this approach. In my perspective this looks clear, simple, flexible as it
should be :)
But I'm open to any constructive criticism.
As mentioned in the document, you can download a working version of this
component from the following URL if you want to see how the APIs feel and
how the internals are working:
https://github.com/Salaboy/human-task-poc-proposal/
The next step after the feedback is making it real :)
Cheers
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
9:45 a.m.
Mauricio, great job with all the wiki's about it! it really helps to
follow the design.
As it comes for comments, most of them have already sent to you like a
month ago. In addition to those I have few more:
- is task definition service mandatory - I mean we already have
definition of a task as userTask in bpmn2 so don't see a reason why we
need to have definition once again stored on task server?
- seam transactions - does that mean we have tight dependency on seam
framework? do we want that? I recall that some time ago we tried to
remove such dependency... and wondering how that would look like in
other application servers, etc....
- backward compatibility - will we have any layer that will provide old
way to the new task server or we consider this as one time switch?
Maciej
On 19.07.2012 11:25, Mauricio Salatino wrote:
Hi Guys,
I've made a brief about the refactorings that I'm planning to do based
on the experiments that I was doing based on the concepts and
requirements for a Human Task module that we all know.
I've published this wiki page summarizing the main points that I'm
targeting to cover on this refactor, so I appreciate any feedback
remarks, questions.
https://community.jboss.org/wiki/HumanTaskModuleRefactoring
Let me know if you don't understand something or if you have doubts
about this approach. In my perspective this looks clear, simple,
flexible as it should be :)
But I'm open to any constructive criticism.
As mentioned in the document, you can download a working version of
this component from the following URL if you want to see how the APIs
feel and how the internals are working:
https://github.com/Salaboy/human-task-poc-proposal/
The next step after the feedback is making it real :)
Cheers
--
- 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev
3:13 p.m.
Hi Maciej, thanks for your old and your new comments. Do you remember if I
answer all the old ones? Answers in line
On Sun, Jul 22, 2012 at 3:45 PM, Maciej Swiderski <mswiders(a)redhat.com>wrote:
Mauricio, great job with all the wiki's about it! it really
helps to
follow the design.
As it comes for comments, most of them have already sent to you like a
month ago. In addition to those I have few more:
- is task definition service mandatory - I mean we already have definition
of a task as userTask in bpmn2 so don't see a reason why we need to have
definition once again stored on task server?
Good point, and the answer is: It depends. the UserTask information is just
a dimension of the information that can be stored about a Human
Interaction. As you well mention this information is already inside the
BPMN2 schema. We can decorate this information with additional information
if we want, and we can share those definitions between different processes.
Think about it as a UserTask template with some predefined values and
expressions. Is it mandatory? to have the same functionality that we have
today, no, it is not. But I would love to have the place holder to
implement the logic if we need it in the future. When you start thinking
about the form builder, sub tasking, questionnaires, etc inside the context
of the task, it will probably make more sense to have a place where we can
store that extra information that is not related in any way to the process
definition.
- seam transactions - does that mean we have tight dependency on
seam
framework? do we want that? I recall that some time ago we tried to remove
such dependency... and wondering how that would look like in other
application servers, etc....
Ok, I wasn't suggesting seam transactions, I was suggesting seam
persistence, which basically is doing all the dirty work that we are doing
for supporting different "Persistence and Transactions" configurations.
Think about seam persistence as Spring Persistence, if we adopt Spring,
that dependency will be required. The good thing about Seam Persistence is
that gives us all the glue to support Spring and Weld together under the
umbrella of the CDI specification. Chase me in the chat, if you want to
talk more about this topic, because I know that sometimes we think that
seam is more than what we it really is.
- backward compatibility - will we have any layer that will provide
old
way to the new task server or we consider this as one time switch?
Yes, but I will be working in parallel to implement the same set of
features using
the new proposed architecture. Give me a week and we can
think about how we can support or propose the jump from one to the other.
Because we are re-structuring the interfaces, at some point the migration
will need to happen, it doesn't matter the code behind the interfaces.
Maciej
Cheers, and thanks again for the comments!
On 19.07.2012 11:25, Mauricio Salatino wrote:
Hi Guys,
I've made a brief about the refactorings that I'm planning to do based on
the experiments that I was doing based on the concepts and requirements for
a Human Task module that we all know.
I've published this wiki page summarizing the main points that I'm
targeting to cover on this refactor, so I appreciate any feedback remarks,
questions.
https://community.jboss.org/wiki/HumanTaskModuleRefactoring
Let me know if you don't understand something or if you have doubts
about this approach. In my perspective this looks clear, simple, flexible
as it should be :)
But I'm open to any constructive criticism.
As mentioned in the document, you can download a working version of this
component from the following URL if you want to see how the APIs feel and
how the internals are working:
https://github.com/Salaboy/human-task-poc-proposal/
The next step after the feedback is making it real :)
Cheers
--
- 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 -
4505
days inactive
4508
days old
2 comments
2 participants
participants (2)
-
Maciej Swiderski -
Mauricio Salatino