Correlation sets in BPEL allow designers to manage asynchronous conversations in their business processes. Correlations sets are both a simple idea and very useful. By design, BPEL engines can manage a wide range of situations automatically, as we explored in CTOT #5: Engine-managed correlations. But what can designers and developers do when things get more complicated?

That’s what we’ll explore  on CTO Tuesdays for Tuesday, May 4, 2010. We’ll be discussing more complicated correlation examples and offer tips and techniques for using BPEL correlation to support a very wide range of processes.

Please join us at noon ET, 9am PT and 16:00 GMT. You can register to watch the podcast live and participate in the Q&A discussion by registering at http://www.activevos.com/ctot.

We look forward to seeing you on the podcast.

Today, Active Endpoints announced that Australian telecom AAPT has gone into production with ActiveVOS to support the launch of many of its updated services.

Details of how AAPT has used BPM to change the way it develops applications are in the press release attached to this post.

Episode 17 of CTO Tuesdays covers BPMS support for long-running business transactions and compensation. Michael Rowley compares and contrasts BPMS support for transactions with that of transaction managers and describes how compensation can be applied to business transactions.

This episode is the second of two on persistence and compensation. If you haven’t seen the previous episode, you might find it interesting to review before watching this one.

Four files are attached to this post. Three are video recordings of the podcast in different formats; the fourth is a PDF of the slides Rowley presented.

Please be sure to sign up for our next CTO Tuesdays, scheduled for March 30, 2010 at noon ET. The topic will be “Handling approvals by email in business processes.”

This time on CTO Tuesdays, the BPMS podcast, we discuss what persistence of state offers process developers and BPM users. Michael Rowely, host of the podcast and CTO at Active Endpoints discusses what persistence is, how it works and what the potential performance costs might be.

We hope you enjoy this podcast. We’d love to hear your feedback on the series. Just email us or leave a comment here.

Remember: sign up for next week’s CTO Tuesdays here. We will be expanding on persistence to talk about BPMS support for long-running transactions.

Update 3/17: in case you missed the second part, you can watch the replay here.

In this episode of CTO Tuesdays (our 15th!), Active Endpoints CTO Michael Rowley discusses an elegant way of bridging the world of BPEL and the Java world. Then, after the technical presentation, Rowley discusses in the Q&A how, when and why process developers might want to use Java in their processes and warns against “speaking BPEL with an accent.”

There are three formats of the webinar attached to this post. For iTunes and iPod touch/iPhone users, an .m4v is available. A Flash file that can be streamed from the blog and/or downloaded is attached and a Windows Media 9 .wmv is also available.

Please remember to register for next week’s CTO Tuesdays at http://www.activevos.com/ctot

Attached to this post is a replay of a webinar we recently presented with our UK partner, T-Impact. T-Impact has deep expertise in BPM in industries like telecom. In this webinar, they detail their approach to BPM and how they use ActiveVOS to deliver process applications for their clients.

There are three formats attached to this post. First, an iPod touch/iPhone-formatted .m4v. We also have a Flash file that can be streamed from the blog and a Windows Media 9-encoded .wmv.

OK, I know…the title “preventing problems through static analysis” doesn’t exactly make you want to spend 40 minutes watching the replay of episode #14 of our weekly tech talk on BPMS technology.

But you’d be missing a really interesting and, dare I say it, fun topic. Trust me.

This week Michael Rowley tackles bugs in BPMSs. Bugs are just a part of life when creating business applications. But what about when you are creating process applications using a model-based BPMS? What happens then? How does the BPMS help you identify — even prevent and eliminate — bugs? Watch this episode to find out how standards like BPMN 2.0 and BPEL work together to help make designing and executing process applications more error-free.

As always, we have three formats of the podcast posted. There’s an iPod touch/iPhone .m4v; a Flash file that can be streamed from the blog and a Windows Media 9 .wmv.

On this episode of CTO Tuesdays, we explore an important concept in software modeling: structured vs. unstructured modelers. Examples of both types are compared and contrasted. Also, the ActiveVOS BPMN 2.0 modeler, which blends the best of both types of modelers is demonstrated.

Three versions of the webinar are attached to this post: an iPod-formatted .m4v file, a Flash .flv file and a Windows Media 9-formatted .wmv.

Every Wednesday at noon ET, 17:00 UTC, we present a live webinar followed by a Q&A with our product manager, Mike Moniz, that takes a look at the features of ActiveVOS BPMS. You can always register for the upcoming webinar here.

However, we realize that this is a very inconvenient time for people in Asia-Pacific and some other time zones. So, we occasionally record the most recent webinar and post it to the blog. Attached to this post are three versions of the same recording. One, a .m4v file, is intended for iPod touch/iPhone users and is also available in our podcast feed. Second is a Flash .flv file (which can also be played directly on the blog). Finally, there’s an Windows Media 9-encoded .wmv. These files are large, because the webinar lasted over an hour. But the content is worth the download time.

In the last quarter of 2009, ActiveVOS sales grew rapidly. Details are in the attached press release.

As those of you who follow us know, we’re very proud of the fact that ActiveVOS is built from the ground up on standards. We strongly believe that standards support is the entry price for any BPMS that hopes to change the way process applications are built and deployed.

Now, I am pleased to report that OASIS has announced that the WS-BPEL Extension for People (also known by its alliterative shorthand name, BPEL4People) 1.1 specification is available for public review. In addition, the companion specification, WS-HumanTask 1.1, is also available for public review. ActiveVOS 7 implements both WS-HumanTask and BPEL4People.

In short, these two standards marry automated processing with a vastly updated and more intelligent approach to human workflow that (finally!) makes including people in complex processes as easy as including any system task.

Consider the graphic above. Prior to WS-HumanTask (and BPEL4People), creating human tasks usually required interaction with a proprietary workflow system that didn’t necessarily integrate easily with the rest of the application architecture:

One of the motivations of WS-HumanTask was an increasingly important need to support the ability to allow any application to create human tasks in a service-oriented manner. Human tasks had traditionally been created by tightly-coupled workflow management systems (WFMS). In such environments the workflow management system managed the entirety of a task’s lifecycle, an approach that did not allow the means to directly affect a task’s lifecycle outside of the workflow management environment (other than for a human to actually carry out the task). Particularly significant was an inability to allow applications to create a human task in such tightly coupled environments.

This graphic neatly shows how these new standards separate — and standardize — the work items from the processing of those items. All in all, a huge step forward for a new generation of process apps.

When you do take a look at the specs, I hope you’ll notice the level of commitment Active Endpoints has made to developing and finalizing these standards. Two of our technical leaders, Luc Clément and Michael Rowley, are listed as editors for the drafts. They are helping make a lasting contribution to BPM through their efforts to bring these standards to market, in partnership with the other members of the OASIS Technical Committee.

Attached to this post is a reply of the December 8, 2009 edition of CTO Tuesdays. CTOT is a weekly webinar presented by Active Endpoints CTO Michael Rowley which presents a technical topic of interest to BPM users. CTOT discusses the “how” and “why” of technologies like BPMN and BPEL at a detailed technical level and is of interest to enterprise architects, developers and managers who want to understand the latest in BPM technology.

This episode takes a look at how it is possible to meld the “Wild West” control flow of BPMN 2.0 with the more buttoned-down control flow of BPEL. Rowley gives an example of a BPEL extension that effectively marries these two standards in a way that preserves the best of both BPMN modeling and BPEL execution.

There are two versions of the webinar replay file attached. First is an iPod-formatted .m4v. Also available is a Windows Media 9-encoded .wmv file.

You can always register for the upcoming CTO Tuesdays webinar at http://www.activevos.com/ctot. Registration is free. Access replays on the Wednesday following the webinar at http://www.ctotuesdays.com or via RSS feed at http://www.ctotuesdays.com/feed.

Be sure to join us next Tuesday, December 15, 2009 at noon ET, 17:00 UTC, 9am PT for a very special CTO Tuesdays in which Michael Rowley will deliver an introduction to BPMN 2.0. If you are interested in BPM and BPMS technology, you won’t want to miss this episode.

Frequent visitors to our blog (and we hope you become one) will have already that we are in the middle of a fascinating discussion on the question of execution engines. Now, Rob Barry of searchSOA.com has weighed in with this post.

We welcome your comments and feedback on this topic.

Also, we would also like to invite you to our weekly webinar CTO Tuesdays. Every Tuesday at noon ET, 17:00 UTC, Active Endpoints CTO Michael Rowley discusses a single technical topic in 30 minutes, followed by a Q&A from the audience. In the recent past, we’ve covered topics like the BPMN 2.0 diamond control flow and engine-managed execution. Our most recent webinar delved into the the issues of dead path detection in BPEL and how to model in BPMN 2.0 to avoid duplicate activity execution.

You can always find the replays of the webinars on this blog in the “CTO Tuesdays” category (RSS feed here). Registration for the next CTO Tuesdays webinar is always available here.

I am very pleased to post a recording of what I personally think was the most interesting CTO Tuesdays talk we’ve had yet. This time, Active Endpoints CTO Michael Rowley discussed BPMN 2.0 and BPEL control flows, pointing out the “trap doors” in BPMN 2.0 notation that can, for example, lead to unintended simultaneous downstream process execution and how BPEL (still using BPMN 2.0 notation) can effectively prevent hard-to-understand and -debug process applications in a BPMS.

CTO Tuesdays has been getting great feedback from our growing audience, and I’d like to offer this week’s episode as a good example of why. The discussion of BPMN 2.0 and BPEL flows is something you might not find elsewhere, delivered in an objective way and surrounded by stimulating questions and discussion with attendees. I hope you will join us every Tuesday at 17:00 GMT and participate as well. You can register at http://www.activevos.com/ctot. The replays are always available at http://www.ctotuesdays.com or via our RSS feed at http://www.ctotuesdays.com/feed

Bruce Silver saw my previous post on the simplicity of BPMN vs. BPEL for execution and wondered: “Are we still debating this?”

Still?

The BPMN 2.0 spec just went to beta in August and no vendor yet has an implementation of the new BPMN 2.0 execution language. So at this point the debate is just getting started. We can only compare what exists (BPMN 2.0 with BPEL execution) with the theoretical idea of a product that will someday implement the new BPMN 2.0 execution language.

At that point we will be able to get a real side-by-side comparison. Until that time, we have to guard against “shiny-new-thing syndrome,” where the newly envisioned technology gets to paint a wonderful picture looking toward the horizon, while actual working technology has to compete against that vision bearing the stains that come from living where the rubber meets the road.  Although, in this case, even the horizon envisioned by the BPMN 2.0 execution language is tainted by some pretty scary-looking smoke.

Bruce dismissed my assertion that BPMN 2.0 on top of BPEL is simpler than the new BPMN 2.0 execution language with the following:

Simpler for whom?  When you sort it all out, he’s actually saying BPEL is simpler for an engine vendor because it doesn’t have overlapping or alternative constructs like BPMN does.  No one would argue with that, but who cares?  No engine vendor is going to support every possible BPMN 2.0 element and attribute called out in the metamodel.  And I’m not saying just in the first release.  Not ever.  In that sense, BPMN 2.0 is not a self-contained execution language like BPEL is.

We disagree. Because we’ve actually built an execution engine, we know that it is actually pretty easy to implement alternative overlapping language constructs. This debate about simplicity isn’t about what a vendor can build — it’s about what the ultimate impact of that engine technology is on the user who designs and deploys processes on that engine.

My concern is for the poor person who is trying to figure out what is going wrong with a process that occasionally gets stuck. Forward progress for a process that uses the BPMN 2.0 execution language depends on a complex interplay between a huge number of constructs: event handlers, correlation mechanisms, data-flow with optional and required data, and token-based control flow that has to account for multiple tokens flowing simultaneously on a single sequence flow.

The problem with a language that is large and complex is that it is hard to have any confidence that what you’ve created will always work the way that you expect it to in production, especially when you can only test a small subset of the exponential number of possible execution scenarios.

Bruce’s admission that “BPMN is not a self-contained execution language” is noteworthy and I hope people pay close attention to it. Why do people care about standards for the languages that they use for their software? The answer is portability – primarily portability of skills but also portability of code and interoperability of tools. Basically, they are looking for an ecosystem around the language.

I love the fact that portability of skills will be enhanced by the standardization of BPMN as a notation, but for all of the constructs that are necessary to get the thing to actually execute, it seems like there are two choices: use BPEL, which is (despite assertions to the contrary) quite portable, or use some vendor’s subset/interpretation of the new BPMN 2.0 execution language. By “interpretation” I mean that even strict conformance to BPMN 2.0 admits incredible levels of freedom that are counterproductive to the creation of a language ecosystem. The most egregious example of this is the fact that the type system is pluggable. Few things are more important in a language than the type system, and yet BPMN 2.0 allows vendors to choose their own.

Bruce’s attack on the use of BPEL with BPMN rests on the assumption that: “BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.” Actually, BPEL supports both styles (although with some caveats). Here is a process built using ActiveVOS that is standard BPEL:

Doesn’t this look like a flow chart to you?

The one caveat that BPEL put on this style is that the loops have to be nested. This is where I agree with Bruce – without any extensions, BPEL does have an issue with “interleaved loops.” From my experience, interleaved loops are not the most common case, but if you do have a process where interleaved loops are the most natural way to represent it, what do you do? You have two choices: 1) with the use of variables, you can always rework the graph so that the loops aren’t interleaved; or, 2) you can use an extension to BPEL that removes the looping links restriction. This is an extension that is supported by both Active Endpoints and IBM and does away this nagging issue in the mapping between BPMN and BPEL. And it does this without thowing the entire language out the window and starting from scratch to make a bigger, more complex language.