BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Article: Why BPEL is not the Holy Grail for BPM

by Gavin Terrill on Oct 22, 2008 |

BPEL (Business Process Execution Language - short for WS-BPEL) was originally conceived to facilitate the orchestration of the various web services interactions (i.e. the SOAPful variety) required to complete a business process. BPEL recently came into the spotlight again, after a post by Ismael Ghalimi (of Intalio) explaining "Why BPEL matters":

Whether you like it or not, BPEL won the war of standards. While we (Intalio) lost a battle when BPML was supplanted by BPEL (because we had failed to secure IBM’s support for it), the war was eventually won when BPEL 2.0 was released (with Intalio’s support), and all major vendors adopted it against XPDL, including Microsoft, Oracle, and SAP. Some legacy workflow vendors might find delight in trying to re-play lost battles of the past (like some nostalgic French patriot dreaming of what could have been had Bonaparte’s army won the Battle of Waterloo ? I know, I’m French), it’s time to move on. Really.

This article sparked a major discussion in the BPM community about the technical merits of BPEL. Arthur ter Hofstede, a respected voice in BPM academia, responded strongly to the claims that BPEL leverages the Pi-Calculus mathematical model, pointing out:

It is not sufficient to just say that a certain language is based on a certain theory and that therefore this language derives some wonderful properties from this theory. This needs to be actually demonstrated in a reproducible (and hence publicly available) way. Till then such claims should not be made.

In this new article, Pierre Vignéras, a member of the Bonita team at Bull R&D, adds more fuel to the flame; exploring issues facing practioneers trying to use BPEL to model a simple parrellel process modelled with BPMN (Business Process Modelling Notation).

Read the article: Why BPEL is not the holy grail of BPM.

 

 

 

 

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.

Tell us what you think

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

Email me replies to any of my messages in this thread

Why BPEL is not the holy grail for BPM by Stephen Baudendistel

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

Re: Why BPEL is not the holy grail for BPM by Gavin Terrill

Fixed. Thanks.

Nice try. by Alex Boisvert

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

"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

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

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

Tom,

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

Robert
soaprobe.blogspot.com

Re: Nice try. by Mickael Istria

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

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

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

@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

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

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

@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

...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

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

Robert
soaprobe.blogspot.com

Not the only way to go by Alexis Brouard

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

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

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

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

the 3 links in the Resources section still produce 404s

Re: Why BPEL is not the holy grail for BPM by Stephen Baudendistel

The 3 links in the Resource section still produce 404s

Re: People == Asynchronous Services by Tammo van Lessen

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

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

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

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


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


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

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

29 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT