Why we chose JXTA

In my last blog posting, I talked about why we decided to build Kerika using Java, and how that experience turned out for us.

The other key decision that we made mid-way through our product development was to switch from a traditional client-server model targeting large enterprises to a more flexible, inexpensive peer-to-peer system that could be made available as a inexpensive subscription service.

We concluded that we had a better market opportunity among small professional services firms than with the Fortune 500, since the latter would have entailed much higher development costs, a much longer sales cycle, a much larger support organization, and much more competition. In other words, much of everything that we wanted to avoid!

For the peer-to-peer networking, we turned to JXTA, another open-source technology that had originally been developed by Sun Microsystems (under the guidance of the great Bill Joy, no less!) There were several reasons for using JXTA:

1. The overall architecture made a lot of sense: in fact, we had independently designed our own peer-to-peer architecture along the same lines before finding out about JXTA, such as using rendezvous and relay serversto implement a hybrid rather than pure peer-to-peer network.
   
   A pure peer-to-peer network is rarely practical in collaboration scenarios, since communication cannot take place unless both parties are online at the same time. We wanted to connect people working in different time zones, or simply according to different work schedules, so a hybrid peer-to-peer architecture was important, with a storage server kicking in automatically when you need to send messages to a team member who isn't online.
   
   The hybrid P2P architecture gives Kerika's users the best of both worlds: P2P's ability to quickly transfer large files directly from one computer to another, when both parties are online, and the store-and-forward reliability of email and other client-server systems.


2. JXTA was written entirely in Java, which meant we would have an easier integration job than if we had chosen a different protocol, such as Jabber, and the Java implementation also meant we could stay true to our cross-platform vision for Kerika.


3. JXTA looked like it could better handle large files and more diverse message types than other protocols, which was important for Kerika. JXTA's weakest point was in handling voice traffic, but this was not a design feature for Kerika so this weakness was not very relevant.
   

After hearing from our users, during our beta trials last year, that privacy was an important consideration, we went one step further and packaged up our storage server for use by our customer – at no additional cost. This enables our users to create private networks, i.e. a ring of trust that secures their data more thoroughly than they can get from any Web 2.0 free service like those from Google.