BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Why BPEL is not the holy grail for BPM

Why BPEL is not the holy grail for BPM

This item in japanese

Bookmarks

Introduction

Looking at recent articles and various BPM solutions, it would be easy to assume that BPEL is now the defacto standard to be used when implementing a workflow engine. From a technical perspective this may well be correct, however few people will claim that BPEL can be easily understood by the end-user, a.k.a the business analyst, who definitely prefers a graph based notation such as BPMN. This article will provide guidance in understanding the discrepancy between the technical point of view (pro-BPEL) and analyst's (pro-BPMN). Going further, even if most BPEL-based BPM solutions agree on the discrepancy (since they usually provide a BPMN to BPEL mapping) this article will explain why it is not currently the solution to BPM problems. A real-world example will be used to illustrate our arguments.

Parallelism and Structuredness in Programming Languages

Developers and BPM users may believe that BPEL [BPEL07] is a structured language since it is basically based on blocks, much as traditional languages such as Java and C amongst others. This comes in part from its origin: Microsoft's XLANG, which was block based. However, BPEL origins also include IBM's WSFL, and this is of great importance for the following discussion as it was graph based (hence unstructured). We find in BPEL a mix of structuredness (blocks) and unstructuredness (control-links and events). Those last constructs introduce a bit of unstructuredness into a world of structuredness... The conclusion is that BPEL is not a structured languages even if it looks like a structured language.

On the other hand, BPMN is a flow-chart notation which is naturally unstructured. No doubt about this. In chapter 11 (page 137) of the BPMN specification [BPMN06], a direct mapping from BPMN to BPEL is provided. Some BPMN editors (and users) believe that BPMN is a simple GUI for the underlying BPEL language. This is not quite true as explained in the BPMN FAQ:

"By design there are some limitations on the process topologies that can be described in BPEL, so it is possible to represent processes in BPMN that cannot be mapped to BPEL".

This article, will provide some fundamental details to that very important statement. But let's first focus on structured versus unstructured languages. Why is it so important? The main point is that it is much harder to perform code analysis on an unstructured language than a structured one (such as Java, C, and most --- if not all --- widely used programming languages). Code analysis has a wide range of applications, from error checking (e.g. compilers), to bug detection (e.g. findbugs, deadlock detection, ...) and quality checking (e.g. check style).

An important theorem from Böhm and Jacopini [BOHM66] (and vulgarized on Wikipedia) states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are:

  • executing one subprogram, and then another subprogram (sequence);

  • executing one of two subprograms according to the value of a boolean variable (selection);

  • executing a subprogram until a boolean variable is true (iteration).

This basically means that any (unstructured) flow-chart can be transformed into a structured one. This formed the basis of Dijkstra' paper "Go To Statement Considered Harmful" [DIJKSTRA68].

There is still a debate on whether we should allow unstructured programming language or not. Nevertheless, the facts are:

  1. most students in the world are taught structured programming;

  2. the most widely used programming languages are (non-strict) structured programming languages;

  3. most unstructured programming languages have introduced some structured constructions (BASIC, COBOL, FORTRAN).

So in general, most programmers do focus on structured programming but sometimes use unstructured constructions (goto, jump, break, exceptions) for various reasons (mainly readability, maintenance, sometimes performance).

Business Analysts Write Parallel and Unstructured Processes

A business analyst (BPM end-user) has to deal with the real world1, which is in essence not only unstructured but highly parallel. This has two implications:

  1. BPM end-users are usually not computer engineers, neither computer scientists: they design business processes using flow-chart notation (this is the most natural) for them, hence, unstructured (and parallel, this is important);

  2. in the face of parallelism, unstructuredness is more expressive than structuredness.

Point 2 is of great importance and has been formally proven by Kiepuszewski et al. [KIEPUSZEWSKI00]. The fact is that there are parallel unstructured, workflows that cannot be expressed into a parallel, structured one. Actually, those cases are quite simple to find. Consider this example using the BPMN notation (created with the Intalio BPMN designer):

In a tool that uses BPEL as its underlying format, a separate pool has to be created in order to validate that diagram. We will discuss this problem later, but the main point here is to focus on the pool called 'Employer' and the 6 activities it contains. When a new employee arrives at a company, a workflow is instantiated. First a record needs to be created in the Human Resources database. Simultaneously, an office has to be provided. As soon as the Human Resources activity has been completed, the employee can undergo a medical check. During that time, a computer is provided. This is only possible when both an office has been set up and an account created in the information system from the human resource database. When both the computer and the medical check have been performed, the employee is ready to work. Of course, you may want to model this simple process differently, but the point I want to make here is that you cannot define a structured parallel workflow that is equivalent 2 to this one, I mean, you will never be able to! We will use this simple example throughout this document.

As a first conclusion from this study we have:

  • developers naturally write their programs using sequential structured constructions (blocks);

  • BPM users naturally design their processes using unstructured and parallel constructions (graph);

  • unstructured and parallel workflows are more expressive than structured parallel ones.

There are workflows that BPM users will design that you definitely cannot express equivalently into a structured parallel workflow. Worse, also in [KIEPUSZEWSKI00], the author shows that even when the transformation from a parallel unstructured workflow to a parallel structured one is possible, it requires the addition of several variables and/or nodes, so that the final result is almost unreadable to the end user. We will speak soon about that readability problem.

Transforming BPMN to BPEL

In the article [OUYANG06], the authors proposed an automatic translation from BPMN to (readable) BPEL. They define a subset of BPMN due to unclear semantic in the specification. Hence, the OR Gateway and Error Intermediate Events are just not considered in their paper. This is a problem if the process being designed contains multiple end events since they are not considered by the transformation tool, and the standard way to convert from a multiple end events workflow to a single one is by using OR Gateways. The algorithm basically works like this:

  1. Try to find well known patterns that map directly to BPEL (sequence, flow, pick, while, ...) in the graph. For each of these, replace the component by a simple task containing the mapped BPEL code.

  2. Then, try to find some quasi-structured component and transforms them in such a way that most of the component is mapped directly to a BPEL structure.

  3. Then, search for acyclic BPMN sub-models (containing only sequence flows and parallel gateways). For these, use BPEL control-links.

  4. Finally, BPEL events are used for the rest.

The result is an "as readable as possible" equivalent BPEL process. Note that using events in BPEL we can always transform BPMN to BPEL. The problem is that the generated code is not readable at all. The conclusion is that an algorithm for transforming any BPMN diagram into an equivalent 3 BPEL process that is "as readable as possible" 4 does exist.

The Intalio Use Case

Note that this is certainly not the algorithm used by the Intalio BPM v2.0 solution for their transformation from BPMN to BPEL as shown by the simple example below. Taking the previous parallel unstructured BPMN diagram, the Intalio solution transforms it into the BPEL process, some of which is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<bpel:process
	xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"
	xmlns:pnlk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:this="http://example.com/Unstructured/Employer"
	xmlns:Employee="http://example.com/Unstructured/Employee"
	xmlns:diag="http://example.com/Unstructured"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"
	xmlns:bpmn="http://www.intalio.com/bpms"
	xmlns:atomic="http://ode.apache.org/atomicScope"
	queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
	expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
	bpmn:label="Employer" bpmn:id="_TGthsJkdEd29aqy0ek4Sxw" name="Employer"
	targetNamespace="http://example.com/Unstructured/Employer">
	<bpel:import namespace="http://example.com/Unstructured"
		location="Unstructured.wsdl"
		importType="http://schemas.xmlsoap.org/wsdl/" />
	<bpel:import namespace="http://example.com/Unstructured/Employer"
		location="Unstructured-Employer.wsdl"
		importType="http://schemas.xmlsoap.org/wsdl/" />
	<bpel:partnerLinks>
		<bpel:partnerLink name="employeeAndEmployerPlkVar"
			partnerLinkType="diag:EmployeeAndEmployer"
			myRole="Employer_for_Employee" />
	</bpel:partnerLinks>
	<bpel:variables>
		<bpel:variable name="thisEmployee_ArrivalRequestMsg"
			messageType="this:Employee_ArrivalRequest" />
	</bpel:variables>
	<bpel:sequence>
		<bpel:receive partnerLink="employeeAndEmployerPlkVar"
			portType="this:ForEmployee" operation="Employee_Arrival"
			variable="thisEmployee_ArrivalRequestMsg" createInstance="yes"
			bpmn:label="Employee Arrival" bpmn:id="_THp84JkdEd29aqy0ek4Sxw">
		</bpel:receive>
		<bpel:flow bpmn:label="GatewayParallel"
			bpmn:id="_DHLtcJkeEd29aqy0ek4Sxw">
			<bpel:sequence>
				<bpel:empty bpmn:label="Fill HR DB"
					bpmn:id="_hCvXsJkdEd29aqy0ek4Sxw" />
				<bpel:flow bpmn:label="GatewayParallel"
					bpmn:id="_H2UWEJkeEd29aqy0ek4Sxw">
					<bpel:sequence>
						<bpel:empty bpmn:label="Medical Check"
							bpmn:id="_ivks8JkdEd29aqy0ek4Sxw" />
					</bpel:sequence>
					<bpel:sequence>
						<bpel:empty bpmn:label="Provide Computer"
							bpmn:id="_lXApQJkdEd29aqy0ek4Sxw" />
					</bpel:sequence>
				</bpel:flow>
			</bpel:sequence>
			<bpel:sequence>
				<bpel:empty bpmn:label="Provide Office"
					bpmn:id="_iHEigJkdEd29aqy0ek4Sxw" />
				<bpel:empty bpmn:label="Provide Computer"
					bpmn:id="_lXApQJkdEd29aqy0ek4Sxw" />
			</bpel:sequence>
		</bpel:flow>
		<bpel:empty bpmn:label="Ready to work"
			bpmn:id="_nh6akJkdEd29aqy0ek4Sxw" />
	</bpel:sequence>
</bpel:process>

To get a better picture of the transformation output, we opened the process into the Eclipse BPEL designer:

For some reason, labels for the activities 'Fill HR Db', 'Medical Check', and so on are missing, but in any case we can see from the BPEL source code that the BPMN activity 'Employee Arrival' has been transformed into a 'Receive' BPEL operation. To the business analyst, it is strange to now see 7 activities ('Receive' and 6 other 'Empty' activities) while our original process contained only 6. Looking at the BPEL source code the puzzle is solved: we can see that the activity 'Provide Computer' has been duplicated. In some ways, this is good for the employee: they will get two computers in their office!

Whether the Intalio BPMN2BPEL transformation algorithm produces a readable BPEL or not, is not the issue here: the problem is that the transformation is simply wrong. You can hardly imagine the result for diagrams produced by professional BPM designers focusing on real business processes since they are highly parallel and unstructured in essence.

The Readability problem

The claim in [AALST_UNKNOWNDATE] is that BPEL is not readable by the end-user, so there is a need for a high-level language in which processes are designed. Typically though, runtime information is required before the process can actually be executed. How will this be entered in into the resulting BPEL code? One could argue this is the reason it is important to generate a readable BPEL code. In the case where all the information is entered directly into the editor/designer, at least for debugging purposes, the BPEL code should be as readable as possible where readable means: using BPEL direct straightforward structure (sequence, flow, pick, wait, etc...) as much as possible.

On this readability issue, let's introduce the eclipse JWT sub-project whose aim is to provide a toolkit for Workflow management (designer, transformations, simulations and connections to engine). JWT currently uses the UML Activity Diagram notation (UML-AD for short) for designing workflows. UML-AD is strictly equivalent (in terms of expressive power) to BPMN (see [WHITE_UNKNOWN_DATE] for details). So, using an UML-AD notation, we can represent the previous BPMN diagram in JWT:

JWT has been developed to be extensible, and provides different transformation plugins. One of them is a UML-AD2BPEL transformation provided as a research project from the University of Augsburg. The BPEL transformation plugin outputs a BPEL-WS-1.1 document that is 518 lines long (provided at the end of this document). Note that neither the Eclipse BPEL Designer nor the Intalio Designer were able to properly display this BPEL file. We used Netbeans for that purpose. The diagram produced is too complex to be presented here (see the resources section for a partial rendering of the diagram). The JWT2BPEL transformation tool uses BPEL events extensively in order to get the equivalent 5 BPEL representation. For the courageous readers who tried to read and understand the resulting BPEL file, it should be obvious that it is very hard.

So the simple parallel and unstructured process expressed using pure workflow notation such as BPMN or UML-AD is hardly representable into a “readable” BPEL format. This is a general fact, and not specific to the simple process we are discussing. The situation is worse when BPMN-to-BPEL round-trip engineering problems are taken into consideration: (from Wikipedia) “generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other”. Definitely, using BPEL as the final format for executing business processes expressed using a natural workflow notation such as BPMN is asking for trouble.

Note that making a BPMN diagram out of a BPEL process seems to be much easier than the reverse: transforming structured elements to unstructured elements is straightforward. Note that such a transformation --- BPEL2BPMN --- is provided in Intalio in the Java class available here. It seems to be in the core of STP and it is (currently) not fully BPEL compliant seeing the comments in the class:

/*
 * Very basic sample that generates BPMN out of a BPEL file.
 * The BPEL parsed is a small subset of the bpel spec:
 * scope, assign, receive, reply, invoke, flow, sequence.
 * ...
 */

Still, importing the BPEL file generated by the Intalio Designer itself does not work for obscure reasons. Nevertheless, the round-trip problem is about synchronizing two quite different representations of the same process: one in BPMN and one in BPEL.

Conclusion

First, we have clarified a common misunderstanding: BPEL is not a structured language, but it is based on a structured language (block-based). In some ways, BPEL is much closer to a standard language such as Java than to a natural workflow notation such as BPMN (which is graph-based). Until now, programmers have dealt directly with their language. Integrated Development Environments are used to simplify several recurrent steps such as compiling, refactoring, testing and so on. But programmers “speak” their language directly. We claim that it should be the same with BPEL. An IDE can only simplify programming (note that we don't use the term “designing” here). But BPEL programmers will have to “speak” BPEL in order to use it and make something useful out of it. The question of whether BPEL is “speakable” or not by general technicians --- as Java can be --- is out of scope of this article, but is definitely an interesting question.

For the business analyst however, it is clear that BPEL is not user-friendly. BPEL is hard to read, hard to learn, hard to implement, and most of all as this is the major end-user concern: hard to hide. We have already noticed that when creating the “Employer” pool in the simple example used in this document we were constrained to having to create another “non-executable” pool in order to generate the BPEL file. Many other BPEL related baggage is present in the Intalio designer that is irrelevant from the point of view of the BPMN analyst: e.g. namespaces, web-service invocations, and XML data type amongst others.

Therefore, we consider BPMN notation as the only currently viable solution for Business Analysts 6. Nevertheless, many execution details, absent from the BPMN specification --- and unknown at design time from the analyst --- will have to be specified before the process can actually get executed. This information is usually technical in nature and site (e.g. mail server address, task repository) or implementation dependent (e.g. web service, J2EE service or .NET service). It is therefore of a great importance that the process skeleton on which the technician will enter the environmental context is both equivalent to the original BPMN process in terms of execution semantics (bisimulation), and easy to read to ensure that modifications made do not change the process behaviour.

Transformation from BPMN to (readable) BPEL is quite hard to implement, and produces --- when correct --- hardly readable code. By the way, the round-trip problem is even harder. This last problem unless resolved, makes BPEL a very difficult target for the output of a process designed by a real business analyst.

Therefore, we may wonder why BPMN is transformed to BPEL since there exist a graph-based standard that maps directly BPMN constructs --- namely XPDL v2.0. With this mapping, XPDL v2.0 becomes the natural BPMN persistence file format. Moreover, it specifies behaviours that were only available previously in BPEL such as Web Service invocations and compensations. Of course, one may claim that XPDL 2.0 lacks some execution specifications that makes him unsuitable for direct execution. We believe that using the BPEL semantic wherever XPDL is under-specified makes room for an engine that can be fully BPMN v2.0, XPDL v2.0 and BPEL compliant. This is how Bonita and Orchestra team will implement their next generation of BPM engine. But this is another story, that requires an article of its own... Stay tuned!

I would like to thank the Bonita & Orchestra team for their help and support during the writing of this article, and especially Miguel Valdes-Faura for his review and suggestions. I would also like to thank Gavin Terrill for his help on corrections and final touches.

Pierre Vignéras

Bull, Architect of an Open World™

*BPM Team*, Bull R & D

Bibliography

Footnotes

  1. One may say that programmers also have to deal with the real world. But they are definitely not at the same abstraction level (what would be the point otherwise defining specific notations for analysts?).
  2. Of course we have to define what 'equivalent' means. Usually, in the processes world, the formally defined bisimulation [MILNER89] is used. But since it cannot make a difference between a parallel execution and its sequential simulation -- something that BPM users want, the notion of fully parallel bisimulation [EKIE89] is used instead.
  3. According to the notion of fully parallel bisimulation
  4. According to the common idea of a human readable BPEL, i.e. made of block wherever possible.
  5. By the way, proving formally that the resulting BPEL file is really equivalent (bisimulation) to the original BPMN diagram is left as an exercise... ;-)
  6. UML-AD notation may also be used as its expressive power is equivalent to BPMN. Nevertheless, we think that BPMN is closer to BPM analyst needs.

Resources

1. The JWT2BPEL transformation outputs this BPEL file.

2. Using NetBeans to get a graphical representation of the BPEL process presented in the previous resource, we get this diagram. This diagram represents the whole process, with the central part collapsed (the node with a '+' symbol). If we expand this node, we get an expanded diagram. On that diagram, we can see two nodes with a '+' symbol inside. They are respectively the 'Employee Arrival' activity and the 'Ready to work' activity of the BPMN original diagram. From the 'Employee Arrival' node, we see a BPEL scope labelled C5 from which events are attached. Those events are seen on its right side. Those events are used to implement in BPEL the parallel and unstructured flow specified in the original BPMN diagram.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Why BPEL is not the holy grail for BPM

    by Stephen Baudendistel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The links in the Resources section of the article are broken.

  • Re: Why BPEL is not the holy grail for BPM

    by Gavin Terrill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Fixed. Thanks.

  • Nice try.

    by Alex Boisvert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Think of BPEL as defining the set of instructions for a process virtual machine (e.g., VM bytecode)

    Now think of BPMN as a visual language to define process logic.

    Most would agree that VM bytecode is mostly relevant to language designers, virtual machine experts and programming enthousiasts trying to understand how high-level languages map to low-level instructions for correctness and performance purposes. Just like bytecode, BPEL was not designed to be read or written by people directly. The fact that BPEL is more readable than bytecode is simply a consequence of chosing XML as the interchange format; it does not imply it was designed to be read by business people.

    The main intent behind BPEL is to standardize the "instruction set" and semantic of the process virtual machine, such that:
    * process definitions can be exchanged between different organizations and run the same way on different VM implementations;
    * different languages (incl. BPMN) can produce the same bytecode and run on the same virtual machine;
    * most importantly, a larger ecosystem of knowledge, know-how, tools and solutions can develop around a standard process infrastructure.

    This article simply misrepresents BPEL and its value to the software industry. If the authors' aim is to increase the mindshare of XPDL, they might want to consider discussing its relative merits instead of spreading misinformation about BPEL.

    Alex Boisvert
    Director of Product Development
    Intalio inc.

    PS: Thanks for reporting an important bug in our BPMN-to-BPEL translator. We'll be sure to fix it in future versions of our software.

  • Re: Nice try.

    by John Mettraux,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "spreading misinformation about BPEL" : seems like Pierre is not the first one, if he did. See why bpel ? post by your CEO (then read a reaction to it from the academic community)

    John

  • Re: Nice try.

    by Tom Baeyens,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Alex,

    If you look at BPEL from the perspective of scripting a new course grained service out of finer grained services, then it makes perfect sense. Cause in that scenario, all the services you want to consume are already available.

    BPEL has XML based services as their building blocks. XML based processing technologies (XPath, XQuery) are in kindergarten compared to what you can do in languages like Java. So for every tiny bit of processing you want to do in a BPEL process you need to build this functionality in a programming language, expose it as a service and then call that service from the BPEL process. This creates a huge overhead for the developer.

    As explained in 'BPM as a discipline' (see my article Seven Forms of BPM), software development is done in silos (aka software projects). First, in this scenario, the business process diagram provides the structure, but typically a lot of logic in the business process needs to be coded and associated to the business process. That is where BPEL's foundations on WSDL are a PITA because all of your business logic will have to be written in a programming language and then exposed and consumed as a service. Second, software projects are a combination of processes, domain models and mostly some UI. So processes need to be integrated with the software development projects. I believe that is where the BPM bottleneck has been to this date. Some think that BPM-as-a-Service will bring light at the end of the tunnel, but I think that is only making the integration with a software project more difficult. To integrate process technology in to an application or software project, WSDL (read: web services) is not the most appropriate way to bind these together.

    That's why we believe that a Process Virtual Machine should be build on Java technology, rather then WSDL (read: web service) technology. From Java you can easily call other Java code, but also webservices when that is needed. We also believe that business processes are most often related and embedded into an application. That's why embedding those processes in a Java project usually makes more sense then extracting them and putting them into the Enterprise Service Bus (ESB).

    And as a side note: Now vendors like yours claim that BPMN - BPEL is the way to go. But wasn't BPEL intended to provide the business level diagram in the first place ? So now you translate graphical BPMN to another graphical BPEL process. I don't think the BPEL diagram makes sense. If you look at it as byte code, it should be transparant. In that perspective, it should not matter whether the "byte code" is BPEL, Java, byte code or assembler.

    Our Java-based Process Virtual Machine is much more capable of providing that byte code layer. We already have BPEL, XPDL and jPDL running on it. And XPDL and jPDL are much closer to BPMN then BPEL.

    Tom Baeyens
    JBoss jBPM

  • Re: Nice try.

    by Pierre Vignéras,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Seing this in your reply:

    Thanks for reporting an important bug in our BPMN-to-BPEL translator. We'll be sure to fix it in future versions of our software.


    clearly shows that you misunderstood the post. Even if you fix that bug, it does not mean that the resulting BPEL file will be readable. Therefore, the problem will basically remain. As shown by the JWT UML-AD2BPEL transformation tool --- which as the merit of being correct on that simple example by the way --- the BPEL generated file is not readable. And the round-trip problem makes the problem even worse. Claiming that BPEL " was not designed to be read by business people " is non-sense : what does the 'L' stands for in BPEL? Language isn't it? So BPEL would be the first language not designed to be readable?

    Regards.

    PS: There are other important bugs (such as this one) that we have identified on the Intalio BPMN2BPEL transformation tool (and on the Intalio solution as a whole). But we cannot really contribute since the Intalio source code is not available (that is rather strange for a so called open-source solution):

    dev.eclipse.org/newslists/news.eclipse.stp/msg0...
    jorgechollet.wordpress.com/2008/08/11/so-wheres...

  • Re: Nice try.

    by Robert Morschel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Tom,

    PVM seems to overlap conceptually with SCA, or have I missed the point?

    Robert
    soaprobe.blogspot.com

  • Re: Nice try.

    by Mickael Istria,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Robert,

    PVM is about processes and and is an architecture/API of runtime able to run any graph with nodes and transition. On top of the PVM, you can describe a workflow engine or a web service orchestrator or any process engine that is intended to run processes that can be described with nodes and transitions. (Tom, feel free to correct me if I'm wrong)

    SCA is not about orchestration nor process, it is about assembly. What you describe with SCA are in fact services (external or SCA components) and dependencies between them. A SCA description is not a "process" and does not describe an "orchestration" of services, it simply defines components with injection of services (like Spring for Java, but with a great service comprehension). SCA components are not states but components, and SCA edges are not transitions but dependencies.


    Thus, I don't really see the overlap between both technologies, but I may be wrong...

    Regards,
    Mickael

  • Re: Nice try.

    by Tom Baeyens,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Robert,

    PVM is about processes and and is an architecture/API of runtime able to run any graph with nodes and transition. On top of the PVM, you can describe a workflow engine or a web service orchestrator or any process engine that is intended to run processes that can be described with nodes and transitions. (Tom, feel free to correct me if I'm wrong)

    SCA is not about orchestration nor process, it is about assembly. What you describe with SCA are in fact services (external or SCA components) and dependencies between them. A SCA description is not a "process" and does not describe an "orchestration" of services, it simply defines components with injection of services (like Spring for Java, but with a great service comprehension). SCA components are not states but components, and SCA edges are not transitions but dependencies.


    Thus, I don't really see the overlap between both technologies, but I may be wrong...

    Regards,
    Mickael


    +1
    spot on.

    so you can leave out the "but I may be wrong" part, Mickael :-)

  • Re: Nice try.

    by Tammo van Lessen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So, is this now the InfoQ "Exclusive Content" Intalio bashing? Who's next? Who's sponsoring?

    Anyways, it's actually neither Intalio's fault, nor BPEL's, nor BPMN's nor a wrong translator. The actual problem is based on the problems graph-based modeling impose. I'm personally a big fan of graph-based modeling, however, it leads to specific problems like Lack of Synchronization and Dead Locks when it comes to execution. So, to deal with this problem there are a few possibilities: a) ignore the problem (this is AFAIK the jBPM, PVM,... approach), which is perfectly fine as longs as people make their models right. b) There is currently a lot of reseach efforts to detect such problems in arbitrary graphs. A solution can be to combine a) with such soundness checks and finally c) make sure that the language as a defined and foolproof execution semantic. The latter is the BPEL way.

    I understand that business people don't want to deal with such problems. However, when they notice that their processes get stuck in a dead lock, they would be happy if there would be something like DPE, be it by knowing it and directly modeling BPEL, or by having a tool that takes care of this, that ensures that the BPMN model (with rather unclear semantics) is transformed into a foolproof and properly executable process model (e.g. BPEL). Who would care whether its still "beautiful BPEL" as long it works as expected? Compare it to C++ -> Assembler. I'm pretty sure there are Assembler pros who claim that such generated code also looks strange. If you take a closer look at reference process models you will find that most of them are not fully correct. In this case I definitely prefer the foolproof solution. I don't believe that both can be achieved without making compromises. Let's see what the BPMN 2.0 tradeoff brings.
    Bashing around would be another option ;)

    Regards.

  • Re: Nice try.

    by Alex Boisvert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Pierre: Is your best evidence that BPEL should be readable by business people the fact that it's called a Language? Would you say that assembly language is readable by most programmers? The fact that BPEL is hard to read has been acknowledged for many years. In fact, it's one of the main reasons we've started the SimPEL dialect [2] -- a syntax variant of BPEL that is more friendly to programmers (but still not aimed at your average business person).

    @Tom:

    1) BPEL was not intended to provide graphical modeling -- this is another common misconception. A long time before BPEL was finalized, many organizations (including many who were on the BPEL working group) had already started to work on the BPMN notation, knowing full well that BPEL would not fit the requirements of graphical business process modeling. The suitability of BPEL to graphical modeling is only incidental.

    2) You are quite right with your comment about language integration. WSDL is both a strength and a weakness for BPEL. On one hand it forces process designers to think in terms of high-level service building blocks (so-called 'programming in the large'), on the other hand BPEL left out a fairly critical part of the integration story. I'm one of those people who believe this was a good choice. Specifying how BPEL 2.0 would integrate with programming languages as part of the same effort would have been premature. It was a better choice to leave this out of scope of the specification and allow time for experimentation. IBM's own attempt at this was BPEL4J. It think it's fair to say now that it was a good shot at the problem but didn't really succeed. Our own experimentation, within Apache Ode, has led us to SimPEL and in particular, the integration of JavaScript (incl. E4X extensions) with the BPEL language model into a friendly process scripting language. Time will tell if this is a winning combination but so far the feedback has been very positive.

  • Re: Nice try.

    by Tammo van Lessen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BPEL was not intended to provide graphical modeling -- this is another common misconception. A long time before BPEL was finalized, many organizations (including many who were on the BPEL working group) had already started to work on the BPMN notation, knowing full well that BPEL would not fit the requirements of graphical business process modeling. The suitability of BPEL to graphical modeling is only incidental.


    I don't agree. I consider graphical modeling one of the most powerful features of BPEL as it makes it less a (parallel) programming language but rather introduces means that business people can easily deal with (sticks and boxes). Its for instance pretty hard to refactor a block structured model (because you'd need to change the nesting) but pretty easy if you just can bend links. In any case its a matter of tooling and unfortunately current modeling tools are not as good as needed. I believe that SimPEL, BPELscript, ... can surely help to make BPEL a more accessible to more people but it targets developers only. To reach business people, graphs _plus_ very good tooling is IMO required and capable to do the job.

    Regarding the WSDL issue: I also think that tools should try to hide the WSDL informations from modelers as good as it gets, either by providing high-level means of an SOA, allowing users to easily select registered services for partner links, by employing semantic web technologies (e.g. BPEL4SWS) or by removing the dependency on WSDL completely and moving the binding to deploytime (the "BPEL light" approach). When BPEL is just about defining data and control flow between message exchanges with a well-defined execution semantics, I believe that BPEL provides the armamentarium for business modelers.

  • BPMN XML Serialization Format

    by Bernd Eckenfels,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting enough it looks like the new BPM Process Engine "Galaxy" in SAP Netweaver CE EHP1 is not using BPEL. The modeller is based on BPMN and rumors on SDN are, that the process model is planned to be in the upcoming BPMN 2.0 serialization format.

    I personally think that the BPMN is quite disambiguos, missing the simple executability of BPEL. However UML serialization formats (which have the same lack of semantics) proofen to be usefull. And it looks like the submissions to OMG try to define execution semantics as well (OMG yet another xml language for execution?!)

    www.brsilver.com/wordpress/2008/10/08/bpmn-20-s...

    However a interchange format for BPMN models is highly desireable.

    Greetings
    Bernd

  • Re: Nice try.

    by Stefan Tilkov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Tammo, you wrote

    So, is this now the InfoQ "Exclusive Content" Intalio bashing? Who's next? Who's sponsoring?

    Not being entirely sure what you're suggesting, but vendor content is clearly marked as such on InfoQ. There is much more opinion than truth in all things SOA and BPM, but we're trying to make very sure that when someone expresses their views, they do so under their own name.

    We'd be happy to consider articles for publication that make the case for the opposite view.

  • Re: Nice try.

    by Tom Baeyens,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ...leads to specific problems like Lack of Synchronization and Dead Locks when it comes to execution. So, to deal with this problem there are a few possibilities: a) ignore the problem (this is AFAIK the jBPM, PVM,... approach)


    We don't ignore it. We see executable processes similar to any other form of software and hence it needs a test suite. A test suite actually shows that the executable process actually does what you want it to do. Whereas static analysis techniques can only raise a red flag and ask the modeler: "Are you sure?"

    In BPM as a discipline, writing tests for executable processes is the only option. Dead Path Elimination (DPE) will not be sufficient. Non technical people will not be able to produce software. But they are able to produce models on which the executable process models can be based. Once a diagram becomes an executable process, then it becomes software and needs to be tested as such. Preferrably in combination with the rest of the application.

    Only when a specific purpose process language (kinda like a process DSL) is very limited in scope, then it might be possible to make sure that non technical people can actually model executable processes. But in those cases you have to simplify the modelling capabilities to such a low level that you can only handle very specific things with it. Like e.g. specifying approvals in a document management system.

  • Re: Nice try.

    by Robert Morschel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In that case I'll take a more detailed look. Thanks.

    Robert
    soaprobe.blogspot.com

  • Not the only way to go

    by Alexis Brouard,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Pierre,

    You're right to say BPEL is not a structured language and BPEL programmers will have to speak BPEL (both are obvious from my point of view). I also agree that BPEL is not user-friendly (but was it designed to be?).
    However, for a BPEL programmer, I think it is neither worst or best than another (programming) language: in every language you can do beautiful things (in your discussion, you can read "beautiful = readable") as very ugly ones depending of the principles and the expertise you have in it.
    You also give the need to create a non-executive pool aside the "Employer" one to generate a BPEL file; this is more a BPMN constraint than a BPEL one so it's a bit unfair to take this as an sample to make BPEL dirty...

    You also say that you consider BPMN as the only currently viable solution for Business Analyst even if the model should be reviewed by technical people to add specific details (that is more than normal as, unfortunately, IT is complex and needs specific skills to be successful).
    However, I think BPMN (or UML) is too complex for non-IT compliant people (I mean not "algorithm-structured mindset" people) such as business analysts.
    When you don't think with an algorithm thinking, you just can't do BPMN (or UML or any programming language) as you won't be able to figure the tokens that flows from gateways to branches and (unpredictable) events to activities.

    About bisimulation and round-tripping: you're absolutely right! There's no easy way to do them with BPMN and BPEL.
    But, as far as I know, I can't easily check bisimulation nor easily do round-tripping with, let's say, UML and Java (and this, even if I respect MDA philosophy and standard!).
    Does this mean this is a wrong way to go?
    No, this just means we still have work to do to improve our industrialization tools and processes.
    But we should also be careful of not hoping for a myth of the allmighty button which, when clicked on it, produces all the complex systems we've designed and optimizes the code (and making it readable) at all steps of the process! If you want to reach efficiency, you need to tune (code, designs, hardware) and there is no way to do it for all.
    There is a way to do it for a specific context because the context is... specific (i.e. does not aim to cover all cases).

    Your last part about XPDL is right but where is the contradiction of switching from BPMN to BPEL and not going through XPDL?
    XPDL is a format to exchange process models between modeling tools. So storing in XPDL a process model drawed with BPMN is completely normal (for instance, Tibco Business Modeler - a free tool quite concurrent to Intalio Designer - do it well). By doing this, you can open your process model in another modeler (and maybe in a modeler that do not support BPMN is the XPDL file does not abuse of extension sets).
    In what I agree with your claim is that there is no XPDL to BPEL transformer (or I don't know about it) and maybe this could be a way to go to generate BPEL files.
    But this does not mean the other ways are wrong...

    To conclude my too long speech, thanks to you for saying, claiming and proving that BPEL is not alone in the BPM world (especially in modeling) and BPMN + BPEL is not the only way to go.
    But please, do not invalidate those ways as they are valids (in specific contexts) but they can be improved on several subjects (tools included but not only the Intalio ones, also IBM, Tibco, webMethods and SAP ones ;-) ).

    Alexis

  • Re: Nice try.

    by Tammo van Lessen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BPEL was not intended to provide graphical modeling. [...]


    I don't agree. [...]


    Being able to read helps. graphical modeling != graphbased modeling. So, we're in sync :) Sorry for the noise.

  • My BPM advice: Listen to Tom Baeyens / use jBPM!

    by Brett Gorres,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you're doing SOA and want to build a great process-oriented system TODAY, look at jBPM--specifically the jPDL version, which is to say, NOT BPEL. I don't see a compelling reason to go with a heavyweight BPM approach, when jBPM is so competent. And I have consulted at shops where they've used heavyweight BPM systems.

    If you're into modeling (as I am):
    As an Eclipse user, I appreciate the GPD (graphical process designer) and the XML code it maintains (bi-directionally) which is very concise and human-readable. (I have tried many workflow engine / finite state machine designers / generators, and the jBPM GPD is a gem.)

    BPEL vs jPDL: In terms of flexibility and extensibility:
    I believe Java developers and architects will be frustrated if they commit too much to a SOAP / web services-dependent strategy such as BPEL. The beauty (for me) of jBPM+jPDL is that it will interface with more heavyweight systems but does not require them. Also note jBPM's road map. Seems to thoughtfully embrace standards that help keep things improving in the right direction.

    What a joy to have testable, flexible, lightweight solutions, even at the heart of enterprise systems. I can do test-driven development and code to interfaces instead of heavyweight specs.

    Re: BA involvement
    I know business analysts are able to work with jBPM diagrams (and if you believe this book: "Business Process Management with JBoss jBPM: A Practical Guide for Business Analysts") a BA can even "drive" jBPM--not that I am into that. (I'm an agile developer / architect sort of person, but maybe it makes sense to some of you out there.)

    I am grateful that JBoss acquired jBPM and I hope Tom Baeyens keeps up the good work. (I attended his lecture at Java One in 2005 and occasionally read his blog. Tom knows his stuff!)

    Looking forward to jBPM version 4.0 in 2009. As a consultant for a big bank and an entrepreneur, I'm thankful we already have jBPM today and I know it will continue to be a good option:

    Not in spite of other specs, but in concert with them.

    I like to advocate for good open source when I see it. jBPM, rock on!

    -Brett

    One caveat, it took me a while to gain the experience and confidence to be able to confidently promote jBPM at a large client. But that's because I had to do my homework to weed through examples, user guides, optional downloads, etc. in order to build real solutions with it and go through rigorous comparisons for my employer. I'm glad I did.

    Recommended reading:
    a few jBPM-related chapters in Open Source SOA (an early access Manning title: www.manning.com/davis/ ) which will also help explain how jBPM fits into the larger context of SOA.

  • People == Asynchronous Services

    by John Reynolds,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BPEL was designed to choreograph synchronous autonomous services. BPM is generally concerned with asynchronous (usually human-powered) services...

    The basis for BPM must reflect this reality... or (as we see with BPEL for People) it just feels like a kludge.

  • Re: Why BPEL is not the holy grail for BPM

    by Stephen Baudendistel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    the 3 links in the Resources section still produce 404s

  • Re: Why BPEL is not the holy grail for BPM

    by Stephen Baudendistel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The 3 links in the Resource section still produce 404s

  • Re: People == Asynchronous Services

    by Tammo van Lessen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BPEL was designed to choreograph synchronous autonomous services. BPM is generally concerned with asynchronous (usually human-powered) services...


    What do you exactly mean by "synchronous autonomous services"? You can of course render and/or invoke synchronous services, the main idea is however to orchestrate message exchanges, which are inherently asynchronous. Using synchronous request/reply is just one option in BPEL.

  • Your example done without BPEL

    by K Swenson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is a great example process, so I have done with an approach that directly executes the BPMN, without needing BPEL at all. I believe it executes the process correctly, drawing more into question the need for BPEL:

    kswenson.wordpress.com/2008/10/29/directly-exec...

    -Keith Swenson

  • Re: Nice try.

    by Bernd Ruecker,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi.

    I want to add some thoughts out of my working/consulting experience.

    I see BPEL as a very good thing in terms of that it brought up a lot of cool concepts (e.g. the sophisticated correlation mechanism) and started necessary discusssions (e.g. about compensation actions). BUT: It's use case value for real life projects is still limited. Basically it makes sense if you want to build some composed service out of a couple of other WebServices. So I see it as a scripting language for WebServices. But for business processes?

    First of all as shown nicely in this article, the BPMN to BPEL mapping is hard, the resultiung code not readable. Readability of BPEL is not important I heard here? So why to use BPEL at all? If the graphical representation or the readability doesn't matter, hey, than I would propose to generate Java or .NET code out of BPMN. There I have hords of developers know how they can deal with it. Where is the added value of BPEL?

    The biggest problem in real life is, that BPEL and the whole WS-Stack is too complicated. It is hard to understand and it is hard to find the right people for your project. If you don't have the right people, your project will fail. Should be good news for us as consultants, but I like it more to enable the companys to do their stuff on their own than making myself irreplaceable.

    Brings me to some last statement: BPEL is too tool centric! Good for vendors, bad for the users. Without good tooling you cannot succeed with BPEL, because it is simply to complex. Reminds me somehow of EJB 1 & 2.1: Good ideas, conceptually right, but not really usable. Ah yeah: And SimBPEL - Isn't that a move away from the standard? At least I see it as prove for being BPEL to complex!

    Indeed, I saw much more successfull jBPM projects, even very big ones, even company wide SOAs. There you deal with Java a lot (not limited to it, you still can access your ESB or WebServices easily), so you have people knowing their job. And it is not that hard to understand, no expensive tooling necessary.

    We will see what time brings, but I could image this direction: one BPMN model for business, second model technical BPMN and "code"-generation out of that. Maybe directly to Java or the like or better to a generic state-machine, which is Tom's idea of the Process Virtual Machine (jBPM PVM).

    Cheers
    Bernd

  • Re: Nice try.

    by Oliver Kopp,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If the graphical representation or the readability doesn't matter, hey, than I would propose to generate Java or .NET code out of BPMN. [...] Where is the added value of BPEL?

    The added value lies in the existing runtime-environments of BPEL. A BPEL process conceptionally runs for years, which is enabled by these engines. Of course, you can (partially) achieve that by code-generation, too. - However, a BPEL-engine can also run distributed to enable thousands of BPEL processes running on the same machine. BPEL processes give control back after each step, so process instances are not tied to threads or OS processes. You can't achieve that with plain old java.

  • SimPEL and BPELscript

    by Oliver Kopp,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Ah yeah: And SimBPEL - Isn't that a move away from the standard? At least I see it as prove for being BPEL to complex!

    SimPEL is definitively a move away from the standard. One reason is that the correlation mechanism is different to BPEL.

    If you want to have both, a more readable syntax and a bi-directional mapping to BPEL, you should have a look at BPELscript.

  • Re: Nice try.

    by Miguel Valdes Faura,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    The added value lies in the existing runtime-environments of BPEL. A BPEL process conceptionally runs for years, which is enabled by these engines. Of course, you can (partially) achieve that by code-generation, too. - However, a BPEL-engine can also run distributed to enable thousands of BPEL processes running on the same machine. BPEL processes give control back after each step, so process instances are not tied to threads or OS processes. You can't achieve that with plain old java.



    This is not a benefit of the BPEL standard but one related to the way the BPM egine is implemented to run a BPM process (wrote in BPEL or any other language)

    Any well coded BPM engine in java should gives control back after each step in a process...

    Miguel Valdes
    Bonita & Orchestra teams

  • JWT2BPEL BPEL file

    by Florian Lautenbacher,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just a quick note concerning the resulting BPEL file that is generated by the transformation framework. Yes, mostly it relies on bpel:Events, but that is not the cause for the length of the file. JWT thinks of models that not only have executable actions, but other artifacts that can be modeled and connected with these actions such as data, applications, responsible roles, etc.
    All of these modeled artifacts need to be considered when BPEL code shall be generated from the model. Therefore, for each action a new bpel:Scope is generated with some initial web services and final web services that are always invoked. These web services are part of an integration framework that has been developed as part of the project AgilPro. The Workflow Code Generation Framework is simply currently adapted to this framework. But since it is template based, it can easily be changed to fit other needs and other process engines (without an integration framework), too.

    The provided User Manual simply describes how the templates can be changed. Nevertheless, I agree with Pierre that transforming a process model either from BPMN or JWT to BPEL is a non-trivial task.

    Regards,

    Florian

    Project co-lead of the Workflow Code Generation Framework of the
    University of Augsburg, Germany

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT