5 Replies Latest reply on Oct 2, 2007 7:56 AM by tom.baeyens

    Instance class on the PVM ?

      I remember a previous discussion on the addition of an instance class at the PVM level, I would like to re-open this discussion to know your opinion guys:

      Indeed we are requiring the concept of instance at both BPEL and XPDL extensions. We are currently leveraging either BpelExecution and XpdlExecution classes (both extending Execution) to get the Root Execution (Process Instance concept) when needed.

      As far as any process language leverages instances why do not add this class to the PVM main concepts ?

      I think would be cleaner than (as currently implementations) add instance specific data to the Root executions.
      Even more, would be great to differentiate between root execution creation ChildExecutions in the PVM APIs

      Thoughts ?

      regards,
      Miguel Valdes

        • 1. Re: Instance class on the PVM ?
          tom.baeyens

          i agree with addition of a property called root to execution.

          i didn't get

          Even more, would be great to differentiate between root execution creation ChildExecutions in the PVM APIs


          • 2. Re: Instance class on the PVM ?

            Tom,

            I was suggesting to add a new class called Instance and to change the current newExecution() method in Process API by newInstance(). Previous method will return an Instance rather than an Execution ?

            newInstance() method

            Instance objects could have additional attributes to Execution and so it would be helpful to make the difference between Root and ChildExecutions:

            i.e current BPEL and XPDL Executions are extending ExecutionImpl and adding new attributes. Those classes are used to represent both root and child executions when childExecution will probably do not need added attributes.

            The point is to have a dedicated class to represent Root executions (Instance) different than ChildExecutions.


            regards,
            Miguel Valdes

            • 3. Re: Instance class on the PVM ?
              tom.baeyens

              i'm not against adding an instance class if it inherits from execution. but... i didn't see any arguments yet why we should do that.

              if a process language needs that change, the distinction between BpelInstance and BpelExecution can still be achieved with the current api. Just a matter of overriding the Proces.newInstance and execution.createExecution.

              does it introduce any more problems then that ?

              it would be nice to keep it simpler for the simple cases. then users wouldn't have to learn the distinction between instance and execution if they never use concurrent paths of execution.

              • 4. Re: Instance class on the PVM ?

                This is not a technical issue but more a conceptual concern.

                I'm concerning on how to have a maximum number of users happy with the PVM APIs... and so I think there is still a difference between Instance concept (from an end user point of view) than Execution (from a developers prespective), may be this differentiation is more on the languages extensions APIs than in the PVM side ?

                regards,
                Miguel valdes

                • 5. Re: Instance class on the PVM ?
                  tom.baeyens

                   

                  "mvaldes" wrote:
                  I'm concerning on how to have a maximum number of users happy with the PVM APIs...


                  me too :-)

                  "mvaldes" wrote:
                  and so I think there is still a difference between Instance concept (from an end user point of view) than Execution (from a developers prespective)


                  there is a difference. i agree. though

                  i don't think this difference relates to user point of view vs developer point of view

                  the current execution still allows you to differentiate process executions (=instances) from paths of execution (=executions). you can just look up the root execution. every execution that doesn't have a parent is an instance.

                  as i understand good API design, simple things should be simple and it's not that big of a problem if advanced things are a bit more difficult to achieve with an API. if we introduce a differentiation between instance and execution, we violate the first part of that equation. cause then users or developers will have to learn that difference. even if they only work with workflows that have a single main path of execution.

                  that said. in summary, i only have a minimal argumtation why i don't want to introduce the instance yet. so i'm looking for the arguments in your point. what would be the reasons why an instance would need to be introduced ?

                  so far i only understood your 'with a separate instance class, the model better matches with the real situation'. to which my answer is: only if you have workflows with concurrent paths of execution.


                  "mvaldes" wrote:
                  may be this differentiation is more on the languages extensions APIs than in the PVM side ?


                  to find that out, we must have use cases for why we want to split execution and instance. then we'll know whether we do it best on the language side versus the pvm level.