Tuesday, 20 November 2007

Unifying Processes And Rules

In "A Vision for Unified Rules and Processes", Mark Proctor, lead of the Drools rules engine describes how he sees the further integration between rules and processes.

I believe that any company that isn't able to truly unify rules and processes into a single modelling system, how PegaSystems have done, will not be in a suitable position for the future. ... rules and processes must exist as first class citizens within the modelling and execution environment ... we need to make sure that we unify these models and allow it to go to much greater depths. Once rules and processes are fully integrated that modelling environment will benefit from any other declarative systems added, such as our plans to add Complex Event Processing (CEP) to the engine and language - this means we can have rules monitoring streams of data and triggering process milestones.

From a product point of view, I totally agree with Mark. In fact, I met him last week and I was impressed with the productization ideas they had for creating in integrated processes and rules environment.

For instance the Business Rules Management System (BRMS) manages the full lifecycle of rules from sources, over packaging to runtime deployment. The model and tooling that they have layed out would fit perfectly with jPDL processes. Futhermore, it supports both the developer use cases as well as the business user use cases. The drools vision in that respect is fully applicable to jPDL processes.

Similar for the business user test scenarios. Drools has a web UI for creating test scenarios on a business level. While this will not replace software testing based on something like JUnit, it does allow for business users to express basic scenarios. For non complex processes, this vision is also applicable to jPDL processes.

So if you look at it from a product point of view, we agree. The way I see this unification is a drools-jPDL integration is a single download that just can be unzipped to be installed. Integrated BRMS, console and designer. Drools has this approach and jPDL has the same appraoch with the suite distribution package.

But I see the componentization underneath the product quite differently. First of all I think that ruleflow should be merged with jPDL. They fit together and complement each other perfectly. I don't think that ruleflow should be a separate language from jPDL. Ruleflow could be build as a set of nodes build on top of the PVM. These nodes could be added to jPDL. Whenever you use them, you get a dependency on the drools.jar. This is just like with e.g. the beanshell based script node that we have now in jPDL.

Secondly, I don't think we need to integrate jar packages. IMO, "truly unify rules and processes" as Mark Proctor refers to, should be in the productized package that integrates jPDL (incl ruleflow) and drools. There is no need for the jars to merge in order to realize the vision as Mark Proctor describes it.


  1. I like the idea or Mark "A Vision for Unified Rules and Processes", but I can’t see how construct a bpm system, keeping separated package of rules and process. How design a data model that can be reused and integrated for rules and process. Maybe the 2 teams have to make architecture in paper; it could be a good idea.

  2. What do you think of Mark's view of jBPM and Drools using the same context/working memory?
    I'm currently integrating the two using the technique of copying context variables into Drools working memory outlined here http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmAndDrools

  3. anonymous,

    At the core of the integration in Mark's view is the automatic integration of the process variables and the working memory. In addition the capabilities of ruleflow will be usable in jpdl processes. On top of that Mark's vision includes a unified management of processes, rules and any other artifacts. The latter is beyond anything currently available and his ideas have already impressed many industry leaders.

  4. Saul,

    In a way, you alswered your question already yourself :-) Your application will still have a domain model. It's up to drools and jbpm to integrate with your domain model. The work that is now done on the jbpm-drools integration will make it very natural for a developer to work with those three in combination: your domain model, rules on the domain model and processes on the domain model.

    The tricky thing is that some (most?) BPM products are sometimes envisioned in a process oriented world, where the whole software development is centered around the processes instead of e.g. being part of java development. While this is a viable strategy for a small number of use cases, it's only one extreme end of the spectrum. Mostly it's a combination of java coded domain model, processes and rules.

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

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

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

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