Thursday 22 November 2007

Workflow In Java *Is* Sexy !

Ever since Marc Fleury started to wiggle with the foundations of the software industry, most people know that open source software doesn't just fall out of the sky. A good idea is not enough. It takes passionate people who believe they can make a difference. A project may start out as a hobby, but combining a day time job with after hours hobby rarely is sustainable for a longer period of time. That is in summary the idea behind Professional Open Source.

With the JBoss jBPM project, we are now having a kind of a luxury problem: The rate at which we can hire people from our community is greater then the number of contributors that join the project. Last night I talked about it to Stephan Janssen, the BeJUG chairman. Stephan suggested that maybe workflow is not sexy compared to hot technologies like Rich Internet Application (RIA) technologies and scripting languages.

That reminded me that BPM and orchestration still have a bad reputation in the developer community. Looking at all the other workflow technologies out there, I can't really argue with that perception. But in case of JBoss jBPM, it should be fairly easy to to show that our project is steaming hot and sexy! Especially when looking forward to what is coming in the next major version.

I'll start with the nittypittylittlelightest form of workflow ever and then build up to pure play BPM product features. In essence, the core of JBoss jBPM is a simple Java library to define and execute state machines. That is called the Process Virtual Machine. This already enables the simplest form of workflow in plain Java like this:

ProcessDefinition processDefinition = new ProcessFactory()
.initial().behaviour(new WaitState())
.transition().to("a")
.node("a").behaviour(new SomeAutomaticActivity())
.transition().to("b")
.node("b").behaviour(new SomeHumanTask())
.transition().to("c")
.node("c").behaviour(new WaitState())
.processDefinition();

Execution execution = processDefinition.startExecution();

What is really cool and sexy about our new PVM is that we have extracted the programming model for the nodes in a workflow in a NodeBehaviour interface. The NodeBehaviour interface looks something like this

public interface NodeBehaviour {

/** called when an execution arrives in a node. */
void execute(ExecutionController execution);

/** called when an execution, positioned in this node
* receives an external trigger. */
void signal(ExecutionController execution, String signal);
}
With this API it becomes childsplay to implement any kind of state machine behaviour for your specific use case. Furthermore, you'll be able to create custom extensions to process languages like jPDL, BPEL or XPDL this way.

At the next level, XML parsing is added. I admit, this is the least sexy of all, but the point I'll make is that the XML parsing is also pluggable for each node. That is still a little bit sexy, no ? Each process language needs it's own parser. The parsers we build for the process languages are based on JAXP so there are no extra library dependencies introduced outside of the Java 5 JVM. Each process language will have it's parser that walks the main structure of the process XML document. Then to parse the nodes, a Binding interface is used like this:

public interface Binding {
Object parse(Element element, Parse parse, Parser parser);
}

A node type now is made up of the runtime behaviour and the binding parser.

(btw, I hope that the language workbenches become mature soon on the Java platform. Instead of XML, I would much rather use a custom syntax language that has the look and feel of the Java programming language. But currently, that turns out to be harder for the graphical designer and the node pluggability)

Next is persistence. The sexy thing about our persistence is that in the PVM we'll support all forms of process persistence. As you saw above, processes can be created and executed without any relation to persistence.

Alternatively, you can read the process from an XML resource and save the state in your domain model object like for example an Order. A hibernate custom type that we supply takes care of converting the Execution field value into a state string, corresponding to the current node name. This is limited to a single path of execution, but it avoids the complete workflow database. The state is actually saved into your own domain model.

In case you do want the full workflow database to store the processes and executions, then we can easily link between your domain model objects (like e.g. an Order, Account or Customer) persisted with Hibernate and the process Execution.

For the process languages we support out of the box, we'll have hibernate mappings that store the process definitions and executions. But another sexy thing about the new PVM persistence is that you'll be able to add a new node with parser and complex configuration properties and keep the database schema stable.

Do you see it coming ? We're working towards easy customization of process languages. Development teams will rarely build a complete process language from scratch. But with the new PVM, they'll be able to take for example jPDL and extend it with their own custom node types very easily, without any deployment hassle.

Supporting this whole range of persistence options is IMO the most sexy of all! This is the main reason why BPM, workflow, orchestration and pageflow now all have different runtime engines. So with the new PVM, we'll be able to support the full deployment axis. This includes the different forms of persistence in both standard java and enterprise java. Apart from the deployment axis, there is the process language axis. So that gives some background into why this multitude of languages and runtime engines exist and how we're going to consolidate that.

Then on top of the XML and persistence, we're building out the usual BPM tooling like designers, web & administration consoles, business activity monitoring and so on. Since those tools are typically the only interface offered to developers, I can understand the bad reputation that BPM still has with developers. I hope that this post showed you that workflow can be sexy also for Java developers.

I can understand that in 5 years from now, workflow systems will be as boring as database systems. But in the meantime, building out the concepts and techniques behind those indispensable systems is ultimately sexy for clever developers.

So if you're looking for a sexy project to contribute to, look no further. JBoss jBPM is it !

7 comments:

  1. Hi,
    Yes, Years, Workflow, but why workflow cannot be hot and sexy?
    IMH, Tek and UI is the keys.
    For jbpm, who oriented? IMH, programmer or developer, but who use the products or final products? End users.
    Okay, what about UI? user and developer UI? same or difference?
    IMH, The same, so serviceR can talk about a process of workflow with his customer without trouble and barrier.
    osworkflow just for programmer, jbpm, I not truely try it, so I cannot say more about it.
    And I not get all means of this article of yours, Yes, I would read it again later.
    Maybe when that, We can talk more.

    ReplyDelete
  2. Working for more than a year on an Orchestration system using jBPM under the hood, and fighting over and over with the difficulties of customization, it sounds like we should have waited more than a year for the PVM to be ready.
    Is this PVM you`re talking about a forthcoming reality, or it`s is something not to be seen in a near future?
    Is there a way to see work in progress?

    ReplyDelete
  3. PVM is being developed in our svn at https://svn.jboss.org/repos/jbpm/tempranillo/pvm/trunk

    It's being developed in collaboration with the Bull teams so the next versions of Bonita and Orchestra will be based on that PVM as well.

    Please let us know what kind of difficulties in customization you had with jBPM. So that we can do our best to make it easier in the new version based on the PVM.

    My current estimation is that before the summer, the jPDL product based on PVM will have a similar feature set as the current. Starting from early next year, I hope to start releasing alphas and betas with parts of the functionality.

    ReplyDelete
  4. And anonymous access to the pvm source code is located at http://anonsvn.jboss.org/repos/jbpm/tempranillo/pvm/trunk/

    ReplyDelete
  5. I have worked with BPEL extension for over a year as well and have customized JBPM to fit our needs. But most of them are related to orchestrations and nothing in the base engine with couple of small exceptions. On BPEL side however, I have added support for dynamic url, soap headers, http headers to name a few that are required by real world web services. Will BPEL extension get ported to PVM as well?

    ReplyDelete
  6. Meghana,

    Yes, Bull is collaborating with us to build BPEL on top of the PVM.

    They have already done a release. Search for novaorchestra.

    regards, tom.

    ReplyDelete
  7. 1
    秋天賞楓何處去酒店經紀,安排韓國旅遊有獨到心得的寶馬旅行社表示 酒店打工,秋遊韓國的重點就是美食、溫泉、還有雪嶽山美麗秋景。位於江原道 酒店兼差束草、襄陽、麟蹄一帶的雪嶽山,是韓國最早楓葉轉紅的地方,也由於雪嶽山一年四季都有奇岩絕璧 酒店兼職
    、溪谷瀑布等美景,吸引了許多觀光客前來旅遊。一到 酒店工作秋天,以雪嶽山的最高峰~大青峰(1,708公尺)為首,雪嶽山各主要登山路線沿途的楓葉把山染 酒店上班成一片紅色的圖畫,美不勝收。


    標榜「全程無自費」,相當受旅客歡 寒假打工迎,而且價格相當平易近人,只要14500元即可成行。另外還有全程五星酒店、海陸空版的「戀戀秋濟^海陸空濟州4日」 暑假打工,同樣獨家全程無自費!緊張刺激360度噴射快艇(價值韓幣25000元)、飛天熱氣球(價值韓幣25000元) 酒店PT、海水溫泉汗蒸幕(價值韓幣8000元) 禮服酒店等,海、陸、空讓您玩的盡興也只要13900元!現在就去體驗韓國秋天的美景吧~


    驚險摩托車秀HAPPY TOWN 兼差價值韓幣12000元):表演者以機車為主,靈活的玩弄, 打工全世界只有兩組特技人員能做的高難度表演,在一個小時的演出中還有空中飛人﹑民俗雜技和大車輪 台北酒店經紀等表演,保證讓您大呼過隱,不虛此行喝花酒 特技令人嘖嘖稱奇。而享譽全球的國寶級亂打秀(價值韓幣45000元),是韓國人獨創的敲擊樂表演,故事的場景是發生在廚房中,因此所謂的樂器就是就地以鍋碗等廚房交際應酬 用具敲 打出澎湃的節奏。在沒有冷場的過程裡,不需要語言您就可以清楚知道劇情粉味的發展,台上演員還會與台下觀眾互動演出,整場歡笑不斷。


    去過的旅客都津津樂道的酒店喝酒韓文化生活體驗營」,讓您親手體驗泡菜製作,穿著傳統韓服更能體驗韓國婦女的優雅!另外,精緻好吃的韓國美食當然也不能 酒店不嚐:鮑魚太極人蔘雞、長壽麵、、黑毛豬烤肉、還有獨家特色餐「?花魚定食+五花肉+鐵板馬肉+?料」「生猛海鮮大餐」等等讓人食指大動。酒店經紀酒店經紀酒店兼差酒店打工酒店上班酒店經紀酒店小姐酒店打工酒店兼差 酒店工作> 彩妝指甲彩繪口紅彩妝馬甲美白

    ReplyDelete