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.
Former URL: http://weblog.infoworld.com/udell/2004/06/15.html#a1023