Jon's Radio

Jon's Radio : Jon Udell's Radio Blog

Updated: 8/6/2002; 12:30:52 AM.

Note: Jon's Radio has moved to InfoWorld

Thursday, May 16, 2002

Sam reflects on the discussion in Dave Winer's session:

What amazed me most is that things I take for granted like RSS and referrers and how other experienced bloggers seem to be just discovering such concepts. [Sam Ruby]

Ditto for me. I've been running an RSS channel for my personal homepage since 1999. In 2000, I wrote a report on Internet groupware that recommended pushbutton web publishing, RSS aggregators, and RSS readers as engines of a new era of scientific collaboration.

It's taking much longer than I thought. But it does appear we are finally approaching the tipping point for this cluster of technologies.
5:22:08 PM

Spectrum is a nonrivalrous resource

David Reed, on the panel following Larry Lessig's talk, is speaking about a fundamental flaw at the heart of the FCC's management of spectrum. The FCC assumes that spectrum is rivalrous. It isn't:

We now know that we can arrange for the capacity of a fixed amount of spectrum in a fixed volume of space to increase as the number of users increases.

Here's the example. Two independent research projects (Tim Shepard in his MIT Ph.D. thesis, and Gupta and Kumar of University of Illinois, Urbana-Champaign in a recent paper) have shown that the capacity of "spectrum" can be managed so that it increases with the number of users. The key idea is to organize the spectrum users into a cooperative network rather than an uncoordinated set of point-to-point channels. As the number of users N increases, the capacity can grow as N1/2 (the square root of N) in the architectures they suggest. Thus, the more users that make up the network, the more capacity the network can carry.

We need a regime that allows RF networks to interoperate and cooperate in use of "spectrum" in an open and experimental way, just as the Internet did. [David Reed]

The room we're sitting in is a great place to ponder the implications of Reed's argument. Most of us at this conference have never before breathed such data-rich air. Spectrum scales far beyond what we imagine, Reed says. It does so for reasons related to Reed's law of group-forming networks. Can this myth of scarcity be successfully challenged?
5:13:55 PM

Web services and the web ecosystem

Adam Bosworth gave a whirlwind tour of BEA's WebLogic Workshop. After the obligatory Hello World, he dived into the good stuff. Cajun (I'll still call it that, for brevity) takes the web services mantra of loose coupling very seriously. It separates interfaces from implementations by generating XML grammars, called maps. In a nutshell, your map abstracts away from member variables in implementation code. An element in the map, say <PERSON>, is not sensitive to changes in the names of underlying member variable names. This contrasts with most SOAP toolkits which generate interfaces based on those names -- interfaces that break when the names change.

A second key abstraction is conversational context. The framework persists member variables when a service is marked as conversational, and automatically sets up one-way messaging with callbacks. Under the covers, JMS (Java Messaging Service) is used rather than HTTP as the SOAP transport.

Bosworth argued that Microsoft's toolkit makes it too easy to create tightly-coupled RPC-style services. In the follow-on panel discussion, Microsoft's Dave Stutz admitted as much. "Guilty as charged," he said, while pointing that as with VB, early concept demos have been biased toward the simple, easy-to-use end of the spectrum.

I asked Stutz, Bosworth, and IBM's Sam Ruby if the doc/literal style of SOAP usage, which Visual Studio.NET in fact prefers, represents the generic approach to BEA's mapping technology. They agreed violently. Bosworth: "I'd even say RPC was a bad idea to begin with."

Bubbling under the surface here are the somewhat ominous implications of an architectural style that solely addresses application-to-application communication. "Where's the web in web services?" asked KnowNow's Rohit Khare. The term is a complete misnomer, the panel agreed. It should have been called Net Services, not Web Services, but the name stuck and it's too late to change it.

Tim O'Reilly jumped up to say that we ignore the social dimension of the web at our peril. There is "innovative froth" that comes from the bottom up, driven by open source energy and by the interactions among people and applications. I agree. Web services are reinventing the client/server space, and aiming to solve coordination and scaling problems that were never solved before. This necessarily goes beyond the original charter of the web, which was to be a distributed hypermedia application. But the two worlds are not wholly incompatible either. Not every message requires conversational context and asynchronous callbacks. There's a vast and useful intersection between the web as an interactive hypermedia application (used promiscuously by humans and applications), and web services as a mainly application-to-application affair.

It's great to see BEA, Microsoft, and IBM violently agreeing on architectural principles and protocols. But like Tim O'Reilly, I wish that consensus didn't sound so much like a vendor-driven secession from the web ecosystem.
3:02:41 PM

Rob Flickenger: Tapping the alpha geek noosphere with EtherPEG

Thanks to EtherPEG, Rob Flickenger saw a different, and frightening, view of the group mind during a session today:

I have stared at the sun, and for the sake of my sanity, will never again look directly at the consciousness of the online uber-geek collective. [Tapping the alpha geek noosphere with EtherPEG]

An amazing and scary twist on visualizing the data-thick atmosphere we're all breathing here.
12:38:43 AM

Sketching on napkins

Over at Industrie Toulouse, Jeffrey P Shell has a long meditation on agile modeling, which touches on themes he has been exploring for many years.

Today is actually the first time I've read about it at all, besides seeing the book title. And I don't claim to follow any of their practices fully. I just like the general idea. Modeling is about communication. Sometimes that communication is in the form of ideas of how a system could be shaped. Sometimes that communication is in the form of details about how a system is shaped. [Industrie Toulouse]

As Jeffrey points out, doing this kind of communication easily and quickly in a lightweight tool can make all the difference. Life is short; things move quickly; formal methods like UML often can't keep up; computers should help us do sketches on napkins faster and better too.
12:25:30 AM