JXTA

1. JXTA Anand Prabhakar

2. JXTA jux·ta·pose; v. tr. jux·ta·posed, jux·ta·pos·ing, jux·ta·pos·es. To place side by side, especially for comparison/contrast • JXTA is short for Juxtapose, as in side by side. It is a recognition that peer to peer is juxtaposed to client server or Web based computing -- what is considered today's traditional computing model.

3. Project JXTA • Started as a research project incubated at Sun Microsystems, Inc. under the guidance of Bill Joy and Mike Clary, to address the peer-to-peer space. • Objective was to build a small, lightweight platform as the foundation of all peer-to-peer systems

4. What is JXTA? • JXTA technology is a set of open, generalized peer-to-peer (P2P) protocols, defined as XML messages, that allow any connected device on the network ranging from cell phones and wireless PDA’s to PCs and servers to communicate and collaborate in a P2P manner.

5. Peers Any entity on the network implementing one or more JXTA protocols. A peer could be anything from a mainframe to a mobile phone or even just a motion sensor. A peer exists independently and communicates with other peers asynchronously.

6. Peer Groups Peers with common interests can aggregate and form peer groups. Peer groups can span multiple physical network domains.

7. Messages • All communication in the JXTA network is achieved by sending and receiving messages. These messages, called JXTA messages, adhere to a standard format, which is key to interoperability.

8. Pipes • Pipes establish virtual communication channels in the JXTA environment. Peers use them for sending and receiving JXTA messages. Pipes are deemed virtual because peers don't need to know their actual network addresses to use them. That is an important abstraction.

9. Services • Both peers and peer groups can offer services. A service offered by a peer individually, at a personal level, is called a peer service, a concept equivalent to centralization. No other peer needs to offer that service; if the peer is not active, the service might become unavailable.

10. Peer Group Services • Peer groups offer services called peer group services. Unlike peer services, these services are not specific to a single peer but available from multiple peers in the group. Peer group services are more readily available, because even if one peer is unavailable, other peers offer the same services.

11. JXTA Codats • Codat (Code/Data), in JXTA, means content that could be either code or data. Codats can be published, discovered, and replicated if necessary.

12. JXTA Advertisements • An advertisement publishes and discovers any JXTA resource such as a peer, a peer group, a pipe, or a codat. Advertisements are represented as XML documents.

13. JXTA Identifiers • Identifiers play a key role in the JXTA environment. They specify resources, not physical network addresses. The JXTA identifier is defined as a URN (Uniform Resource Name). A URN is nothing but a URI (Uniform Resource Identifier) that has to remain globally unique and persistent even when the resource ceases to exist.

14. World peer group • Every JXTA peer is, by default, a member of the world peer group. Each JXTA peer intrinsically knows the world peer group and can join this peer group, even if it can't find any other peers on the network. Even disconnected peers are members.

15. Net peer group • On a local network, the network administrators can usually configure a peer group that every peer on the network can join: the net peer group. This group resembles a DHCP (dynamic host configuration protocol) service. The net peer group provides peers with a global connectivity according to restrictions imposed by the administrators.

16. Rendezvous peers • A rendezvous peer is a special peer that stores information about other peers it knows, by caching these known peers' advertisements. Thus, a rendezvous peer can help peers discover other peers in the network. Rendezvous peers can also forward discovery requests to other rendezvous peers.

17. JXTA Endpoints • Endpoints are destinations on the network and can be represented by a network address. Peers don't generally use endpoints directly; they use them indirectly through pipes, which are built on top of endpoints.

18. JXTA Routers • Anything that moves packets around the JXTA network is called a JXTA router. Not all peers need to be routers. Peers that are not routers must find a router to route their messages.

19. XML in JXTA • The first step towards providing a universal base protocol layer is to adopt a suitable representation that a majority of the platforms currently available can understand. • XML is fast becoming the default standard for data exchange. • XML provides a universal, language-independent, and platform-independent form of data representation. • XML can also be easily transformed into other encoding. Hence, the XML format defines all JXTA protocols.

20. Benefits of XML in JXTA • In theory, JXTA can be independent of any format used to encode advertisement documents and messages. In practice,it uses XML as the encoding format, mainly for its convenience in parsing and for its extensibility. • If the world decides to abandon XML tomorrow and uses YML instead, JXTA can be simply re- defined and recoded to use the YML format.

21. More Benefits of XML in JXTA • Not all peer nodes must be able to parse and to create XML documents. A cell phone with limited resources can be programmed to recognize and create canned XML messages and participate in a network of peers. • JXTA uses a lightweight parser that supports a subset of XML. Work is being carried out towards normalizing this subset to be called Micro-XML.

22. Interoperability • JXTA is designed to enable interconnected peers to easily locate, communicate, participate in community-based activities, and offer services to each other seamlessly across different P2P systems and different communities. • Peer-to-peer systems are built for delivering a single type of services. For example, Napster provides music file sharing, Gnutella provides generic file sharing, and AIM provides instant messaging. This resembles the pre-browser Internet. JXTA aims to bring to the P2P world what the browser brought to the Internet.

23. Platform Independence • JXTA is designed to be independent of programming languages, system platforms, and networking platforms. • Most other P2P systems offer their features or services through a set of APIs that are delivered on a particular operating system using a specific networking protocol, often for a particular programming language.

24. Ubiquity • JXTA is designed to be implementable on any digital device, including sensors, consumer electronics, PDA’s, appliances, network routers, desktop computers, data-center servers, and storage systems. • Many P2P systems choose MS Windows as their target deployment platform to target the largest installed base and the fastest path to profit. The inevitable result is many dependencies in the system.

25. JXTA Architecture • Existing P2P software architectures were analyzed and a common layering structure at the conceptual level was depicted.

26. JXTA Protocols • JXTA has in a set of common protocols defined by the JXTA community as a foundation to build applications. • Designed with a low overhead, the protocols assume nothing about the underlying network topology over which an application that uses them is built.

27. Peer Discovery Protocol (PDP) • Peers use PDP to discover all published JXTA resources. Since advertisements represent published resources, PDP essentially helps a peer discover an advertisement on other peers. As the lowest-level discovery protocol, PDP provides a basic mechanism for discovery. Applications might choose to use higher-level discovery mechanisms. PDP serves as a low-level protocol over which higher-level discovery mechanisms can be built.

28. Peer Resolver Protocol (PRP) • On the network, peers send queries to other peers to locate some service or content. The Peer Resolver Protocol intends to standardize these queries' formats. With this protocol, peers can send generic queries and receive responses.

29. Peer Information Protocol (PIP) • PIP is used to ping a peer in the JXTA environment. A peer receiving a ping message has several options: It can give a simple acknowledgment, consisting only of its uptime. It can send a full response, which includes its advertisement. Or it can ignore the ping. Thus, there can be peers capable of receiving messages but not sending responses.

30. Peer Membership Protocol (PMP) Used for joining and leaving peer groups. This protocol recognizes four discrete steps used by peers • Apply: A peer interested in entering a group applies for a membership to the group membership authenticator. The authenticator responds by sending back an acknowledge message to the peer. • Join: After an apply, the peer can choose to join the peer group. • Renew: To update their membership information in the group, peers use the renew message. • Cancel: Peers can choose to cancel their peer group memberships.

31. Pipe Binding Protocol (PBP) • In the JXTA environment, peers use pipes to access services. A peer can bind to a pipe's end at runtime and access services. The peer can create a new pipe, bind to an existing pipe, and unbind from a pipe using the Pipe Binding Protocol.

32. Endpoint Routing Protocol (ERP) • This protocol helps a peer route messages to a destination. The ERP helps peer routers query other peer routers about available routes for sending messages. JXTA defines a core set of peer group services, a basic set of services required to create a fully functional JXTA network.

33. JXTA Core Services • Each core service implements one of the JXTA protocols for simplicity's sake. For example, the core Discovery Service is implemented over the Peer Discovery Protocol. • The other core services are Membership Service, Access Service, Pipe Service, Resolver Service, and Monitoring Service.

34. JXTA Content Manager The JXTA Content Manager Service, referred to as CMS, allows sharing and retrieving of content -- represented by a unique content ID --within a peer group. The CMS also features a content advertisement that provides metadata about the content. In addition, the service allows content management on the local peer. And it lets a peer browse and download content from remote peers.

35. JXTA Security Considerations The security requirements of a P2P system are similar to any other computer system. The dominant requirements are confidentiality, integrity, and availability. These translate into specific functionality requirements that include authentication, access control, audit, secure communication, encryption and non-repudiation.

36. JXTA Security Consideration Given that JXTA is defined around the concepts of peers and peer groups, one can envision a security architecture in which peer IDs and group IDs are treated as low-level subjects (just like uid and gid), codats are treated as objects (just like files), and actions are those operations on peers, peer groups, and codats.

37. JXTA Security Considerations • JXTA technology is neutral to cryptographic schemes or security algorithms. As such, it does not mandate any specific security solution. In such cases, at best, we have provided a framework where different security solutions can be plugged in.

38. JXTA Security Considerations JXTA provides the following security primitives: • A simple crypto library supporting hash functions (e.g., MD5), symmetric encryption algorithms (e.g., RC4), and asymmetric crypto algorithms (e.g., Diffie-Hellman and RSA). • An authentication framework that is modeled after PAM (Pluggable Authentication Module, first defined for the UNIX platform and later adopted by the Java security architecture).

39. JXTA Security Considerations • A simple password-based login scheme that, like other authentication modules, can be plugged into the PAM framework. • A simple access control mechanism based on peer groups, where a member of a group is automatically granted access to all data offered by another member for sharing, whereas non-members cannot access such data.

40. JXTA Promise • JXTA holds promise as a low-level platform for P2P application development. While the technology is in its early stages today, it is expected to mature over time to provide a robust, reliable framework for P2P computing. Because Java is the preferred language for applications designed for heterogeneous environments, it is the natural choice for P2P applications.

41. References • www.jxta.org • Project JXTA: A Technology Overview by Li Gong, • Sun Microsystems, Inc. • An Introduction On JXTA Shellby Ke Duan • The JXTA demo version is available at www.jxta.org