Shared newsfeed readers

More and more sites are using RSS to publish news, information and commentary, but so far the readership for those RSS feeds has mainly been limited to individuals motivated enough to download and install one of the desktop RSS newsreader programs, such as AmphetaDesk, FeedReader, and the combined newsreader and weblog publishing tool Radio Userland. For everyone else, the only way to view multiple feeds in a single place has been to visit one of the handful of sites that publish selected feeds as HTML — examples include NewsIsFree, Nuzee and, in a small way, Loosely Coupled's own news headlines page — but there are not nearly enough of them.

There are signs that may, finally, be about to change. Last week UserLand upgraded Manila, its hosted weblog publishing engine, by adding a news aggregator publishing engine. The new feature lets users create their own custom pages to publish news items from multiple RSS sources. "I asked for this feature," writes Dave Winer, Userland's founder, "because I wanted my colleagues at Berkman to have the aggregator experience without having to install software on their machines." I think Dave underestimates the importance of what UserLand has just done. Yes, it's convenient, but there's something far more significant than that about it. The results are published on the Web, instead of being viewable only on a single individual's desktop.

What this does is open the way to a flourishing of published aggregators, each of them specializing in a particular field or area of interest. Then, instead of having to personally research and subscribe to a whole list of feeds each time I want to track a new topic, all I need to do is find the website of someone who's already done that, and view their published aggregation.

Of course, there's one further, very obvious step UserLand ought to be taking. If they gave Manila users the option of publishing their aggregations to an RSS feed of their own, then I could subscribe to my favorite aggregations, and either view them in the comfort of my own desktop aggregator or — better still — republish them on the web as part of my own aggregation page.

"... And you know, with that step, we've just started to venture into the realms of network leverage, because the expert [I'm] relying on to aggregate those feeds for [me] would automatically add new feeds as they became available, so [I] would be adding valuable new feeds without even having to lift a finger."

The quote comes from a posting I wrote back in June last year, Why not aggregate collectively?. It's something that's been bugging me even longer than that. In January 2002 I posted a message, Publishing newsfeed selections, to the K-Logs discussion group that UserLand COO Jon Robb had set up on Yahoo!. "It seems to me that the selection of news feeds an expert makes is itself something that would be valuable to share with others," I wrote. "But I have never seen this offered as something that a user can choose to publish to their weblog/k-log/otherpage, rather than running it privately on their own desktop."

Unfortunately, my pleas back then fell on deaf ears. In fact, I'm not sure that anyone really grokked what I was talking about. Now, of course, having freshly invented the concept, Dave Winer says of the new Manila feature, "It's a new idea, a workgroup news aggregator." Well, not quite a new idea, but still welcome — and perhaps now, an idea whose time has finally arrived.
posted by Phil Wainewright 2:43 AM (GMT) | comments | link

More development, less progress

Marc Andreessen makes some interesting points in a Network World interview about the development of the browser (this month marks the ten-year anniversary of the release of Mosaic, the first graphical web browser, which Andreessen developed, before going on to found Netscape).

I think there's an important lesson for the developers of web services specifications when he points out that web browsers haven't really changed all that much in the past five years: "Creativity stopped in 1997. Before that, there were huge numbers of changes: dynamic HTML, JavaScript, Java mail, plugins for security and other functions... The browser today is basically what it was in 1998-99. The good news is that everyone knows what a browser is and what it does."

The reason development stopped, he explains, is that there's no commercial incentive to compete with Microsoft when the browser is free. But the result has been a stable, well-understood platform for a huge explosion in web-accessed applications and services. Dismissing later developments like the semantic web (and even XML) as an irrelevance to the future of the browser, he likens its success to that of TV: "TV was invented in 1950. Today, we have 500 channels instead of three. But it's the same model, exactly as it was 50 years ago. Once these things get started, it's hard to slow them down."

The point here is that the stability of the platform has allowed creativity to flourish in developing services that take advantage of it. I think the same applies to web services. There's already a strong platform using XML in conjunction with HTTP. Some applications may need the additional capabilities of SOAP and WSDL. In enterprise server environments you'll probably want to add UDDI and some of the emerging security and messaging standards I discussed yesterday, plus maybe a bit of orchestration (just as the enterprise sector took Java and created the J2EE application server architecture). But at all costs, it's essential to resist the temptation to over-engineer the core platform.

You see, if you try too hard, you'll end up with something that's too sophisticated to catch on, and too constraining to have broad applicability. Take note of this closing comment from Andreessen, when the interviewer asks him what he would go back and change in the original browser if he had the opportunity: "...there was one feature that was temporary in Mosaic: the Back and Forward buttons. That never made a lot of sense to us. Back to what? Forward to what? We thought there would be a better way to navigate. But no one ever came up with one."
posted by Phil Wainewright 2:35 AM (GMT) | comments | link

Trusting web services

Security and reliability are overlapping but distinct concepts. Both impinge on the risk profile, and thus the trustworthiness, of a web service. But each can exist without the other. It is quite feasible to have a fully secure and yet totally unreliable web service (an alpha-stage prototype confined to a secure development environment, for example). Similarly, a thoroughly robust web service is capable of systematically betraying your confidence (a secure transactions server that performs its nightly data backup over an unprotected link, for example).

For some time now, security has been seen as the biggest barrier to web services adoption. Yet according to InfoWorld's final report from its CTO Forum last week, "Reliable messaging came to the fore ... as perhaps the most important missing ingredient in the web services recipe." The truth is, the real barrier to web services adoption is risk. Where there's no quantifiable risk, there's no reason not to adopt a web service, even if it's both insecure and unreliable (publishing or consuming an RSS news feed, for example). But in most enterprise applications, a lack of either security or reliability each constitute a risk that must be either controlled or eliminated.

Enough progress has been made by now on web services security to begin to manage that source of risk — although defining an acceptable solution remains something of a black art, as David Longworth describes today in the article, No single path to web services security. Nevertheless, there's now enough accumulated wisdom to start to quantify the security risks, and as a result the spotlight has switched to a lack of reliability as the next source of uncertainty.

"Reliable messaging is a tricky business, which takes a great deal of experience to get it right," writes Dave Chappell in an article for Web Services Journal entitled Will the Real Reliable Messaging Please Stand Up?. His article reveals that there are not even just two, but actually three, competing specifications for reliable web services messaging. The best known are WS-Reliability from OASIS, which Dave sits on the committee for, and the joint Microsoft, IBM, BEA and Tibco specification, WS-ReliableMessaging. As it often does (WSCI and BPEL4WS being another case in point), BEA also separately produced its own specifications covering the same ground, some ten days before it joined with its partners to announce WS-ReliableMessaging, which makes three competing sets of specs in all.

Dave Chappell is well qualified to write about messaging, being the chief technology evangelist at messaging infrastructure vendor Sonic Software, as well as an author and frequent conference speaker. But confusingly, another David Chappell was writing about reliable messaging and web services just a week or two previously. Also an author and frequent conference speaker, this David Chappell is principal of his own San Francisco-based consultancy Chappell & Associates.

He takes a different line than Sonic's Dave Chappell. In a piece entitled The Myth of Loosely Coupled Web Services, he sets out why he believes Microsoft and IBM's WS-ReliableMessaging has already won the day, making the rival WS-Reliability "a distraction — at worst a small speed bump — on the way to interoperable, loosely coupled web services." But what's more interesting is his exposition of why reliable messaging, in whatever form it takes, is so crucial to the success of web services.

He points out that web services aren't inherently loosely coupled, and that you don't always want them to be, anyway: "Some applications work better with synchronous communication, others with asynchronous communication. The battle between fans of both approaches ended years ago, and the result was widespread recognition that both have their place." But in cases where you do want loose coupling, you need some form of message queueing, to make sure the asynchronous communications run smoothly. Thus, he concludes:

"Thinking of web services as inherently more loosely coupled than earlier technologies isn’t really accurate. Yet adding support for WS-ReliableMessaging will go a long way toward achieving this goal ... loosely coupled web services won’t be a myth much longer."

It's a rhetorical exaggeration, of course, to go as far as to claim loosely coupled web services are currently a myth. So long as your application tolerates insecurity and unreliability, there's a lot you can already do with them. But to make them absolutely trustworthy, you need these vital infrastructure standards that are currently being formulated. Until the standards have been finalized for both security and reliable messaging, there's a limit to how far you can depend on web services.
posted by Phil Wainewright 11:43 AM (GMT) | comments | link