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 (735)
 VOSibilities podcast #11: Kim Pease on using WS-Security in services-based applications [19:48m]: Download (109)

Please forgive me. This post strains two metaphors and doesn’t do it very artfully. One, the camera obscura, represents, literally, the “dark room” in which many developers find themselves when working with a non-standards-based SOA development platform. The second, “through a glass darkly” represents the transition, indeed, the revolution, that developers need to accept in order to get SOA applications widely deployed.

Because this metaphor exists only in my head, I’ll spare you the rest of this post if you can’t figure out what I am talking about. Here’s the bottom line: ActiveVOS is the answer. Read no further, just download the product and see for yourself.

OK, back to my strained, mixed metaphors. The camera obsucra projects the application you’re trying to create from the other side of the wall. Building that application with proprietary tools is the equivalent of getting there “darkly.”

What I am trying to say is there are three things about building SOA applications you should always keep in mind:

• If it ain’t standards-based, just don’t do it. For those of you who have wedded yourselves to Oracle or whatever-your-favorite-proprietary-vendor-stack-is, you are trying to trace the image on the wall using doomed technology. (Now that was a good use of the camera obscura metaphor, don’t you think?)
• You need the complete package. Piecing stuff together yourself is the ultimate in getting there with muck all over you. It will take longer, cost more and be less flexible. Period, end of story, full stop.
• You gotta reuse what you already have. Nothing is worse than being told you can’t start with at least a trace of the image on the wall. Maybe you’ve got lots of what we used to call “legacy mainframe” stuff (which we all know is running the business). Maybe you want to use Java. Maybe you need to include human workflow. Whatever the situation, having to start over just isn’t an option.

Mercifully, I’m gonna stop here. It may be that you have no idea what I am talking about. But I don’t think that’s the case. More likely, you are mounting a defense in your head of why you cannot “abandon” the path to SOA-based applications you’re on.

C’mon, just between you and yourself, aren’t you willing to admit there’s a better way? Visual orchestration systems, and ActiveVOS in particular, are the digital camera to proprietary systems’ camera obscura.