For solving a host of vexing problems with quiet competence, and for doing it in ways that invite others to stand on their shoulders, I salute them all.
The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward.
The way forward, Geer suggests, is not to abandon ACLs but rather to augment them with aggressive monitoring that holds people accountable for behaviors that can’t economically be permitted or denied.
A few months ago, key Microsoft architects were telling me that it would be impossible to decouple the Avalon presentation subsystem from the Longhorn OS.
...collaborative systems for building a shared database of items, developing a metadata vocabulary about the items, performing metadata-driven queries, and monitoring change in areas of interest.
Discussions about open source and innovation tend to cluster around two opposing memes. One says that open source can't innovate; the other that only open source can innovate. Both are wrong.
Bosworth's hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need -- both offline and online.
Here's a challenge: Let's improve the various functions performed by e-mail without multiplying the interfaces people must learn in order to use those functions.
Fault tolerance, service-level agreements, access control, and business activity monitoring are among the many things enabled by intermediaries that watch (and sometimes transform XML) message flows.
We need HCI (human/computer interface) guidelines more than ever. And we need them not only for Windows, OS X, GNOME, and Flash, but for the uber-platform that subsumes them all.
Clemens Vasters is cofounder and chief technology officer of newtelligence AG, a developer services company focusing on XML Web services and .NET enterprise technologies.
"His current technical interests include alternative transaction models, aspect-oriented programming, statistical modeling of distributed applications, and streaming XML"
"I'm short and I have the remnants of a southern accent," Paul says in a recent interview. Co-founder of Digital Creations, now Zope Corporation, Paul evangelizes the powerful Zope/Python combo.
CTO of Propylon, and previously co-founder of Digotome, Sean has served as an invited expert on W3C committees, and is a widely respected authority on XML.
Q: Does a quick blog entry meet the same standards and go through the same background and vetting process as a "real" story?
A: Many (though not all) of the items I post here are as carefully written as what goes into print. None are is 1 edited by anybody but me. None are vetted by anyone at InfoWorld, but all can be vetted by everybody who chooses to comment.
Q: Is a blog entry equally as obligated to represent both sides of a controversy, or is it expected to only represent the journalist's point of view?
A: For the magazine, I write features and reviews and columns. All are expected to be fair. The story types exist along a spectrum ranging from less to more personal. The blog lives at the personal end of the spectrum.
Q: Are blogs supposed to be more of a conversation -- and if so, should they always have comments enabled?
A: I think blogs can't help but be a conversation. As to comments, after years of doing Web forums and discussions, I'm experimenting with taking a break from flames and spam. I'd like to think that the blogosphere's less tightly-coupled "discussions" -- mediated by logs and search engines -- delivers better signal-to-noise with less psychic strain. That said, I do miss direct comments, I do use them selectively, and I may try renabling them.
Jeremy's questions were motivated by a series of questions I've been asking about Longhorn. This is part of a strategy I've been using -- since the pre-blog era, in fact, when my medium of choice was NNTP -- to deepen the stories I research for magazines. When the subject is not a secret, I find it extremely helpful to raise some issues publicly and invite a range of interested parties to react to them. A recent example was this entry in support of this story.
In that spirit, I owe Jeremy a response to his questions about my take on WinFS. He asks: "What is an 'XML-centric database' anyway?" A good example of the basic idea -- and the one I've been working with -- is Berkeley DB XML (which has also been adopted by the Chandler project). DB XML supports indexed XPath search, a poweful capability that's now being woven into both RDBMSs with XML support, and "native" XML databases. An even more powerful standard is XQuery, which though not a final recommendation is implemented provisionally in both conventional RDBMSs and native-XML dbs.
We have standard query languages (XPath, XQuery), and standard ways of writing schemas (XSD, Relax), and applications (Office 2003) that with herculean effort have been adapted to work with these query and schema languages, and free-text search further enhancing all this goodness. Strategically, why not build directly on top of these foundations?
Tactically, why do I want to write code like this:
public class Person
{
[XmlAttribute()] public string Title;
[XmlAttribute()] public string FirstName;
[XmlAttribute()] public string MiddleName;
[XmlAttribute()] public string LastName;
....
I believe two things to be true. First, we have some great XML-oriented data management technologies. Second, the ambitious goals of WinFS cannot be met solely with those technologies. I'm trying to spell out where the line is being drawn between interop and functionality, and why, and what that will mean for users, developers, and enterprises.
1 David Clarke, of CapeClear, points out that "this statement, precisely by virtue of its obvious lack of sub-editing ('are', not 'is'), re-inforces the very point it seeks to make!" Delightful! As David mentioned to me in email, there ought to be a word for this reflexive case.
Current approaches to taking browsers offline typically enqueue messages that later update a server-based data model. An Alchemy application, though, always works with a genuine local data model that it stores as sets of XML fragments and navigates in a relational style. Bosworth's hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need -- both offline and online. Nothing prevents Java, .Net, and Flash clients from adopting the same strategy, by the way. But if Bosworth is right, the universal client that we know and love could get a new lease on life. [Full story at InfoWorld.com]
In the story as printed, this sentence:
BEA's Alchemy relies on a server component for the same reason that Macromedia's Flex does: both companies want to sell servers.
was abbreviated to this:
BEA's Alchemy relies on a server component for the same reason that Macromedia's Flex does.
Things get left on the cutting room floor, that's just life in the print medium, but I do want to restore (and expand on) the original point. Adam Bosworth is a guy who knows an awful lot about building client software -- Quattro, Paradox, Access, IE. But he is not now selling client software. Rather, he's selling infrastructure based on principles -- asynchronous coarse-grained XML messaging -- that he has forcefully and consistently evangelized. From our interview, here are some quotes that restate why such infrastructure must be:
Clustered
People who build services tend to assume they don't know who's going to use them, and how often.
Metadata-driven
So you can change the behavior without recompiling and redeploying the code.
Asynchronous We're still trying to convince the industry of this, but it's a lot better if you do this asynchronously, because a lot of time the thing you're trying to talk to can't respond right away, either because it wasn't written to handle the load or because the thing you're asking it to do takes time.
Intermediated
The problem is that your credit approval service got bought by BFA and they consolidated the thing, so now it's a different address with a different message, and you don't want to redeploy your app. So you want everything to go through some fabric that is essentially modifiable. Call these things intermediaries, enterprise service buses, fabrics, I don't care, but you need one of these things. We've announced one called QuickSilver, BlueTitan does a nice job with this, there's Confluent...
Nothing controversial here. But there are wildly different approaches to the construction of the client-side systems that we'll attach to this infrastructure. Microsoft's Longhorn must try to extend the Windows franchise. BEA's Alchemy is free to extend the Web. This isn't an either-or deal, of course. Both strategies can succeed and co-exist. It helps, though, that the Web has found a powerful new ally.