VOSibilities

I am very pleased to be able to post another fascinating talk from our own Kim Pease. This time, Kim makes clear a topic that we have repeatedly heard is on the minds of developers and managers alike: application security in a messaging environment. Kim pays special attention to all the WS-Security options and explains, among other things, why some authentication and encryption options are recommended in the WS-Security standards.

Normal application security is, ’scuse the ugly metaphor, a hairy ball of wax. But when you add in the additional requirements necessary to deal with a messaging-driven, services-based application environment, the complexity can overwhelm you. WS-I…SAML…WS-I…it can all become mush. Or, as least it seems this way until Kim clearly describes each part of the standard and then delivers a demonstration of the most important OASIS specifications in a demo.

Due to the depth of this topic, this podcast episode runs about 18 minutes. There are two versions posted here. The .avi format is encoded at 1024×768 and uses a standard DivX codec. The .m4v is formatted for the iPod at 640×480. The .m4v will play on the blog at half size (320×480), though it plays at full size on iTunes and on the iPod.

Based on the very good response to Kim’s last talk, I expect many of you will find it well worth the bandwidth to download either or both versions for reference at your leisure.

 

 VOSibilities podcast #11: Kim Pease on using WS-Security in services-based applications [19:48m]: Play Now | Play in Popup | Download (331)
 VOSibilities podcast #11: Kim Pease on using WS-Security in services-based applications [19:48m]: Download (66)

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.

We are pleased to present a recording of a joint webinar we presented on June 12, 2008 with XAware entitled How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications.

Despite the imposing title, I think you will find the content — especially the lively Q&A at the end of the webinar — very interesting.

 

 VOSibilities podcast #10: Webinar replay - How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications [80:19m]: Play Now | Play in Popup | Download (491)
 VOSibilities podcast #10: Webinar replay - How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications [80:19m]: Download (143)

We are pleased to post a recording of a webinar we presented this week. While the title of the webinar might make you think that this is only of interest to systems integrators, I think everyone will be interested in at least two sections of this podcast: the demo and the panel Q&A. The demo by our vp of marketing, Eric Egertson, begins at about 8:00 and the Q&A, with Eric, our systems engineer Victor Chan and me, begins at about 33:00 into the recording.

Many will find the entire webinar interesting as it contains an excellent overview of ActiveVOS and how it can allow users to create services-based applications, including BPM applications, all 100% based on open standards like BPEL.

We hope you enjoy this webinar and look forward to your feedback.

 

 VOSibilities podcast #9: Webinar replay - An Introduction to ActiveVOS for Systems Integrators [49:12m]: Play Now | Play in Popup | Download (387)
 VOSibilities podcast #9: Webinar replay - An Introduction to ActiveVOS for Systems Integrators [49:12m]: Download (60)

Tomorrow and Wednesday, June 4 and 5, we are holding a webinar for systems integrators, consultants and custom application developers. We’ve had quite a lot of interest from SIs since we introduced ActiveVOS in early March, and this is the first time we have prepared content specifically to show SIs how they can use ActiveVOS in their custom application development efforts, accelerate their practices and increase client satisfaction.

Attendees will receive a special offer on ActiveVOS training.

Please register via this page on our website. We hope to see you at one of the webinars.

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.

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.