JavaSpaces and Agile Development

Today we had a lunchtime talk about JavaSpaces, which is a form of grid computing (this is a new thing for me, so if I get anything wrong, yell).

Grid computing is when a lot of computers are used to split up processing of a hard task. The SETI screensaver uses your CPU at home to form a big grid. If you want to draw a Mandlebrot fractal, you can parcel out the various bits to nodes in a grid to calculate (this is so easy that everyone uses it as an example). There are lots of ways in which grids can be implemented, and some implementations are better than others. Some of them push tasks out from an orchestrating machine. Others have nodes which pull their tasks out of memory space.

JavaSpaces uses this latter technique, and also shares the memory space amongst several different computers. While we were learning about this, we asked a lot of questions and began to form a picture of how a really good, robust grid would work.

  1. A good grid has redundancy in its memory store, so that if one node goes down another has the necessary information to continue.
  2. Some really good grids have nodes which work out when they’re being polled for information too often, and find another node which isn’t being used so much to share it with.
  3. A good grid will work out when a given task is killing nodes too often, and flag the task as something which needs fixing.
  4. A good grid will look for high-priority tasks to run first.
  5. A good grid runs transactionally, so that if a node fails to complete a task, it doesn’t break the grid. Instead the task stays on the list.
  6. Some really good grids accept that their nodes aren’t perfect (for instance, floating point arithmetic may differ from one hardware base to another). These grids use a voting system, so that the result of one machine is checked by others.

Can you see where I’m going with this?

There are a lot of parallels with Agile Development and collaboration between Agile developers.

  1. A good team will communicate, so that everyone knows what’s going on.
  2. On a good team, developers are encouraged to share information instead of hoarding knowledge. This reduces the bus factor.
  3. A good team will spot problems which kill their velocity and sort them out.
  4. A good team will take on the tasks which the customer has decided have the highest business value.
  5. On a good team, members won’t check in stuff that breaks the build. They’ll use version control so that if they do accidentally do something which breaks the build, they can roll back their changes and try again.
  6. On a good team, developers ask for help and accept it from other developers. They will pair together, and discuss possible solutions until they have an idea of which solution is best.

I wonder – is Agile naturally suited to this kind of development work? Does splitting things into manageable chunks lead to easier, more even development? Would developers communicate better if we were coding for a distributed system? If we developers lend out our brains, will we discover life beyond our world?

This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to JavaSpaces and Agile Development

  1. anonymous says:

    Javaspaces is an implementation of an architectural style called “blackboard”, “shared memory”, or “tuple spaces”.

    Javaspaces is not tied to grid computing however the architecture underlying the technology solves or makes easier to solve many of the problems inherent to grid computing.

  2. anonymous says:

    Grid computing is about scheduling stuff, (programs, commands, method calls etc), transparently across many resources and sharing those resources between multiple applications, business units etc. This is not necessarily parallel processing or splitting up a hard task across multiple resources.
    A JavaSpace is not a grid, but a shared associative memory area. Sure you can use JavaSpaces as a building block for a Grid, but a JavaSpace doesn’t know anything about resourcing, task failure, etc etc.


    A grid has redundancy …
    A grid will work out when a given task is killing nodes …
    A grid will look for high-priority tasks to run first.
    A grid runs task transactionally …

    If it doesn’t do these things it is not a grid let alone a “good grid”


  3. sirenian says:

    Heh. I shall pass your comments on to my lecturer. 🙂

  4. sirenian says:

    Thank you; I missed that in the talk. I have now looked up JavaSpaces, tuplespaces and Grid Computing, and have excellent definitions of all except the latter. Watch the next post…

  5. entropyjim says:

    Does splitting things into manageable chunks lead to easier, more even development?

    Clearly yes.

    Would developers communicate better if we were coding for a distributed system?

    I suspect that just because you’re coding for a given system, you’re not going to start acting like you’re a component of it 😉

    On a more serious note, cutting tasks up to run over a distributed architecture can be a hard problem (depending on what you’re actually doing). In my experience harder problems give more people a chance to get things wrong.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s