3 Replies Latest reply on Oct 10, 2014 10:47 AM by swiderski.maciej

    Script tasks vs. Service tasks

    happyhippo
    happyhippo Oct 7, 2014 7:42 AM

      Hello 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

        • 1. Re: Script tasks vs. Service tasks
          swiderski.maciej
          swiderski.maciej Oct 8, 2014 1:52 AM (in response to happyhippo)

          Dan,

           

          script tasks are mainly meant for rather simple cases like initialize variables and so on. They should not be used for service invocation (of any type not only remote services) as they lack any way to handle errors and whatever error happens in the service it cannot be processed to recover from e.g. retry.

           

          As it comes to service tasks you have all the powerful features at your disposal:

          • error handling
          • async execution
          • out of the box support for some of services - web service, REST, java method invocation and more
          • possibility to write your own handlers that could do all the checks, validation, versioning that you need
          • isolated testability
          • possibility to switch implementations (handlers) without touching process definition

           

          So personally I see services task as the way to go for actual implementations.

           

          When it comes to versioning of service tasks you can do it in two ways:

          • if the changes are backward compatible you simply use the latest version
          • if they are not then isolation on deployment level is required, not really possible in v5 (when using jbpm console) but with v6 each deployment is completely isolated. All dependencies are bound to the project only and by that you can have different versions of deployments using different libraries.

          Another approach could be to make use of the handlers to manage versioning but that would mean classes must be named uniquely to avoid classpath clashes (especially in v5).

           

          HTH

            • Actions
          • 2. Re: Script tasks vs. Service tasks
            happyhippo
            happyhippo Oct 10, 2014 10:04 AM (in response to swiderski.maciej)

            Maciej,

             

            Thank you for your detailed answer! I will try to go the way you proposed.

             

            One thing is still not 100% clear for me:

             

            • if they are not then isolation on deployment level is required, not really possible in v5 (when using jbpm console) but with v6 each deployment is completely isolated. All dependencies are bound to the project only and by that you can have different versions of deployments using different libraries.

             

            I understood that between 5.4 and 6.x is a big difference, and in 6.x the process definitions are being stored in an own artifact which you can reference using maven dependencies. Lets say we have following situation:

             

            A process definition with version 1.0 uses service tasks with Workitemhandlers that are part of myApp version 10.0.

            Now my business logic of the Workitemhandlers changes (not backwards compatible), and i update myApp to version 11.0, still using the process definitions with version 1.0 as a dependency. In order to keep backwards compatibility, i HAVE TO deploy both 10.0 AND 11.0 of myApp. Is this the way to go?

             

            Dan

              • Actions
            • 3. Re: Script tasks vs. Service tasks
              swiderski.maciej
              swiderski.maciej Oct 10, 2014 10:47 AM (in response to happyhippo)

              depending of what you mean by app. in version 6 the main application is jbpm console aka kie-wb that runs the processes. That allows you to put as many deployment units as you like. Deployment unit is a jar with dependencies. The main jar is the one that contains the business assets(processes and rules, etc) then it might have bunch of dependencies e.g. handlers, listeners, data model. Once deployed each of such a unit will have it's own class loader and will run in isolation. That allows you to deploy same process definitions with different dependencies.

               

              so you should always think about units as business assets(the knowledge) plus dependencies.

               

              HTH

                • Actions