VOSibilities

I am very pleased to be able to post the first public screenshot of the Designer in our upcoming ActiveVOS 6.0 product. Click on the thumbnail above to see the image full size.

Those of you who knew us for ActiveBPEL, the world’s leading Business Process Execution Language (BPEL) engine, will be delighted to discover that BPEL remains at the core of ActiveVOS 6.0. All of our BPEL execution engine’s virtues — a superior visual design environment, rigorous adherence to the BPEL 2.0 specification, process versioning, the world’s first implementation of BPEL4People, remote testing and debugging, dynamic switching of endpoints on failure, clustering and failover — remain as you’ve known them. And there are some truly magical new enhancements, like support for POJO’s that turns old Java applications into web services with a few clicks of a mouse. Clearly, on the BPEL engine feature list, what few competitive lights there were in the rear view mirror grow far dimmer in ActiveVOS 6.0. (Message to Oracle BPEL Process Manager users: it’s about time to get to a real implementation of BPEL 2.0, don’t you think?)

But ActiveVOS is no longer just a BPEL engine. We are, truly, a VOS or visual orchestration system. BPEL is, in part, how we accomplish services-based applications. But it’s no longer what ActiveVOS is. Consider this partial list of new capabilities that will be included in ActiveVOS 6.0 and you’ll see why nothing else — not “open source” arrivistes like Inalio or the stack oligarchy of SAP, IBM and Oracle can compete.

• ActiveVOS 6.0 implements a spectacular Business Process Modeling Notation (BPMN) capability. Now, business analysts can design processes and transform them into executable BPEL at the click of a mouse. Wait until you see it. It’s just astonishing.
• ActiveVOS 6.0 contains a complete complex event processing engine (CEP). One of the things that our BPEL engine has always done is emit the events needed to produce CEP applications. But now, for the first time, these two capabilities are combined in a single product. That means developers never have to integrate things themselves…they simply take advantage of it. CEP in ActiveVOS 6.0 is specified at process deployment time, eliminating the need to code CEP into the process itself and making it easy to add CEP to deployed processes.
• Killer new reporting, BAM and BI capabilities. I don’t have screenshots from development for these yet, but these will not only win the eye-candy wars, [update: after they saw this post, guess what? I received a great screenshot of our new console] they’ll actually make it a snap for businesses to easily understand the overall state of the enterprise.

With these and other new features, we believe that the age of the visual orchestration system has begun. Now, when developers are considering how to do services-based applications, the choice couldn’t be more clear. You can do what the stack oligarchy wants: buy a bunch of indigestible piece parts and engineer the equivalent of a VOS in your shop before you can even hope to begin writing applications. Or, you can use the all-in-one, standards-based capabilities of ActiveVOS 6.0 and get done better and faster.

ActiveVOS 6.0 will be generally available in a few weeks.

We are very pleased to present a replay of a webinar that we presented jointly with the JBoss division of Red Hat entitled How to Achieve Your SOA Vision in the Real World.

Presenting along with me are Pierre Fricke of JBoss and Mike Moniz of Active Endpoints. The webinar details our companies’ joint vision and technology for how developers, managers, enterprise architects and business analysts can move beyond the debates, the complexity and the high costs that have torpedoed implementation of services-based applications for far too long.

And, Active Endpoints is very proud to show publicly for the first time the upcoming ActiveVOS 6.0 (slated to to generally available in August, 2008) which completely resets the standard for what an integrated, all-in-one development and deployment system can achieve. Be sure to check out Mike’s amazing demo. And I also recommend you stick around for the lively panel Q&A at the end of the webinar.

You may have also noticed that when we have a video podcast, I try to post both a higher resolution .avi and an iPod-formatted .m4v. The .avi is approximately 150MB; the .m4v is approximately 80MB.

There are three ways to watch the webinar replay. In ascending order of resolution they are: playing the .m4v file from the website, which results in a 320×240 image. If you download the .m4v file, it will play in iTunes or QuickTime at 640×480. Finally, if you download the .avi, the resolution is 775×582. The .avi file is DivX encoded, so most everyone should be able to view it.

As always, we’d love to know what you think of the webinar. Please email me comments at editor@activevos.com or post a comment here.

 

 VOSibilities podcast #14: Webinar replay - Real World SOA [64:34m]: Play Now | Play in Popup | Download (715)
 VOSibilities podcast #14: Webinar replay - Real World SOA [64:34m]: Download (252)

Yeah, baby! Ain’t nuthin’ like a good blog war-o-words. And a juicy one has just broken out between two influential voices: Nick Malik and Bruce Silver. And I suspect we haven’t seen the last of it. (At least I hope we haven’t. July is a slow month; we could use some American Gladiators-style trash talkin’ right about now.)

Apparently, Nick found the top dead center of the button you shouldn’t push in Bruce’s mind: he says BPM is never going to live up to expectations that non-developers will create applications.

In reply, Bruce — slappin’ Nick right upside the head – replies that Nick has to “prove” his assertion by showing that someone — anyone — in the “BPM community” has made a claim that modeling leads directly to completed applications.

While I hope the histrionics continue, this is really nothing more than two purists trying to keep their rivers from converging.  (I gotta admit that I find these near-screaming matches to be more educational than so-called “polite debate” for the very simple reason that they strip out the fluff in favor of direct frontal attacks everyone can understand.)

We all know from long, bitter experience that the “third rail” in the Microsoft world (touch it and die) is developers. MSFT will do what it takes to keep developers tied to the Windows API. Anything that could loosen that death-grip is a danger, and that includes end users working in standards-based tools that could care less about the underlying OS.

And from what I’ve read about the “BPM community” there’s a fair bit of wishful thinking there, too. Bruce is probably correct that no responsible entity has claimed what he believes Nick is claiming. Yet, you don’t have to say the “E” (execution) word outright to lead people to the conclusion that your BPMS does it directly from pretty pictures. Go ahead, spend five minutes on Lombardi’s site and tell me you don’t see it there.

What do we care? Well, let me be the first to pre-announce our upcoming ActiveVOS release, scheduled for mid-August, in which we actually converge the rivers. We will have the most complete BPMN modeling capabilities and, of course, we have the world’s best and most complete BPEL deployment, execution and management system.

ActiveVOS will make it possible for business users to come very, very close to execution via BPMN. And we believe that developers will take that non-executable model and “finish” it in a 100%-standards-based environment that frees them and their businesses from .NetJail.

Forgive me the nested platitude, but the issue boils down to that old saw that says, “Get the right tool for the job.” Developers need modern, standards-based languages that execute on the metal; business analysts need modern, standards-based ways to describe what systems have to accomplish. Being doctrinaire about which is the “correct” way to serve business and IT is beside the point.

So, while it’s fun to see the purists bloody each other, we intend to deliver an implementable, cost-effective and complete way to achieve what neither side really seems to want. And that, dear readers, is what a visual orchestration system is all about.

I checked Wikipedia to see what a “sapphire” really is because I wondered if SAP’s SAPPHIRE trade show was using it as a pun on its company name and the “clarity” of a sapphire. Turns out it might be, since Wikipedia defines it as a mineral that’s not red. Unfortunately, the recent SAPPHIRE I attended has me seeing red.

Check out this slide from their announcement of their “BPM” products:

Once past the initial hype, what SAP claims to be bringing to market seems to be more hope than code. What bothered me the most are their claims of an “executable” business process model and that “immediate execution” speeds time to value. Hold on there…even if you did execute the model directly, is that necessarily a good thing?

Surely SAP isn’t suggesting that all of a sudden, you’re going to stop following best practices and the SDLC that you have developed over the years: separation of concern from the model, its implementation, testing, and methodical deployment across development, sit/cit and pre-production environments before you put it in production.

Beyond the question of what the right thing to do is in terms of development process, what exactly did SAP announce? A beta of BPM/BRM that will be released this June with the actual product shipping — maybe — in March 2009. (We’re hearing it’s $4500 per seat. Get that special checkbook you use for SAP products ready…you know the one with eight zeros pre-printed in the amount field.)

When it ships next March, there will be no announced integration with BPEL and no means of import/export of the BPMN from the tool that SAP customers have largely adopted, ARIS.

We talked with ARIS customers who aren’t happy about the lack of integration. One we spoke with uses ARIS heavily to model processes and hand them over to development. Instead, SAP chose to generate executable code directly bypassing the developer. If you believe SAP, you’ve now empowered your business analysts with the means to build executable models.

The good news is that you now have 300 new developers; the bad news is that you have 300 new developers. Is there an IT group on the planet that would deploy such a model in production directly? Please let us know if you do…we want to see how you’ve managed to skip validation, testing, performance trials and all the rest of the standard things a real application has to have.

SAP indicated that interoperability with ARIS is not possible because of a lack of a standard for BPMN serialization. While that’s true — BPMN is a notation (i.e. not an executable process definition like BPEL) — not having import/export with ARIS only suggests SAP is more interested in account control than real BPM. If it was motivated in ensuring no lock-in, SAP would have worked more closely with ARIS in developing an import/export mechanism, maybe via XPDL or XMI. But they haven’t, and while we’re only speculating, it seems clear why they haven’t. So much for the claims by ARIS at SAPPHIRE that ARIS is the “Business Processing Arm of SAP”.

See why does this have us seeing red? We’re steaming for the SAP customers who actually buy this line…who’ll be waiting a year (at best) for capabilities they need today…who’ll end up even more locked-in than ever to proprietary, closed, non-standards-compliant applications.