|By Janice J. Heiss, August 11, 2005|
Distributed systems such as the Internet are built on a few foundation protocols that standardize the way devices interact and communicate with each other, forming the Internet's common language.
Sun Microsystems' open source JXTA technology was designed to provide a set of standard protocols to extend today's Internet infrastructure and allow any connected devices on the network -- sensors, cell phones, wireless PDAs, PCs, and servers -- to self-organize and collaborate in a peer-to-peer (P2P) decentralized manner to create a deep and extended web.
"With JXTA, we are attempting to build -- or perhaps rebuild -- on top of the existing Internet a virtual Internet that returns the Internet to its original foundation: a highly decentralized, dynamic, and scalable network infrastructure," explains Bernard Traversat, chief architect of JXTA technology at Sun Microsystems.
The Internet is a 30-year-old technology that was initially designed to implement a system in which no centralized service would control any aspect of the network and that would survive a violent attack with its infrastructure intact. The birth of the Domain Name System (DNS) altered this model by establishing a centralized distribution of domain names that created a naming space through translation of symbolic names into IP addresses, along with a means for discovery of that space through hierarchical DNS servers. Unfortunately, DNS does not adequately support dynamic mappings, given that flushing a DNS entry may take days. In addition, few people are running DNS servers in their homes or on ad hoc public networks, leaving many computers without DNS entries.
DNS also introduced a naming resolution scheme on which the entire Internet now relies: the URL. The URL takes for granted the existence of a naming service that translates symbolic names into network addresses and provides, in most cases, a single point of failure by associating data with a unique network location.
In addition to DNS and URLs, several other factors centralize and limit the web:
The web has a flat structure under predefined root nodes (.net, .com, .edu, .org). The most searched level under the initial roots has a flat organization, with all companies at the same level, CompanyName.com, which makes searching very difficult. The organization and location of information is driven by the publisher, not by the information itself or by readers who could be providing information to other readers. Information is located where the publisher is located. The lack of self-configuring network domains means that a system administrator has to set up a number of network services (DNS, Dynamic Host Configuration Protocol [DHCP], proxy server, gateway).
Finally, the Internet lacks service guarantees. Everyone has equal access, without priority levels. There is low-level fault tolerance. When a portal crashes, for example, its information becomes unavailable even if the information exists somewhere else on the Internet.
"Clearly," observes Traversat, "some of the original concepts of the Internet have been forgotten: The web already suffers from too many viruses and denial-of-service attacks on its infrastructure. This is an economic concern as the world economy increasingly relies on the web infrastructure to function."
JXTA technology was designed to address many of today's Internet limitations and return control to the edge of the network, where it initially started.
The Internet has always been supported by communities of users. Its original supporters were the Department of Defense and the academic world. Then, business entities began using it for commercial purposes. Users organized their own Internet domains through ad hoc bulletin board services (BBS) to exchange information.
"JXTA virtual network domains are a dynamic entity," notes Traversat, "spontaneously composed of heterogeneous peers who publish, access, and update contents in a decentralized and self-organized way. Member peers can interact directly with each other without requiring a central mediating server." Within each peergroup, the peers may not all be equal. Some peers may be assigned or elect themselves to provide specific services to enable each virtual domain to operate. JXTA enables a multitude of these virtual Internet domains to be created and deployed for social, economic, or security purposes.
The design goal for the JXTA technology protocols has been to define a simple set of building blocks for the network in order to deploy universal, scalable, and highly available virtual domains and to allow developers to carve out their own virtual domains. The building blocks are generic enough to foster diversity. With JXTA technology, developers can customize and define their own network community rules and policies on membership, security, content, distribution, and so on. They can also publish and exchange virtually any type of content -- documents, services, credentials, code, data, and the like -- without limitation.
There is a need on the Internet to build network domains that function like both a cathedral and a bazaar. JXTA allows virtual network domains to organize their own content without imposing rigid and restrictive rules or centralized controls, so user communities can use centralized mechanisms when needed. Individual responsibility and individual decision making will allow communities to build themselves from the ground up. The intent of the building blocks is to specify the necessary and sufficient set of network semantics that will define the P2P domain platform.
"The JXTA protocols permit the creation of a multitude of virtual network domains on top of the existing physical network infrastructure of the Internet," says Traversat. "The JXTA virtual network allows all peers to exchange messages independently of their network locations. Messages are transparently routed, potentially traversing firewalls or NATs [network address translations], and using different transport and transfer protocols [TCP/IP, HTTP] to reach the receiving peers."
JXTA technology's virtual P2P network allows peers to communicate without needing to understand or manage complex and changing physical network topologies, thus allowing mobile peers to roam transparently from one network location to another. The JXTA virtual network standardizes the manner in which peers discover each other, organize themselves into peergroups, discover peer resources, and communicate with each other. The JXTA protocols are built on five network abstractions:
JXTA technology's addressing model is based on a uniform and location-independent logical addressing model. Every network resource -- peer, pipe, data, peergroup, and so on -- is assigned a unique JXTA ID. JXTA IDs are abstract objects enabling multiple ID representations to coexist within the same JXTA technology network. The reference implementation uses 128-bit random UUIDs, allowing each peer to generate its own IDs. A peer in the JXTA technology network is uniquely identified by its peer ID, which allows the peer to be addressed independently of its current physical IP address.
JXTA technology's logical addressing model introduces a fundamental indirection that separates a resource's identification from its location, allowing a variety of virtual mappings to be used to determine the resource's physical location. JXTA IDs enable a content-addressable network. A peer endpoint is associated with each peer ID, encapsulating all available physical network addresses for a peer. Peer endpoints are very much like business cards, listing ways to contact a person -- phone, fax, email address, and so on. When receiving a peer endpoint advertisement, another peer can select the most efficient way to communicate with that peer from the list of published peer endpoint addresses. Peers can publish different sets of endpoints within each virtual domain. They can also hide their address by publishing another peer or relay address. The relay peer is used to relay messages to that peer. A peer may expose a relay address to protect its address, and it may publish its IP address only to trusted peers.
Peers in the JXTA technology network self-organize into peergroups. A peergroup represents a dynamic set of peers that have a common set of interests and have agreed on a common set of policies regarding membership, content exchange, and the like. Each peergroup is identified by a unique peergroup ID. JXTA does not dictate when, where, or why peergroups are created. JXTA technology only describes how a peergroup is created, discovered, and joined. Users, service developers, and network administrators can dynamically create peergroups for scoping interaction between peers and for matching their application's demands.
JXTA technology recognizes three primary motivations for creating peergroups:
To create secure and protected Internet domains: Peergroups form logical regions whose boundaries limit access to nonmembers. A peergroup does not necessarily reflect the underlying physical network boundaries, such as those imposed by routers and firewalls. Peergroups virtualize the notion of routers and firewalls, subdividing the network into secure regions without respect to actual physical network boundaries, thus enabling JXTA peergroups to reach across multiple organization and firewall domains.
To create a scoping environment: Peergroups typically form and self-organize based on peers' mutual interests. Peergroups serve to subdivide the Internet into abstract regions, providing an implicit scoping mechanism to restrict the propagation of discovery and search requests.
To create a monitoring environment: Peergroups allow monitoring -- traffic inspection, accounting, tracing -- of peers for any purpose.
JXTA core peergroup services provide the basic functionality to support a peergroup's existence, publishing and discovering resources and exchanging messages. Peergroup creators can customize their peergroup services to match their peergroup requirements -- centralized versus decentralized, deterministic versus undeterministic, and so on.
All network resources in the JXTA technology network, such as peers, peergroups, pipes, and services, are represented by advertisements, which are language-neutral metadata structure resource descriptors represented as XML documents. JXTA standardizes advertisements for the following core JXTA resources: peer, peergroup, pipe, service, metering, route, content, rendezvous, peer endpoint, and transport.
Developers can subtype these advertisements to add unlimited additional metadata information to each resource description. For example, a web service advertisement will contain the associated Web Services Description Language (WSDL) document associated with the service. Advertisements can be used to describe virtually anything, including source code, script, binary, classes, compiled just-in-time (JIT) code, Java objects, and Enterprise JavaBeans technology.
JXTA technology uses a universal resource binding protocol called the resolver to perform all resolution operations found in traditional distributed systems, such as resolving a peer name into an IP address (DNS), binding a socket to a port, locating a service through a directory service (LDAP), or searching for content in a distributed filesystem (NFS). In JXTA technology, all resolution operations are unified under the simple discovery of one or more advertisements.
The JXTA protocols define a resolver protocol based on rendezvous superpeers. Rendezvous are peers that have agreed and have been authorized to participate in a Distributed Hash Table (DHT) network infrastructure that distributes edge advertisement indexes, that is, pointers to edge peers that have published the corresponding advertisement.
As the network self-organizes, new rendezvous peers enter the rendezvous DHT infrastructure transparently. Edge peers maintain a dynamic relationship with their rendezvous peers. JXTA uses a fully decentralized model in which resolver requests are dynamically routed across the DHT rendezvous infrastructure to peers that can answer the query. The index mapping is maintained across the entire rendezvous population, which route resolver queries. Only rendezvous peers are involved in propagating resolver queries. A query is forwarded to an edge peer only when a matching index has been found. As more peers join and more rendezvous are elected, more peers become available for holding range of the index space, allowing massive scaling of the rendezvous infrastructure and protecting against rendezvous failures.
Pipes are communication channels used to send and receive messages between peers. Pipes offer a virtual abstraction over the peer endpoints to create the illusion of virtual in and out connections that are not physically bound to specific peer locations. Pipes can connect one or more peer endpoints.
The pipe ends are referred as the input pipe, the receiving end, and the output pipe, the sending end. Pipes are published and discovered using pipe advertisements, and they are uniquely identified by a pipe ID. Pipe ends are dynamically bound to a peer endpoint at runtime by the resolver. Using the pipe abstraction, applications and services can transparently fail over from one physical peer endpoint to another in order to mask a service or peer failure or to access a newly published instance of a service. The pipe-binding process consists of searching and connecting the two or more ends of a pipe. When a message is sent into a pipe, the message is sent by the local output pipe to the destination input pipe currently listening to the pipe.
A point-to-point pipe connects two pipe ends with a unidirectional and asynchronous channel: an input pipe end that receives messages sent from the output pipe end. Additional information in the message payload, such as a unique ID, may be required to thread message sequences. The message payload may also contain a pipe advertisement that can be used to open a new pipe to reply to the sender.
A propagate pipe connects one output pipe to multiple input pipes. Messages flow into the input pipe ends from the output pipe end, also known as the propagation source. The propagate message is sent to all listening input pipe ends in the current peergroup context. This process may create multiple copies of the message. On TCP/IP, when the propagate scope maps an underlying physical subnet in a one-to-one fashion, IP multicast may be used as an implementation for propagate pipes. Propagate pipes can be implemented using point-to-point communication on transports that do not provide multicast.
Bidirectional, reliable, and secure pipe services and a socket service have been implemented on top of the core pipe services. Asynchronous point-to-point pipes can have ends that are connected to different peers at different times or not connected at all. Pipe advertisements can contain unique data-typed XML schema to describe the valid set of messages to be sent or received through a pipe.
JXTA technology enables a world in which billions of network services, all addressable on the Internet, will be able to discover and interact with each other in an ad hoc and decentralized manner through a multitude of virtual Internet domains.
The main focus of JXTA technology has been to build a highly scalable and resilient Internet-scale infrastructure. For instance, JXTA technology's decentralized P2P routing protocols provide the foundation to build a highly scalable search engine in which search queries get routed dynamically to the end peers that published the information. This is the inverse of Google's indexing model, in which queries get sent to a centralized index cache. Unfortunately, for every new page that Google indexes every day, 100 thousand new pages are created that Google does not index.
JXTA technology protocols can also be used to deploy a decentralized name service to discover dynamic web services. For an enterprise, the ability to establish and control a virtual web service discovery domain can be essential to creating practical web service deployments. Enterprises will significantly benefit from the ability to create and manage virtual web service collaboration contexts that can capture their transient business relationships. Current ways to discover web services are either too static or too centralized to scale to support dynamic web service deployments.
JXTA technology has matured to a point where network infrastructure providers are embracing JXTA technology's P2P network vision. In 1968, ARPA awarded the ARPANET contract to BBN. It took a couple of years for the commercial world to understand the value and leverage the Internet. In 2003, the Department of Defense awarded the U.S. Army's multibillion dollar Future Combat System (FCS) project to Boeing. Boeing selected JXTA technology as the foundation for the FCS network infrastructure. The FCS network infrastructure has a good chance of addressing many of today's Internet infrastructure problems and will bring the Internet back to its origin. It's only a matter of time until the commercial world realizes it.
On June 15, the JXTA technology community released three implementations of the JXTA protocols: JXTA-Java SE 2.3.4, JXTA-Java ME 2.0, and JXTA-C/C++ 2.2 releases. These three implementations are fully interoperable, enabling the deployment of a self-organizing, highly resilient, and scalable ubiquitous Internet P2P network on devices such as sensors, phones, iPods, PDAs, PCs, TVs, set top boxes, DVRs, servers, and supercomputers.