I got a comment on my last post which so obviously misses the point so much of the discussion around these standards, that I half suspect this Anonymous post was a practical joke from a colleague for the amusement of watching me get defensive. However, lets assume that the poster was sincere, and respond to anyone who might hold a similar point of view.
Arguing that BPEL is “more” or “better” than XPDL is like arguing that red is “more” or “better” than blue. Like arguing that apples are “more” or “better” than oranges. Like arguing that a race-car is more or less useful than a jeep.
Consider an analogy of two file formats: one for documents (e.g. Microsoft Word) and one for presentations (e.g. Microsoft PowerPoint). If you look at a list of “brochure points” these different product categories might seem very similar: they both support fonts and word-wrapping, they both support pagination, they both have the ability to draw graphics, they both can do tables, they both can display full screen, they both have spell checking, they both support hidden comments, and so on. Yet you might assemble a room full of people; on one side would be the technical writers, journalist, novelists who would point out how the document format is clearly superior and more useful to them, and they would be right. These writers might say that they have the presentation software, but just use it to make graphics to paste into the documents, and overall the document format is of primary importance. Yet on the other side of the room is a bunch of presenters, lecturers, teachers, and (dare I say it) politicians. This side claims that is the presentation format that is far more useful and powerful; while they keep the document processor around to read files they occasionally find on the Internet, they really only need the presentation package to do their work. If such a debate were considered seriously, it could go on forever getting more and more detailed about the fine points of word-wrapping, spell-checking, animation, pagination, etc.
Hopefully this analogy makes it clear just how silly such a debate would be. There is no war between document processors and presentation graphics packages. Yes, there is a certain overlap, but the only thing that the debaters are proving is that they have different goals for what the software should do. There is no reason to believe that adoption of a document format will necessarily cause the exclusion of a presentation graphics format. They are different things used for different purposes.
Just to make things perfectly clear, I never said that BPEL was less important than XPDL. I never said that BPEL would in any way be replaced or supplanted by XPDL. BPEL is an important standard that does what it does, but utterly fails to what XPDL does, because it is simply a completely different thing. There is no war between XPDL and BPEL.
For example, draw a process diagram, lay the nodes and lines in particular positions, write it out to BPEL, and read it back in. It is impossible to get the same diagram back in because BPEL simply has no way to preserve node positions and line positions. Arguing that you don’t NEED the lines and positions to be preserved brings us with circular logic back to our starting point: BPEL and XPDL are designed to satisfy different needs. XPDL, on the other hand, represents the graphics of the process, and when you read it again you end up with the same diagram.
Let me illustrates the differences between these different standards in a more concrete way. I will have to use a very simple diagram, and a simplifications of the BPEL and XPDL output, so bear with me. Consider the following BPMN diagram:
What do you see? On the surface, you see six shapes: two circles, two diamonds, and two rounded rectangles. You also see six lines (with bends in them) that connect the shapes. Those lines have arrows to show the direction of flow. If you understand the symbols in BPMN, then you understand that this diagram is showing that after the process starts, there are two activities: Activity1 and Activity2, which execute at the same time. The process will complete only after both activities are complete. See how there are two ways of thinking about the picture, one is very superficial and includes the specific shapes, the other attempts to include only the underlying meaning. This is similar to the distinction between BPEL and XPDL.
BPEL attempts to capture only what the execution engine needs to know: the two activities and the fact that they need to be run in parallel. In BPEL, if you want to activities to run at the same time, you nest the activities inside of a <flow> tag. The flow tag says that everything inside of it will be executed in parallel. A highly simplified BPEL output might look like this:
In a certain sense, this is all that an execution engine needsto know. The two invoke activities will be launched in parallel, and the process will not complete until both invoke activities are complete. But if you try to read this back into the process modeler, you will find that you can construct something that looks very much like the original (because the AND gateways can be added in because they are logically required, and the arrows between them are logically required) but you can not guarantee that the diagram will be the same because the graphical information is simply not there in the file. Note that BPEL has no way to directly represent a line in the diagram, and it does not need to, since lines are not executed, they simply show the relationships of things.
The XPDL representation would be decidedly different. XPDL represent the process model, not simply what is needed to execute the process. It will have six activity tags to represent each of the nodes (in XPDL the term “activity” encompasses all of the BPMN nodes: activities, gateways, and events) and it will have six “transition” tags, one for each line. The graphical coordinates for the nodes can all be saved, and the points for the lines, including details of precisely where the lines bend and where they touch the nodes, is included in the Transition tag. A simplified version might look like this:
Above is a direct representation of the process diagram, not the abstracted meaning behind the diagram. It should be obvious to everyone that you can read the XPDL file, and recoverthe exact same diagram that you saved. XPDL is a direct one-for-one representation of the BPMN diagram, and all the additional attributes associated with the diagram. BPEL, on the other hand, is a one-way transformation; the translation is a “lossy” translation because it does not contain all the details of the diagram. It was never designed to do this, so there is nothing wrongwith this, it simply is something that BPEL does not do.
Saying that “BPEL is more portable than XPDL” simply tells me that all you care to communicate is the execution meaning of the process. It tells me that you do not care about, and possibly have never tried to transfer a process diagram of any complexity. If all you need to do is to communicate process execution semantics, then by all means continue to use BPEL – there is no reason to think you should be using XPDL for this. They are, after all, completely different standards designed for completely different things. However, your experience with interoperability is not commonplace. John Evdemon, co-chairman for the WSBPEL working group at OASIS, asked the attendees of last year’s BPM ThinkTank whether anyone was using BPEL for interoperability between products. When nobody raised their hands, he used this as evidence to support the claim that “the portability of executable BPEL will be low to non-existent“. It is a strong claim, and the head of the working group should have as much experience as anyone in the subject. But if it works for you, that is great.
I personally believe that eventually BPEL will offer great value to all of us, and I support its adoption for the things that it is capable of doing. At the same time, so does XPDL, which is capable of exchanging of process definition diagrams between products. The broad support of the XPDL standard today, with more than 60 products using it, is a sure sign that it will not die any time soon. I only hope that this post has helped make it clear for all those die-hards out there that adoption of XPDL does not mean that BPEL is on the decline nor does the adoption of BPEL cause the demise of XPDL. They are simply different things, like apples and oranges.
Thinking Matters 
Keith,
The example you take is perhaps not the best one. It is an example of a structured process model. Structured process models can be translated easily between BPMN/XPDL and BPEL, and you can even do round-tripping with this class of models (i.e. go from XPDL to BPEL and back). People who have actually dealt with domain analysts know that they often do not write structured process model. And if you try to explain them that their models should be block-structured, they will simply throw you and your tool out and go back to doing IDEF like we did in the old days. If you want to engage with analysts, and you’re serious about business/IT alignment, you have to allow them the freedom, among others, of writing their favourite unstructured models. You should then provide methods and tools so that system analysts and developers can turn these models into implementations, for example in BPEL. To provide this tool support, what tools vendors need is to clearly identify which classes of BPMN/XPDL models they can automatically translate, which ones need some human input, which ones need refinement, etc. There’s a few posts in Bruce Silver’s blog about this, e.g. http://www.brsilver.com/wordpress/2006/10/13/more-on-eclarus-and-class-2/
Many vendors (e.g. large ones like Oracle, but also smaller ones like Telelogic) have understood this and they are building methods and technology chains that recognise that the business/IT divide can not be bridge by forcing everyone the way developers think.
For those who would like to know more about different classes of XPDL/BPMN models and their translation to BPEL, they can take a look at this paper: http://sky.fit.qut.edu.au/~dumas/BPMN2BPEL-Patterns.pdf
Hhm, I think you got me wrong. My intention was to point to a flaw in your argumentation that XPDL is supported by many different vendors (you quote 60 products). I can just tell you that just because a standard is on a feature list of a product, it doesn’t mean that the product has really great support for it.
Your discussion in this post comes mostly down to that BPEL has no diagram layout information like XMI 1.X had also no diagram layout information. That is not really important, because most process modelling tools come with some kind of layout algorithm. So it is true that it is impossible nowadays to transfer the exact layout of a BPEL process between different tools. But in the end you use BPEL as well as XPDL for describing executable business processes and to execute them in an engine. So in that sense both languages do compete.
Now it might be that I’m wrong, but if BPEL and XPDL can coexist, please tell me how I can make use of both standards without overlap. Should I design executable processes using XPDL just to have a way to save the layout information? And later on I transform the XPDL file to BPEL? I think, someone trying to use standards would do as follows:
– use BPMN to design the process model
– use a proprietary format to exchange the diagram information, because there is no standard for it – there is no SOA-XMI
– export the BPMN model from within the modelling tool either to XPDL or BPEL, but not to both
Regards!
I appreciate your comments.
I certainly will agree with part of your statement. Like any standard, some products offer only token support so they can claim support. This is true for XPDL, BPEL, and any other standard I can think of. The true test is demonstrations of interoperability which has been done for a dozen or so implementations, and is currently a project for the XPDL support group.
My experience is that among products that support XPDL 2.0, all of the nodes of a BPMN diagram are reliably transferred from one product to another. The positions of the nodes are reliably transferred. There are details of the layout which are not the same in the two modeling tools: e.g. because of node size differences, lines that came out of the middle of a node, end up coming from slightly off center. These are things that are resolved by a few moments of prettying up. The important thing is that all the properties and metadata are reliably carried along.
Back to your point about “diagram layout information is not important”. I would refer you back to the people arguing about whether a document processor or a presentation graphics package is more important. You clearly have no desire to preserve or communicate the process diagram itself, and find it sufficient to use BPEL. If it works for you, that is great, you have no need to change. But many people DO have a desire to preserve the exact diagram and for them XPDL is the right choice.
For example, TIBCO has a new BPMN process design tool which runs in Eclipse. They use XPDL as the internal format to store the process definition, and to transfer the process to the execution engine. They did not choose this because of some nefarious political power that WfMC holds over them, but because XPDL is a convenient and readily available format for doing this. They found they did not need a proprietary format for this.
Fujitsu’s new Eclipse based process design studio is the same: BPMN processes are designed in a graphical environment, and they are saved locally as XPDL files between editing sessions. When you want to transfer it to the server, you use XPDL as the format for this. It works as a storage format because it has a complete representation of the process diagram layout information. Clearly BPEL could not be used for this.
Enhydra JaWE is an open source process design tool that does exactly this as well. It provides a graphical environment for process definitions, and there are three or four open source process engines which all claim that JaWE is the design tool of choice for their engine. The point about all of these cases is that they REQUIRE that the process layout be included, so XPDL is the format that does this today.
Some people like to use ProForma to design process models for Fuego (now BEA) and the format that you use to get the process model from ProForma to Fuego is XPDL, because XPDL has always been the interchange format for Fuego. These are not token implementations.
Please see my post from last year about “The BPMN-XPDL-BPEL Value Chain” where I covered this usage pattern as follows:
– use BPMN based editor
– store the process in XPDL locally, exchange it between tools in the design environment in XPDL, particularly convenient if it is placed in a repository where multiple tools have access to the single file instance directly.
– convert from XPDL to an engine specific format to send to the execution engine. There are a number of engines that support BPEL, but there are also a number of engines that accept XPDL directly, and there are further proprietary engine formats.
In your second step, you say there is no SOA-XMI, so vendors are forced to use a proprietary format. I have given numerous examples of products which use XPDL as a standard for doing exactly this, so I would claim, as I have done many times, that XPDL is a good format for this. But nobody is ramming this down your throat — any vendor who chooses to use a proprietary format for basic storage and exchange of the process diagram may certainly do so. But there are many cases of vendors who have found XPDL to be a convenient format readily available today, and does the job of persisting the process diagram in a way that can be read by multiple tools.
In summary, XPDL is the ONLY standard format available today that can serialize the complete BPMN diagram. It is useful primarily to people who care about the actual diagram layout and want that preserved, as well as all the other design metadata.
Your product may not need or care about exchange of the design information, and if so, you might have only token support for the XPDL standard.
Pingback: BPMS Watch » The Real Issues with XPDL, BPEL, and BPMN
Thanks Keith for your clarification. I think now I can agree more. Still, do you think it is in the interest of a SOA modelling/repository/engine product vendor to make sharing the layout of diagrams easy? In my opinion, this is not the interest of a vendor.
That is an interesting comment. In many cases, standards in general are NOT in the interest of a dominant vendor, who would rather trap customer with vendor lock in. There is one thing that always tips the balance in favor of supporting standards: customers are not stupid. If as a vendor you are offering a product that has true value, then sometimes offering a an exit door is the best way to keep customers.
In the case of process modelling there is something special going on. As more and more people with different levels of skill and different backgrounds get involved in process modelling, we are finding that there are a variety of different new and creative tools, and it is impossible for one vendor to offer them all. Having an open file format allows the process definition to be put into a repository, and available to all tools at once, or to be used in any order, without having to explicitely export/import before and after specific tasks. As a vendor, this makes it really easy for a third party to come in and add value to my process product. The third party benefits when support for a single format make them useful in a number of different vendor suites. Maybe ten years from now we will know exactly what should and should not be included in a process design tool so that all users can share a single tool, but we are not there yet.
In response to the comment from Marlon Dumas (sorry, this got caught in a “moderation queue” I did not know about.)
I chose the example to illustrate that the structure of XPDL matches the structure of diagram, whereas the BPEL structure is different. As “round tripping”, it is true that you can generate a BPMN diagram that is ‘similar’ to the original, but clearly certain details about the diagram must be lost because there is no place to put them. For example, if the arrows had labels on them, where would you put them?
As for for the comment about automatic translations: I don’t quite know where you are going with that. All the workflow/BPM vendors I know of provide a tool that do this automatic translations to executable, and warns you when you are doing something that makes no sense.
Pingback: BPMS Watch » Diagrams, Models, and Metamodels…Oh My!