BPMN 2.0 Model Portability Workshop, Nov 4, Maidenhead, England

Will BPMN diagrams be exchangeable between tools? Will BPMN 1.2 diagram be portable to BPMN 2.0? WfMC is asking Thought Leaders to come to a full day workshop on Nov 4 in Maidenhead England to work through some of these details. Find information pages at:

http://wfmc.org/november-member-meeting.html

Work Completed by Project Group:

* Proposal for XPDL2.2/BPMN2.0 portability conformance classes
* Revision of XPDL2.1 Events to support BPMN2.0 Events
* Visio template for drawing BPMN2.0 diagrams
* BPMN Google Users Group created
* Sourceforge Open Source Project for Sketchpad BPMN/XPDL drawing tool created.
* Source Code available for download.
* Installer available for download.
* Google Code Open Source Project for Conformance Testing
* Code and transforms available for download

Prototypes for Serialization of BPMN2.0 Transforms Between BPMN2.0 & XPDL

* Proposed BPMN2.0 serialization schema.
* Prototype transform from XPDL2.1 to proposed BPMN2.0 serialization
* Prototype transform from BPMN2.0 serialization to XPDL2.1

Recent activities, working group meeting

* BPMN 1.2 Status and use today. How fast are people migrating?
* XPDL Diagram Interchange
* conformance classes,
* tools for validation
* BPMN 2.0 Finalization Task Force Status
* Concerns over the direction
* Working group activities

See also: http://www.xpdl.org/nugen/p/lpqyjklyf/public.htm

XPDL Interoperability Test

The WfMC has started in motion an interoperability test procedure between the various implementers of XPDL. It is in everyone’s interest to make sure that the files we read and write can actually be interchanged with other products. This additional step beyond the “claim” for XPDL support will help to insure that we and our customers get full value from XPDL.

This discussion is focused at vendors and individual who have actually implemented XPDL, or who expect to implement it in the near future.

You do not have to have implemented the 6 patterns (see attachment) yet to participate in the sample exchange.

Attached is the XPDL Interoperability Test procedure. I realize of course that these six patterns are very basic, possibly even simplistic. We will expand this to more complex patterns in the future, but we need to start somewhere. It is better to start simple with something that we all can succeed at, before jumping into complex diagrams.

Every vendor who models processes should follow the instructions (in the attachment) to model each of the sample process patterns. They should take a screen shot of the process (GIF) and export the process to XPDL.

The 6 GIF files, and the 6 XPDL files should be bundled together into a ZIP file, and then uploaded as an attachment in a post to this Workflow Discussion Forum.

Every vendor who can import XPDL should download each of the ZIP files, and attempt to import. The results of this test should be a reply to the message that held the original post.

((A technical problem seem to prevent me from attaching the document at this moment, so please check in a following post for the document to explain how to do the test.))

You might find more information at this temporary site: http://www.kswenson.com/wiki/Wiki.jsp?page=XPDLConformance

-Keith

Q&A from European ministry

Got these questions from a researcher in the ministry of a European country, and I added the answers below. The questions are good ones, so this might be helpful to everyone.

----

- I understand that XPDLs primary function is the ability to import/export businessprocess descriptions in a standardised format using Xf-XML. Do you expect that to happen dynamically, meaning that you on runtime send a businessproces and ask the partner to execute this proces?

XPDL is designed as an exchange format for business process definition. It can be transferred using Wf-XMl, or it can be transferred using any other means. There are about 2 dozen products that use XPDL today, most of them simply export/import to/from a file.

While it is certainly possible to accept a process from an external partner and execute it, this is not very likely to be done for many of the same reasons that you would not accept a Java class and execute it. To expand on the analogy: Java classes are fully transportable, but accepting an external class into your server is very risky because the capabilities available to the Java code is relatively unrestricted; it is very difficult to make a running environment where everything you can access is completely safe. The exact capabilities depend upon the implementation of the process engine. Most process engines give relatively open and unrestricted access to back-end resources (e.g. database server, file system) and so the workflow application programmer constructs a process definition that controls the access. Steps of the process are devoted to making sure that the original request that started the process is valid and authorized for the steps which happen later on. Consider a typical purchase order process where earlier steps get approval for purchase, and the later steps actually order the item. Accepting an external process might allow someone to skip the approval process and go right to the item ordering. This is not a restriction of XPDL, but rather a restriction inherent in the design of most process engines.

XPDL was designed more with the idea to give the internal application designer a choice of process definition tools. Take for example the open source JaWE process design tool. There are several open source process engines based on XPDL, but those projects have not had the manpower to make a graphical process design tool, but since they are based on XPDL, they all suggest that you use JaWE to design the processes. IDS Scheer make the ARIS Toolset which is a dedicated business modelling tool and does not include a process engine, but you can export process diagrams in XPDL and run them in the Fujitsu Interstage BPM process engine for example.

- I understand that you don't expect XPDL to be used as the internal Business proces language in any product. Each product will have its own language and XPDL is expected only to be used when you need to transfer the business proces to another product. Is this understanding correct?

This is for the most part correct. XPDL is designed to be a representation of the process design. That means it is a representation of the boxes and lines that you draw. This "top-down" approach assumes that the commonality between various process technologies is in the diagram; almost every process system offers a representation of the process which consists of different kinds of boxes which represent activities, and arrows that represent the transitions between them. This is the same basis for BPMN to be a standard visual representation of the process. BPMN and XPDL are a perfect fit because anything that can be represented in BPMN can be transferred with XPDL.

The amount of translation from XPDL to the engine's internal format depends upon the engine. For some there is a large translation, and others effectively execute the XPDL directly. The key is that XPDL transfers the diagram, and each engine is reponsible for making it runnable.

- Do you expect that XPDL can be used similar to WS-Choreogaphy from W3C og BPELs public process, where a standard XML-document describing the public aspect of a process is published and the partners uses this document to build their own internal process that comply to the oveerall external proces?

WS-Choreography: This is a definition of the temporal relationships between various web service calls. More simply put, it tells you what web service calls you are allowed to make and when. WS-CDL is designed to be a definition of the "interface" to a process, but not the internal process itself. It is focussed only on web service calls, and nothing else that a process might do. As long as the process engine supports web services interactions to control the process, for any given XPDL process installed into it, there is a corresponding WS-CDL definition of how to manipulate the process through web services.

BPEL: As the name implies, this is an execution language. This "bottom-up" approach defines specific executable instructions, and control structures. It is best to think of this as a programming language like Java. It proscribes a particular execution environment. It has built in functionality for storing XML in variables and manipulating it. It is a block structured language like Java which allows you to have nested scopes and exceptions which are thrown from scope to scope. The one key capability that puts it above Java is that it has an easy way to make multiple web service requests at the same time. This capability alone will justify the success of BPEL in the market.

- How do you position BPEL, is it just another business process language that can be exported to XPDL or do you see it as a competing specification?

BPEL is not a replacement for XPDL because it has no capability to describe the diagram. It has no ability to assign an activity to a user. It is designed to support machine to machine communication. There is no capability to have alarms to remind the user assigned to a task that it is emminently coming due. It has no concepts for looking up groups/roles from an organizational directory in order to determine who to assign the task to. In otherwords, all of the built in capabilites that a human oriented process engine offers has to be explicitely coded in BPEL. Every byte that is transferred in or out of the system is explicitly represented in the BPEL process. A human oriented process engine might have the ability to "reassign" a task to another user, and because this is built in functionality, all the interation required for this would not have to clutter up the diagram. While a BPMN diagram can (if drawn to some rules) be translated to BPEL, the BPMN standards committee insists that it is not possible in general to convert BPEL back to BPMN. XPDL is designed precisely to be a representation of the diagram at the BPMN level. BPEL can not be extended to include the diagram information because it is on a completely different level of abstraction from the diagram. Many industry experts are confused about this, and there is much debate on this topic. I think you will find in the end that XPDL is a format to get process diagrams from one process design tool to another or to an engine, while BPEL will remain an executable format that might run in more than one engine to drive machine to machine communications.

- Do you expect that all internal business process languages will be able to be exported completely to a XPDL format or is it only languages that can be descibed completely using BPMN.

XPDL should be able to describe any "graph oriented" visual language. The basic building blocks are the "activity" which is a shape on the diagram at a position, and the "transition" which is the arrow that starts at one activity and ends at another. The activity includes a number of properties that give an indication about how the process is supposed to execute: for example the "split" attribute tells whether all the outbound arrows are activated, or only one. Specific process engines then extend the properties of activities to include unique capabilities. Different process engines will be able to read each others process definitions to varying degrees of fidelity depending upon the amount of extended attribute use, but they will all be able to transfer the basic diagram and common attributes like name and description. Moving a process from one engine to another is not guaranteed to execute in an identical fashion, but it is the best possible starting point for then editing the process to make it run the same way.

- Is there any royalty associated with the use of XPDL?

No. It is freely availble for use by anyone without royalty. This has made it very popular in the open source community. See XPDL Implementers.

RDF Vocabulary for Workflow

I received this email below, and thought people here would be interested in it. From what I see it is a very credible start, but I would like to see it conform a bit more closely with the glossary and XPDL.
-Keith Swenson

---------------------
Dear WfMC

I’m working in Chasqui®, which belongs to the University of Las Villas, Cuba. We’ve been developing contents management systems (CMS) for the Cuban Press and other enterprise-like organizations in Cuba.

Currently we are studying the possibility of extending our CMS capabilities by rebuilding it based on a WfMS. However, at the same time, we’re developing an RDF module for our CMS.

As it is the case that the items we manage are now to be work items in the WfMS, we’re interested in keeping the things simple by using an RDF vocabulary for Wf.

The attachment is an RDF document sketching our very first ideas on this topic. Since we’re still studying the WfMC documentation along with other documents we’ve found, we’ve not complete this work yet, that’s the reason for my inquiry on the WfMC works on this issue.

On the other hand, RDF is intended to be the lingua franca for the semantic web, so an RDF vocabulary for Wf, may lead to a more simplified and interoperable environment.

Regards,
Lic. Manuel Vázquez Acosta.

-----------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!--
//+-----------------------------------------------------+
//| Chasqui® |
//| http://www.chasqui.cu/ |
//+-----------------------------------------------------+
//| Chasqui® Contents Management Division |
//| http://www.chasqui.cu/gestcont/ |
//+-----------------------------------------------------+
//| © Copyright 1999-2003 Chasqui® |
//+-----------------------------------------------------+

//
// $Id$
//
-->

<!-- Notes:

Use owl: http://www.w3.org/2002/07/owl# instead of DAML+OIL
Consider translation: http://www.mindswap.org/2002/owl.shtml
-->

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dpo="http://www.daml.org/2001/03/daml+oil#"
xmlns="http://www.daml.org/2001/03/daml+oil#"
xmlns:wfdef="http://www.chasqui.cu/2004/07/wf-def#"
xml:base="http://www.chasqui.cu/2004/07/wf-def#">


<Ontology rdf:about="">
<imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/>
<imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/>
<comment xml:lang="es">
Define que este documento es una ontología que confía en las definiciones
de RDFS y DAML+OIL
</comment>
</Ontology>

<Class rdf:ID="WorkflowDefinition">
<comment>
<rdf:Alt>
<rdf:li xml:lang="es">
Una clase para asegurar que un recurso es la definición
de un Workflow
</rdf:li>
<rdf:li xml:lang="en">
A class to assert that some Resource is a Workflow definition
</rdf:li>
</rdf:Alt>
</comment>
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</Class>

<Class rdf:ID="WorkflowDescription">
<sameClassAs rdf:resource="#WorkflowDefinition"/>
</Class>

<Class rdf:ID="Activity">
</Class>

<!-- WorkflowInstance: The description of (running?) case.
Might be useful when interchangin workflow data between several
wf enactment engines, because they need not only the "abstract"
definition of the bussiness process, but also the CURRENT STATE
of the instance.
-->
<Class rdf:ID="WorkflowInstance">
</Class>

<Class rdf:ID="WorkflowLanguage">
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</Class>

<Class rdf:ID="WorkItem">
</Class>

<Class rdf:ID="WorkList">
</Class>

<!-- Supported Languages -->
<WorkflowLanguage rdf:ID="PetriNet">
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</WorkflowLanguage>

<WorkflowLanguage rdf:ID="YAWL">
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</WorkflowLanguage>

<!--
La clase de los patrones de diseño de forma general.
Esta clase permite la definición más abstracta de workflows
con los patrones: Dicriminator, ParallelSplit, etc...

General Workflow Design Patterns. More thinking needed on how to relate
these patterns with the elements given by a particular language: PetriNet,
YAWL, XPDL, an so forth.
-->
<Class rdf:ID="WorkflowPattern">
<comment xml:lang="es">
La (meta)clase de los patrones de diseño.
</comment>
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</Class>

<!-- Workflow Design Patterns, as given by [Aalst01] -->
<!-- Parallel Split and aliases -->
<WorkflowPattern rdf:ID="ParallelSplit">
</WorkflowPattern>

<WorkflowPattern rdf:ID="AndSplit">
<sameClassAs rdf:resource="#ParallelSplit"/>
</WorkflowPattern>

<WorkflowPattern rdf:ID="Fork">
<sameClassAs rdf:resource="#ParallelSplit"/>
</WorkflowPattern>

<!-- Synchronization and aliases -->
<WorkflowPattern rdf:ID="Synchronization">
</WorkflowPattern>

<WorkflowPattern rdf:ID="AndJoin">
<sameClassAs rdf:resource="#Synchronization"/>
</WorkflowPattern>

<!-- Exclusive Choice and aliases -->
<WorkflowPattern rdf:ID="ExclusiveChoice">
</WorkflowPattern>

<WorkflowPattern rdf:ID="XorSplit">
<sameClassAs rdf:resource="#ExclusiveChoice"/>
</WorkflowPattern>

<WorkflowPattern rdf:ID="Switch">
<sameClassAs rdf:resource="#ExclusiveChoice"/>
</WorkflowPattern>

<!-- Simple Merge and aliases -->
<WorkflowPattern rdf:ID="SimpleMerge">
</WorkflowPattern>

<WorkflowPattern rdf:ID="XorJoin">
<sameClassAs rdf:resource="#SimpleMerge"/>
</WorkflowPattern>

<WorkflowPattern rdf:ID="Merge">
<sameClassAs rdf:resource="#SimpleMerge"/>
</WorkflowPattern>

<!-- Multiple Choice and aliases -->
<WorkflowPattern rdf:ID="MultiChoice">
</WorkflowPattern>

<WorkflowPattern rdf:ID="OrSplit">
<sameClassAs rdf:resource="#MultiChoice"/>
</WorkflowPattern>

<!-- Multiple Merge -->
<WorkflowPattern rdf:ID="MultiMerge">
</WorkflowPattern>

<!-- Discriminator -->
<WorkflowPattern rdf:ID="Discriminator">
<comment xml:lang="en">
The discriminator is a point in a workflow process that waits for one of the
incoming branches to complete before activating the subsequent activity. From that moment on
it waits for all remaining branches to complete and "ignores" them. Once all incoming branches
have been triggered, it resets itself so that it can be triggered again (which is important
otherwise it could not really be used in the context of a loop).
</comment>
</WorkflowPattern>

<!-- Interleaved Parallel Routing -->
<WorkflowPattern rdf:ID="UnorderedSequence">
</WorkflowPattern>

<WorkflowPattern rdf:ID="InterleavedParallelRouting">
<sameClassAs rdf:resource="#UnorderedSequence"/>
</WorkflowPattern>


<!-- Esta propiedad pretende relacionar un patrón de diseño
con una lista de traducciones a los lenguajes -->
<Property rdf:ID="patternTranslation">
<!-- subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Property"/ -->
<domain rdf:resource="#WorkflowPattern"/>
</Property>


<!-- This part of the document is still in a highly unstable state -->
<Class rdf:ID="PatternTranslatorClass">
<subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</Class>

<PatternTranslatorClass rdf:ID="AbstractTranslator">
</PatternTranslatorClass>

<PatternTranslatorClass rdf:ID="WebServiceTranslator">
<subClassOf rdf:resource="#AbstractTranslator"/>
</PatternTranslatorClass>

<PatternTranslatorClass rdf:ID="DownloadableScriptTranslator"/>
<subClassOf rdf:resource="#AbstractTranslator"/>
</PatternTranslatorClass>

<Property rdf:ID="patternTranslator">
<rdf:range rdf:resource="#AbstractTranslator"/>
</Property>

<Property rdf:ID="translatorWSDL">
<rdf:domain rdf:resource="#AbstractTranslator"/>
</Property>

</rdf:RDF>

<!--
References:
TODO: URLs de los documentos.
[Aalst01] W.M.P van der Aalst et al. - Workflow Patterns; pp. 6-30.
http://tmitwww.tm.tue.nl/research/patterns...fs-pat-2002.pdf

-->

question about Wf-XML and BPEL4WS

Your question relates to the position of BPEL and Wf-XML.

BPEL is a language to describe system interaction while WfXML is a protocol for specific generic operations.

Please take a look at ASAP (http://www.oasis-open.org/apps/org/workgroup/asap/) because this presents the asynchronous service interface, without requiring that those services be workflow. The new WfXML 2.0 is an extension to this interface which adds workflow features to an otherwise generic service.

The idea for linking two systems with BPEL: you have a BPEL description of the foriegn system (and local), and you have a design time tool that a programmer uses to generate an adapter to talk to that foreign system. Messages are tightly bound with strong typing, and you need a programmer to arrange to send the right kind of message.

The idea for linking two systems with WfXML: you use a system that has teh WfXMl protocol built in (it is a fixed protocol). For any given operation you wish to perform at a foreign site, you need only specify the resource address of that operatation (the factory) and a simply name-to-name mapping of data values. In general no programming is needed, and the linkage can be changed at run-time without the need of generating any adapters. This is a loose-binding approach.

The analogy I use is: when connecting telephones, you could wire the phones directly into the network, or you could provide a plug and socket that allows an ordinary user to plug the phone in. WfXML is that plug for basic run-time connections. BPEL is a somewhat powerful way of describing all possible different types of connections you might want to make, but the end result is somewhat hard-wired together without the ability to change at run-time.

-Keith

-----Original Message-----
From: Francisco Mancardi
Sent: Thursday, March 11, 2004 2:08 AM
To: Keith Swenson
Subject: A few questions about Wf-XML and BPEL4WS


Dear Sir:
I would like to take five minutes of your time.

I'm working for an italian company in the development of a web-based
workflow application
(www.gruppotesi.com). The product is very young (2 years) and now we are
starting
to work to add standard interfaces.
I've got the specifications from WfMC site, and trying to understand it.
Would you mind reading my questions ?

The company is interested in the interaction with external systems,
and after searching in the Internet, downloading, reading the Wf-XML and
BPEL4WS
specifications I'm very confused.

In my confusion, I fear I'm trying to compare apples with bananas.

When I want to interact with an external system, using Wf-XML I've to
think in every
external system as a Workflow Management System ?.

Do you think I've to consider using BPEL4WS if i think 90% of time I
will interact
with generic systems (i.e. ticket reservation, ERP, etc) ?

I've to use the best of both worlds ? (Wf-XML, BPEL4WS)
A little bit of yout wisdom is welcome.


Best Regards


Francisco Mancardi
www.gruppotesi.com