BPEL or XPDL - Why there is need of two standards? Options

[Swati S]

With the increasing importance of Business Process Management in the enterprise, several tools are available for organizations to choose from and with that there is increasing need to follow common standards of interchange.
BPEL is one of the more widely used in tools like IBM Web sphere, Oracle JDeveloper, Oracle BPA, etc.
XPDL is also widely used in tools like AquaLogicBPM, Global 360, TIBCO, etc. Some tools support both.

If BPM products are supporting both XPDL and BPEL, what are the benefits of one over the other? How are BPM standards likely to evolve?


Regards,
Swati S

[antonio filogran...]

XPDL is an interchange format, you can use it to exchange the business process diagrams among different tools.
BPEL is an execution language of the business process and you don't use it to exchange diagrams because it cannot store graphical information about the diagram.
Someone says that these two standards are complementary, others say that these are mutual exclusive.
Regards
Antonio

[Swati S]

XPDL is an interchange format, you can use it to exchange the business process diagrams among different tools.
BPEL is an execution language of the business process and you don't use it to exchange diagrams because it cannot store graphical information about the diagram.
Someone says that these two standards are complementary, others say that these are mutual exclusive.
Regards
Antonio

Hmm... agree but the tools which have XPDL support extends XPDL attributes and use it . because of this we can not use the same process in another tool. So it doesnot serve the purpose behind XPDL that is Process Exhange.

[Mickael Istria]

BPEL is originally more an orchestration language for WebServices than a Business Process definition language.
Compared to XPDL, BPEL is much more technical, much more difficult to read, much more difficult to write. BPEL is almost a scripting language that inherits from webservices problematics, XPDL is a true descriptive language dedicated to Business Processes.

(As you may have understood, I really prefer XPDL to BPEL, so that I am probably not totally objective )

[frankiben123]

thanks for the post..........

sales tracking software

[Swati S]

BPEL is originally more an orchestration language for WebServices than a Business Process definition language.
Compared to XPDL, BPEL is much more technical, much more difficult to read, much more difficult to write. BPEL is almost a scripting language that inherits from webservices problematics, XPDL is a true descriptive language dedicated to Business Processes.

(As you may have understood, I really prefer XPDL to BPEL, so that I am probably not totally objective )

Agree But I want to repeat this. Purpose of XPDL was to exchange process information across the BPM products even though each extends XPDL schema and use them and the same we can not use in other tool because of proprietary things present in Process Definition file.

[Michael zur Mueh...]

The purpose of XPDL is to capture the layout of the process and the essential information necessary to make it "run". Tool vendors can used extended attributes to store tool-specific information (e.g. specifics about internal tool functionality that is being used in the process). Its main purpose is to move the diagram around. The extended attributes must be preserved by the tools, even if they don't understand them. So, say, you model a process in TIBCO and export it to XPDL and then import the process in eClarus - if TIBCO adds some extended attributes to the XPDL file that eClarus does not understand eClarus should just ignore them, but not remove them from the file. If you change the diagram in eClarus and then export the XPDL and re-read it in TIBCO the original extended attributes from TIBCO should still be there.

In practice this is really meant to move the diagram around - capturing ~80% of the process semantics. It works well for requirements engineering. Once you start adding implementation details you will most likely stay within one vendor's environment. That means, you probably won't use IBM's process editor to specify a workflow that is then to be executed in Oracle's engine - there is just too much proprietary detail connected with the execution platforms to make this feasible. What you CAN do however is to draw the process in itp Commerce, eClarus or BizAgi, validate it with your line of business representatives, and then move it into an execution environment for further refinement.

BPEL and XPDL are complementary. You may use XPDL to move your BPMN diagram from a drawing tool to a workflow platform, and the workflow platform might use BPEL internally to store the process for execution. BPEL is XML scripting for web services orchestration, and some tools extend this to allow for user interactions (+ BPEL4People/WS-HumanTask are intended to help there). I would not want to write BPEL code by hand, so you'll probably work in a graphical environment to specify the process flow. If you want to move the diagram to another platform, you can use XPDL. BPEL doesn't store layout information by default, so a BPEL process will most likely be rendered very differently if moved from one platform to the other. XPDL is designed to preserve the layout.

[Lesley Fang]

Thanks for your post Michael. Really cleared a lot of things for me.

But I still have a question about BPEL & XPDL. Actually I'm currently trying to design a workflow engine. I'm new to this area. I have read many stuffs about BPEL & XPDL & BPMN, but I just wondered, why we have to use BPEL / XPDL when design the workflow engine, can we just run the flow by using programming language and database?

Thanks a lot!

[Swati S]

The purpose of XPDL is to capture the layout of the process and the essential information necessary to make it "run". Tool vendors can used extended attributes to store tool-specific information (e.g. specifics about internal tool functionality that is being used in the process). Its main purpose is to move the diagram around. The extended attributes must be preserved by the tools, even if they don't understand them. So, say, you model a process in TIBCO and export it to XPDL and then import the process in eClarus - if TIBCO adds some extended attributes to the XPDL file that eClarus does not understand eClarus should just ignore them, but not remove them from the file. If you change the diagram in eClarus and then export the XPDL and re-read it in TIBCO the original extended attributes from TIBCO should still be there.

In practice this is really meant to move the diagram around - capturing ~80% of the process semantics. It works well for requirements engineering. Once you start adding implementation details you will most likely stay within one vendor's environment. That means, you probably won't use IBM's process editor to specify a workflow that is then to be executed in Oracle's engine - there is just too much proprietary detail connected with the execution platforms to make this feasible. What you CAN do however is to draw the process in itp Commerce, eClarus or BizAgi, validate it with your line of business representatives, and then move it into an execution environment for further refinement.

BPEL and XPDL are complementary. You may use XPDL to move your BPMN diagram from a drawing tool to a workflow platform, and the workflow platform might use BPEL internally to store the process for execution. BPEL is XML scripting for web services orchestration, and some tools extend this to allow for user interactions (+ BPEL4People/WS-HumanTask are intended to help there). I would not want to write BPEL code by hand, so you'll probably work in a graphical environment to specify the process flow. If you want to move the diagram to another platform, you can use XPDL. BPEL doesn't store layout information by default, so a BPEL process will most likely be rendered very differently if moved from one platform to the other. XPDL is designed to preserve the layout.

Well explained. So I understand from what you said is its tool responsibility first not to remove other tools extended attributes as well as ignore them... right? Mostly time is invested to capture business requirement adn map it into business process. So its really important to not to waste the efforts because tool is changed.

[Swati S]

Thanks for your post Michael. Really cleared a lot of things for me.

But I still have a question about BPEL & XPDL. Actually I'm currently trying to design a workflow engine. I'm new to this area. I have read many stuffs about BPEL & XPDL & BPMN, but I just wondered, why we have to use BPEL / XPDL when design the workflow engine, can we just run the flow by using programming language and database?

Thanks a lot!

Thats how it works. Workflow is nothing but is series of steps. This steps can be defined in XML format. But to make this XML run meaning to make it executable tehre is workflow engine written in PL which reads this XML and execute. Database can be used as workflow repository and many other things...

[Abbasi]

Thanks for your post Michael. Really cleared a lot of things for me.

But I still have a question about BPEL & XPDL. Actually I'm currently trying to design a workflow engine. I'm new to this area. I have read many stuffs about BPEL & XPDL & BPMN, but I just wondered, why we have to use BPEL / XPDL when design the workflow engine, can we just run the flow by using programming language and database?

Thanks a lot!

Thats how it works. Workflow is nothing but is series of steps. This steps can be defined in XML format. But to make this XML run meaning to make it executable tehre is workflow engine written in PL which reads this XML and execute. Database can be used as workflow repository and many other things...

Just to clarify why we can't just run the flow using a programming language and database. Well, you can. Nobody stops you doing it. Actually this was how initial workflow systems worked. And then came the WfMC that addresses the need of a common reference model for interoperability amony products. They asked business analysts and process designers to do that using the standard workflow description language i.e. XPDL. It makes any vendor's engine that understands the XPDL to execute the workflow description. And as Michael said, you can always add the vendor specific attributes to these process definitions. The kind of workflows which are tightly coupled with the applications, often are very rigid and offer lesser functionality. Processes modeled through this approach are very difficult to evolve also. So it seems appropriate to use the standards like XPDL or BPEL to describe a workflow and let them be executed through stnadard worklfow engines.

Moreover @Swati S
Workflow engines embed numerous functionalities other than just executing the process XML like scheduling, data management, persistance etc.

Lastly, I say that the question initially asked is still unanswered. That is how does a standard be evolved if we keep on getting complementary solutions? More research and academia/professionals interaction are required in this regards.

[Lesley Fang]

Hi, Abbasi & Swati S,

Thanks for your valuable reply.

Actually my boss asked me to develop a workflow system for our product. He prefers the workflow to be drawn using BPMN notation, and then be executed using either BPEL or XPDL. I searched the internet and found that, it seems very difficult to directly map a BPMN graphical diagram to BPEL (especially if there are complicated loops inside the diagram). Does that mean I'd better use XPDL in this case?

Correct me if my understanding is wrong~~~ Thank you!

[Michael zur Mueh...]

Hi, Abbasi & Swati S,

Thanks for your valuable reply.

Actually my boss asked me to develop a workflow system for our product. He prefers the workflow to be drawn using BPMN notation, and then be executed using either BPEL or XPDL. I searched the internet and found that, it seems very difficult to directly map a BPMN graphical diagram to BPEL (especially if there are complicated loops inside the diagram). Does that mean I'd better use XPDL in this case?

Correct me if my understanding is wrong~~~ Thank you!

There are engines that run XPDL processes (with extended attributes). There are engines that run BPEL processes (often with vendor-specific extensions). And there are engines that run off a proprietary format or database schema.

There are arguments for each of these solutions, but the bottom line is: At the runtime level it does not matter what format the engine operates from.

The main argument to use BPEL is that it is designed as a scripting language to orchestrate the invocation of services. So, if your product is intended to connect different services (that have a WSDL specification) along a process model, then BPEL is typically a good choice. Your developers will probably need to finetune the BPEL code by hand, and by using BPEL rather than a proprietary format you will have a larger base of developers to tap into. There are extensions for BPEL (BPEL4People and WS-HumanTask) that allow for the integration of human performers, and some tools offer this functionality using proprietary extensions.

The issue that some people have raised when translating BPMN to BPEL lies in the fact that BPEL is a block-structured language (meaning that for instance every split in the process needs to have a corresponding join). BPMN allows you to design processes that are not block-structured (e.g. by using certain loops). These processes cannot easily be translated into BPEL. If an engine uses BPEL as the underlying/intermediary execution language it will have to constrain the modeler so that they can only design processes that fit into this block-structured model.

I hope this clarifies it.

[Swati S]

Just to clarify why we can't just run the flow using a programming language and database. Well, you can. Nobody stops you doing it. Actually this was how initial workflow systems worked. And then came the WfMC that addresses the need of a common reference model for interoperability amony products. They asked business analysts and process designers to do that using the standard workflow description language i.e. XPDL. It makes any vendor's engine that understands the XPDL to execute the workflow description. And as Michael said, you can always add the vendor specific attributes to these process definitions. The kind of workflows which are tightly coupled with the applications, often are very rigid and offer lesser functionality. Processes modeled through this approach are very difficult to evolve also. So it seems appropriate to use the standards like XPDL or BPEL to describe a workflow and let them be executed through stnadard worklfow engines.

I did not say "We MUST store process definition in XML format" but "We CAN". Modeling tool provides GUI for BA to map business requirement to process flow and and modeling tool stores this information in XML format at backend. Instead of storing in XML format this information we can directly put into DB and use it for execution and execute it using PL. Most of the tools uses DB for storing process definition XML into database for data persistence. Standard XML(XPDL) is structured to achieve interoperablity.

Moreover @Swati S
Workflow engines embed numerous functionalities other than just executing the process XML like scheduling, data management, persistance etc.

core functionality of workflow engine is to execute business processes defined. rest are the extended features which can be implemented by each tool. Job Scheduling, BAM, Data Persistence, Reporting can be added to make it full fledged BPM product.

Lastly, I say that the question initially asked is still unanswered. That is how does a standard be evolved if we keep on getting complementary solutions? More research and academia/professionals interaction are required in this regards.

Hmm... please eloborate more on this...