Pete Lacey’s Weblog

In the past I noted that while REST doesn’t say anything about transport- or message-level security, there does not currently exist any standard means of using message-level security in a RESTful system. I was wrong.

I don’t know how I missed it, but section 5 of the Atom Syndication Format (Atom) describes how to encrypt and sign an Atom document. Like WS-Security, Atom leverages the existing W3C specifications for digital signatures and encryption. What does Atom have to do with REST? Technically, nothing. It’s just a well known, high-level, media type that you are strongly encouraged to use as your representation format—as an envelope around your content.

Traditionally, Atom feeds are polled by subscribers and thus forms a pub/sub model. Securing the feeds or the internal entries will allow me, for instance, to subscribe to my cell phone usage data and know that the message is confidential, unmodified in transit, and really created by my cellular provider. But what about the more common request/response needs, where, say, a buyer wants to purchase 1,000 widgets? Well, that’s where the Atom Publishing Protocol comes in. I, the supplier, can expose my order processor as a resource (http://example.com/orders) and my customers can POST a signed and encrypted purchase order wrapped up in an Atom entry to that URL.

What about authentication credentials? Well, if the entry is signed, then the signature serves as the originator’s credentials. Coolness! If for some reason digital signatures don’t work for you, then Atom supplies an extensible author element. It’s lacking a password field, but to address that just drag in the WSS Username Token Profile:

In for a penny, in for a pound.

So I dug around in Apollo a little bit, and I did a little bit more thinking about my reflexive dismissal of the technology. And I admit to misunderstanding and miscategorizing Apollo. Here’s what I learned.

Apollo is not a browser plugin, nor does it leverage or extend your browser in any way. It runs completely outside the browser. It is a run-time environment for building cross-platform desktop applications. It contains an HTML rendering engine (coutesy of WebKit), JavaScript and ActionScript engines, a Flash player and numerous other components. Developing for Apollo is allegedly easier than developing towards other desktop environments, and that’s probably true.

An exercise in positioning Apollo

Lets say you want to build a RSS/Atom reader. I’m using a news reader as an example because it divorces the client from the server. In other words, the server is as Web-ish as you want. However, you can pretend that you’re developing any old app, even—especially—business apps.

If you were targeting a single desktop environment, say Windows XP, you might choose to use the native development environment, .NET. Or maybe C++. But lets add a requirement: my news reader must be cross-platform. That eliminates .NET as a development platform, but still leaves C++. However, with C++ I have to carefully separate my common functionality from my OS-specific functionality and become more of an expert on OS and windowing quirks then I would like, so that’s out. Fortunately, there’s quite a few other ways to go:

1. Browser based
2. Java based
3. Dynamic language based: Perl, Python, Ruby, Tcl
4. Native cross-platform development environment, e.g Qt
5. Apollo
6. Others, e.g. Eclipse RCP

All of these have pros and cons. Browsers are limited in functionality, and quirky. Java is a pain to develop towards-especially GUI apps, has spotty HTML rendering ability, and a non-native look and feel. The dynamic languages are far from guaranteed to be installed on any particular machine—especially Windows machines, and (likely) also have their own look and feel issues. Qt still leaves me in C++ land; that is it’s hard to develop towards. Apollo also has its own look and feel, and will require a download of the runtime environment if it’s not already there (I’m ignoring its alpha release state). I don’t care about any others cross-platform techniques right now.

If we add another requirement: time to market (aka ease of development), we can eliminate Java and Qt (and its ilk). Adding one more: end user experience (ease of installation, richness) gets rid of the dynamic languages.

That leaves us with the browser and Apollo. Now lets add one more requirement: off-line mode. It’s an absolute requirement that my users be able to read feeds when disconnected from the Internet. And that’s it, Apollo is the only reasonable choice for me given my constraints.

Does that officially put Apollo in my good graces. Well, yeah, I guess it does. But that’s not to say that I don’t have reservations. For one thing, in the real world I would weigh off-line access (to pick an Apollo feature not available in browsers) very carefully against ubiquitous access. Even imagining a world where Apollo is widely deployed, it will never be as universally deployed as a browser. There will most likely never be a Win2K version, and I can imagine a large number of Linux desktop environements will be left out in the cold. Let alone other Unixes, BSDs, and so on. Moreover, even for supported OSs I think it’ll be a crapshoot as to whether Apollo’s installed or not. Right now, I can be sitting at any one of four different operating systems on six different computers without leaving my house. What are the odds, then, that I will find Apollo installed on my friend’s computer, on my client’s computer, on my phone, at the library. Even imagining 100% deployment on every machine I sit down in front of, there’s still the need to download the Apollo app locally, which I would be reluctant to do, assuming I was allowed.

That said, Apollo is probably not targeting the kind of application that the peripatetic user might need. They are more likely targeting the corporate user on a locked-down PC. This is certainly much more reasonable, but I would still be hesitant to develop Apollo applications for this environment. Why? Things change. Will Apollo be around forever? Will its release and support schedule match my retirement/upgrade schedule. Not too long ago a corporate developer could safely (if unwisely) assume that using IE specific features and quirks was fine, after all everyone in the company uses Windows and IE is the corporate browser. Now, of course, that’s coming back to bite them. The kids in IT are all using Linux (and three different flavors) and OS X, all the creatives and a handful of VIPs are using OS X too, and 20% of the company ditched IE for Firefox despite corporate policy.

The long and the short of it is this: I would develop Apollo applications if, and only if, my application was deployed inside the firewall and I had a set-in-stone requirement that could not be met by a browser-based app. But, again, that’s just me. YMMV.

My apologies to Adobe. Next up: Silverlight.

This announcement was just published to the Burton Group Web site:

The blogosphere is abuzz with discussions of REST (Representational State Transfer). Ardent REST proponents [are] recommending using REST for most distributed applications. Many recommend using REST instead of the WS-* framework. So what is REST? What are the benefits of using REST? Are there any downsides? When should you use it? And how do you go about implementing RESTful applications? In this Application Platform Strategies TeleBriefing, research director, Anne Thomas Manes, and senior consultant, Peter Lacey, discuss and debate the advantages and disadvantages of REST.

Slides for this TeleBriefing will be available the day before the TeleBriefing is held.

As you may know, Anne is responsible for mixing a lot of the WS-KoolAid, so this should be fun. Unfortunately, Burton Group Telebriefings are a service offered only to our customers. Occasionally, we make these available to the larger world. Maybe we will with this one too. I’ll let you know if we do.

In yesterday’s post about the end of WS-*, I tacked on a throwaway comment about RIA. To wit: “Now, of course, the same cast of characters are manning the ramparts in RIA vs. the Web. I know where I’d place my bets.” And even though the post was not about RIA, that’s what a number of people took issue with. (Interesting that no one seemed to care about the Ragnarok of web services.) So let me clarify my position on this subject.

1. I’m not all that vested in this controversy.
2. I have not looked deeply into Apollo/Flex, Siverlight, JavaFX, etc.
3. My gut tells me that five years from now HTML, CSS, JS, DOM will be the preferred deployment environment for the Web.
4. My main problem with these RIA technologies today is that they are proprietary. My other main problem is this looks like a land grab.
5. “RIA vs. the Web” was a poor choice of words. “Proprietary RIA vs ubiquitous standards” might have been better.
6. I have no problem with anyone using these RIA solutions, if the technology addresses business requirements
7. I admit that they are easier to develop towards than Ajax.
8. I sure wish Adobe and MS would try and float all boats and not just their own

That said, Patrick Logan paints an interesting picture that I hadn’t really considered. Rather than viewing Apollo—for example—as a proprietary plugin to a browser, view it as yet another Web-capable client with some interesting features. That is Apollo equates more to (a closed source) Firefox+XUL than anything else. I’m cool with that.

At Burton Group we have these things called reference architectures. They begin with principles (e.g., best of breed vs single vendor), and then move on to technical positions–stakes in the ground (e.g., J2EE only). My principles are open source preferred over closed, standards over proprietary. My technical position for developing Web apps is HTML, CSS, JavaScript, and other standard technologies only–exceptions must be justified. Must run in IE, FF, and Safari on Windows 2000 on up, Mac OS X, and Linux. But, hey, that’s just me.

Oh, and I just downloaded Apollo (painful registration process), picked an app to run (an RSS reader), received a nice warning that it had unrestricted system access (yikes!), let it install itself locally (???), saw it has yet another look and feel (bother), and renders at near glacial speeds (sadness). Fine. But not for me.

Bottom line: If Apollo and Silverlight work for you? Good on ya. For me, for now, I’m sitting this one out.

While attending the W3C Web of Services Workshop I had a brief conversation with Mark Baker and Nick Gall. All of us presumed the imminent demise of WS-*, but couldn’t agree on when. I said within two years, Nick thought much longer, and - honestly - I can’t remember what Mark might have said. The problem, though, was identifying what event (or series of related events) would be universally recognized as the WS-* swan song. Well, I don’t know about you, but this might be it: “REST is totally sweeping Microsoft,” the litany of WCF engineers expounding the virtues of URIs and GET (as collected here by Tim Bray), the “deeper support for the web” in .NET 3.5 (Orcas), the Astoria Project, the Windows Live Data component of Microsoft’s Windows Live Services (seeming Microsoft’s answer to Google’s GData), and finally the fact that Mark himself has been helping move some of this along.

So instead of two years, it was two months.

Now, of course, the same cast of characters are manning the ramparts in RIA vs. the Web. I know where I’d place my bets. Money quote: “you might say that RIA is to user interfaces as RPC is to messaging interfaces.”

Update (already): Alex Barnett’s two most recent posts are about Astoria.  Read them, follow the links, watch the video.  I think this will be exciting.
Follow along with me on this one.

My colleague at Burton Group, Lyn Robison, is working on a report that, in part, argues for separating information from the applications that use it via a data services layer. After all, says Lyn, information and applications are very different, and should be managed separately.

Over at Quoderat, David Megginson, provides the REST elevator pitch: “With REST, every piece of information has its own URL.”

Meanwhile, Don Box shouts out what is quickly becoming axiomatic: “(HTTP) GET is one of the most optimized pieces of distributed systems plumbing in the world.”

Finally, Stefan Tilkov points out the Astoria skunk-works project coming out of Microsoft Live Labs.

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interactions with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON.

I love it when a plan comes together.