2 Replies Latest reply on Sep 6, 2007 8:26 AM by mvaldes

    Other Workflow/BPM players are getting inspired from the PVM

    mvaldes Novice

      In a recently article on infoQ, ODE guys are pushing up a new concept which seems inspired from the Process Virtual Machine. They call that "Message-Passing Virtual Machine": http://www.infoq.com/news/2007/09/paul-brown-ode

      I guess Intalio guys were inspired since our last discussion in San Francisco around the PVM :-) well, that's great, we are just starting to create mindshare :-)

      In fact this concept is just a rename of their JACOB framework (http://ode.apache.org/jacob.html).

      I was having a look to it and I found some similarities and differences with the PVM that I would like to share in this post:

      - Both technologies are focusing on WaitStates and concurrency.

      - In both PVM and JACOB, nodes requires the implementation of a particular interface (NodeBehaviour vs JacobRunnable). Main difference here is that NodeBevahiour requires two method to be implemented: "execute" and "signal" and JacobRuntime only one "run". In fact signal operations in Jacob are handled by leveraging what they call "Channels".

      - In PVM, ExecutionImpl class is responsible for process instances execution. Different interfaces can be used to interact with the previous class depending of the user's type: external clients, PVM developers...

      In Jacob execution is handled by the VPU (a kind of processing manager) together with Channels and Method Lists.
      Jacob is completely based on Channels to handle node communications. Channels are interfaces used for nodes communication, an example of Channels is: TerminationChannel.

      My first impression is that Jacob was built up with BPEL in mind (in fact they do not try it yet to support any other process language on top), this is why everything holds on communication channels to handle control flow (in BPEL nodes always have relationships with other nodes).

      Did you guys had a look at Jacob concepts before ? Do you see this technology as a challenger for the PVM in the Java World ?

      regards,
      Miguel Valdes




        • 1. Re: Other Workflow/BPM players are getting inspired from the
          Tom Baeyens Master

          i don't think they were inspired by pvm.

          the communication channel approach comes from 'pi-calculus' although the link between pi-calculus and ode is only possible with a big freedom in interpretation.

          translation step from process models to their message passing vm is much harder. so that results into a much more difficult model of coding your own custom logic. something that turns out to be practially possible with our pvm approach as many developers have writting their own runtime behaviours. certainly for actions, but even for node behaviours.

          i don't think it's a competitor. they don't claim to run multiple process languages. and if they would do that they probably will face a lot of problems that are hard to fix in their design based on communication channels. aspectizing a pvm (like e.g. making persistence configurable and unpluggable, and operate in standard java and enterprise java) is hard.

          • 2. Re: Other Workflow/BPM players are getting inspired from the
            mvaldes Novice

             

            "tom.baeyens@jboss.com" wrote:

            i don't think they were inspired by pvm.


            Probably not by the PVM concepts by i'm in doubt about the name: this is the first time they use Message-Passing Virtual Machine for Jacob ?? :-)

            "tom.baeyens@jboss.com" wrote:

            i don't think it's a competitor. they don't claim to run multiple process languages. and if they would do that they probably will face a lot of problems that are hard to fix in their design based on communication channels. aspectizing a pvm (like e.g. making persistence configurable and unpluggable, and operate in standard java and enterprise java) is hard.


            I agree, for instance, peristence in their framework is directly handled by the VPU which is definetely not a good idea !

            They have already some pluggable services such persistence or integration with JBI or AXIS2 (SCA to come) but certainly standard vs enterprise versions support would be hard to achieve.

            In the roadmap no mention to support any other process language for the next versions.

            regards,
            Miguel Valdes