VOSibilities

This week’s topic on CTO Tuesdays was an introduction to the new WS-HumanTask standard for workflow. In this informative session, Michael Rowley describes the importance of the new standard for workflow, how it separates tasks from processing and how WS-HumanTask enables human activities to be seen as services in a process application.

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.

 CTO Tuesdays #2: Introduction to WS-HumanTask [49:03m]: Download (8493)
 CTO Tuesdays #2: Introduction to WS-HumanTask [48:56m]: Download (1078)
 CTO Tuesdays #2: Introduction to WS-HumanTask: Download (300)

We are very pleased to post the recording of the first episode of our new weekly webinar on BPM technology called CTO Tuesdays.

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

 

 CTOT #1: The BPMN diamond [39:32m]: Play Now | Play in Popup | Download (4596)
 CTOT #1: The BPMN diamond [39:30m]: Download (7398)

As we promised in part 1 of of our discussion on the new features in the ActiveVOS 7 BPMS, we are delighted to post part 2 of a conversation among me (Alex Neihaus), Luc Clément and Michael Rowley. In this second podcast, Michael and Luc cover topics that are of interest to enterprise architects, developers and operations staff. Topics include continuous development (including support for the open-source Hudson project) and new features in the BPMN designer that improve productivity and operational enhancements.

We hope you enjoy this podcast.

 

 VOSibilities podcast #37: ActiveVOS 7.0, part 2 [28:32m]: Play Now | Play in Popup | Download (1569)

ActiveVOS 7.0 is a major new release of the business process management system (BPMS) that development teams love. The document attached to this post gives an overview of new features in the release. The document discusses the new BPMN 2.0-compliant modeler with BPEL execution and no round-trip problems, a new AJAX capable services-based forms designer and ActiveVOS Central. ActiveVOS Central is a complete, out-of-the-box solution for managing work, accessing reports and graphs of system activity and creating processes. In addition, the document describes additional new features of the BPMS that improve productivity and enhance collaboration between an extended development team and end users.

This version is a draft of the What’s New in ActiveVOS 7.0 document. Please check back frequently for updated versions.

 What's New in ActiveVOS 7.0: Download (999)

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.

We are pleased to offer a recording of a webinar presented by Jim Ballas, Ph.D. and Justin Nevitt of the Naval Research Laboratory on the topic of process orchestration for defense systems. Originally presented on July 29, 2009, the webinar also features Rick Rosenburg, CEO, Seros, Inc and me, Alex Neihaus, as moderator and host. Jim and Justin describe the leading-edge work they have done in researching the applicability of web services and orchestration for defense systems. Their learnings are also generally applicable to non-defense users interested in developing the next generation of applications.

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.

 

 VOSibilities podcast #36: The Naval Research Laboratory on SOA-based process orchestration [83:57m]: Play Now | Play in Popup | Download (809)
 VOSibilities podcast #36: The Naval Research Laboratory on SOA-based process orchestration [83:54m]: Download (635)
 VOSibilities podcast #36: The Naval Research Laboratory on SOA-based process orchestration -- slides: Download (384)

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.

We are pleased to post a recording of a webinar originally presented on May 7, 2009 entitled “BPMS for Java Developers.” This webinar, jointly presented by JBoss and Active Endpoints, will introduce Java developers to business process management suites (BPMS) using ActiveVOS and to the JBoss SOA Platform.

There are two files attached to this post. The first is an iPod-formatted .m4v file for our podcast feed subscribers. The second file is a DivX-encoded .avi with slightly larger resolution.

Update, October 21, 2009: If you’d like to learn more about ActiveVOS 7.0 and its ability to implement a SOA-based BPM solution, released in September 2009, please visit What’s New In ActiveVOS 7.

 

 VOSibilities podcast #32: BPMS for Java developers [78:51m]: Play Now | Play in Popup | Download (4229)
 VOSibilities podcast #32: BPMS for Java developers [78:50m]: Download (3838)

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.

Writing in eBizQ’s SOA in Action blog, Joe McKendrick discusses how Fastenal Corp. is using ActiveVOS in production to revamp to its sales order processing system.

Today, Active Endpoints announced that it has published a white paper authored by noted industry analyst David Linthicum which debunks the idea that SOA development of business process management applications is difficult and expensive. The press release describing the new white paper is attached to this post. You can download the white paper itself here or here. 

 A Call-to-Action for SOA Development: Download (518)

In this new white paper, titled Leveraging Process Configuration within the Context of SOA, noted industry analyst, blogger and podcaster David Linthicum tackles perceptions that developing BPM applications in a services-oriented architecture (SOA) environment has to be difficult and expensive.  

 Leveraging Process Configuration within the Context of SOA: Download (656)

Integration developer Adam Swift at Fastenal describes how his team uses ActiveVOS to quickly implement SOA-based applications for vital business processes, including an order management system. Read the article here.

Today, we are very pleased and excited to announce ActiveVOS 6.1. The press release with all the details is attached to this post.

To view selected content about the release, visit our What’s New page on our product website. And, don’t forget to listen to Michael Rowley and Luc Clément discuss the themes and objectives for ActiveVOS 6.1 in this podcast.

 Active Endpoints Announces ActiveVOS 6.1: Download (484)

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.

 

 VOSibilities podcast #28: ActiveVOS 6.1: Play Now | Play in Popup | Download (365)