JXTA extension

Design discussion on the upcoming JXTA/HTTP connector for Restlet 1.1

Open points - URI design

Future improvements

 - handle persistent HTTP connections, to reuse JXTA sockets that may be costly to create/recreate compared to TCP/IP sockets.

 - multi-cast client/server option

Notes

 - When the JXTA connector registers, it can specify the supported protocols (HTTP initially at least, maybe P2P2, P2MP too?). This will allow to engine to forward requests to it. We we should consider the case where JXTA/HTTP connectors are used in parallel with standard HTTP connectors as the framework won't be able to use both at the same time. This requires more thoughts to fully connect the dots :)

 - One JxtaReference class, subclass of our org.restlet.data.Reference class
   * to facilitate the formatting/parsing of JXTA URIs

 - Jerome: I'm working on a streamlined connector that will provide a HTTP client and a HTTP server with the minimal number of classes, reusing a maximum of Restlet concepts. From this point, we will progressively grow the connectors to handle more scenarios as envisioned with James.

Requirements from James

 - support varying content types (txt, xml, html, xmpp, etc)

 - support jxta socket client and server

 - support secure sockets using https protocol for cert exchange

 - support jxta multicast (this one will be fun, many-to-many)

 - scoping context groups, this will be new but given i worked on tomcat i like
it to servlet context

 - config various deployment models (adhoc, local net, wide are net)

Initial notes from James

jxta and dependency jars [note: go w/ nightly for now due to bug fixes]:

  http://download.jxta.org/build/nightly

    jxta-lib-YYYYMMDD.zip

      jxta.jar
      bcprov-jdk14.jar
      javax.servlet.jar [note: for relay service only]
      org.mortbay.jetty.jar [note: for relay service only]

  there are jars in meerkat ( http://meerkat.dev.java.net) that we may wish to incorporate over time,
  namely configuration and network management.

environment:

  jxta will need, by default, a directory (aka JXTA_HOME)  w/ which to cache data

operational modes:

  adhoc: local network multicast [note: we should start w/ this configuration option for ease of deployment]
  peer: consumer
  super peer: provisioner [note: rendezvous and/or relay services, see relay jar note above]

  a peer can change it's roles w/in varying groups over time

lifecyle:

  (re)configuration (JXTA_HOME, operation mode)
  network start
  group(s) join
  service(s) start
  service(s) stop
  group(s) resign
  network stop

jxta primitives:

  for this project we should focus at this time on:

    JxtaServerSocket (server)
    JxtaSocket (client)
    JxtaMulticastSocket (many to many)

    [note: UDP is emerging]

  we should focus on JxtaServerSocket and JxtaSocket initially noting that JxtaMulticastSocket will follow

  secure ssl/tls communcations can be established over JxtaSocket connections

    [note: i would like to consider classic http->https protocol support for jxta p2p credential exchange]

configuration:

  initially we can go for adhoc which will not require http/jetty jars and is easiest to configure and discover (on a local network)

  over time, we will incoproate other configuration/runtime operational modes

  we will operate in the NetPeerGroup (root group) of an application specific network

server/service:

  JxtaServerSocket(s) can be instantiated w/ a classical SocketAddress of which JxtaSocketAddress is one such implementation

  altrnatively and for JxtaMulticastSocket one can use jxta primitive advertisements and groups to instantiate a socket

  we should likely focus on JxtaServerSocket and JxtaSocket initially noting that JxtaMulticastSocket will follow

  server should be startable and then listen

  optimally a wide assortment of protocol content should be supported (eg html, text, xml, rest, xmpp, rtp, streaming, etc)

  server should be stoppable and restartable

client:

  JxtaSocket(s) can be instantiate w/ a classical SocketAddress of which JxtaSocketAddress is one such implementation

  client should be startable

  client should be able to be provided with and/or discover "server" peer(s)

  client should be establish a connection conveying a number of supported protocols with server peer(s)

application:

  it is envisioned that a jxta/restlet application will likely be both a client and a server although this model is not required

  further, over time, it is envisioned that an application will also want to provision a JxtaMulticastSocket service as this is a
  great means for ManyToMany communcations yet one can opt to communicate back to the inbound connection in a OneToOne
  fashion. a example application would be presence.

  also, peer crediential exchange is envisioned over time as well and it would be optimal to implement this in a standard fashion
  (eg http->http certificate exchange) vs application specific (see myjxta)

  jxta groups can provide for context scoping that aid in scale and can enfore credentialed membership. at this time we will assume
  our application operates in the NetPeerGroup (aka root group).

  one can join and/or create varying jxta networks, with an example being the default jxta "public network" (aka PubNet). we will
  create an application specific network at this time (more on this later).

api:

  the overall api should center around everything being accessible via URIs. meerkat uris include:

    p2pp://...    (OneToOne)
    p2mp://... (ManyToMany)
    p2pps://... (secure OneToOne, not yet implemented)

resources (i am a principal on the following projects):

  http://meerkat.dev.java.net (refactor exploring a restful jxta lib)

  http://blogs.sun.com/gonzo/entry/jxta_for_the_rest_of1 (reference entry)

  http://myjxta2.jxta.org <http://myjxta2.jxta.org>  (prototypical application, can use meerket over time)