In this interview with Artima, Robert Dunne, principal software engineer at Paremus, discusses three levels of dynamism, and why it's so difficult to deal with "impolite" services.

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?

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.