PittJUG: JavaSpaces presentation

I went to my first Pittsburgh Java Users Group meeting tonight, the topic was JavaSpaces. Bob Namestka from Sun filled in admirably for a speaker who had a last-minute family emergency. Fortunately, he'd given a talk a few years ago on the same topic, so he was able to reuse his old slides ( available here) and talk quite smartly on them. I doubt I'd be able to do as well with any talk I gave four years ago :-).

JavaSpaces is an implementation of tuple spaces, which have quite a few fans, including a couple of the folks at Liberty Mutual. That they've been writing about spaces as the best thing ever made me interested, even though JavaSpaces (and Jini) have this monorail-ish feel about them as the perpetual technology of the future.

So, a few notes:

  • Sun has mismarketed spaces and space-based architectures, starting with the dismissal of Jini as a 'device thing' after the initial demo
  • Spaces: carved out a niche with financial services
  • Mostly prototypes so far (at least from Bob)
  • GigaSpaces: startup from Israel, large in financial services
  • JavaSpaces: runs on top of Jini, but you don't need to care about that
  • All Jini work being done under Apache River
  • Shared memory applications that allow you to easily (!) build distributed architectures; easily == four calls (read + read if exists, take + take if exists, write, notify)
  • Later: one more call, how to access the space
  • What's hard: latency (how is failure different from sloth?), memory access (local vs server), partial failure, concurrency
  • Two open implementations of spaces: RI is built for getting comfy with tech, scales up to 100K objects (Outrigger, sp?)
  • Dan Creswell: built Blitz on top of Outrigger
  • Some generic uses:
    • distributed cache
    • messaging (point to point, pub/sub)
    • parallel processing (building grids)
    • object load balancing (commercial: GigaSpaces)
  • how to get something from the space: give the space a template of an object you're looking for, get one back from the space
  • Space: isa Jini-enabled service, needs to register itself with a Jini lookup service (can be discovered via uni/multicast)
  • Objects you get out of the space can be transactional, and they can be leased (object will expire, gets re-requested from space)
  • Object mobility comes as part of the architecture, get live objects out of the space
  • Space isn't an object database or filesystem, more like shared memory
  • If an object lives in a space it needs to implement Entry interface. Real requirements: serializable, no-arg constructor, needs attributes
  • Data objects can be entries, but...
  • ...some people like to create wrappers for their data objects (still need to be serializable, same for properties, but they can be transient -- look that up)
  • Getting an object out of the space requires a template: get me something like this
  • Objects aren't manipulated directly in the space: you read it (or take it), modify it, then write it back (very REST-y)
  • Typical app: a Lease returned from the space.write() can be consolidated and managed (auto-renew)
  • read(): provide a template of attributes to find an object for; if there are multiple matches it picks an arbitrary one; attributes might specify a service operation, unique identifier, whatever
  • 2005 update: there are bulk read/write operations
  • read() blocks and can timeout, readIfExists() doesn't
  • take() blocks and can timeout, takeIfExists() doesn't
  • template matching is all or none, so you can't do t.setName( "Chr*" ), you need t.setName( "Chris" )
  • notify() takes a template, let me know when entries arrive matching that type
  • What happens if the client issues a notify() and then dies? Client needs to re-establish.