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.