VOSibilities

Vance McCarthy of Integration Developer News has posted a very interesting podcast with Active Endpoints’ Director of Strategy and Technology, Michael Rowley. Vance discusses with Michael what the concept of a visual orcehstration system is, the standards we have implemented in ActiveVOS 6.0, and how an integrated system accelerates developement of SOA-based applications.

The podcast can be accessed here.

In this podcast, I talk with Luc Clement, our Sr. Director of Product Management for the “inside story” on the development of ActiveVOS 6.0 and the features we think make it so important and unique. You’ll hear Luc and me discuss our thinking behind the new features and improvements we made in our visual orchestration system. We hope you enjoy this podcast.

 

 VOSibilities podcast #16: Luc Clement on ActiveVOS 6.0 [21:52m]: Play Now | Play in Popup | Download (1761)

Today, Active Endpoints announced ActiveVOS 6.0, the world’s most complete and open visual orchestration system. You can read all the details about ActiveVOS 6.0 in the PDF attached to this post. We also encourage you to try ActiveVOS 6.0 with our free, supported 30-day trial at www.activevos.com/trial.

 Active Endpoints Announces ActiveVOS 6.0: Download (827)

…does it matter that it’s not “BPM, BAM, BRE, BRMS or SOA?”

That question popped into my head as I read what Tim Bass has to say on this topic because, as I hope everyone knows, we’ve just released ActiveVOS 6.0 (watch a demo here and get a free trial). ActiveVOS 6.0 is the first product to contain an integrated CEP capability.

For us, this kind of “territorial discussion” goes to the heart of why we did what we did in ActiveVOS 6.0. ActiveVOS 6.0 is something new…what we call a visual orchestration system. We put CEP, BPMS, BPEL and more together in a single product precisely because we believe that unifying disparate technologies is the key to finally creating an explosion of services-based applications. 

In his post, Tim Bass talks about a fraud routing example which he describes as BPM, not CEP. That may be classically correct. But who cares? Why have unnecessary and artificial boundaries among related technologies?

That’s the problem a visual orchestration system is designed to fix: the endless need for specialists. The constant conflict developers find themselves in all the time: “I need to do a services-based app, but I get to put all the pieces together myself.” We believe that when developers can choose from among many well-integrated, category-blurring technologies in a single visual orchestration system they will produce better, higher quality applications faster.

Take cars for example. Engine technology is clearly not the same as transmission technology. People simply want to start the car, and put it in gear and drive away. Likewise, developers don’t necessarily want to know the difference and become expert in the academic distinctions between BPM and CEP; they want to do fraud applications.

The real shocker is that IBM, SAP, Oracle and others ship developers an engine and a transmission separately, expect them to bolt them together themselves and presume that their customers accept it as if that’s the way it’s supposed to be. We don’t assume customers want that kind of suffering, of course, and our increasing traction for ActiveVOS gives us confidence we are moving away from this “my-technology-space-is-purer-without-yours” era.

So, while Tim has a good point that CEP is new, different and important, our belief is that the real innovation today is in finding a way to put all these things together into a compelling whole. 

Active Endpoints announced today that ActiveVOS has been selected to orchestrate the FBI’s Next Generation Identification system as part of a 10-year, US$1 billion contract awarded to Lockheed Martin. You can read all the details in the press release attached to this post.

 ActiveVOS selected to orchestrate FBI’s Next Generation Identification system: Download (941)

In a new podcast, Dennis Byron of ebizQ talks with Active Endpoints CEO Mark Taber about visual orchestration systems in general and ActiveVOS in particular. There’s also an interesting discussion about the importance of standards like BPEL for creating service orchestrations.

Thanks to Dennis and Mark for a very interesting podcast, one that’s well worth your time.

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’re not surprised that our message to Java developers created quite a stir (Sandy’s comments, Alan Zeichick’s post, Dana Blanekhorn’s post, Adrian Bridgewater’s comments and Josh Fruhlinger’s post).

I knew it would, and there was significant soul-searching inside the company about releasing it and sending it to so many developers. I’d be the last to deny we’re promoting ActiveVOS and our company. (That is my job.) But being jingoistic was the last thing we were thinking. I was patterning the idea after something I did in a previous life in which we reported on the incidence of spam, something we were in position to know because we aggregated stats from spam filters. People loved it.

At Active Endpoints, we “know” something about the relative state of adoption of modern app dev technology in the Java community based on our geographic aggregate data that individual Java developers wouldn’t have access to unless we told them. And it’s an interesting data point because it does say something about relative economic advantage that economies with vastly larger GDP — and therefore an increased need to be agile– aren’t demonstrating the same alacrity of adoption that emerging economies are.

Do you think that the open-source SOA companies who claim “millions” of downloads in efforts to promote themselves as viable businesses in North America would have shared this with the community? I doubt it. It took a measure of courage to speak up.

I’d argue we’re being more honest by sharing what we’ve learned in the marketplace than most. And I’d hoped this would signal to the Java community what working with us would be like: we’re dedicated to what we do and we’ll always try to be open and direct. If we’ve scared a couple of people into wanting to move application development forward in their companies, we have arguably done those companies a service, whether or not they use ActiveVOS.

I think you can tell a lot about a company that will share its market knowledge with you and which wants to create constructive discussion about the impact of its technology on the businesses it seeks to serve.

This wasn’t a “buy American” screed. This was, instead, exactly what we called it: a wake-up call to the Java community to look past obstacles and move to the next level of services-based development.

Copied below is the text of an email we sent today to more than 30,000 developers in the US. We are in a unique position to see what the rate of adoption of modern development tools is. And what we’ve seen is so strong a trend, we simply had to go public with what we’ve learned. As always, we welcome any comments or feedback, either here on our blog or via email to editor@activevos.com.

Attention US developers: Active Endpoints has a wake-up call for you

Dear Developer,

We are emailing you because we are concerned about you.  We’ve learned something about the state of middleware technology in the US, its impact on outsourcing and US business competitiveness that we felt strongly we should share with you.

Since early March, we have been offering downloads of our new ActiveVOS visual orchestration system at www.activevos.com. With ActiveVOS, you can automate, control, adapt and manage your services-based applications in ways you never dreamed were possible. And, you do it in a 100%-standards based environment, at breakthrough pricing.

As you might imagine, we watch our download statistics very carefully…sometime hourly. We expected to have downloads from all over the world, but the shocking truth is that a majority of our downloads are coming from outside the US, especially from India and China. A conversation I had with a marketing director at a major open-source ESB provider confirmed that company is seeing fully half of its downloads from India and China.

At first, we couldn’t believe it. And we were surprised, because the US market for app dev products is several orders of magnitude larger than in these developing markets. Then, we started asking ourselves questions like “Why is this so pronounced a trend?” And “what do these developers, business analysts and companies know that US enterprises don’t?”

The answers are clear. US companies have become too caught up in the complexity of their current systems…too content to be dictated to by proprietary middleware vendors…too comfortable with their status quo. Meanwhile, companies without legacy issues – and without the temptation to use those issues as an excuse for stasis – adopt the most effective and modern middleware technologies rapidly.

Is it any wonder, then, that US developers are increasingly frustrated by the slow pace of change, the threat to their jobs, and the technical and political paralysis created by so-called enterprise architectures?

Clearly, we hope you will be the agent for change in your company and download ActiveVOS at www.activevos.com. We hope you will take advantage of our education center to update your skills. We hope you will join the hundreds of developers who have watched the replay of webinar we hosted called “BPEL for Java Developers.” (You can find it on our blog at www.vosibilities.com or in our podcast feed in the iTunes Store; search for “VOSibilities.”)

But mostly, we hope you will carefully consider the fact that the status quo in application development in your company is a very dangerous proposition. No matter how daunting change may seem, it’s better than the alternative: a world in which your company and you personally have been eclipsed by external competitors.

 

Thank you.

 

Alex Neihaus
VP Marketing
Active Endpoints, Inc.
editor@activevos.com

For the last several weeks, there’s been a lot of blog discussion about a Burton Group report on SOA “success” or the apparent lack of it.

An interesting thread of commentary has broken out about the role of CIOs in the success or failure of next-generation application development in business. David Linthicum suggests that CIOs are “…very different animals from company to company.” And Scott Wilson thinks CIOs are in a “delicate position” when it comes to adopting new technologies, balancing needs to progress versus reliable service delivery.

For us, it’s simpler: it’s much more dangerous — bordering on suicidal — to let the fear of change become the rationale for continued stasis. That’s why Burton reports that companies get better results with newly hired CIOs. The new guy has a honeymoon period in which he or she can do the unthinkable. (Marketing execs in software companies are almost as perishable as CIOs. We are often brought in to “fix” the previous guy’s reluctance to change.)

But at the end of the day, a change in leadership doesn’t change the underlying reality that the whole IT organization — from the developer in his cube to the CIO — just isn’t scared enough.

Sure, they’re a little bit scared: “If we have to change, we run a risk.” But it’s the wrong thing they’re afraid of…the wrong fear.

What’s a fossil? Something that stood still long enough to get buried, then wedged into rock to be cooked by pressure over time until it disappears. That’s what developers, analysts, business owners and CIOs are doing: letting the small fear of change become comfortable enough to crowd out the large, more important fear of being fossilized.

And that’s a whole lot scarier. For the business…for individuals.

If this sounds like a wake-up call to developers to lose more sleep at night over why they keep finding reasons not to move to services-based apps, it is. If you think we are saying that enterprise architects should be put on a multi-step program to recovery from PowerPoint architectures, we are. If you think we are suggesting the CIO is more damned if he doesn’t implement today’s visual orchestration systems, you’ve got it.

Many readers will remember a couple of years ago when Justice Antonin Scalia was caught giving “an obscene gesture” to reporters after getting a question he didn’t like.

Today, a lot of SAP and Oracle customers have got to be feeling like they’ve just been given that very gesture by SAP and Oracle, who have both substantially raised prices (here and here).

I guess that with the very big increases in the cost of transporting those very heavy license keys and object code across the Internet, Oracle and SAP felt they were justified in nailing customers’ budgets to the wall yet again.

Here at Active Endpoints, we wonder how long corporate users will permit themselves to be abused like this. And from what we hear from customers on a daily basis, it’s not just the pricing that’s obscene, the products themselves are unusable.

Just this morning, one of our sales guys told me he’d just spoken to a customer that had completely failed with the obese, impenetrable middleware that had been inflicted on him and who had, in desperation, tried ActiveVOS. This customer said he’d succeed with ActiveVOS without any training.

Let us help you get on a two-step program to recovery. First, figure out what it’ll cost you to use ActiveVOS. We publish our prices — which anybody can understand — right on our website. Step two: download ActiveVOS, try it, and see how much you can achieve with a fraction of the effort or pain compared to anything — and I mean anything  — else out there.

Go on…give the gesture back to Oracle, SAP and IBM. It’ll feel great. You’ll be 10 years younger, you’ll feel like a new man or woman…and your enterprise development capabilities will loose two tons of weight.

I expect that by now most everyone has seen the amazing film Wall-E in which a corporation called BNL — for “Big and Large” literally destroys Earth and emasculates humanity of its ability to survive on the planet.

Ryan Bagnulo of Aspect-i and I were talking about enterprises and their surprising tendency to remain with the status quo even when they should know better. And how that’s just fine with the big three — IBM, Oracle and SAP. Suddenly, Ryan said, “That’s kind of what happened in Wall-E!” At that point, I had to record the conversation for our listeners because it was so compelling a comparison.

That lead to this podcast in which Ryan and I discuss how IBM, SAP and Oracle are almost exactly like BNL and are quite content to let enterprises get so porked up on closed, proprietary application development software that they can’t get out of their chairs…to mix metaphors.

We hope you like the podcast, and as always, welcome your responses.

[After I posted this, I came across this broadside of SAP's pricing policies on Cnet. Need any more proof that these companies will suck the life out of enterprise application development buyers?]

 

 VOSibilities podcast #13: How IBM, SAP and Oracle could have been in "Wall-E" [7:49m]: Play Now | Play in Popup | Download (709)

In this podcast episode, I talk with Active Endpoints’ CEO, Mark Taber, about our company’s vision for how we intend to “democratize” complex event processing (CEP) and stream processing so that everyone can benefit from these technologies in their applications.

Mark describes the concepts and then talks about why we believe these technologies should be part of every visual orchestration system — and previews what we’ll be delivering in ActiveVOS in our upcoming release in August, 2008.

As always, we appreciate your support of our podcast, as demonstrated by the large number of people who are downloading and subscribing to this content, and we welcome all feedback. Just email us at editor@vosibilities.com.

 

 VOSibilities podcast # 12: Complex event processing and visual orchestration systems [14:06m]: Play Now | Play in Popup | Download (988)

Last week, David Linthicum’s SOA podcast continued a theme he’s been on lately, a discussion of BPEL’s “fallings” [sic]. I think he meant failings…but in any event, he mentions several times in the podcast that a post he’d previously written on this topic had generated quite a discussion (it did) and feedback from unnamed “BPEL vendors” (that’d be us; I can’t imagine why he didn’t name us. (-: )

Anyway, today after I heard the podcast, I asked Chris Keller, our founder and vp of development and one of the most knowledgeable people on BPEL in the world for his feedback. Chris has not only written the BPEL engine that’s at the core of our visual orchestration system (a VOS is a whole lot more than a BPEL engine), he’s active on the OASIS committees that are furthering the standards.

Chris gave me a lot of food for thought, and being in a playful mood, I thought it might be fun to that feedback into a Q&A. Sorta like a game show, with Mr. Linthicum as the contestant. The prize, for correct answers, is a free ActiveVOS license. Let’s see how Mr. Linthicum does…

Question 1: In the podcast, David says that a major problem with BPEL is that it’s synchronous.
Did David get it right? Click the arrow to find out… Then click here to read the correct answer
Sorry, no. Chris points out that the exact opposite is true. BPEL is asynchronous by definition.

Question 2: David says BPEL has a few programmer-level issues including limitations around request/reply exchanges in a heterogeneous architecture.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Whooppss…wrong again. Chris points out that this isn’t a problem with BPEL as much as it is a problem with vendor support for standards that make request-response asynchronous, like reliable messaging. It’s one prime reasons for the WS-TF standards effort.

Question 3: David says BPEL has issues with failure recovery, exception handling and multi-programming model support.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
So very sorry. Chris points that exception handling is covered by the specifications and that recovery isn’t something that belongs in the specification at all (This is a major differentiator among vendors, and something ActiveVOS does brilliantly — ed.). As for multi-programming model support, we aren’t quite sure what David means, but if he’s talking about multi-tasking, the spec has that covered, too.

Question 4: David says BPEL is not very good at adding a human as part of the process and as SOA moves forward, he’s finding that composites and workflows are more applicable than simple service binding and extending.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Close…but no cigar. Chris points WS-HT and BPEL4People have been added to the specification for precisely this purpose. While David’s criticism was once correct, it’s not applicable today.

We hope that you’ve enjoyed our little episode of The BPEL Game Show. And sorry, David, but you didn’t win our prize. However, anytime you’d like to be brought up-to-date on why BPEL is at the heart of SOA development, we’re happy to update you so you can win the next time.

In a recent post, David Linthicum asks if BPEL is irrelevant. And just as David predicts BPEL providers would do, we fundamentally disagree with the premise. In fact, we don’t see how you could create an SOA without BPEL.

As I read the post it seems he has two sets objections. First, a lack of integration of people into processes and second, a collection of concerns about recovery and exception handling.

ActiveVOS is the first development system that’s based on BPEL 2.0 with no proprietary extensions and to include BPEL4People. As a result, it’s the only 100% standards-based way to achieve long-running orchestrations that include human tasks as first-class participants in the orchestrations.

And if you want recovery and error handling, how’s this: what if you could, in a running orchestration, dynamically switch endpoints when the primary wasn’t available? What if you could change what a running orchestration does based on the current state of the overall business process? IOW, if you could determine that processes that included human tasks had problems with the quality of the work and as a result you could dynamically change what happens to in-flight orchestrations? What if you could, very simply, suspend a failed transaction — one that might have been running for weeks or even months — so that corrective action could be taken? What if you could easily version processes so that in-flight orchestrations could conclude before a new process is implemented?

These are just some of the things that ActiveVOS does that we believe are part and parcel of creating applications in a services-based environment and for which there are no real substitutes. BPMN ain’t gonna do all this (it’s not even executable). AJAX and most Web 2.0 technologies are primarily front-of-screen and do nothing to manage the amazing complexities of long-running orchestrations made up of heterogeneous services.

David, don’t pull that trigger until you talk with us. We’re happy to show you (and anyone else) all this and more, anytime, anywhere. I think you’ll come away with a completely different perception.