An Interview with Paremus' Robert Dunne from JavaOne 2007

---

The problem of error-handling is as old as the need to decide just how much margin of safety to provision for in a system. As software systems become increasingly heterogeneous, this question frequently comes up when relying on services over which a developer has little control: services that often come from the network, and that may appear or disappear at any time.

In this interview with Artima, Robert Dunne, principal developer at Peramus, distinguishes between static services, polite services, and impolite services, and discusses why it's so hard to deal with the latter:

You can have three levels of dynamicity. The first one is no dynamicity at all: everything is very static. [That's] the kind of thing you get these days in sort of pojo-like frameworks where, given your dependencies at start-up, there is a fixed set of dependencies...

There's another level, which is what you can encounter with OSGi: within a single VM, you have a number of services written by a number of different people that may be coming and going independently of each other. They detect each others' presence, and also detect a service's departure. These services are "polite" in that sense: you always get told when they arrive and when they go.

And then further down you've got distributed systems where there is a network in the way, and things may disappear without saying good-bye. There may be network failures, there may be temporary outages, and you don't have full information [of the cause]. So that's kind of an "impolite" environment, and a more difficult one to deal with.

Even to manage polite services, [that] is not something people are all that familiar with. The coming of things like Spring OSGi means that people really need to start thinking about these things a lot more. [Managing polite services] is just a question of keeping your eye out in the VM for some new party that's providing you something... The fact that things say good-bye means that you've got a level of certainty.

[Managing] impolite services is the tricky one. A lot of today's infrastructure doesn't acknowledge the existence of impolite services. Systems [that] have a static nature, you can't rely [on] in a distributed world. Our way of looking at distributed systems is that your infrastructure and your application better be at least as dynamic as the environment it wants to survive in... There are a number of things you might expect to change in your environment, and that you can code for. You can't code for everything, but within a wide range of things you can code for these scenarios. That's the level of dynamicity you're able to tolerate.

Dunne compared the level of dynamicity a system can tolerate to relying on the bus schedule to get to work each day:

If your assumption about the world is that there will be a bus along every day within a given range, then that's kind of a polite scenario, really. You're saying that you're not going to tolerate very much of a diversity, that this is how things are going to be.

If that's what you've coded for, but actually the bus may from time to time not come, then you've got problems—you're not going to get to work that day. So you're probably going to code for a wider range of things: [If] the bus doesn't come, call a cab. If the cab doesn't come, try to get there on your bike.

At some point you're going to hit a level at which you haven't coded for the dynamicity that's really there. There may be an earthquake. It's not reasonable for you to plan for that. There's always a trade-off.

Robert Dunne, principal developer at Paremus, talks about three levels of dynamicity. (5 minutes 10 seconds)

How do you decide what level of dynamicity you design for in your systems?

Post your opinion in the discussion forum.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.