Project JXTA: Open P2P Architecture Platform (TS-2915), Tuesday
As I said earlier, JXTA has been
the most interesting thing so far. The Tuesday session was presented by
Bernard Traversat; I believe he’s the JXTA bigwig at Sun.
As a pronunciation note, everyone seems to say “Jux-tah,” not
“J-X-T-A.”
What is JXTA?
In short, JXTA is a framework and standard
for creating virtual peer to peer networks. Put another way, it’s an
abstract network layer to drape over other, physical networks to
enable networkable devices to talk to each other and manage their own
network interactions.
Sounds pie in the sky, right? Well, here’s a concrete example from
one of today’s (Wednesday) sessions,
Robust Distributed Applications with JXTA.
Soft Teams of Sensors
speakers (see below for more on that session), work with/for the US DoD. The DoD wants to reduce the human
involvement in “soft teams,” and use a bunch of robots instead. “Soft
Teams,” now are largely special ops folks, like SEALs, that go behind
enemy lines, setup a bunch of monitoring equipment, and then stay
there for days maintaining the sensor network, filtering the data (?),
and sending it back.
Loosely quoting the speakers, “the DoD wants to just drop in a
bunch of sensors, let them sort out networking with each other,
gathering information, and nominate one of them [or several] to send
the data back to the satellite.”
So, in this example, you have bunch of networkable devices that
need to talk to each other - in the most simplistic example, comparing
notes about what they’re sensing to double check each other - and we
certainly don’t have a physical network pre-installed and ready to
plug into.
You have the need, then, for an ad hoc peer to peer network:
you need the devices to discover each other, share
information, establish their own network, and provide fail-over
handling should any peer go down.
These are essentially the requirements that JXTA satisfies. It
doesn’t provide the implementation of the network (the underlying
layers do that), but it provides the structure of the network and
services the peers use for access to the network.
The astute among you, dear readers, will immediately recognize this
as the Sun pattern for design: don’t create the implementation,
create the design and framework to layer on top of the
implementation. From what I’ve seen, though, this is a choice one.
Comparison to Traditional Networks
The traditional
(current) network is basically hubs/routers and clients (compared to
the first generation, client-server): clients talk to each other, but
all their traffic goes through routers. At home, if I want to print from my
laptop I have to send the print job through my
router, which sends it to the printer. If the network was peer to
peer, the laptop would just talk directly to the printer.
The hubs-clients network, as the internet has proven, is actually
very good for many uses like web browsing, email, simple desktop apps, etc.
The problem, however, is that you must have your
network planned out a priori (some old philosophy speak that
several speakers like using which, in this context, basically just means “before hand”).
Using the example above, if I just put my laptop, my printer, and a
router in a room together, they still won’t be able to talk to each
other: they need me (or some really smart software) to tell each of
them how to talk to each other (usually over Ethernet/WiFi and
TCP/IP). Each device also needs to be told about each other.
JXTA networks don’t need this additional setup: devices
discover and figure out how to talk to each other. Of course, on a
deep code level, you’re really just auto-magic’ing all the
things you were doing in the hubs-client model. As
effort went into making this effortless.”
Enough with all that explanation. All of you probably know what a
p2p network is anyway.
Back to JXTA
First, JXTA is free and open source. As
Traversat said several times and emphasized over and over, Sun
realized that anything that’s going to be an infrastructure technology
(networking) must be free and open to be successful.
JXTA, like many things now-a-days, has an XML protocol; which is to
say that unlike, for example, SNMP which BER encodes data (making the
data unreadable to humans until it’s decoded), the
data is in “plain text.” Though, as many of you know, XML protocols
are often unreadable themselves.
Key JXTA Abstractions
- Peers - the networkable devices.
- Virtual Networks - the network, which doesn’t have to be
“physical,” that the peers form through JXTA. One important point
about the virtual network is that peers are given logicaladdressed, not physical. addresses. I take this to mean that a
peer can move from device to device. Through this, peers could
something along the lines of the anthropomorphic idea of viruses and
worms: a piece of software/application that moves from machine to
machine. - Advertisements - XML descriptors of the peers and what services
they provide. I assume that these “adverts,” as one of the BBN people
said, can also serve as generic envelopes for any
type of meta-data. Every ad is assigned a lifetime, and there’s some
grounds keeping handling for dead ads. - Decentralized Resource Discovery - there are several types of
peers (see below); those that help route traffic are called Rendezvous
peers. These “RDV”’s facilitates looking up other peers; that is, they
act as “ad servers,” do caching, and even provide indexes. RDV’s help
keep track of “where” edge peers are, and what they provide. Even
better, if the RDV doesn’t know what you want, it helps you find
other RDV’s. - Ad Hoc Peer Groups - peers can be grouped together to
create logical sets. Peer groups are used to established different
policies (about routing, searching, access, etc.). If I recall and
understood right, the policies are represented by ads. - Pipes - “very similar - in concept - to UNIX pipes.” A JXTA pipe
is just a generic conduit for peers to exchange data. If I
understood right, a pipe will follow a peer through it’s logical
address. That is, if peer A is talking to a peer through a pipe, and
peer A switches to a different machine, the pipe will follow the peer
to it’s new physical location.
Tyes of Peers
- Edge Peer - the classic client that produces and consumes data.
- Relay Peer - virtual routers; “landmarks,” that is, other peers use Relay Peers as known points in the network, e.g., “If you want to talk to me, talke to the landmark Relay Peer X.”
- Rendevous Peers - ad servers, caching, and indexing. This is different than Relay Peers in that actual network topology and information is stored in these peers…I think.
Those are essentially the main points. Despite my disjointed
writeup, it’s actually quite simple. JXTA doesn’t seem like much at
first, but it opens up new ways for apps to use networks and interact
with other apps over the networks (like BBN’s self organizing and
co-operating “soft team” of sensors above).
JXTA 2.1
As a final note, JXTA 2.1 was released not too long ago. It’s
“primarily a bug release,” but there’s some new “metering and monitoring”
features as well.
Building Robust Distributed Applications with Project JXTA (TS-1297), Wednesday
This was presented by some folks from BBN who’d been doing research and implementations for the DoD, the Coast Guard, Homeland Security, and a “Western regional airport.” Their main interest was using sensors to do security and detection, which makes their “clients” interest obvious. Their jobs sounded real fun, despite the chill of Big Brotherism that could sneak up on you.
For those not working on perimeter security, it’s important to think of “sensors” more broadly: anything that collects data and (to be useful) provides collected data to clients can be thought of as a “sensor.”
The core nugget of this session is summarized above with the “soft team of sensors” example. Here’s some interesting notes and quotes:
- Dana Moore recommended WorldOfEnds.com and “The Rise of the Stupid Networks”, which was cool to hear at such a big conference. I thought they were just obscure, late night surfing reading. He recommenced them, I’m guessing, because they help you get an idea of the type of “world” that peer to peer networking could enable and the business rules that exist in it, e.g., “All the nets value grows on it’s edges.” They’re good essays: read ‘em!
- Along the lines of the stupid networks, Moore said, “transport is guided by the needs of the data, not the network’s assumptions.”
- JXTA is quite interoperable: there’s C implementations, Perl, Python, Java, etc. The protocol is in XML, so interoperability is possible, vs., for example, RMI.
- Traditional sensor either send too much dumb data, burying the info you’re interested in, or send too little data. Moore gave an example of too much dumb data: net admins looking at system output on 10 vt100’s trying to detect a network intrusion.
- “Hypotheses” - it took me awhile to figure out the exact meaning of this old term in the JXTA context. The sensors/peers in the network have hypothi that roll up to global hypotheses. A “hypothesis” is something that a sensor thinks is true (according to the input it’s getting), e.g., “a vehicle just drove past me.” Each sensor/peer creates tons of these hypothesis, and tells it’s peers about them. Then, at a higher level, you programmatically compare all the hypothesis, and verify which ones are true; presumably, you run some business rules like, “70% of the sensors must have the same hypothesis for it to be ‘true.’” This was an interesting concept for verifying multi-source data about one event.
p2p Inseption and Elaboration Design Considerations
Lastly, here are some architectural considerations to sort out when doing p2p network/app design:
- Deployment constraints - e.g., physical terrain, like mountains and expected up time, drive requirements for hardware and power. In a more applicable setting, the type of network you’re deploying into might drive the policies and practices you establish: can your peers roam around the network as they please? Is the network reliable and stable? Does data need to be real-time? Etc.
- Anticipated operation sequences - though JXTA can enable a lot of synergistic interactions and lifecycles for your apps/peers, it’s still good to plan for chains of events that will commonly happen and what you’ll need to put into your peers, or even the way the peers interact to enable those “operation sequences.” For example, I’d think, if you were going to have a bunch of DB access, you might assign some peers the role of DB accessors, and you might make a policy that RDVs always know where a DB accessor peer is so that looking them up is fast. In the OO sense, this is the behavior of your network.
- Info processing paths - synchronous or asynchronous? That is, how will the information flow through your network? In the same way that anticipated operation sequences can drive the design, the how/where/what of the data can drive design. As always, from a high level, data and behavior are not so different.
- “Scalability, Scalability, Scalability.”
JXTA URLs
- JXTA.org - main JXTA site.
- SPIDAR - the BBN JXTA application.
- COUGAAR - recommended, and used, by the BBN guys.
As with an
post, here’s a fun quote to end with:
“Is there going to be a way to do all that Web application descriptor
crap [in RAVE]?”
“‘Web application descriptor crap’…I love that phrase.”
–Q&A at TS-3730
Comments 1
You might find this interesting: a startup’s perspective on using JXTA to develop a (pretty cool) P2P collaboration application: http://www.kerika.com/2007/06/why-we-chose-jxta.html
Posted 28 Jun 2007 at 5:58 PM ¶Post a Comment