Software Innovation

...it's not just about product anymore

Users are increasingly part of the plan in software innovation.

Went to the - Apollo

...should have seen them go go go...

Adobe's announcement of Apollo is a big deal. The quest for a routine way to generate Rich Internet Applications (RIAs) has been a troubled one: Ajax/CSS is great but hard to make work across browsers, and Flex is great and works across browsers but is controlled by a single company (again, Adobe).

Apollo matters as the next step in Adobe's efforts to become the Microsoft-of-the-cloud.

By all means take a look at Ted Leung's terrific set of posts on the quest for the next great world-scale development environment.

New REST Links

REST (representational state transfer) is a simple means of providing SOA for declarative (noun-based) systems.

REST is neat because it is relatively easy to design for and implement, and straightforward to connect to. Roy Fielding's PhD thesis has come a long way, and many of the more dynamic development communities (Ruby on Rails is a good example) have embraced it fully.

I've written a lot about REST in the past, and figure to write more in the future. To summarize REST benefits in a single sentence: "REST lets developers design the machine interface to their web applications 'for free' - as part of the regular, human-interface design process."
In the meantime, this morning the RSS net served up a bunch of great links this morning. To get a better sense of REST, you might follow the following links:

• You are already doing REST
• The REST Triangular Pyramid
• SOA Maturity Model
• REST issues - real and imagined

Enjoy.

This is not a Pipe

Every once in a while, something happens that makes me completely reassess my take on "what's next" in the technology sector. The original Macintosh was one such epiphany, Apple's Hypercard was another (Hypercard is a much-unappreciated program - had Apple added network links to it we'd have had a writeable, scriptable WWW in 1989). Netscape's first browser was a third. On Thursday, the release of Yahoo! Pipes shook my world.

The Pipes slogan is "Rewire the web", and that's what it purports to do - as a visual editor for RSS feeds that dramatically lowers the time and expertise needed to create a mashup. Pipes lets you create your own personal web channels, and Gina Trapani at Lifehacker has a great example of how to do this.

And so, if your interest is, say, the NFL draft, it's pretty easy to wire up all the draft-tracking sites so that if a potential 7th round pick out in East Treestump gets a hangnail, you'll know about it. But the implications go so much further...

In a REST-ian world, it's pretty easy, once you've modeled your world as a set of resources, to create RSS feeds that track the changes in those resources. With an application like Pipes, it's really easy to tie those feeds together into new applications. This is the future of "SOA" and "Web Services."

Forget SOAP, and the growing pile of WS-* standards as a means of wiring up disparate applications. REST-ify the applications, use RSS to publish the changes, and a tool like Pipes (or one of the imitators that should be quick to follow) to wire the whole thing up. SOAPians - put that in your pipe and smoke it!

Seriously, though, while the Pipes idea is great, there are still some issues to work through. The intuitive purity of the Pipes concept was proven when everyone from the merest script-kiddy to the deepest hacker jumped on Yahoo! and bought the Pipes site Down! all day on launch day. Yahoo! knows a bit about keeping large sites up under volume, so we are surely talking about a big human wave here.

But that's not all, either. XML is wordy, and XML transformation is slow and computationally intensive. I'm curious to see if the sheer processing load leads to more restricted (e.g. JSON) or more efficient/binary formats as a wire protocol for Pipe-y services.

I'm convinced these things will be worked out, and Tim O'Reilly's comments about Pipes as a milestone in the history of the internet will prove to be true.

As such, let this be my 14th prediction for 2007: February 7, the Pipes release date, will be looked back on as the day SOAP died. Not that it's bad, but the future has been shown to lie elsewhere.

RESTful Goodness - I declare!

Rails 1.2 was recently released, and I've been updating and upgrading Pikaplanner to take advantage of some of the new features in 1.2.

The highlight of Rails 1.2 is built-in REST support, and I've been updating my controllers to provide what amounts to a standard, easy-to use, web-services API.

My first step in the process was to work through some of the examples in Rob Orsini's terrific developer volume Rails Cookbook. Diego Scataglini's examples in Rob's book provide a simple and quick intro to REST support in Rails 1.2.

REST is a great example of Clayton Christensen's concept of a disruptive technology. I've worked with SOAP and RPC in the past, and at first blush REST is less powerful than either. Still, with Rails, REST is easy and cheap to adopt at the service-provider end, and easy to experiment with at the receiver end.

For example, one of the first code areas I worked through was a simple product listing. The goal here is to provide both a web (HTML) and web services (XML) interface to our (sample) product information.

The REST support in Rails makes it easy, and all we need to do to turn our web pages into a web-services interface is tell (though the URL) our application that we want XML (instead of HTML) back.

So: to see the web page listing our products, we'd use "/products", as shown below:

So far, so good, so common -- in Rails we've called up pages like this in the ":controller/:action/:id" form (that defaults to a GET on index.html here) zillions of times. What's new, with REST and Rails 1.2, is that all we have to do to have a web services interface is tell the application we want XML back, instead of HTML. So our URL is of the form ":controller/:action/:id.xml", as shown below:

and as you can see we get XML back - a web services interface practically for free (developer time-wise).

There is a lot of magic underlying this simple example, but a handful of key points stand out:

1) All we need for our "web services" interface is to tell our controller we want XML back.

2) We could have gotten JavaScript back (where that is appropriate) in the same manner

3) The key shift in development mindset is that the interface is not imperative (as SOAP and most web services are) but declarative -- everything important in the system a) has its own URL for CRUD access, b) exists as a stateless resource, in which complex actions can be created by changes in state of one resource triggering actions to change the state of other, related resources, and 3) is capable of varying the format of responses, depending on what is requested.

That third point is a mouthful, and the core of stuff on which theses have been written.

Declarative programming is a significant mind-shift, one I'll be writing more about in the future.