Author: geoff

Jim Waldo expressed an understandable skepticism about my inclusion of autonomous agents in my piece on the future of software; I thought I’d share my reply to him:
I think that autonomous agents may be an ever-receding category, a bit like AI. Remember how every advance in AI would provoke the retort, “But that’s just X – that’s not A.I.” Every time we add a bit more autonomous capability to a software component (advertisement, peer group discovery, self-monitoring for SLO, negotiating over a shared security context,….) people will say, “Oh, yes, I see how you can do that, but that’s not REAL agent behaviour.” Some people will insist that we expose the inner workings, and if there isn’t an obviously “AI-like” mechanism like multi-level planning or BDI they’ll deny that it’s an agent. Whatever. [shrug] I just want software systems that are a bit more robust, a bit more tolerant of version skew, a bit better about proactive resource management and self-diagnosis, a bit more flexible about how they organize themselves with their peers.

Many of my colleagues at Sun are busy blogging about the software technologies that they work on – Solaris 10 features like zones (sorry, N1 Grid Containers), ZFS and dtrace; Java platforms (J2*E) and applications like speech synthesis and phone games; even Perl. And all of this is important – as Bruce emphasized, it’s important to articulate who we are and what we do.
I spend much of my time thinking about the future: about what cutting-edge systems and software will look like three or five years out. Now I know that this isn’t fashionable: Jonathan’s priorities for the year, immortalized here, emphasize the tactical rather than the strategic, and that’s just fine with me. And I also know that for most people the answer will be “same as it ever was”, because innovation in computing tends to be additive: augmenting rather than replacing. But the beauty of the future is that it’s already happening. Check out two articles in last week’s Computerworld if you don’t believe me.
Have Jini, will travel describes how Orbitz built their travel reservation system using Java and Jini. To quote from the article:
Under the Orbitz architecture, a customer request to book an airline ticket passes to a Java servlet container — the Jini client — running on BEA Systems Inc.’s WebLogic application server. The Jini client uses the Jini discovery protocol to find a Jini lookup service, which sends a proxy back to the Jini client. Through the proxy, the Jini client uses the lookup service to find a Jini service that can do what it needs. The lookup service then delivers the Jini service proxy back to the Jini client, and the client uses the proxy to communicate directly with the Jini service.
Orbitz registers its 1,332 Jini services on multiple instances of lookup services for redundancy, so there’s never a single point of failure in the event of a power supply or hard drive failure. It also builds redundancy into the servlet containers and the services themselves, scaling horizontally through Intel-based dual-processor PCs running Linux. The PCs act as servers in the Orbitz environment. “It’s not just redundancy; it’s also capacity,” says Hoffman. “If you need today 10 boxes to service a particular request and your traffic doubles, we can just add 10 more, and it’s not only handling twice the capacity but it’s now twice as redundant as it was before.”
While analysts are starting to label every kind of new software methodology as “Service-Oriented Architecture”, Orbitz is running a system consisting of thousands of services, with a high degree of self-configuration and self-healing. It’s a compelling vision. And it’s happening right now. (Shameless plug: I used Orbitz to book last week’s vacation trip to England.)
So what will all of these thousands of application services be doing in the future? Another article in the same paper, Agents of change, looks at the current developments of autonomous agent software. (This is an area that I worked on some years ago; some of our thoughts are summarized here.) Agents represent a paradigm shift as fundamental as object orientation: from building software as a bunch of reactive services and wiring them up according to a fixed pattern, to creating a community of self-interested goal-driven agents that can negotiate with their peers to solve complex problems. (The anthropomorphism is inevitable.) What I find interesting is that the ideas apply at so many levels – to application business logic, as described in the article, but also to service lifecycle and systems management.
What links these two articles is that today the technologies are widely regarded as rocket science, or even science fiction. It’s tempting to hand-wave and assert that a little syntactic sugar and tool-building will allow us to transform these powerful techniques into Lego components for the journeyman programmer. Well, maybe. But we should also consider how they might be used to solve intrinsically complex problems – the kind of thing that today we don’t even try to tackle. One size definitely won’t fit all.
(The other thing that links them is that they describe how our customers are building the future today. And that’s a tactical business opportunity – right, Jonathan?!)