Only connect

Separate interviews with Adam Bosworth and John Shewchuk this week share modularity as a strong theme in common.

Darryl Taft of eWeek has a wide-ranging interview with BEA Systems' chief architect Adam Bosworth (who in a previous role at Microsoft was a key champion of XML and web services). It runs to five pages, under the title BEA's Bosworth: The World Needs Simpler Java, which signally fails to indicate the full scope of the piece. Here is just a sampling of the many interesting points covered:

• On widening the market for J2EE tools Bosworth says: "I would argue that there were really only about 500,000 people who could effectively use J2EE before Workshop ... And I believe we truly have made it possible for the corporate developer, the applications developer to play in that and that means there's more like 5 million people." He then goes on to say that's probably half the total number of programmers in the world, which he notes is an order of magnitude less than "about 100 million people who I think can use complex abstract tools — meaning build really complex spreadsheets, do Visio, use Access at all." BEA is not targeting them, he says. So BEA is taking the opposite approach from Charles Simonyi's Intentional Software, which I described in my last posting, Not as intended. BEA aims to make complex programming more accessible to the 10 million, whereas Intentional aims to automate it so that the 100 million can take advantage of it without having to learn program.
• On the browser vs Windows he points out how easy people find it to use the browser "because it's so self-evident what to do." Not only is it harder to learn all the widgets in Windows, it's also harder to maintain. "Software's gotten better at being adaptive and self-modifying, but that cuts both ways," he says. "I'm sick of applying my upgrades on Windows every night. And it makes me nervous that the software on my PC is constantly changing." In his mind, the case against a traditional Windows-style thick client is settled; no one wants it: "I think in general we still want to say an app is just something you point to with a URL." But that in turn, he goes on to say, means we want more from our browsers, including support for disconnected working.
• On Longhorn he provides some interesting insight: "Longhorn I think is conflicted about this. Bill has always wanted a thick client." So that's what Longhorn will be. Except that, "for most of us most of the time the browser works well enough."
• On where browser architecture is headed he seems to suggest the browser may become more of a behind-the-scenes component in the client system alongside other functionality: "You can think of IE as a component within something. InfoPath was actually built on top of IE as a component. So I think what you may see is people building stuff that uses IE as a component."
• On Indigo's chances of success he gives a thumbs-down, suggesting that Indigo will arrive too late: "I would say that the Web services stuff is pretty ubiquitous and pretty widely used at this point. Indigo as far as I can tell is still a couple years away ... Three years from now I wonder if anyone, even Microsoft, can replace plumbing at that level." He concludes by noting that it seems too tightly coupled: "I haven't yet seen what I'll call a sufficient focus on messaging. This is very basic to me."

That comment about browser functionality being combined with other modular components was picked up by Collaxa's Edwin Khodabakchian, who highlights Adam's prophecy that, "You use the browser as you do today, but the communication on the back end is richer," and notes: "It will be interesting to see how long it will take for Microsoft to realize that they are going down the wrong path and start re-designing Longhorn/XAML/Avalon."

But perhaps it will not be so long, according to some comments by John Shewchuk, an architect on Microsoft's Indigo team, quoted by Jon Udell in his InfoWorld column this week, Web services alphabet soup. The title is a reference to the plethora of web services standards that is emerging, of which Jon demonstrates his encyclopedic knowledge by quoting a small sample, straight off the top of his head:

"WS-Addressing, WS-AtomicTransaction, WS-Attachments, WS-Context, WS-Coordination, WS-Eventing, WS-Federation, WS-Reliability, WS-ReliableMessaging, WS-Routing, WS-SecureConversation, WS-Security, WS-SecurityPolicy, WS-Transaction, and WS-Trust. That's just the WS series; there's also XML 1.0, XML Schema, SOAP, WSDL, UDDI, XML-DSig, XML-Encryption, XKMS, SAML, XACML, ebXML, BPEL4WS, WSRP, and a partridge in a pear tree."

John Shewcuck isn't fazed by the apparent threat of fragmentation among all these overlapping standards because, Jon writes, "There is something qualitatively different about the WS menagerie: modularity ... What makes this modular approach possible, Shewchuk says, is XML itself ... XML packets are flexible, accordion-like structures. Individually they can grow; collectively they can be rearranged. This 'composable architecture,' Shewchuk argues, is something new in the realm of communication protocols."

How Indigo uses this modularity is by calling them as runtime attributes: "In Indigo, it boils down to attributes," Shewchuk says. "You tell the run time you want confidentiality, longevity, and reliability, and it uses the composable architecture to translate that into a configuration on an execution pipeline."

So while Bill's influence presumably looms large over the Indigo team, pressing them towards a tightly integrated, bells-and-whistles client environment, at the same time there's a great deal of determination to build in runtime modularity, which might just succeed in giving Bill the performance and rich functionality he demands, without sacrificing the flexibility that comes from a message-oriented architecture.

One further item that leapt out at me from Adam's interview was the revelation that, shortly after BEA acquired Crossgain (the company he had set up on leaving Microsoft), he instigated the purchase of a little-remarked startup called Westside. This rang a bell for me because two years ago I acted as a judge for the 2002 round of the SIIA Codie Awards. My role was to review the nominees for the Best Application Service Solution, of which Westside was one. The company had developed a database-driven, hosted development and deployment platform for application-driven websites. It was definitely the slickest implementation of this type of functionality that I'd seen at the time, and it's interesting that those skills in particular were of interest to BEA in the development of WebLogic WorkShop.

One of the barriers the former Westsiders may recall from their time as an ASP was the impossibility of linking up to other hosted functionality. Messaging, as Adam says, is absolutely fundamental, but it's quite alien to the way the world has gotten used to writing software in the first few decades of computing. Every vendor still tries to own every connection, which is probably why Indigo still looks like it's going to be too tightly integrated.

Few people yet recognize that the source of power in the networked world is open connection rather than guarded isolation. The dots are there, but no one has yet joined them up.

My thanks, as a final postscript, to BlogLines, the hosted RSS newsreader service that I became a user of on Friday morning, having read a recommendation from Sam Ruby. Unlike Adam Bosworth, I long ago gave up on upgrading Windows (I keep on promising myself a new PC soon) and so my preferred means of adding new applications is by signing up to online services. Taking five minutes to sign on and get set up is far preferable to all the hassle of installing new software on my clapped-out P3.

BlogLines has already proven to be a great improvement on my previous RSS newsreading arrangements. But I'm slightly miffed to find that, less than an hour after I signed up, the Bloglines database got corrupted and they had to do a restore later that day. I didn't lose any data but others registering later did. I hope it wasn't the strain of adding my selections that caused the problem! The experience underlines the challenges service providers face in scaling up to demand. Being a hosted service provider isn't easy, but it's a skill that's going to have to become commonplace as the loosely coupled universe of web services begins to take shape.

posted by Phil Wainewright 4:09 PM (GMT) | comments | link