Article: Process Component Models: The Next Generation In Workflow?

Posted by Floyd Marinescu on Feb 11, 2008 03:48 PM

Community

Architecture,

Java,

SOA

Topics

Business Process Modeling ,

Business Process Management ,

Workflow / BPM

Tags

BPEL ,

BPMN ,

Modeling Tool ,

jBPM ,

WS-BPEL

In this latest InfoQ article, Tom Baeyens founder and lead of JBoss jBPM, wrote a summary of the state of Workflow & BPM standards and tools.  After a detailed look at BPEL, BPMN, and other technologies such as choreography, XPDL, BPDM, jPDL, Tom takes the stance that it is time to abandon the idea that non-technical business analysts can draw production-ready software in diagrams and separate the analysis process models and executable process models.  This separation is a foundation of jBPM (documented in The Process Virtual Machine) and Tom claims many similarities with the approach taken by MS's workflow foundation.

Read Process Component Models: The Next Generation In Workflow?

Going into detail on separating the execution framework from the process framework, Tom explains:

A first observation is that multiple process languages can be implemented on top of the same activity component framework. Each process language is composed of a number of activity types. For each of those activity types, the runtime behaviour can be implemented in a general programming language like e.g. Java or C#. So an executable process language just becomes a set of activity type implementations. The most important part of such an activity component is the code that implements the runtime behaviour of the process constructs. But also the XML serialization, the designer forms to configure the process construct, persistence and many other aspects can potentially be included in a process construct component.

The article has already been commented on by several other BPM framework providers including Sun's middleware & standards guru Mark Hapner.

1. Back to top

   Make a good choice

   Feb 5, 2008 1:27 AM by Rafal Ziolkowski

   Good choice is to use tool which can perfom both actions at one time. Then BPM Folks can model real actions and WS Folks can implement only some basic components. We choose Logic Base Studio from Transparent Logic (currently part of Altiris) wich is brilliant and effecient solution.

   Reply

2. Back to top

   Design diagrams that are 'input-only' are declining in value ...

   Feb 5, 2008 5:21 PM by Mark Hapner

   Tom, there is another aspect of this diagram/implementation gap that is missing from BPM discussions. The gap you describe so well does capture how industry thinks about the problem and the fact that most pure-play BPM products 'over state' their ability to 'round-trip' design and implementation. The other aspect is that 'upper case' design has more-or-less disappeared. From Google's perpetually beta services to Ruby scripted web apps, design and implementation is interleaved. The idea that something can be designed by a 'non-technical' user and then later implemented, isn't efficient enough for today's business pressure-cooker. This makes the design-impl gap even a bigger problem because the cross functional teams tasked with delivering new BPs can't get off the ground. If they can't continuously communicate through iteratively evolving notation of what's being built they are likely going to fail. They have to be able to start with a basic working model that is jointly improved; that all can interrogate and experience as it evolves. In this mode of development, diagrams with loose to non-existent semantics don't play an important role. On the other hand, diagrams that capture a facet of an evolving prototype are very useful. If the development environment can't spit these out then it just complicates the process of development via iteration.

   Reply

3. Back to top

   Re: Design diagrams that are 'input-only' are declining in value ...

   Feb 6, 2008 2:31 AM by Tom Baeyens

   I agree with you. Probably I didn't state it clear. In 'Process development process', I agree with you that round tripping between an analysis model and a technical model is basically not solvable. That gap is indeed too big. Therefore, I stated that the translation from an analysis model into a executable (=design) process model is a one-way translation. But I didn't want to imply that the connection with the analyst is broken at that point. On the contrary, the better the process language (BPEL scores pretty bad at this target), the better the design diagram will match the analysis diagram and then the analysts will still recognize it. Then the diagram serves as the common language between analysts and developers. But since the executable process artifact is now software, it should not be updated by the analyst in e.g. a graphical designer tool at that stage. The input should be collected by the developers in meetings and they should apply the changes to the executable process. In my presentation for JBossWorld next week in Orlando, I have put a picture to illustrate that reasoning. While this is the only way that the pure play BPM vendors approach the problem, this is not the only one way of making valid use of BPM technology. By far, most BPM is done by documenting the business processes (with Visio, IDS Scheer's ARIS or a BPMN modelling tool) and then *never* make the processes executable on a BPMS. It's only a small fraction of BPM use cases that try to make the bridge between analysis and design models. On the other hand, there is the technical approach. Where developers model the processes. In that case there is no analysis model. Only design process models.

   Reply

4. Back to top

   Re: Design diagrams that are 'input-only' are declining in value ...

   Feb 6, 2008 12:42 PM by Jarkko Lietolahti

   I simply love your picture. This is something I've always tried to explain to everybody, customers and IT-experts alike.

   Reply

5. Back to top

   Process Component Model

   Feb 7, 2008 9:45 AM by Miguel Valdes Faura

   I cannot but agree with the global message in Tom’s article. I definitely think that a process components model approach is the way to go when dealing with DSL based on processes. BTW, I would like to highlight that The Process Virtual Machine technology is the result of collaboration between Jboss and Bull and so you must consider Bull workflow and BPM open source products as a major player in this domain next years. Indeed we are on the road of providing a new version of our open source solutions based on this technology: Bonita (The XPDL open source project) and Orchestra (The BPEL open source solution). That said, I will also take the chance to disagree with some of the Tom’s arguments pointed out in the article. I have posted a dedicated item on this subject at BPM Corner community . Regards, Miguel Valdes The BPEL open source project: http://orchestra.objectweb.org The XPDL open source project: http://bonita.objectweb.org

   Reply

6. Back to top

   Good one Tom...

   Feb 7, 2008 9:07 PM by Zubin Wadia

   I think it's high time we stopped going the pure-play BPM route and came to terms with the realities of delivering customer value. As Tom mentions, Business Process Re-engineering initiatives get too caught up in the 'as-is' & 'to-be' business worlds and pay less consideration to other core aspects such as: - interacting with the domain model in an efficient manner (crafting lean payload exchanges). - building service interfaces that deliver more value than being simple decorators to data back-ends. - allocating time to translate their Process expressions to Process composites. There just isn't enough discipline and time spent on those aspects. And the result is a multitude of implementations that give BPM/Workflow/Orchestration approaches a bad name. A reasonable resolution at this point would be to stop pretending like the 'round-trip process engineering' technologies are delivering on their promises and focus on honing three technology areas to make it closer to reality: 1. Process Expression. Let's not get hung up on mapping models to BPEL. It's an impedance mismatch we'll just have to deal with. There are plenty of process expression suites that Business Analysts like to use. Let them work with what they are comfortable with. 2. Process Composition. There is opportunity here to allow a 'Technical Analyst' to begin the process of 'distilling' these expressions into re-usable blocks that properly delineate responsibility between processes, services, domain data & humans. A DSL for expressing process compositions is sorely missed (we have a rudimentary version of our own). Let's focus on expression first. Exchange later. 3. Process Implementation. Once you know the actual scope of the process vs. what the business analyst thought it would do - you can go ahead and define it in BPEL or use a simpler language abstraction like SimPEL (work in progress) for it. I like to call the resulting solution for the customer an 'Intelligent Composite'. It works. We have happy customers to prove it :). Cheers, Zubin Wadia CTO www.imagework.com "Business Acceleration through Process Automation."

   Reply

7. Back to top

   What does Route Planning has to do with Business Process Management?

   Feb 12, 2008 1:37 PM by Freddie van Rijswijk

   Tom, I liked your artice a lot and agree with the fact that BPEL (and the tools for it) is not suited for BPM. I would go even one step further and challenge the fact that a real business process is far more complex and event-driven and influenced by users and context that it's to my opinion NOT possible at all to model all possible variations to execute it. I guess we need an other mechanism (pattern matching, adaptive self learning systems, event driven) to be able to provide the business with goal driven automated processes. I have wrote a short blog-item on it in analogy with a route planner. see: http://www.gridshore.nl/2008/02/07/what-does-route-planning-has-to-do-with-business-process-management/

   Reply

8. Back to top

   Formalized DSL definition

   Apr 17, 2008 8:05 AM by Johan den Haan

   Tom, nice article! I totally agree with the idea of a component activity framework. I think the idea behind can be used in general for defining domain specific languages. I've worked it out with some scientific foundation in my blogpost: Combining general purpose and domain specific languages for Model-Driven Engineering

   Reply

9. Back to top

   Common misperception about BPEL's block-structured nature

   Aug 26, 2008 4:31 AM by Jörg Nitzsche

   Your article starts very promising. However, I had to stop reading when entering the "Thoughts and comments on BPEL" part.
   
   You write:
   "A BPEL process doesn't have a notion of transitions."
   
   Within a <flow> environment you can use <link>s to define the ordering of activities in BPEL. You can have links without transition condition or links with a transition condition which correspond to a BPMN sequence flow or conditional sequence flow respectively. So, in general, BPEL allows you to "to draw boxes and arrows" (arbitrary cycles are not supported).
   
   You are a victim of the commom misperception that BPEL is block-structured. Of course BPEL provides for complex activities like <sequence> and <if>, which allow you defining a block-based process, but BPEL supports also graph-based modelling.
   
   I know it's convenient to learn by reading other peoples articles/papers, but sometimes you guys should really consider taking a look to the specs...
   
   I skipped the rest of your article I but was interested in your conclusion:
   "BPEL is an executable process language, which [...] is not suited for supporting Business Process Management"
   Then you say:
   "By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the business analyst and the developers, based on one single diagram."
   
   Well, why not taking the intersection of BPMN and BPEL, which is BPMN plus DPE (Dead Path Elemination) minus arbitrary cycles, or simply BPEL (maybe minus WSDL)? :-)

   Reply

• Older >