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)
</ul>
- 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.
</ul>