I'm surprised nobody here is talking about JXTA...
For all its flaws (and I'd like to go over some of those, below), JXTA is quite significant - if only for Sun's realisation that decentralised systems are a wide-reaching new paradigm for systems-building. But, for peple on this list, is it something you'll plan to use?
I posted my initial impressions to groovelog,
and they need some revision or at least justification.
I like the use of XML throughout jxta, but it's a very half-hearted effort. When the wire data protocol is "nearly XML but not", and endpoints are not expected to contain a parser, then the whole system can't take advantage of XML's portability. From the jxta_spec.pdf, (p.6)
The representation on the wire of the JXTA peer endpoint messages is as follows. It is important to point out that the
message representation is not a well-formed and valid XML document. To improve efficiency, the intent is to NOT
require XML at the low-level peer endpoint message layer.
and (tech_overview.pdf p7, monstrous)
If the world decides to abandon XML tomorrow and uses YML instead, JXTA can be simply re-defined and re-coded
to use the YML format.
but on the other hand (spec, p.10)
All XML advertisements are strongly typed and validated using XML schemas. Only valid XML documents that
descend from the base XML advertisement types are accepted by peers supporting the various protocols requiring that
advertisements be exchanged in messages.
there's a very mixed message. To my mind, you either use XML or you don't. If you do use XML, then the XML specification takes responsibility for all the detail of byte-ordering, character encoding and so on. If endpoints don't require a conformant XML parser, the spec needs to say which character encodings are acceptable, whether internal and external entities can be used, whether whitespace is significant, and so on. Otherwise there's no chance of interop.
APIs vs protocols
I'm in the "standardise APIs as well as wire protocols" camp, because that's the level at which I want to build portable code. Does this matter?
Purposes of JXTA
What is JXTA for? Is it just a stronger backbone for gnutella (and infrasearch)? Is it a candidate foundation layer for distributed computing systems such as AppliedMeta? Is it a candidate for other p2p applications' transports, such as Groove? Is it intended as a generic p2p infrastructure layer? All the intentions seem to be for the last of these, but I don't think the spec bears this out.
What sort of interop is useful anyway, if everyone used JXTA for their abstraction of peers, peer groups and piped communications? Are application developers expected to extend the core services and hence only really interop with other peers which implement those extensions? The "pipes" part of jxta seems to me the most interesting. Is this really smart? Since the power lies in a service-based model, why doesn't JXTA leverage the SOAP or XML-RPC service protocols which already exist? Or, is jxta obsessing on the "pipes" model to the exclusion of a "services" model which the rest of the world is getting excited about?
A little more detail on the "generality" comments above. I find it hard to understand some of the spec's detail if it's meant to be very general.
Content, for example, is shared amongst group members, but then hacked to death with "Each content copy may reside on a different peer in the peer group. The only difference between the copies may be their encoding type (HTML or WML, for example). These copies will have the same ContentID". If you want to manage content, then why say that differently-formatted content can have the same canonical name? What counts as "different"? If I go applying arbitrary XSL transformations to content and re-advertising it with the same canonical ID, will content consumers really accept that?
Another little example: uptime. The ping response message has a mandatory field "uptime" (how long this peer has been alive). That's probably important in some scenarios, but I can't think of any. I would be more interested in "idle time" for instant messaging-capable peers; or "average load", or whatever.
And so it goes on. Depressing, really.
hpyle@... | +44 (0)20 8783 3592
http://www.agora.co.uk/ | http://groovelog.agora.co.uk/ | http://rendezvoo.net/