The Chaupal Container for JAVA P2P applications

If you are a seasoned OSGI developer, you may have noticed that the bundle project that was made, is almost identical to a regular OSGI bundle. The only changes to regular plugin-project is that:

• The Activator derives from net.jp2p.chaupal.activator.Jp2pBundleActivator
• A JP2P-INF folder has been made with a jp2p-1.0.0.xml file in it.

These two features make a Chaupal JP2P project! Behind the scenes, the activator is busy checking the OSGI container for bundles that contain the resources that are defined in the jp2p XML file, and when it finds all the required resource, it creates a jp2p container that will hold these resources.

If you are a seasoned JXTA developer, you may also notice that the project actually represents a JXTA^TM Rendezvous Service.In Chaupal, the functionality provided by JXTA^TM is transformed in a format that the Chaupal JP2P container can understand (and parse). In fact, the Chaupal JP2P container is little more than a light-weight OSGI wrapper around the core JXTA^TM  functionality. You may wonder why we decided to take this approach and not embed the JXTA^TM classes in a more straightforward fashion.

There are a number of reasons for doing so:

1. The Chaupal team was facing a licensing problem with the JXTA^TM code, since Oracle bought SUN and support for JXTA^TM was discontinued. By developing a new container in which JXTA^TM could be 'plugged in', we were able to utilise the existing functionality, but still develop under an Apache 2.0 license.
2. JXTA^TM  is, from a developer's perspective, basically less a matter of programming and more one of configuring a peer-to-peer node. Most developers will use very comparable configurations, and only start their programming when messages are relayed throughout the network. By using XML, this practice is enforced.
3. From a configuration perspective, the NetworkManager and NetworkConfigurator classes are not really different than, say a PeerGroup or a DiscoveryService. The Chaupal container considers all these to be JP2P services,, which allows for a more versatile manner of configuring your P2P network
4. The JXTA^TMspecifications were made prior to the rise of social media and new connection structures, such as web sockets. The Chaupal container is more extensible, because it uses the highly modular approach of OSGI.

In order to get a feel for the Chaupal approach, open the jp2p-1.0.0.xml file in an editor. Eclipse has a very good editor hidden in the Web, XML, JavaEE and OSGI Enterpise section of the Luna update site, so you may want to install this software first:
       

•  Help -> Install new software
• Select the  'Luna' repository  and choose the Eclipse Editors and Tools from the section mentioned above

Restart Eclipse and open the XML file with the provided XML Editor:

<?xml version='1.0' encoding='UTF-8'?>
<jp2p-container id="org.chaupal.rdv" name="RDV" auto-start="true">
  <properties>
    <home-folder>${user.home}/.jxta/${bundle-id}</home-folder>
  </properties>
  <persistence-service context="chaupal"/>
  <network-manager clear-config="true">
    <properties>
      <config-mode>RENDEZVOUS</config-mode>
      <peer-id create="true" persist="true"/>
    </properties>
    <network-configurator>
       <properties></properties>
       <tcp>
         <properties>    
            <port>9715</port>
            <incoming-status>true</incoming-status>
            <outgoing-status>true</outgoing-status>
         </properties>
       </tcp>
       <http>
         <properties>    
            <port>8081</port>
            <incoming-status>true</incoming-status>
            <outgoing-status>true</outgoing-status>
         </properties>    
       </http>
       <multicast enabled="true"/>
    </network-configurator>
  </network-manager>
</jp2p-container>

JXTA developers will immediately see the familiar outlines of a very common Rendezvous configuration. In fact, it is one of the first examples which is presented in the book Practical JXTA II by Jérôme Verstrynge. However, with a few modifications! Let's examine the code above a bit closer:

<?xml version='1.0' encoding='UTF-8'?>
<jp2p-container id="org.chaupal.rdv" name="RDV" auto-start="true">
  <properties>
    <home-folder>${user.home}/.jxta/${bundle-id}</home-folder>
  </properties>
  <persistence-service context="chaupal"/>
</jp2p-container>

The first few lines of the jp2p file (you can actually run this without problems, try it!) has no relationships with any  JXTA^TM code whatsoever. The code tells the system to:

• Create a JP2P container
• 'Auto start' it, so that the services are activated when they are parsed successfully
• Use a folder called ".jxta/org.chaupal.rdv" in the user section of your computer's operating system
• Persist properties using a service of context 'chaupal', which basically means that the OSGI preferences are used.

It may be clear that JXTA^TMs NetworkConfigurator will use this location, so it is no longer available there. Instead, Chaupal takes care that the load and save configuration of the NetworkConfigurator use the locations provided by the configuration file. The other settings are rather straightforward for JXTA^TMdevelopers. If you are new to JXTA^TM, you can read the section "Jack the Rendezvous peer" in Jérôme Verstrynge's book. You will see that the JP2P configuration file is a representation of the settings that are coded there.