The BPMN-XPDL-BPEL value chain

I got the chance to participate on a panel session at the BPM Think Tank in Arlington VA on May 24 2006 on the subject of BPM Standards.  Richard Mark Soley was on one end representing OMG and the BPMN standard. John Evdemon from Microsoft was on the other end representing BPEL for which he is the TC Co-Chairman. I was between them representing XPDL from WfMC. The order was random (although Richard suggested we were ordered by height) but as it turns out this is a natural order of progression for use of these standards.  Sandy Kemsley described this as the “BPMN-XPDL-BPEL value chain” in her post about that panel session. (Thanks Sandy for the term!)
Many people today automatically assume that BPEL and XPDL are direct competitors. This is not at all true. BPEL and XPDL are entirely different things for entirely different purposes. I will repeat that statement a few times here to emphasis it. But first, and quick summary of how they are different.

BPEL is an “execution language”. It is a programming language that has variables and operations. The operations can send and receive SOAP messages, and there is strong support for XML and XML transformation. It has constructs that make it easy to call multiple web services at the same time, and synchronize the results. It does not have any concepts to support the graphics of the diagram; activities do not have a position and size, and there is no representation at all of an “arrow”.

XPDL is a process design format. It is a file format that represents the “drawing” of the process definition. It has X & Y coordinates and node size. It has a concept of lines, and points along the line that give it a particular path. The nodes and lines have attributes which can specify executable information such as roles, activity descriptions, timers, web service calls, etc. XPDL 2.0 contains extensions in order to be able to represent all aspects of BPMN (BP Modeling Notation). The goal is to be able to save and exchange the process diagram.

The goal of BPEL is to provide a definition of web service orchestration, the underlying sequence of interactions, the flow of data from point to point. Ultimately BPEL is all about bits and bytes being moved from place to place and manipulated. It does not however attempt to represent the drawing that you used specify the orchestration.

The goal of XPDL is to store and exchange the process diagram. It allows one process design tool to write out the diagram, and another to read the diagram, and for the picture that you see to be as similar as possible. It does not, however, guarantee the precise execution semantics. As you see, BPEL and XPDL are entirely different things for entirely different purposes.

The different usage is best represented the diagram below. At the top are various design level tools. At the bottom are execution environments. XPDL can be used to carry the design from design tool to design tool. BPEL, XPDL, or other formats might be used be used to communicate the executable process to the engine. Generally, a vendor specific design tool is necessary to translate the design into an engine specific format. Generally, it is not possible to take executable code from one vendor’s design tool, and execute it in another vendor’s engine. Even with BPEL, which many believe was for this purpose, does not at this time allow different engines to run identical copies of BPEL code.

Diagram A

The XPDL file can provide this design interchange because it offers one for one representation of the original BPMN process diagram; it can be written, and re-read to recover the original diagram. BPEL, on the other hand is a non trivial mapping which is widely recognized as being one directional: you can take a BPMN diagram and produce BPEL, but it is difficult or impossible to recover the original BPMN diagram from the BPEL. This is not surprising since it was not designed for process design interchange.

Process interchange is ver important to customers who are investing a tremendous value in their process diagrams, and do not want to locked into a single vendor. (The vendors may desire this lock in, but never forget that the customers are paying the bill and have a choice.)

The importance of process design interchange will increase as the market matures. Currently, without design exchange, a single vendor must supply all of the tools that an organization might use. As the market matures, we can expect to find specialized tools that provide one function better than the vendor providing the engine. Or there will be people who are trained on a special tool and don’t want to lose that skill to pick up a new vendor version. The result is that we see a complete ecosystem of specialized tool that all work at the design level. This might be depected as below:

Diagram B

You might ask, if BPEL does not manage to communicate the execution representation to various engines with complete fidelity, why then would we expect XPDL to exchange the process diagram with complete fidelity? The answer is simply that is does not need to. One design tool does not understand the output from another tool completely, but every design tool will understand the most important parts (the form and shape of the diagram) as well as many standard BPM attributes. Because the model is communicated from design tool to design tool, if the transfer is not perfect, you have a chance in the receiving tool to fix it up. Not perfect, but both useful and pragmatic.

Not every tool needs to understand the complete diagram. A simulation tool for instance will use the standard parts of the diagram, but probably ignore things like the attributes that define web service calls, since simulation does not need to know this.

One of the most important aspects of XPDL is the extensibility mechanism. Each tool has specialized requirements on the diagram, it can represent these using extended attributes. Other tools will not understand these extensions, but they will carry the extensions along. Thus a tool specialized to clean up the layout, might manipulate the graphical aspects of the model, and return a cleaned up model including all the extensions back to the original source without losing any information. Enhydra JaWE for instance is an open source XPDL editing tool has been publicly demonstrated to read an XPDL file from Fujitsu’s Interstage BPM, edit, and return without loss of vendor specific extensions. JaWE even allows you to view and modify the extended attribute values.

Some execution engines take XPDL directly. Fujitsu’s Interstage BPM does because it is workflow style BPM and it is important for human activities to retain their identity even while executing, so that run time modification and process migration can be readily supported. That is the choice that a particular engine makes.  Some of the more EAI-style engines may use BPEL, but even in that case the portability is not proving viable, and some engines are going straight to the underlying technology such as Java, C#, Ruby, etc.

These are the differences in the roles of these three important standards. Our sitting order on the panel was appropriate and fitting because users will usually start by drawing a BPMN diagram, saving the partial diagrams as XPDL during development, and ultimately translating to BPEL for transmission to an EAI style BPM engine. These are three very different and very compatible roles.  But remember this: BPEL and XPDL are entirely different things for entirely different purposes.


30 thoughts on “The BPMN-XPDL-BPEL value chain

  1. Pingback: Bits & Notes » On the differences of BPEL and XPDL

  2. Pingback: processi » Blog Archive » BPM inside

  3. Pingback: The Tipping Point for XPDL « Go Flow

  4. Pingback: BPMN, XPDL y BPEL… cuál escoger? « Espacio SOA

  5. Pingback: Column 2 : BPMN-XPDL-BPEL value chain revisited

  6. Truly said.. I have tried Couple of Vendor. ActiveBpel,OracleBpel ,intallio and many others.. The one thing i have noticed is that Even though the bpel standard being specified lot many vendors are not following. And as u said it is not feasible to use bpel made from one vendor in another makes serious concerns, other than Activebpel I couldnt find any other vendors where usage of other Bpel is possible. All these raise serious questions on the Bpel as standard.


    Hashique thajudeen

  7. Pingback: BPMN - XPDL - BPEL :: slightly

  8. 1. An obvious question is of course: can XPDL reliably be transferred to BPEL?

    2. Something that’s not clear to me: What’s the difference between “workflow style BPM” and “EAI-style”? And if the XPDL notation is more suited to the first and BPEL to the latter, doesn’t this suggest fundamental differences in approach to BPM (see again question 1)?

  9. Good questions. First question: the BPMN spec used to include a way to convert BPMN to BPEL. This is a one-way conversion for the information that would be captured by a tool that used BPMN to display the process. Since XPDL is a superset of the of the information necessary for BPMN, if you were to limit your modeling to that part defined by BPMN, then the exact same transformation would be useful to convert the XPDL to BPEL.

    This conversion was made later a non-normative part of the BPMN specification, and I am not sure it is in the latest BPMN spec.

    There is no unambiguous way to convert the BPEL back to BPMN. Of course there are heuristics that could be applied that would generate something representative, but there are multiple ways to represent the same thing, and therefor no guarantee that you would get the same diagram back.

    XPDL is a different thing. It is a representation of the diagram. It hold information in a one-to-one way with the BPMN diagram. There is no “conversion” required. A BPMN diagram can be stored in XPDL, and retrieved from it, without any loss.

    So XPDL represents the diagram. There are many BPM engines that work directly off this BPMN diagram (reading XPDL directly). Yes, it is a different approach to convert the to BPEL. BPEL forces a particular approach to execution which is not suitable for many human workflow solutions. It is hard to explain here why, but many people with experience with human workflow find BPEL unsuitable. On the other hand, if BPEL does everything you want, then by all means go with BPEL. Just be sure to validate that it does everything you want.

  10. Almost all of the main tools that support XPDL also support BPMN. That is a broad general statement which I believe is true, but let me be specific:

    1. Fujitsu Interstage BPM support XPDL and BPMN. All diagrams in Interstage BPM are BPMN diagrams, and the primary import/export is XPDL. The studio writes XPDL in order to send the process to the server. It also downloads processes from the server in XPDL, and can render them without loss.

    2. TIBCO Staffware supports BPMN and XPDL. The sudio represents processes in BPMN, and it uses XPDL to send the process to/from the server.

    3. IDS Scheer allows BPMN diagrams to be exported in XPDL.

    4. Global 360 supports BPMN and XPDL, both reading and writing without loss.

    5. ITP Commerce is a Visio based BPMN modeler which exports XPDL, both reading and writing without loss.

    That is what I remember off the top of my head. There are lots of these now, and I expect to see quite a few more in the coming months.

  11. Hi, exist a tools which allows translate XPDL process in a BPEL4People process?

    Thanks, and sorry for my bad english 😦




  12. @kswenson

    Yes thanks,
    BPEL4People does not exist yet as a standard, but ActiveVos 5 for example, allows the use of this extension of BPEL, or not?
    So, you say that BPM-Xchange, allows a traslate XPDL in BPEL4People?

    Thanks for all 😉

  13. There are a number of products that make marketing claims that they already support BPEL4People. You should consider such claims with a high degree of skepticism. It seems that such claims can be made, and nobody ever challenges them.

  14. The problem with all this is that one of the key business requirements is for preservation of the training and knowledge reident within your user population in using a modeling tool, and the related invested value – we should be able to move engines without moving modeling tool. As long as the vendors do not support the ability to migrate process from one tool to different engine they are not meeting business’s needs and are attempting to lock you into their platform…this demostrates a non-customer centric vendor mindset – solving this problem should be the top of the list – reflects a lack of integrity from the vendors because in selling their products they never divulge this! I note even in your end state model above there is still not this capability exepected…sad!

  15. Yes, you have nailed the desire precisely: companies spend a lot of time and energy developing a process model, and they want to preserve that. It is the model that we wish to preserve, and not the program that was generated by the model. XPDL is the format that is closest to that model, and therefor preserves the model for future use. If a program is then generated from the XPDL, the presumption is that the new engine will have a new generator. the old generated program is not important.

    Today we can not guarantee that a given model will execute the same way on two different engines. There are ambiguities in the semantics of the BPMN langauge, and then there are vendor extensions. If you limit yourself to only well defined BPMN and avoid all vendor extensions, then you will have portable models today. The problem is that there is very little real work that can be done when you restrict yourself in this way.

  16. Currently we are working with pattern-based-transformations algorithms to map any kind of methododology (e.g. BPMN serialized XPDL as source models) into destination models with different methodology. As long a transformation could be described unambiguously, we transform e.g. very different methods like cEPC into BPMN. The concept is to have neutral projection of the model graph (with attributes) as base for subsequent transformations.
    So I see no problem to generate valid BPEL4People as long valid mappings describtions are existing.
    Feel free to contact me,

  17. It appears to me from the discussion that the best way to use XPDL and BPEL are as follows:
    XPDL (systems Integration) – This can be used in the requirements phase of a development effort; capturing the needs of a customer and ensuring the high value requirements are being met. This is done by modeling the processes and simulating their potential performance, identifying the boundaries for the solution space. Once this is solidified we move to the development phase. Also we are not tied to a development tool.
    BPEL (development) – This can be used in the execution phase, by using BPEL to develop a solution based on the above requirements. The BPEL captures the detailed data interfaces within the executable solution.

  18. The XPDL specification tells how each of the elements of BPMN is supported — there is a 1 to 1 mapping of BPMN graphical elements into XPDL file format. There is no “transformation” necessary since the BPMN is a process diagram, and the XPDL is simply the file format for that process diagram.

  19. Hello there, You’ve done a fantastic job. I’ll definitely
    digg it and personally recommend to my friends. I’m sure they’ll
    be benefited from this website.

  20. I guess all the above was valid /drafted for BPMN 1.2….is all the above still valid with BPMN 2.0?
    I understood this new bidning is an attempt to merge all the above, or at least two of the aspects originally separted in BPMN 1.2 and XPDL which is the graphical (eg BéMN 1.2) and process flow description (eg XPDL) into on single XML biding schema…being :BPMN files….It is not clear to me what then a XMI extension is all about…Any update by the above writers who seem to know the formats in depth?

  21. Thanks for the comment. BPMN 2.0 attempts to bring a serialization format for exchange of models, and as far as I can tell, this serialization should be pretty much equivalent to XPDL. That is, the BPMN serialization is at the same conceptual level as XPDL. Fujitsu supports both. The importance is that both of these are distinct from BPEL which is purely a execution level programming language that is distinct from the design language. The WfMC pushed OMG hard to actually supply XML Schemas for the serialization format, and that was done, so I guess the only update for this post is that BPMN 2.0 offers a serialization similar to XPDL.

  22. Pingback: Still think you need BPEL? | Thinking Matters

  23. Pingback: BPMN-XPDL-BPEL value chain revisited – Column 2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s