Script tasks vs. Service tasks
happyhippo Oct 7, 2014 7:42 AMHello community,
the project i am currently working at (based on jbpm 5.4) uses exclusively script tasks (to call further service functions). After reading a lot, i noticed that the develpers favour service tasks over script tasks. I could not find any comparison between both methods, thats why i am asking here whether i should consider redesigning our current process definitions (one note before: the process definitions are designed and used ONLY by develpers, there are no business-analysts involved).
I would like to summarize both advantages and disadvantages of script / service tasks (as i see them) and i hope to find some feedback, why (and in which scenarios) one way is the superior one.
script tasks:
+ quick and easy to realize
+ possibility to change code flexible (without redeploying the whole application, just updating the knowledge base)
- no syntax / type checking --> runtime errors if you are not careful
service tasks:
+ type-safety
+ clear separation between process and code
+ better reusablility
(+ as i understood, the exception handling in workItemHandlers from jbpm 6.0 was improved)
(+ if you use service tasks via web services (e.g. REST), there will be / is some native support?)
+ / - you are more likely beeing forced to map in- and out-variables (dataInputSet, dataOutputSet, Assignments) compared to script tasks. This is an overhead, but also serves a better understanding of the process definitions
- large overhead by designing workItemDefinitions
- need to create extra classes for each workItemHandler
- with growing number of service tasks, the list of services in the designer (guvnor) might get confusing
I tend to implement new process definitions using service tasks exclusively and experiment with how they behave compared to script tasks in various requirements that we have. Maybe you see some advantages / disadvantages that i did not mention, and i am interested in which way you prefer.
Also i am interested in how you solve several other problems related to tasks, especially maintaining and versioning your service tasks:
Sometimes it happens, that (not touching the process definition itself) the logic within a service tasks has to be changed. How are your experiences in keeping backwards compatibility for older process instances that should use the old code? Do you create a new process definition each time the logic of a service might change (copy the old definition and replacing the old service with the new one) or do you handle the versioning problem within the service task itself?
I am hoping for a vivid discussion
Dan