-
1. Re: Other Workflow/BPM players are getting inspired from the
tom.baeyens Sep 6, 2007 6:26 AM (in response to mvaldes)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 Sep 6, 2007 8:26 AM (in response to mvaldes)"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