Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #35: Boundary events in BPMN 2.0

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #34: XPath – The Unsung Hero of Service-Oriented BPM

• OASIS: BPEL4People 1.1 and WS-HumanTask 1.1
• OMG: BPMN 2.0
• WfMC: XPDL 2.2
• OASIS: SCA 1.1

In this week’s CTO Tuesdays, I describe the current state of each of these efforts along with a brief description of the history and main goals of these standards. Here is a recording of the presentation and a copy of the slides.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #32: BPM Standards Update

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #31: SOA — from concept to SOAP opera, part 2

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #30: SOA — from concept to SOAP opera, part 1

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Active Endpoints posts record sales in Q2 2010

OK, OK…I know. The pun on SOAP and soap opera is a little much. But doesn’t the SOA world feel like a never-ending, overwrought daytime TV drama?

I mean, c’mon. Nobody can decide if SOA is dead or alive…if it’s a product (or set of products) or if it’s JBOI (just a bunch of ideas, a pun on “JBOD.” I just can’t help myself.).

So, starting tomorrow on CTO Tuesdays, the BPM podcast, Michael Rowley will begin another “miniseries” within the larger podcast that begins with the very basics of SOA and builds over time to paint a complete picture of this much discussed and often misunderstood development approach. We intend this as a primer for both new and expert users and we are excited that the recurring SOA topics will expand CTO Tuesdays’ regular line-up of BPM technology talks.

Register for CTO Tuesdays at http://www.activevos.com/ctot and, as always, you can return to this blog for replays. But we hope you can join us live because we expect the discussion after Michael’s presentation on these topics to be very lively and we hope to have you join in the discussion.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Next on “CTO Tuesdays:” SOA – from concept to SOAP opera

Starting with last week’s CTO Tuesdays and continuing with the episode posted below, we have increased our range to crucial technical decisions for BPM users which may have very long-term effects.

We are, to put it bluntly, very concerned that the marketplace is receiving — and accepting — incorrect information about the real relationship between BPEL and BPMN 2.0. Last week, Michael Rowley dispelled this myth in the abstract. This week, Michael has gone further: he actually shows what a two-toolset, two-engine BPMS environment with only a fig-leaf of integration looks like, using Oracle’s BPM Suite 11g and SOA Suite 11g as the poster children.

Yes, Oracle is a competitor. And yes, we have a “dog in the hunt,” as they say. Therefore, for sure, we have an opinion.

None of that undoes the fact that users should consider alternative points of view — views based, as we attempt to do, on the exact text and meaning of the BPMN 2.0 specification. And the fact that we have an opinion — and a product based on that belief — doesn’t undo the fact that much of the argument that BPMN should execute directly and that BPEL is passe is as self-serving as anything we may say.

So, I urge you to watch the replay of CTO Tuesdays attached to this post and to consider the alternative arguments we make. We’re not going to convince everybody, but we truly believe that the people who do consider their long-term BPMS strategy will find that BPMN as notation with BPEL execution is the better alternative.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #29: Oracle’s misguided approach to BPMN and BPEL

You can see the very best of that loud-but-authentic aesthetic at work in episode 28 of CTO Tuesdays, the BPM podcast.

For too long — and, frankly, for reasons that mystify me — some voices have spoken of a “conflict” between BPMN and BPEL. It has always seemed to me that those points of view — that BPMN 2.0 is somehow a “successor” or “replacment” for BPEL –  have an agenda that’s more about their preferred results in the marketplace than about the “best” or the “right” thing for users. IOW, politicking is at play.

But, as we all know, in politics, negative campaigning works. “BPEL is dead;” “BPMN 2.0 execution obviates BPEL.” These misstatements have gained far more attention than they deserve. They have escalated to the level of myth — or worse, conventional wisdom — both of which can have lives very separate from reality.

Our response: BPMN 2.0 is better with BPEL execution for users for a plethora of reasons. Far from dead, BPEL’s fundamental mistake of not specifying a visual notation is cured by BPMN 2.0. And BPMN 2.0 achieves its highest likelihood of success when coupled with BPEL execution.

Still, the myth that these two crucial standards are in conflict persists. Watch this podcast replay to see and hear Michael Rowley debunk these myths — passionately and accurately.

And be sure to join us next week for episode 29, titled “Oracle’s misguided approach to BPMN and BPEL” for even more myth-busting. Register at http://www.activevos.com/ctot.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #28: Debunking the myth of conflict between BPMN and BPEL

BPMN 2.0 Complete Conformance can only be claimed by an engine if the engine also supports the BPEL Process Execution Semantics Conformance Type.

The phrases in bold are the names of conformance classes in the latest public draft of the BPMN 2.0 standard specification. The conformance section of the specification defines multiple conformance types; one of which is the “BPEL Process Execution Semantics Conformance Type”, which defines how to use BPEL to execute a standard BPMN model. The last BPMN conformance type is called “complete conformance” and it also requires support for BPEL.

So, back to the article that Tom Baeyens’ linked to when he claimed that that “the translation step from BPMN to BPEL is very problematic to say the least.”

As it turns out, William Vambenepe misunderstood the semantics of the BPMN construct that was supposedly in conflict with BPEL. He references this snippet of BPMN:

But he describes it this way:

The customer quote can be reviewed by the region manager, the country manager or the VP of sales. At least one of them must review the quote. More than one may review the quote.

He then goes on the show how hard it is to represent the at-least-one requirement in BPEL. The problem is, the above BPMN snippet has no at-least-one semantic.

Here is what the BPMN 2.0 specification says about the inclusive gateway: “each path is considered to be independent, all combinations of the paths may be taken, from zero to all. However, it should be designed so that at least one path is taken.”

This means it has the exact same semantics as BPEL’s concept of conditional links out of an activity: any subset can be followed, including none.

People also sometimes claim that the problem comes from the fact that BPMN is unstructured while BPEL is structured. Actually, the problem is that some tools don’t know about the free-form style that is permitted in BPEL. BPEL supports both structured constructs and unstructured flows. Oracle BPEL Process Manager, for example, does not show the links in unstructured flows (no arrows), so they are basically worthless in that tool, but the standard does allow them and ActiveVOS supports them fully.

So, are there any processes that can be represented in BPMN that are difficult or impossible to map to BPMN? Yes, there is a restriction in BPEL against cycles in flows that make it difficult to represent interleaved loops in standard BPEL (although I haven’t actually seen an example of this pattern in a post about the mismatch between the two languages). However, this restriction in BPEL is not is fundamental to the language. Active Endpoints has implemented this simple extension that removes that restriction and we encourage all BPEL engines to also support the elimination of that restriction.

Let me finish by quoting the first two paragraphs of the BPMN 2.0 specification. Note especially the second paragraph.

1. Scope

The Object Management Group (OMG) has developed a standard Business Process Modeling Notation (BPMN). The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.

Another goal, but no less important is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.

Clearly the specification writers see no conflict between BPMN and BPEL.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Debunking the myth of BPMN conflict with BPEL

In this episode, Active Endpoints CTO Michael Rowley tackles a more complex case for correlation: when you can’t use engine-managed correlation because the developer doesn’t have control of the client in a business process. This episode reviews the terms used in correlation and then walks through a simplified procurement process to illustrate the concept.

As always, we welcome your feedback and suggestions. And we hope you will be able to join us for the live recording of CTO Tuesdays ever Tuesday at noon ET.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #22: Complex correlation scenarios

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Tomorrrow on “CTO Tuesdays:” Complex correlation scenarios

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

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Australian Telecom AAPT goes live with ActiveVOS applications

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

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #17: How BPMSs support long-running business transactions

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #16: The state of BPMS state: persistence for process

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

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #15: Using Java with business processes

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #45: An introduction to T-Impact

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #14: Preventing problems through static analysis of business processes

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #11: Structured and unstructured BPMN modeling

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #40: ActiveVOS 7 demonstration

In our first episode of the new year, Active Endpoints CTO Michael Rowley covers some basic theory of how complex event processing (CEP) works and makes the case for integrating a CEP engine directly into the BPM engine. Topics covered include the Event Processing Language (EPL), time windows as a method of correlating disparate events and event streams. In short, a fascinating — and accessible — introduction to a hot technical topic.

We have attached several formats of the webinar replay to this post. First, for iTunes subscribers, we have a .m4v file, perfect for taking along on your iPod. RSS feed subscribers will automatically receive this file. Also, there’s a .flv file which can be played directly on the blog (click where it says “click here” to play it). Also, we have attached a Windows Media 9-encoded .wmv file. Finally, the slides Michael presented are attached as a .pdf.

Be sure to join us live every Tuesday at noon ET, 9am PT, 17:00 UTC for a new topic. You can always register for the upcoming CTO Tuesdays webinar at http://www.activevos.com/ctot. Replays are usually posted here on our blog within 48 hours.

We have an exciting agenda of upcoming episodes, and later in the first part of Q1, we hope to guest CTOs join us for their perspectives on technical topics. We hope you will join us live each week.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #9: BPM as an event source for CEP

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

ActiveVOS Experiences Rapid Sales Growth in Q4 2009

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

BPEL4People and WS-HumanTask 1.1 reach public review

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #7: Adding Looping Links to BPEL

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

searchSOA.com on the BPMN 2.0 with BPEL discussion

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

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #6: Diamond patterns in BPEL and BPMN

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.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

BPMN 2.0 with BPEL — the debate is just starting

Active Endpoints CTO Michael Rowley then demonstrates using a BPMN 2.0 modeler to create executable BPEL processes.

A panel with Jeffrey and Michael follows the presentations.

Attached to this post are three files. An iPod-encoded .m4v file, a Windows Media 9-encoded file and a PDF of the slides that Jeffrey and Michael presented.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #39: Modeling process applications with BPMN 2.0

BPEL is complex and BPMN is simple, right? After all, BPMN has a nice graphical notation. The BPEL standard only specifies what the language looks like in XML. That alone ought to be enough claim the prize for BPMN.

However, what if you use BPMN’s notation for a process but use BPEL for the executable representation? This removes the graphical vs. XML distinction and can “hide” the non-graphical BPEL as represented in XML. You end up with a BPMN model everyone can understand and a BPEL model your computers can execute. It’s like the two sides of a coin: there are different pictures on each side, but the coin itself is always both sides at once.

However the question of which is simpler gets more complicated when you also consider that the new BPMN 2.0 specification includes hundreds of constructs in its meta-model that have no graphical representation. Now, which is simpler, BPMN with BPEL or BPMN with the new BPMN 2.0 execution language? What may seem obvious (BPMN with BPMN 2.0 execution) isn’t the slam-dunk choice many people might expect it to be.

BPMN 2.0 has two different — but equal — compliance points for execution: BPEL Process Execution Conformance and Process Execution Conformance. This means that BPMN 2.0 standardizes the use of BPEL as the execution language for BPMN, but it also offers the option of making BPMN executable by using new constructs that have been added to the BPMN notation specifically to support execution. These new constructs depend on the execution semantics that have been defined for almost everything in BPMN.

So, which is simpler? Believe it or not, using BPMN with BPEL execution is dramatically simpler than trying to execute processes using the new BPMN 2.0 execution language. I know this sounds counter-intuitive, so I will justify it in this post and a series of follow-up posts on the same subject.

Before I get into the details of why I believe BPMN with BPEL is better, a little history might help clarify the question. There are some factors that caused the BPMN 2.0 standard to eventually become more complex than BPEL. (I know, I know, BPEL has the reputation of being far too complex…but hear me out.)

BPMN was designed to be a language for communicating from one person to another, not from a person to a machine. Languages used for human communication have a natural, and appropriate, tendancy to grow. Whenever people find that they frequently need to convey something that is awkward to express with their current vocabulary, they invent a new word. English, which is especially amenable to such growth, surpassed one million words last year. Just consider “unfriend” or “netbook,”  new words to express new ideas.

The same is true for graphical modeling languages. Look at UML (Universal Modeling Language). It started as the unification of three fairly simple graphical notations (best known by their respective primary inventors: Rumbaugh, Coad & Yourdan, and Grady Booch). Once they unified their modeling languages and people started using them in earnest, they grew larger and larger, with new diagrams and new elements on those diagrams with each successive version. Sure there was always overlap in what could be expressed by different diagrams or different elements, but in each case, there were situations where one was more natural to the reader than the other. The fact that different constructs have imprecise overlapping meanings is of little concern in a language meant for people, since people are comfortable with choosing among a variety of ways of expressing the same thing, each with their own nuances and connotations.

But while notation creep is a useful way of expanding spoken languages or graphical notations, it is not such a good thing for a language that must be directly executable on a computer.

That’s because it is always a problem to take such a large language and give it formal executable semantics. The problem usually isn’t with a lack of rigor in the definition of any one construct. The problem is with the exponential number of combinations of those constructs.

Good programming languages typically add new fundamental primitives very cautiously. Consider how much hard preparatory work was done in the Java community before Java introduced generics into the language, or the hand wringing that is gripping that community as they grapple with the addition of closures to the language. The way it typically works is that some eminently-respectable, highly-credentialed expert (like Neal Gafter, in the case of closures) will make a seemingly very well-thought-out proposal that describes how the new construct will simplify the lives of so many programmers. Then another equally eminent expert (like Josh Bloch, in this case) will find unintended consequences of the new construct when it is used in combination with other things in the language.

That was just for one language feature. The BPMN 2.0 execution language has dozens of features that have never really been used together in an execution language. For example, the BPMN 2.0 execution not only has a variety of ways of handing the control flow for multiple incoming sequence flows, activities also can’t execute until all of the required inputs from one of the activities input datasets has become available. In other words, it has a fairly complex data flow model intertwined with its control flow model.

Another example is message correlation. BPEL has, in the past, been criticized for the complexity of its approach to correlation, but BPMN has two different correlation mechanisms. Key-based correlation is basically equivalent to BPEL’s correlation mechanism, although the standard has invented all new terminology for the various components. It then defines a new concept of context-based correlation. Rather than trying to convince you that it is complex, I’ll just include the complete explanation of it from the BPMN 2.0 specification (yes, in a 500-page specification, there are no examples or additional explanations for these concepts):

In context-based correlation, the Process context (i.e., its Data Objects and Properties) may dynamically influence the matching criterion. That is, a CorrelationKey may be complemented by a Process-specific CorrelationSubscription. A CorrelationSubscription aggregates as many CorrelationProperty-Bindings as there are CorrelationProperties in the CorrelationKey. A CorrelationPropertyBinding relates to a specific CorrelationProperty and also links to a Formal-Expression which denotes a dynamic extraction rule atop the Process context. At runtime, the Correlation-Key instance for a particular Conversation is populated (and dynamically updated) from the Process context using these FormalExpressions. In that sense, changes in the Process context may alter the correlation condition.

Confused yet? Are you wondering not just why BPMN 2.0 needed to define and redefine an important concept like message correlation, but also wondering how, precisely, to implement BPMN correlation?

These are just a couple of the ways that BPMN’s new execution language is more complex that using BPMN with BPEL. BPEL is now a known commodity. It’s widely implemented. Many production applications are running BPEL today. There are many people with experience with it and the concepts in the language are well understood. With BPMN 2.0, it now has a standardized notation, so there is no need to work with a new language that is a big bag of language constructs whose interactions have never been exercised together.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Which is simpler: BPMN or BPEL?

There are two attached versions of the webinar replay (an iPod-formatted .m4v and a DivX-encoded .avi). As always, you can register for the next episode of CTO Tuesdays at http://www.activevos.com/ctot. We look forward to your comments, suggestions and feedback.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #5: Engine-managed correlation

The bad news is that due to a technical issue, the audio for the host, our own Sonal Rajan, wasn’t recorded. This is shame because at the end of each topic, we always have an open Q&A session on the current topic to amplify the technical discussion. Unfortunately, these replays won’t have that Q&A because there’s no audio for the moderator. However, the actual presentation about message correlation was recorded just fine.

In the two attached versions of the webinar replay (an iPod-formatted .m4v and a DivX-encoded .avi), I have edited most of the silent introduction and the Q&A.

As always, you can register for the next episode of CTO Tuesdays at http://www.activevos.com/ctot.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #4: Message correlation

First, lets assume that you are convinced of the value of BPEL. You see that it is a great high-level language for creating business processes and orchestrating services. Its service-centric approach is simpler and better for long-term manageability and reuse than other approaches to business process management. It is an accepted OASIS standard with multiple vendor implementations, so investments in BPEL processes are not tied to a single vendor and you can find people who already know the language without having to train them from scratch.

But if you are convinced you want BPEL, why should you care about BPMN? There are two main reasons:

1) To get the value of a standard notation;

2) To improve collaboration with a wide variety of stakeholders in the process, since BPMN is a significant simplification over existing notations used for BPEL.

When WS-BPEL 2.0 was standardized, the OASIS Technical Committee chose not to standardize a graphical notation for it. This was unfortunate, since no one creates a business process by writing BPEL in XML, which is the only standardized representation. Every vendor, and every BPEL developer, creates their processes using a graphical representation, but that representation is different for every tool.

And the notations used by these tools haven’t really been very good. They typically provide a one-to-one correspondence between control flow constructs in BPEL and things on the canvas. However, if you use the BPMN notation, it shows a notation that can mostly be understood without any knowledge of BPEL or even BPMN for that matter (as long as the labels are chosen carefully).

Let me make both of these points with the help of a trivial process example. Take a look at the BPMN representation of a process that I’ll call the “Question” process.

(Click on each image to see a larger version)

It is trivial to follow what is going on, especially if you know the standard notation. You can’t tell by looking at this diagram, but I’ve used two different BPEL mechanisms for getting to the next activity. I use a BPEL link to get from “Receive Q” to the first diamond (the beginning of the BPEL if statement). I use a BPEL sequence to get from the second diamond (the end of the if) to the “Record Answer” activity.

The user who is looking at the graphical representation of the process doesn’t need to know about the distinction between these two mechanisms, so the diagram doesn’t show a difference. The developer may want to know about the difference, so ActiveVOS highlights them differently on mouse-over and shows them differently in the “process outline view”, but that isn’t really important for today’s discussion.

What is important is how different the process is represented in different tools due to the fact that no notation had been standardized. I’ll show what this process looks like in three different BPEL process designers.

Here is how ActiveVOS would represent this process in previous versions of the product (or using the optional “classic” style in 7.0):

Here is how the Eclipse BPEL Designer represents it:

And, here is how the designer for Oracle’s BPEL Process Manager represents it:

In all three of these representations, each of the paths through the if statement are represented by a bounding box. The problem with this representation is that nested if statements can result in so many nested bounding boxes that it is hard to follow what is going on. BPMN simply has arrows through each path and the paths merge back into a single control flow at a gateway diamond.

Also notice the differences in the handling of links vs. sequences. Both ActiveVOS classic and Eclipse represent sequences with their own bounding boxes, then any arrow that is a direct child of a sequence box is known to belong to the sequence, rather than being a real link. Eclipse also draws the links in different color. The extra sequence icon and corresponding bounding box just interferes with the ability for non-technical users to follow what is going on in the process.

Oracle’s designer is odd in this respect. Sequences are not shown in a bounding box, so they don’t clutter up the control flow (a good thing in my opinion), but links aren’t shown at all! There is a link from the “Receive_Q” activity to the if statement, but there isn’t any representation of it on the diagram. It shows the “Receive_Q” and the if as if they happen in parallel. You have to look into the properties of “Receive_Q” to discover that it has an outgoing link, and further rummaging to find out where it goes.

The BPMN representation is, by far, the easiest version of this small process to understand. The process illustrates just three constructs whose representation is simpler with BPMN than with other approaches: ifs, sequences and links. The other BPEL constructs are generally as easy or easier for non-technical users to understand than previous approaches.

But, as valuable as the improvement in readability may be, the greater value that BPMN brings to be BPEL is probably consistency. Having different tools represent similar constructs in such different ways is detrimental to one of the key values in having a standard: skills portability. With a common notation, people will be able to carry their knowledge of how to understand and work with standards-based business processes between vendor tools. It will also create a greater incentive for people to learn these technologies and for schools to teach them. After all, people aren’t usually to thrilled about investing a lot of energy into learning proprietary technologies, and no school really wants to be teaching proprietary technologies.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Why use BPMN for BPEL?

I think you will find Michael’s explanation of BPMN 2.0 event notation especially valuable.

I have attached two versions of the recorded webinar to this post. The first is an iPod-formatted .m4v. Also attached to this post is a Windows Media format .wmv file.

We have also made signing up for CTO Tuesdays and accessing the replays much easier. You can always sign up for the upcoming session of CTO Tuesdays at http://www.activevos.com/ctot. Replays are always available at http://www.ctotuesdays.com. And, an RSS feed of the replays is available at http://www.ctotuesdays.com/feed.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #3: BPMN and BPEL events

Attached to this post are three files. A PDF of the slides Dr. Rowley presented, an iPod-formatted .m4v file (which requires QuickTime or iTunes to be installed) and a more-or-less standard .avi file. The .avi is the larger of the two video files.

Due to a technical error (I didn’t press “show” on GoToMeeting), the first few minutes of the video show Michael’s slides, not the ones I am discussing. Since this is just an introduction, you won’t miss anything. I’ve put those “missing” slides into the .pdf file, so you can follow along if you want to.

We had a very lively panel discussion at the end of the presentation; I hope you’ll have the time to listen to the discussion that follows the presentation.

As always, we are very interested in your feedback, comments and topic suggestions.

One more note: you can always register for the upcoming CTO Tuesdays session by visiting http://www.activevos.com/ctot. We hope you join us for next week’s webinar.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #2: Introduction to WS-HumanTask

Every Tuesday, Active Endpoints’ CTO Michael Rowley, will present a topic of interest to BPM users. Our inaugural topic was an explanation of the meaning and uses of the BPMN 2.0 diamond symbol. If you are interested in learning BPMN 2.0 — or if you just want to brush up on some of the more advanced considerations in using this basic BPMN symbol — you will find this recording very instructive. Concepts are demonstrated in ActiveVOS 7’s new BPMN 2.0 modeler.

Attached to this post are two versions of the webinar: an iPod-formatted .m4v file our podcast subscribers will automatically receive and an H.264-encoded .avi file (which is much larger at about 113MB).

We welcome your input and suggestions for CTO Tuesdays. Contact us via email at editor at activevos dot com. Today, the best way to be notified of upcoming CTO Tuesdays is to be on our mailing list. And, the best way to get onto our mailing list is to download a trial of ActiveVOS. You can also register for upcoming CTO Tuesdays by clicking on the link in the right hand column of any interior page on www.activevos.com.

We are working hard on making registering for CTO Tuesdays easier. But because of the demand for education on topics like BPMN 2.0, we started the webinar series without waiting to dot all the “i’s” and cross all our “t’s.”

Update: You can now register for CTO Tuesdays by clicking the link in the right-hand column of any page on www.activevos.com except the home page. So, just navigate into the site a little and you’ll get a little reward: easy access to registration for CTO Tuesdays.

Updated update: You can now always register for the upcoming CTO Tuesdays at http://www.activevos.com/ctot.

We hope you enjoy this recording and that you will join us as your schedule permits for the live CTO Tuesdays every Tuesday at noon ET, 9am PT, 16:00 GMT (17:00 GMT after the end of US daylight savings time in November, 2009).

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

CTO Tuesdays #1: The BPMN diamond

I’m pleased that my recent disagreement with JP Morgenthal was noticed by Joe McKendrick, on his Service Oriented blog, and by Loraine Lawson at ITBusinessEdge. Now, having set the record straight, we can step back a little and start a more general discussion about SCA and why it’s a powerful new approach for developing applications. Loraine made a few comments in particular that got me thinking more about the value of SCA to a chief architect who is “prioritizing and rationalizing applications from an enterprise perspective.”

Once this architect has prioritized the needs of IT for the enterprise, it is critical that the architect’s development team has the right “tools” to update or create the applications that will meet those enterprise priorities. The development team also wants to improve its ability to maintain the application in the long run. I put the word “tools” in quotes in the previous sentence to emphasize the fact that I am using the word in its most general form. Your programming language is a tool. The design patterns you follow are tools. And, of course, the middleware infrastructure you use is a tool. J.P. is just wrong to assert that SCA will lock you into dependency on a vendor. There is no reason that middleware has to lock you in to a vendor any more than using a programming language locks you into a vendor, but that is only true if the middleware uses…

standards (and the right standards at that). If SCA were just some vendor’s tool that was promising great things, J.P. and everyone else would be right to be skeptical. But it isn’t proprietary, it’s a standard.

There are a few important reasons why this is important. It is always difficult to hire people who are skilled in a vendor’s proprietary technology and any application that depends on the technology is always at risk, since the vendor may choose to “improve” the technology in a direction that is retrograde for you. Or, the vendor could possibly abandon it altogether.

A good middleware standard is like a high-level language. It raises the level of abstraction that developers work in, so they can think about the actual problem being solved instead of fiddling with bits – or SOAP headers.  There are three recent standards that do exactly this: BPEL, BPMN and SCA.  BPEL is a language that is specifically designed around creating and using services, so it is also inherently middleware. Then there is BPMN, which standardizes the notation — the look of the business process on the design canvas — so that developers and non-developers alike can share an understanding of what is going on. And finally there is SCA, which allows developers to create, wire, package and deploy services without having to sweat the details of the numerous WS-* standards for every service that is created or used.  It, like high-level languages, raises the level of abstraction without significantly constraining what a developer can accomplish.

Forcing a development team to avoid recent advances in middleware today would be like having a manager in the 1970’s forcing their developers to program in assembler due to a mistrust of languages like FORTRAN. Productivity would suffer.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

If SCA is a tool, it is a power tool

There are three files attached to this post. First, an iPod-formatted .m4v file that’s approximately 140MB in size. Subscribers to the VOSibilities podcast feed (search on “vosibilities” in the iTunes Store) will automatically receive this file. Also available are a DivX-encoded .avi file (about 375MB) and the slides that were presented as a PDF.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #36: The Naval Research Laboratory on SOA-based process orchestration

Yesterday (July 22), Red Hat announced its JBoss BPEL server, available via an open-source project called Riftsaw.

As you can imagine, the whole team at Active Endpoints was interested in the announcement because Active Endpoints is a leader in the BPEL standards effort, ActiveVOS processes are executed as BPEL  (but ActiveVOS  is most emphatically not “just a BPEL engine”) and the new project will create more interest in next-generation application development.

I wish you could be party to the intense discussions the announcement of the JBoss BPEL server kicked off inside our company. One the one hand, we note with pleasure the validation of BPEL that a new JBoss BPEL server signals to developers. On the other hand, we worry that what we saw (or should I say, ” what we riftsaw” ) yesterday will be “good enough” for many developers who are new to services-based development and who don’t realize how rich services-based BPM systems have become. In short, we welcome the JBoss BPEL server to the party, but we want to make sure developers understand there’s no reason to set the clock back with systems that deliver elementary tooling, manual command-line deployment, no operational control and hand-editing of XML files. We want to draw a bright line between an integrated, BPEL-based BPMS that development teams love to use and individual technologies that must be pieced together using Notepad++, soapUI, the command line and ant scripts.

Bear with me a minute as we step back and think about where BPEL came from, where it is today and why the JBoss BPEL server is a step back from several years of advancement in the BPM and BPEL world.

First, why even have something like BPEL? Industry standards aren’t just “whipped up” on a collective industry whim, because getting a standard specified and approved is an arduous process. (Just ask Michael Rowley, who labors with other vendors to keep the BPEL and BPEL4People standards moving forward.) To overcome that inertia and make competitors agree, there must be both a pressing need and a general consensus that something has to be done. The shift to services-based development was the pressing need, and Active Endpoints, Oracle, IBM, SAP and others helped create the general consensus. The result? BPEL: a language designed specifically to do what Java, C++ and C# natively can’t: orchestrate services.

But a standard is just that: a specification. To make the standard into a product that developers will love using is a big job, and it’s how vendors approach that product development effort that differentiates their products. The differences between the “raw” implementation of a standard and a fully-integrated product is what makes competitive vendors willing to agree to a standard in the first place. They hope to benefit by delivering complete solutions based on the standard…they differentiate by combining the standard with other features and capabilities to develop whole products that developers will enjoy using because those products are easy, integrated, complete and fun.

Now I believe (and I may upset some folks with this assertion) that the BPEL effort, noble as it is to introduce a purpose-built language for service orchestration, originally shot itself in the foot because it didn’t specify a way to visually design BPEL and because, until BPEL4People, there was no way to integrate human and automated tasks in processes in  a standardized way. Both issues have been corrected, but BPEL has had trouble shaking the reputation of being hard to develop and deploy.

We think the JBoss BPEL server is likely to resurrect that misperception because it lacks advanced tooling and it has not implemented BPEL4People. We fear that large numbers of developers will experiment with the JBoss BPEL server, decide that it’s either too complex, or perversely, “acceptable” because they like elemental tooling and never experience what a modern BPMS with a superior development and deployment environment can deliver.

I want to give you just one example contrasting a “raw” BPEL server and a complete development environment based on BPEL. BPEL has core and very confusing concepts called partner link types and partner links. These are powerful concepts but not obvious, especially to developers new to services. If you are a services guru, you can understand it easily. If you are like many developers, the explanation is likely to give you a headache and make you swear off BPEL. But there’s no reason to expose the concept of BPEL partner links to the vast majority of process developers.

So, in ActiveVOS 6, we introduced the concept of the Participant’s View, pictured here:

In ActiveVOS, we know BPEL so you don’t have to. Once you’ve imported the WSDLs, we can automatically set up the partner links and partner link types (e.g., upstream and downstream “participants”) in a handy graphical view. You simply drag them onto the canvas, and voila!, instant creation of the correct partner links and partner link types. Contrast ActiveVOS with the recorded July 22 demo of the JBoss BPEL server, which demonstrates editing partner links with Notepad++.

We think we know which kind of development system developers prefer. (And by the way, if you really have to or want to edit the BPEL partner link types in ActiveVOS, be our guest. What we produce automatically and graphically is 100% pure BPEL…just the way you like it.)

This is just one example of the difference between a fully-developed, mature, standards-based BPMS the entire development team can use and “raw” technology in the form of an open source  project. We urge developers to look beyond the headlines of “standards” and “projects” to complete products that are rigorously based on standards but which also make development using those standards simple and quick.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Active Endpoints considers the JBoss BPEL Riftsaw project

Keith Swenson has posted this interesting list of questions to ask a BPM vendor.  I liked his emphasis on standards, since it is so important that the hard work that goes into creating business processes not be trapped in proprietary technology.  However, I think he concentrated on the wrong standard — XPDL.  If you really care about safeguarding your investment in your processes, the standard that you should care the most about is BPEL4People.

Don’t get me wrong, XPDL has its place.  ActiveVOS can both import and export XPDL version 2.1 (the latest version).   But XPDL is not a technology that will allow you to take an business process that is executable on one vendor’s BPM engine and move it to another vendor’s engine.  It just won’t work.  If you are lucky, the resulting business process diagram will look recognizable because the “abstract model” (as XPDL calls it) will import successfully.  But don’t get your hopes up about saving all the work that you did on the executable details.

The problem is not that XPDL has no place to put those executable details — it does.  It just doesn’t put enough constraints on what should go there.  There are just too many different things you can do, so no two tools do the same things.   Also, the bar for being able to say that you support XPDL 2.1 is just too low.  If a tool exports something that conforms to the XML Schema (possibly with liberal use of extensions) and import doesn’t barf on any Schema-valid input, then the tool conforms.  But don’t look for guarantees that you will see, much less be able to execute, anything reasonable.

By contrast, users of ActiveVOS have had great success in using BPEL-based business processes that were created by either IBM, Oracle or TIBCO tooling.  They have also found that the BPEL generated by ActiveVOS can be used by the tools of those other vendors.  That is real investment protection.

I do like Keith’s idea of having a list of questions for BPM vendors to help in the evaluation process.  I think the best way to organize such an evaluation is around four key areas.

Are the key BPM standards supported?

• Does the product generate executable WS-BPEL 2.0 processes?
• Can you model processes using BPMN?
• Does the product use the BPEL4People for activities that are handled by people?
• Are worklists and tasks exposed through the WS-HumanTask standard?
• Does it support the important enterprise web-service standards, such as WS-Security and WS-ReliableMessaging?
• How about non-SOAP access to services, such as JMS, REST or plain Java?
• Does the product import and export XPDL?

Does the development environment make the process developer highly productive, especially for processes that are larger than mere toys?  For some important examples, how easy is it to:

• Incorporate existing web services into a process?
• Detect changes to web service definitions and update the process accordingly?
• Define services provided by the process (including defining XML Schemas and WSDL)?
• Define new human tasks using existing data definitions (XSDs)?
• Prepare the input data for human tasks or services?
• Support services that “call back” into a running process, and specify the appropriate data to use for correlation?
• Find all uses of a variable within a large process?

An executable process is deployed software.  What support is available for ensuring and maintaining its quality?

• Is there test case generation?
• Is there test suite support?
• Is there remote debugging?
• Is there Metadata for controlling the difference between staging and deployment?
• Can you new versions without effecting existing process instances?
• Can you deploy new versions that do change existing process instances?

What can be done to a running instance?  Can you:

• See where it has been (with anotations on the process diagram)?
• View current and historical data?
• Change data?
• Skip activities?
• Single step through activities?
• Rewind execution, optionally reverting all process data to what it was?

What kind of runtime console support is there?

• Can you get reports with either operational or business information?
• Can the end user create any kind of new report and incorporate it into the runtime console?
• How powerful is the query capability to find a process instance you care about?

All of these characteristics of a BPMS will eventually be important to anyone that is creating the kind of critical business processes that will really transform a business.  Knowing the answers to these questions can help you to avoid making the wrong choice.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Thinking about BPM? What you should REALLY ask your BPMS vendor

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Fastenal Corp. uses ActiveVOS to implement SOA

It’s my great pleasure to post a conversation with my colleagues here at Active Endpoints, Michael Rowley, director of technology and strategy and Luc Clément, senior director of products in which they discuss the themes and features in our new release, ActiveVOS 6.1.

Michael and Luc detail how ActiveVOS 6.1 has masked the complexity of BPEL, allowing developers to work more naturally to create advanced SOA-based BPM applications. Luc and Michael also discuss the capabilities of a new feature in ActiveVOS 6.1 called “process rewind” which permits new levels of control over running processes.

And, Michael and Luc give a sneak peak at what’s next for ActiveVOS 6.1, discussing how a BPMN-style canvas can improve collaboration in the development of BPM applications. You may also find the the What’s New in ActiveVOS 6.1 document we posted earlier this week on the blog informative as well.

Whether you are a current user of ActiveVOS or you are evaluating BPM systems, I hope you will find this podcast an informative update. As I am posting this podcast before ActiveVOS 6.1 is officially released, I do not yet have direct links to the new content on our website. But if you visit our home page starting March 10, 2009, you will be able to quickly find updated samples, documentation, demonstrations and, of course, a free trial of ActiveVOS 6.1.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #28: ActiveVOS 6.1

Last week, Active Endpoints’ Michael Rowley participated in the quarterly face-to-face meeting of the OASIS Technical Committee working on the BPEL4People and WS-Human Task specifications. In this very engaging podcast, Rowley describes the inner workings of TC’s (something you usually don’t hear much about), describes the work the TC has recently accomplished and articulates the grand vision for business process management (BPM) and workflow that the committee has been working  on.

If you’ve been wondering about the state of standards-based BPM and workflow systems or, frankly, if you think BPEL and BPEL4People have dropped out of sight, I strongly encourage you to listen to this podcast. You’ll hear how some the of most important thought-leaders in the IT world, including IBM, SAP, Oracle, Microsoft, TIBCO and, of course, Active Endpoints, are working towards a BPM world in which standardized systems make it possible to implement business processes in ways we haven’t been able to reach as yet.

We hope you enjoy this look at BPM today and in the future.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

VOSibilities podcast #27 An Update on the BPEL4People & WS-Human Task Standards

Details are in the press release attached below as well as in Luc’s previous pre-holiday post about the demo. Included in the press release are instructions on how you can download a customized version of the ActiveVOS demo to experiment with the application on your own machine.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Active Endpoints Announces New Learning Tool for Java Developers

Do you know what this logo is?  It’s the new Pepsi logo. What does Pepsi have to do with SOA?

To start off 2009 with a bang, Anne Thomas Manes has written a blog post declaring the term “SOA” dead. Like her previous post on the “failures” of SOA, this post is certain to get a lot of attention.

But a careful reading shows Ms. Manes only wants to kill the term SOA, not, of course, the technological movement which it defines and which she asserts is still critically important to improving application development.

I’ve heard this desire to make SOA a dirty word a lot lately, even inside Active Endpoints. And, as a marketing person, I recognize it for what it is: message fatigue from the avant-garde.

Like the marketing guys at Pepsi, the cognoscenti are tired of talking about SOA. They need something new, something exciting, something…effervescent to talk about. It’s not that the term SOA is dead…it’s simply boring, pedestrian.

In a startup company, the biggest marketing danger is thinking that the “world” knows what you’re saying. When you are small, the noise level around you is so high and the competition is so stiff that your message can’t ever get out unless you stick with it. But creative people don’t like repetition. They thrive on the new. So many technology startups fools themselves into thinking that “everyone knows” what they do. And they move on…into obscurity.

Like a startup company, the thought-leaders that truly believe in SOA as a way of doing things are about to abandon the term at the exact moment it becomes a mainstream, accepted way of doing things.Their need for the new — at least new terminology — threatens consolidation of the very movement they championed. (And it risks generating cynicism among thought-leaders who get frustrated by the incomplete adoption of the “latest thing.” It’s a self-fulfilling cycle: how can something be completely adopted if pundits abandon technology before the movement is consolidated?)

Incomplete adoption is possible because the companies contemplating SOA now are the middle and late adopters. They aren’t the early people who conflated an ESB with SOA. Adopters today are not bleeding-edge customers. They let someone else suffer those pangs.

ActiveVOS’s success in 2008 was, in part, because customers aren’t interested in technological debates. Instead, they wanted modern, affordable, all-in-one technology to achieve their business objectives. They don’t “debate” SOA. They simply implement it.

And in a surprising number of cases in 2008, ActiveVOS displaced or was installed alongside the SOA offerings from IBM and Oracle. Why? Because the never-ending need for “newness” in those products…uh, excuse me…”stacks”…makes them indigestible for customers looking to actually achieve something with their application portfolios. Like the pundits, many big competitors of ours keep “revising the logo,” confusing their customers and delaying consolidation of the SOA movement into the mainstream.

So, would a new term help SOA? I don’t think so…it’s like the Pepsi logo. It makes a lot of leading-edge people feel great. (“Wow, isn’t that beauuuutiful?”)  But it unnecessarily confuses large numbers of people who thought they understood what was going on and who had just begun to dip their toes into the SOA water. 

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Giving SOA terminology a nip/tuck

So, what technology do you want to use if you already have several services and you want to quickly and easily create a few new services, partly by building off of existing services and partly from scratch? Installing an ESB would be a mistake. If you already have one, that’s great, but a small project isn’t the right place to kick off the move to an enterprise-wide bus.

What about development technologies? Should you create your new services using JAX-WS and JAXB deployed using JavaEE deployment machinery? No. Why pay all of the complexity costs related to mapping XML and web services into Java in this case? The new business logic would be so dwarfed by all of the generated code and configuration files that it would be lost in the muck. Just the JAXB generated classes alone will usually be counted in dozens for any real XML document.

Why not use an orchestration language that is already designed to use XML and WSDL as the native type system for the variables and method signatures? In other words why not use BPEL? If the new service can’t be fully automated you can use BPEL4People to handle the involvement of people in the service.

Of course using the right language is not sufficient. For the project to be small and simple, it should also be easy to test and deploy. It should make it easy to manage running services. And just because you want high developer productivity doesn’t mean you can give up the need to develop truly high performance services. And if the project is really going to generate a quick ROI and operate “under the radar,” it has to be budget-friendly.

ActiveVOS anyone?

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Incremental SOA

As Paul puts it “Do yourself a favor and check out this great visual orchestration system.” If you have not yet considered ActiveVOS to orchestrate your SOA based applications, make it one of your New Year’s resolutions.

One week left to enter our Bring SOA Home for the Holidays contest! Download ActiveVOS and submit your good ideas. You could win a very, very cool Lenovo netbook.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Product review: “ActiveVOS 6.0 is a game changer”

Please, not yet another loan application demo!  Far from that. We wanted to do something totally different that visitors to the site could grok quickly by first viewing a Camtasia presentation; that could then be experienced online through a hosted version of the demo; and for the tinkerers at heart, that could be taken apart to learn how it was all built using ActiveVOS.

What better than a “Classic Car Restoration” scenario to demonstrate how, with ActiveVOS, you can model, implement, test and deploy a service orchestration which incorporates human task; Java and web service orchestration, task and process management; activity monitoring and reporting; complex event processing (CEP); and a whole lot more.

We set out to automate the estimate process for Vintage Old Stock, a classic car restoration shop. Play an eight-minute demo to get the feel of the estimate process. Then look under the hood and see how we used ActiveVOS Designer to model and document the estimate process; how we designed and implemented the process; how we simulated and tested it; and how we deployed the process. And don’t stop there! See how ActiveVOS leverages CEP and how, through the ActiveVOS Console , you have complete visibility into your processes and tasks.

I don’t like being just a passenger. If you’re like me, you’ll want to test drive the demo for yourself and take it for a spin. Before you head out, read the Owner’s Manual. Take the demo for a lap by requesting an estimate. Act as the estimator and generate an estimate. Look under the hood to see the process in action. User info can be found in the Owner’s Manual.

We’ve also made available to tinkerers the ActiveVOS Orchestration Project and a fully configured demo environment. For those already using ActiveVOS Designer, download the Vintage Old Stock Orchestration Project files here. If you want to work with the pre-configured demo environment locally, download it here. Enjoy the drive!

Cheers and Happy Holidays,
Luc

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Not your dad’s loan application demo

‘Twas the night before New Year’s and all through the house
Not a process was broken, not even a browse.

The ActiveVOS users sat by their computers with anticipation
In hopes that the “Bring SOA Home for the Holidays” judges would like their contest submission.

When out in the judges’ office there arose such a clatter
Every Active Endpoints employee wondered what was the matter.

And what to their wondering eyes should appear
But the judges with the list of three lucky winners of some really cool Lenovo gear!

—————————————————————————————————–

I hope you enjoyed reading this little parody of “The Night Before Christmas” as much as I enjoyed writing it. Seriously, we have some good news. Because of the great response to our contest “Bring SOA Home for the Holidays,” we have extended the submission deadline to New Year’s Eve – December 31, 11:59pm.

It’s easy and fun! Download a supported 30-day trial of ActiveVOS, the world’s leading visual orchestration system, and tell us how you would use it in your SOA, BPM, BPEL or BPMN projects. Make this holiday season a winner for you and your company. Try ActiveVOS…win a Lenovo netbook! Visit www.soaholiday.com for details and contest rules.

Happy Holidays!

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

“Bring SOA Home for the Holidays” contest extended to 12/31

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

Active Endpoints Joins Web Services Test Forum

Bruce writes:

Because BPEL is more “technical” than BPMN, it is favored by developers who find nothing more annoying than business-types wanting to “collaborate” on implementation.

I disagree that developers don’t want to collaborate with their business-minded colleagues. This is the stereotype, of course, but in my experience it really hasn’t been true. The real question is whether or not business analysts and developers need to work on same model. Neither the developer nor the business analyst really wants this since they have different needs.

Bruce talks about one of these differences: business people using unstructured graph-oriented control flow vs. the structured control flow favored by developers. It’s clear why these different users would need different ways to diagram control flow.

So these difference needs dictate different representations. With the unstructured control flow, it is pretty easy to get into trouble (where “trouble” is defined as something that’s unclear at execution time) . For example, some modelers prefer to use conditional sequence flow (small diamonds on outbound transitions) rather than XOR gateways. Kieth Swenson has a good example and a couple blog posts (here and here) that discuss this. Unfortunately, with the current semantics, it is easy to get into trouble.

Think about this process model:

The business analysts might not think very hard about whether the thing could be red and blue, so at runtime it turns out that both paths could be taken and then you would end up with two simultaneous executions of “D”. That is legal, but probably not what was desired and difficult to debug.

It is the transition from unstructured to structured — as the model is handed from the business analyst to the developer — that causes these issues to surface. The developer will still use something that uses the BPMN notation, but with limitations that basically make it look structured. So yes, round trip is hurt. The developer doesn’t hand back to the modeler the same picture. It has been unwound a bit. This is a less comfortable style for the business analyst, but it’s certainly still understandable.

I don’t think Bruce disagrees with most of this thinking, because what he concludes is exactly in line with my thinking:

We need to recognize that standards for process modeling and process execution have different purposes and benefits. They should be linked, but with proper attention to those differences.

Post from: VOSibilities, the Active Endpoints BPMS blog

Learn more about ActiveVOS

BPMN? BPEL? Both? What’s right for a process execution standard?