Twenty-eight months since my last report on Microsoft's .Net technology suite, it's interesting to see what's changed and what hasn't. The desktop version of the Longhorn OS was renamed Vista, but its release status remains the same: beta. Of the three .Net-oriented "pillars of Longhorn" -- Avalon, Indigo, and WinFS -- two are renamed (Avalon to Windows Presentation Foundation and Indigo to Windows Communication Foundation) but none have shipped, and WinFS has been pushed post-Vista.
Recently I helped a friend categorise her Schedule C expenses. (Schedule C is where proft and loss from businesses is reported in US tax forms). All of her business income is in QuickBooks, but her expenses aren’t. I would have to reconstruct those from bank and credit card records. Although this friend has online accounts at both institutions, my Spidey sense was tingling: I knew there was going to be trouble.
In an interview long ago, Marc Andreessen told me about the moment he realised Netscape’s business plan would succeed. That plan, as you may recall, was modeled on Gillette’s: give away razors (browsers and mail/news clients) and sell blades (enterprise servers). For Andreessen, the magical moment came when, shortly after the word “intranet” was coined, he heard it echoing all around him in a restaurant.
Tom Standage’s history of telegraphy, The Victorian Internet, draws striking parallels between that era’s communication revolution and our modern one. A 19th-century citizen transported to today would be amazed by air travel, Standage suggests, but not by the internet. Been there, done that, they would think.
At Microsoft’s PDC (Professional Developers Conference) a decade ago, the company took the first steps towards a union of Windows and the web. Adam Bosworth showed off the technologies we now call AJAX (Asynchronous JavaScript and XML), while J Allard demonstrated Active Server Pages. Hakon Lie, now Opera’s CTO, talked about a proposed standard called CSS, and the tools division rolled out a suite of components that would make internet protocols available to Win32 programmers and Office scripters.
It was inevitable that someone would coin the phrase “enterprise mashup” and SOA analyst Phil Wainewright seems to have got there first. A mashup, for those not at the white-hot centre of Silicon Valley’s latest craze, is a composite web application.
It’s been a busy week for my LibraryLookup project, which was launched in December 2002. In its original and still most widely deployed incarnation, LibraryLookup is a JavaScript bookmarklet that connects an Amazon book page to the corresponding record in a library catalogue. The success of this technique got me thinking about themes I’ve pursued ever since: the dynamics of user-driven innovation, the protean flexibility of RESTful (Representational State Transfer) web applications and the dynamics of lightweight service orchestration.
LibraryLookup’s failures were equally instructive. Like other kinds of web apps, library catalogues weren’t (and mostly still aren’t) designed for this kind of integration. It doesn’t require much, just an unencumbered search URL. Although some catalogue vendors provide one, sereral still don’t.
The information architecture of the book world was another cause of failure. ISBNs (international standard book numbers) don’t uniquely identify books; there’s one for each hardcover and paperback edition, so the ISBN number in your browser had to match the one you looked up in the catalogue. On my blog, I wished for a service that would unify these variants and about a year ago the Online Computer Library Centre granted my wish. It deployed an experimental service called xISBN that maps a book’s ISBN to the whole set for that book.
Although a bookmarklet can splice a pair of services together, it can’t combine three or more services without relying on some kind of external orchestrator. That was more than I wanted to build and support, so the project was relegated to the backburner for a while.
This week, however, I recalled that I already had one kind of orchestrator in place. It connects my Amazon wish list to my RSS reader, by way of a library catalogue lookup. If a book isn’t available in the library when I’m visiting the Amazon page, but later becomes available, I’m notified via RSS. The orchestrator in this case is just a Python script that’s scheduled to run daily. It was easy to extend it to use xISBN, so I did.
I had earlier shown this RSS notifier in a screencast about client-side intermediation. There I also showed a Greasemonkey script that rewrites an Amazon book page on the fly when it finds that book in the library. Could the Greasemonkey script also be extended to orchestrate a collection of services?
Yes, and you can find the gory details on my blog. Here, I’ll just summarise my conclusions. First, I’m bullish on client-side intermediaries and orchestrators. For me, at least, this is the AJAX (Asynchronous JavaScript and XML) endgame. Service composition in the browser can, and will, nicely complement service composition in the cloud. I’ve done it at the WS-Light end of the tolerance continuum; Tibco General Interface shows it can be done at the WS-Heavy end as well. AJAX and BPEL aren’t in bed together yet but mark my words, it’ll happen.
Second, I’m cautiously optimistic about the future of the kinds of advanced web standards that can make this stuff really sing. The latest W3C APIs all worked well in Firefox 1.0 and they work even better in 1.5. Meanwhile the once-frozen Internet Explorer has thawed and is on the move again. I don’t know how far Microsoft will allow IE to go, but the Windows Live initiative gives me hope that the full power of the standards-based web client may yet be unleashed.
Criticising free services is always dicey. So when I dinged Stanford University and Apple for the non-accessibility of the lectures at itunes.stanford.edu, I knew I risked seeming churlish. But there are some things about this deal that rub me up the wrong way.
All of our standard technologies for human-computer interaction -- the mouse, the GUI, and the web of linked documents -- can be traced directly to Douglas Engelbart. Almost 40 years ago, he showed all of these innovations working together in the famous 1968 "mother of all demos." Although Engelbart still isn't as widely known as he deserves to be, many people do realize that his pioneering work set the agenda for computers and software that are intuitively easy to use.
When Ray Ozzie posted an announcement to his blog about Microsoft’s proposed SSE (simple share extensions) for RSS and OPML (outline processor mark- up language), I was delighted. On the technical front, it’s great to see the synchronisation DNA of Groove and Lotus Notes finding its way, at last, on to the web. But on the social front, it was a milestone, too.
There is a perpetual debate in programming circles about the pros and cons of static verus dynamic typing. I've always favoured dynamically typed languages such as Lisp, Perl and Python because my own coding efforts tend to focus on application prototyping, content wrangling, data analysis and system automation.
The physics of data management used to dictate that your data could be either consistent or highly available but never both at the same time. The discipline of data synchronisation sits uncomfortably on the horns of this Heisenbergian dilemma. As times change, though, so do the trade-offs associated with synchronization and its uses.
Two years ago, I gave the keynote address on the opening day of the XML 2003 conference. The next day, Adam Bosworth delivered a weirdly complementary keynote in which he began to lay out an idea he’s been developing ever since — first at BEA and now at Google. The idea, in a nutshell, is that the truly scalable databases of the future will be more like the web than like Oracle, DB2 or SQL Server.
Walt Johnson is an IT planner at the California Independent System Operator (CalISO), the non-profit operator of the state’s wholesale power grid. I met him at InfoWorld’s SOA Executive Forum earlier this month, where he described CalISO’s transition to service-oriented architecture (SOA).
Let’s cut to the chase in the Massachusetts-Microsoft brouhaha over office document formats. One possible outcome is that Microsoft Office gains support for the OASIS OpenDocument format, either from Microsoft or from the open source community. Another scenario is that Microsoft tweaks its Office XML licensing to conform to the definition of openness that governments are rightly insisting on.