The Trouble with JXTA
Subject:   sun's domination ploy and alternates to heavy XML-based protocol approaches
Date:   2001-05-04 07:26:14
From:   ceterusparibus

it was funny watching bill joy speak at the Jxta unveiling. he said something to the effect of, "just like tcp/ip provides the basis for the internet, and http does for the web, we would like to build jxta as the fundamental protocol for p2p systems"... innocent? not.

http and tcp/ip are completely open, not sponsored by corporations and very very simple. most people here would be familiar with http, which, especially in it's earlier versions, was extremely simple to implement and extremely lightweight. that's why these protocols rule the world today.

even today, you can implement a 15 line perl web server script for simple document delivery. you can choose to implement protocol subsets because the notion of a protocol request is not the same as that of a valid "document". using XML for a p2p network binds you to that notion, in addition to imposing overhead, which as an earlier poster said, is not optimal for scalability reasons.

it goes back to the argument, what is xml really good for? it's good for a lot of things, but maybe not as a data format for implementing light weight protocol messages. that's what p2p protocols have to support - their very nature is such that nodes cannot always be assumed to have high bandwidth connections to the internet.

as far as the ease of interoperability is concerned, this is just off the top of my head, but how about this:

instead of using XML and embedding parsers in every p2p client / server, implement a protocol any way you want. even simple, lightweight text messages without the overhead of XML. then, implement a module that binds each protocol primitive to an action - make the action map readable. for instance, in java, create a class that understands your simple protocol, and allows methodnames to be registered for each protocol primitive. you could then use reflections to load the appropriate actions (methods/classes, whatever) based on what message you receive.

for the more oft-used languages, one could even come up with either code templates, or a generation tool for this sort of module. then, i could implement an IM client and if your IM protocol represents messages with MSG <text here>
that's not a problem for me, because I've bound the msg display code in my client to be invoked whenever it receives that message. And, you may even publish your actionMap module for anyone to obtain and embed.

in short, don't worry about data representation and creating a standard way to represent all data (thus incurring ineffeciencies due to the necessary generality of this task), instead focus on providing easy ways for people to make your protocol actionable. that's what really matters. with technologies such as Java Reflections, now this protocol->method/action binding doesn't even have to be compile time, so there really is no argument against such an approach.

ceterus paribus