Home

News: Tom Baeyens: The Process Virtual Machine

  1. Tom Baeyens: The Process Virtual Machine (9 messages)

    Tom Baeyens and Miquel Valdes Faura wrote up "The Process Virtual Machine" on OnJava a few weeks ago. The idea behind the article: processes can be described using a general description, with specific languages like jPDL, BPEL, page flow, and others being implemented on top of the general "process code." As such, it mirrors the idea of the JVM and various languages implemented on it: BPEL would be a "process language" implemented on the "Process Virtual Machine." It's an interesting idea, offering many advantages to developers of all kinds: since it targets developers as well as business analysts (who are the normal beneficiaries of process languages), process flows can be used by more people, in more areas, with greater results. One example might be a process flow for web applications (as SEAM provides) on a grander scale. While the process flow is usable in SEAM (and, presumably, Web Beans, whenever it's completed), the idea is also generalizable for message queues, data items, workflow, the entire gamut - and having a process virtual machine means that developers can easily hook into the process flow without having to master the entire abstraction.
  2. This was written by IBM people in 1997. There's a book also. If I recall it also attempts to give a theoretical basis for Workflow. It's pretty big. http://www.research.ibm.com/journal/sj/361/leymann.html
  3. This was written by IBM people in 1997. There's a book also. If I recall it also attempts to give a theoretical basis for Workflow. It's pretty big.

    http://www.research.ibm.com/journal/sj/361/leymann.html
    While it's a nice overview article at that time, I think the IBM article makes the typical mistake of mixing the essence of workflow with things that you can build on top. A huge list of features is offered in all of the workflow and BPM products. The Process Virtual Machine is an attempt to separate the essence of workflow/BPM/orchestration from the features that can be build on top. That way, developers can add some simple and basic concepts to their repertoire. With that background, they can decide more easily and accurately wether workflow or process technology is applicable to automate their requirements. In short, the key to this is wait states. Programming languages like Java are good at describing a sequence of instructions. That doesn't fit very well with if your (long running) process has wait states. In 'The Process Virtual Machine', we describe the simplest set of concepts to build support for wait states on top of an OO programming language. But we also add a number of extensions that are necessary to build useful features on top in todays architectures. On top of the The Process Virtual Machine, we already were able to build diverse process languages like BPEL, jPDL and pageflow. And now we're working on XPDL. Further more, all this has been leveraged in a variety of environments like standard java (e.g. leveraging 1 JDBC connection to combine workflow updates and domain model updates), enterprise java (using global transactions), JSF, SEAM and so on. The ultimate goal of the article is to contribute to a common vocabulary for developers to speak about workflow and business processes whereas now, everyone seems to have their own definition of what workflow actually is.
  4. Perhaps a JavaScript VM?[ Go to top ]

    Perhaps a JavaScript VM with continuations would suffice as a target for business process engines? There are engines out there using Rhino directly: http://www.bpmscript.org Scheme could be another useful target. With something like http://sisc.sf.net coming to mind as a potentially useful tool.
  5. Re: Perhaps a JavaScript VM?[ Go to top ]

    indeed continuations can handle wait states from a programmatic point of view. but if you also want a graphical representation for your processes (as many, but not all of the BPM, workflow and orchestration solutions have) then continuations is not sufficient as you can't distill the graphical view from a program with continuations.
  6. The full version[ Go to top ]

    The OnJava article is in fact a shorter version of the full version of the paper. The full version has a more elaborate description on the extensions that are needed to build all the workflow/BPM/orchestration features. And it also has nicer graphics :-)
  7. As a complement of Tom's post, I would like to highlight that the PVM must be seen as a conceptual model for processes. The purpose behind is to create mindshare around process related concepts into the developers community. The PVM is also a technology which put those concepts in practice in the context of a collaboration started by Bull/OW2 (with both Bonita Workflow and Ochestra BPEL engines) and Jboss (with the Jbpm product). This technology will be the basis of our new versions of products at both sides. At the same time is good example of how different BPM vendors can work together on a common piece of technology that can be leveraged afterwards in different solutions. Last, but not least, the PVM is also part of our BPM approach:" there is no single process language that can handle the broad set of environments and capabilities that are associated with BPM. The concept of Process Virtual Machine (PVM) starts from the assertion that we’ll need different process languages for different environments" regards, Miguel Valdes
  8. If your interested in this topic, I highly recomend "Essential Windows Workflow Foundations". They show how the framework handles complex ideas very intuatively and far cleaner than most home-grown approaches I've seen. I could easily see a Java version, heavily influenced by WWF, that is more oriented towards the enterprise being very successful. I wrote a pretty sophisticated one at work to manage our ETL processes through a web-app, but while very successful I see areas I'd like to redesign if I had the time. There's quite a lot of work involved to make a solid enterprise-level job management framework, even more so since its the applications on top of it that matter. You need to write both to really understand the pain points.
  9. If your interested in this topic, I highly recomend "Essential Windows Workflow Foundations". They show how the framework handles complex ideas very intuatively and far cleaner than most home-grown approaches I've seen. I could easily see a Java version, heavily influenced by WWF, that is more oriented towards the enterprise being very successful.

    Sure, the WWF approach is quite similar that what we are doing on the PVM. The great thing is that the PVM is already Java focused.
    I wrote a pretty sophisticated one at work to manage our ETL processes through a web-app, but while very successful I see areas I'd like to redesign if I had the time. There's quite a lot of work involved to make a solid enterprise-level job management framework, even more so since its the applications on top of it that matter. You need to write both to really understand the pain points.
    Sounds interesting, we should definitely sit together and have a discussion on that if you are interested. Do you have some document discribing your work ? regards, Miguel Valdes
  10. Miguel, Yes, I noticed you the article mentioning WWF, so I was mostly mentioning it for those silent ones reading the comments. :) I didn't see your email address attached to the article, so feel free to email me at: ben dot manes at gmail dot com