1. Project JXTA

2. Outline Introduction JXTA Architecture JXTA Concepts JXTA Protocols
JXTA Search

3. What is Project JXTA?
JXTA is a set of open, generalized P2P protocols that allow any connected device on the network (from cell phone to PDA, from PC to server) to communicate and collaborate as peers.
Its goal is to develop basic building blocks and services to enable applications for peer groups
Platform, Programming Language, Transport Protocol independent
a framework with a set of standards that supports p2p apps
JXTA is not an application, it does not define the type of the applications

4. What is Project JXTA?
P2P is juxtaposed to client-server or Web-based computing
The JXTA protocols standardize the manner in which peers:
Discover each other
Self-organize into peer groups
Advertise and discover network services
Communicate with each other
Monitor each other
Hence, implementation is left to developer
The protocols can be implemented in Java, C/C++, Perl, etc.
The protocols can be implemented on top of TCP/IP, HTTP, Bluetooth, HomePNA, or other transport protocols
JXTA protocols defines the minimum required network semantic for peers to form/join a virtual network

5. JXTA Virtual Network

6. Why Project JXTA?
The primary goal is to provide a platform with basic functions necessary for a P2P network. (Mentioned earlier)
JXTA technology seeks to overcome potential shortcomings in many of the existing P2P systems:
Interoperability
Platform independence
Ubiquity (that is, any device with a digital heartbeat)

7. JXTA Architecture

8. JXTA Architecture Layers

9. Platform Layer (JXTA Core)
It encapsulates minimal and essential primitives that are common to P2P networking
discovery
transport (including firewall handling)
the creation of peers and peer groups
security primitives

10. Services Layer
It includes network services that may not be absolutely necessary for a P2P network, but are common in P2P environments:
searching and indexing
directory
storage systems
file sharing
distributed file systems
resource aggregation and renting
protocol translation
authentication
PKI (Public Key Infrastructure)

11. Application Layer
It includes implementation of integrated applications such as:
P2P instant messaging
document and resource sharing
entertainment
content management and delivery
P2P systems
distributed auction systems

12. JXTA Components (Brief)
JXTA network consists of interconnected peers
peers self-organize into peer groups that provide a common set of services
peers advertise their services. Advertisements enable other peers on the network how to connect to, interact with peer’s services
peers use pipes to send messages to one another. Pipes are similar to message queues (asynchronous and unidirectional message transfer)
messages are simple XML documents whose envelope contains routing, digest and credential information
Pipes are bound to endpoints, such as TCP/IP port and associated IP address

13. JXTA Core Specification
Implementations that wish to be JXTA compliant must implement all of the JXTA Core specification

14. JXTA Standard Services
Implementing these services will provide greater interoperability and functionality

15. JXTA Concepts

16. Peers any network device that implements one or more of JXTA protocols
each operates independently and asynchronously
publish one or more network interfaces for use with JXTA protocols
Each published interface is advertised as peer endpoint
Peer endpoints (TCP port of an IP address) are used to establish direct point to point connections

17. Peer Groups
a collection of peers that agreed upon a common set of services
peers may belong to more than one group
By default, the first group that is instantiated is Net Peer Group (All peers belong to this group)
JXTA protocols describe how peers may publish, discover, join and monitor peer groups; they do not dictate when or why peer groups are created
each group can establish its own membership policy

18. Peer Groups Search requests are propagated within the group
groups also form a hierarchical parent-child relationship, in which each group has one parent
The advertisement for the group is published in the parent group in addition to the group itself

19. Peer Groups A peer group provides peer group services
JXTA defines core set of peer group services and additional services can be developed
In order for two peers interact via a service, they must be both in the same group
JXTA Protocols specify the format for these peer group services
Each service implement one or more of the protocols

20. Peer Groups
The core peer groups services provided by JXTA Implementation:
Discovery Service: for discovering resources such as peers, peer groups, pipes and services, implements Peer Discovery Protocol
Membership Service: used by current members to reject or accept a new membership application
Access Service: For example, a peer receiving the request provides the requesting peers credentials and information about the request being made to determine if the access is permitted
Pipe Service: create and manage pipe connections between the peer group members, implements Pipe Binding Protocol
Resolver Service: used to send generic query requests to other peers (the status of service, state of a pipe endpoint) implements Peer Resolver Protocol
Monitoring Service: allow one peer to monitor other members of the same group, implements Peer Information Protocol

21. Network Services
A service is a capability running inside a peer group. The service may be running on all peers, or just a few within the group.
A service denotes a set of functions that a provider offers
A service can be widely accessible such that a peer can just use it or special code may be needed to access the service
There are multiple implementations of service
The process of finding, downloading and installing a service is similar to search for a Web page (get content, install plug-in)

22. Network Services
Once a service is installed and activated, pipes may be used to communicate with the service
Discovery service, routing service are example of some default services. Discovery Service provides access to Peer Discovery Protocol
Services implement one or more of the JXTA protocols
Services are always associated with a group
The services that a group support are listed in peer group ad
Difference from Web Services: you can download it and run it, you can invoke it from another place, it can be anything. (*)

23. Network Services
Peers cooperate and communicate to publish, discover and invoke network services
Peers discover services via Peer Discovery Protocol
Two levels of network services:
Peer Services: service is accessible only on the peer publishing that service. If peer fails, service also fails. Multiple instances can be run on different peers but published individually
Peer Group Services: composed of collection of instances (potentially cooperating each other) of the service on multiple peers. If one fails, collective service is not effected. The service is published as part of the peer group advertisement. When a new service is implemented it is added to the services list of the group

24. Network Services (Invocation)
Service invocation is outside the scope of JXTA
JXTA is designed to interoperate and compatible with any Web service standards: WSDL, uPnP, RMI
JXTA Protocols uses Module Ads but any other service description can be used

25. Modules
an abstraction, used to represent any piece of code that implements a behaviour in the JXTA world, for example “Network Services”
used to define the code to be executed
The code can be a Java class, a Java jar, a DLL, a set of XML messages or a script
For example, when joining a new group, the peer must instantiate group specific services. The modules framework enables the representation and advertisement of platform-independent behaviours, and allows peers to describe and instantiate any type of implementation of a behaviour

26. Modules Modules are definitions of services and applications
The module ads enable JXTA peers to describe a behaviour in a platform-independent way
The module abstraction includes:
Module Class: primarily used to advertise the existence of a behaviour
Module Specification: used to access a module. (Contains all the information to invoke the module). In the case of a JXTA enabled service, contains the pipe advertisement (because sending a message is enough to invoke it). There can be multiple specification for a given class. (similar to interface part of WSDL) defines network compatibility. documentation needed to create conforming implementations
Module Implementation: implementation of a given module specification. There can be multiple implementation for a given specification. (similar to implementation part of WSDL)

27. Modules Each of the three components have associated ads
e.g., JXTA Discovery Service:
unique ModuleClassID, identifying it as a discovery service – its abstract functionality
multiple specifications, one may use different strategies to achieve the discovery

28. JXTA-Enabled Services
services that are published using Module Spec Ad
A Module Spec Ad may specify the pipe ad that can be used by another peer to invoke the service
The service can be invoked remotely or first download the code then execute it
A Module Spec Ad may also contain references to two other services which can be an authenticator and local proxy for the service

29. Pipes Pipes are virtual connection between peers
Pipes are the JXTA abstraction of network connections. Pipes have names and exist independently in the peer group.
JXTA peers use pipes to send messages to one another
asynchronous, unidirectional message transfer
indiscriminative, support the transfer of any object
Pipe endpoints, input endpoint and output endpoint (different from peer endpoints which are available peer network interface, e.g. TCP port of an IP address)

30. Pipes
Peer and Pipe endpoints are bound dynamically at run time via Pipe Binding Protocol
This implies that a pipe can be moved around and bound to different peers, hence, when a peer is crashed, it can be replaced by another peer taking over the existing pipe to keep the communication going
I think, the dynamicity of the network can be handled in this way

31. Pipes
Applications use Pipe Service to create pipe endpoints associated with a pipe ad. The Pipe service uses pipe ad to identify the pipe and resolve the input and output endpoints

32. Pipes Point-to-point pipes: connects exactly two pipe endpoints
Propagate pipes: connects one output pipe to multiple input pipes. All propagation is within the peer group
Secure unicast pipes: point-to-point pipes with secure communication channel

33. Messages basic unit of data exchange
ordered sequence of named and typed contents (elements), thus a message is a set of name/value pairs
elements contain namespaces, name, type, signature, digest and content
content can be arbitrary type
two representations for messages:
XML (hence SOAP or XML-RPC can be used)
binary

34. Advertisements
All JXTA resources (peers, groups, pipes, services) are represented by advertisement (XML)
Peers discover resources by searching for their corresponding ads by Peer Discovery Protocol

35. Advertisements JXTA protocols define the following ads types:
Peer ad: name, peerID, available endpoints, run-time attributes, groupID (in JXTA Core)
Peer Groups ad: name, peerGroupID, description, specification, services, service parameters (in JXTA Core)
Pipe ad: id, type (propagate, etc.), describe the type of pipe
Module Class ad: existence of module class, name, description, ID (in JXTA Core)
Module Spec ad: (primary use) provide references to the documentation needed to create conforming implementations. (secondary use) to make running instances usable remotely, by publishing information such as pipe ad (in JXTA Core)
Module Impl ad: implementation of a specification. name, ModuleSpecID, code, package, parameters (in JXTA Core)

36. Advertisements
Content ad: describes content that can be shared in a peer group. file, byte array, code, process state
Peer Info ad: hold specific information about the current state of the peer, such as, inbound and outbound message count, time last message received, etc.
Rendezvous ad: describes a peer acts as rendezvous peer for a given group

37. Peer Advertisement PID: peerID GID: groupID Name: name
<xs:element name="PA" type="jxta:PA"/>
<xs:complexType name="PA">
<xs:sequence>
<xs:element name="PID" type="JXTAID"/>
<xs:element name="GID" type="JXTAID"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/>
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
<xs:element name="Svc" type="jxta:serviceParams" minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType>
PID: peerID
GID: groupID
Name: name
Desc: Description
Svc: Lists what the peer provides to the group services as data e.g., all accessible end-point addresses are published in association with the Endpoint Service, or the certificate is published with Membership service. These parameters are supplied to the services

38. Peer Advertisement (Example)

39. Peer Group Advertisement
<xs:element name="PGA" type="jxta:PGA"/>
<xs:complexType name="PGA">
<xs:sequence>
<xs:element name="GID" type="jxta:JXTAID"/>
<xs:element name="MSID" type="jxta:JXTAID"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/>
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
<xs:element name="Svc" type="jxta:serviceParam" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
GID: group ID
MSID: Specification ID that this group uses. The ID is used to locate a module that references the services the group uses
Name: name
Des: description
Svc: optional list of MCID. For example, services, e.g. Membership Service

40. Module Class Advertisement
<xs:element name="MCA" type="jxta:MCA"/>
<xs:complexType name="MCA">
<xs:sequence>
<xs:element name="MCID" type="jxta:JXTAID"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/?
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
MCID: module class Id
name: name of the module, used for search
Desc: description, used for search

41. Module Class Advertisement (Example)
<jxta:MCA xmlns:jxta="
<MCID>
urn:jxta:uuid-587B29A1AA9341FAA7C2BE16B2C05E6F05
</MCID>
<Name>
JXTAMOD:JXTA-EX1
</Name>
<Desc>
Tutorial example to use JXTA module advertisement Framework
</Desc>
</jxta:MCA>

42. Module Specification Advertisement
<xs:element name="MSA" type="jxta:MSA"/>
<xs:complexType name="MSA">
<xs:sequence>
<xs:element name="MSID" type="jxta:JXTAID"/>
<xs:element name="Vers" type="xs:string"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/>
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
<xs:element name="Crtr" type="xs:string" minOccurs="0"/>
<xs:element name="SURI" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Parm" type="xs:anyType" minOccurs="0"/>
<xs:element ref="jxta:PipeAdvertisement" minOccurs="0"/>
<xs:element name="Proxy" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Auth" type="jxta:JXTAID" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
CRTR: Creator
SUI: Spec URI that permits to retrieve a document containing the specification
Parm: Arbitrary parameters to be interpreted by each implementation
PipeAdvertisement: Pipe Ad used to communicate to the module
Proxy: Optional Module Spec Id of a proxy module
Auth: Optional Module Spec Id of an authenticator module

43. Module Specification Advertisement (Example)
<jxta:MSA xmlns:jxta="
<MSID>
urn:jxta:uuid-587B29A1AA9341FAA7C2BE16B2C05E6F95A4FB83225E40A1BC2C93D80A3AAF1D06
</MSID>
<Name>JXTASPEC:JXTA-EX1</Name>
<Crtr>sun.com</Crtr>
<SURI>
<Vers>Version 1.0</Vers>
<jxta:PipeAdvertisement xmlns:jxta="
<Id>
urn:jxta:uuid9CCCDF5AD8154D3D87A E59BE4B888209A2241A4A162A A9504
</Id>
<Type>JxtaUnicast</Type>
<Name>JXTA-EX1</Name>
</jxta:PipeAdvertisement>
</jxta:MSA>

44. Module Implementation Advertisement
<xs:element name="MIA" type="jxta:MIA"/>
<xs:complexType name="MIA">
<xs:sequence>
<xs:element name="MSID" type="jxta:JXTAID"/>
<xs:element name="Comp" type="xs:anyType"/>
<xs:element name="Code" type="xs:anyType"/>
<xs:element name="PURI" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Prov" type="xs:string" minOccurs="0"/>
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
<xs:element name="Parm" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
MSID: Module Spec ID, the specification being implemented
Comp: environment in which this implementation may be implemented
Code: in case of a java impl., it contains class name. Other cases it can contain entire code
PURI: Package URI, package containing the code
Prov: Provider
Desc: Description
Parm: arbitrary parameters to be interpreted by the implementation

45. Module Implementation Advertisement (Example)
<jxta:MIA xmlns:jxta="
<MSID>urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE </MSID>
<Comp>
<Efmt>JDK1.4</Efmt>
<Bind>V1.0 Ref Impl</Bind>
</Comp>
<Code>net.jxta.impl.peergroup.ShadowPeerGroup</Code>
<PURI>
<Prov>sun.com</Prov>
<Desc>
Default NetPeerGroup reference implementation.
</Desc>
</jxta:MIA>

46. Pipe Advertisement
<xs:element name="PipeAdvertisment" type="jxta:PipeAdvertisment"/>
<xs:complexType name="PipeAdvertisement">
<xs:sequence>
<xs:element name="Id" type="jxta:JXTAID"/>
<xs:element name="Type" type="xs:string"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Id: JXTA id
Type: unicast, unicast secure or propagate
name: name

47. Pipe Advertisement (Example)
<jxta:PipeAdvertisement xmlns:jxta="
<Id>
urn:jxta:uuid-9CCCDF5AD8154D3D87A E59BE4B888209A2241A4A162A A9504
</Id>
<Type>
JxtaUnicast
</Type>
<Name>
JXTA-EX1
</Name>
</jxta:PipeAdvertisement>

48. Security
JXTA peers operate in a role-based trust model, in which an individual peer acts under the authority granted to it by another trusted peer to perform a particular task
Five basic security requirements:
confidentially: content of the message is not disclosed to unauthorized (encryption and signed by certificate)
authentication: sender is who s/he claims to be (credentials)
authorization: the sender is authorized to send a message (credentials)
data integrity: message was not modified in transit (Message digest)
refutability: (encryption and signed by certificate)
A credential is a token, used to identify a sender, used to verify a sender’s right to send a message to a specified endpoint
A credential is obtained after authentication (Membership Service)
Groups use authentication and credentials to control access and enable security

49. Network Architecture

50. Network Organization
Peers may join or leave the network at any time and routes may change frequently
Four kinds of peer:
minimal peer: send receive message, does not cache ads, does not route messages (PDA or cell phone)
simple peer: send receive message, cache ads, reply to discovery request if it is in cache, do not forward the discovery request (most peers)
Rendezvous peer: in addition to simple peers, forward discovery messages. Any simple peer can configure itself as rendezvous. It has a list of other known rendezvous peers and a list of peers that are using it as rendezvous. It forward discovery request (if it can not found in its cache) to other rendezvous also to the peers that are using it. A message has a TTL of seven hops.
Relay peer: information about the routes to other peers and routes messages to other peers. A peer first look at its local cache for its route info, if it isn’t found, the peer asks relay peer. Relay peers spool messages for unreachable peers.

51. Rendezvous Peers
In JXTA 2.0 adv queries no more propagated to edge peers
A query is forwarded to an edge peer only when a matching index is found
The propagation in Rendezvous peers
SRDI is used by edge peers to index their adv on rendezvous peers
Rendezvous peer has a list of other rendezvous peers (RPV – Rendezvous Peer View)

52. JXTA Protocols

53. Protocols
Peer Discovery Protocol (PDP): advertise resources (peers, peer groups, services, pipes) and discover resources (in JXTA Standard Services)
Peer Information Protocol (PIP): obtain status info from other peers (in JXTA Standard Services)
Peer Resolver Protocol (PRP): enables peers to send generic queries to other peers, allows peer services to define and exchange any arbitrary information (in JXTA Core)
Pipe Binding Protocol (PBP): used by peers to establish pipes to others (in JXTA Standard Services)
Endpoint Routing Protocol (ERP): used by peers to find routes. route is an ordered sequence of relay peers (in JXTA Core)
Rendezvous Protocol (RVP): used by peers to propagate messages within a peer group (in JXTA Standard Services)

54. Protocols enable developers to build and deploy interoperable services
ALL ARE ASYNCHRONOUS
Each of them is independent of the others
A peer is not required to implement all of the JXTA protocols to be a JXTA peer
The PRP and ERP must be implemented by a peer to addressable

55. Peer Discovery Protocol
PDP is default discovery protocol
Custom discovery services can be implemented to leverage PDP
Rendezvous peers provide mechanism of sending requests from one known peer to the next

56. Discovery Query Message
Type: 0, 1, 2
Threshold: Max number of ads that each peer provide
PeerAdv: ad of the requestor
Attribute, Value: constraining the search space

57. Discovery Query Example
<jxta:DiscoveryQuery>
<Type>2</Type>
<Threshold>1</Threshold>
<Attr>Name</Attr>
<Value>*sidus*</Value>
<PeerAdv>
<?xml version="1.0"?>
<!DOCTYPE jxta:PA>
<jxta:PA xmlns:jxta="
<PID>
urn:jxta:uuid A BD268FA AB93A5D7F
</PID>
... remainder omitted for brevity ...
</jxta:PA>
</PeerAdv>
</jxta:DiscoveryQuery>

58. Peer Information Protocol
Once a peer is located, its capabilities and status is queried (such as network traffic)
First a ping message is sent to the peer, and peerinfo (uptime, peer ad, resource peerID, target peerID) message is returned in response.

59. Peer Resolver Protocol
permits the dissemination of generic queries to handlers within a peer group and identify responses
each query is addressed to a specific handler
The handler name defined the particular semantics of the query and its responses (handler names are the name of the module/service)
The query may be received by any number of peers in the group and processed if such a handler name is defined on that peer
PIP and PDP are built using PRP.
PRP uses Rendezvous Protocol to disseminate the queries
e.g., enables peers to define queries to find service information such as state of the service, the state of a pipe endpoint

60. Resolver Query Message
this message is used to send resolver query to the named handler on one or more peers
<xs:element name="ResolverQuery" type="jxta:ResolverQuery"/>
<xs:complexType name="ResolverQuery">
<xs:all>
<xs:element ref="jxta:Cred" minOccurs="0"/>
<xs:element name="SrcPeerID" type="jxta:JXTAID"/>
<!-- This could be extended with a pattern restriction -->
<xs:element name="HandlerName" type="xs:string"/>
<xs:element name="QueryID" type="xs:string"/>
<xs:element name="HC" type="xs:unsignedInt"/>
<xs:element name="Query" type="xs:anyType"/>
</xs:all>
</xs:complexType>
Cred: credential of the sender
HandlerName: destination of the query
SrcPeerId: requesting peer Id
QueryID: query Id
HC: specifies the number of hops the query has been through (incremented by each peer that forwards this query)
Query: Contains the query

61. Resolver Query (example)

62. Resolver Response Message
<xs:element name="ResolverResponse" type="ResolverResponse"/>
<xs:complexType name="ResolverResponse">
<xs:all>
<xs:element ref="jxta:Cred" minOccurs="0"/>
<xs:element name="HandlerName" type="xs:string"/>
<xs:element name="QueryID" type="xs:string"/>
<xs:element name="Response" type="xs:anyType"/>
</xs:all>
</xs:complexType>
jxta:Cred: The credential of the respondent.
HandlerName: Specifies how to handle the response.
QueryID: The query identifier of the query to which this is a response.
Response: The responses.

63. Pipe Binding Protocol (PBP)
used by peers to bind a pipe ads to pipe endpoints

64. Pipe Resolver Message
used by the Pipe Resolver to find an input pipe endpoint bound to the same pipe ad
In answer messages, all of the peers on which the input pipe is known to be bound

65. Endpoint Routing Protocol (ERP)
enable one peer to find route information from relay peers

66. Rendezvous Protocol
responsible for propagating messages within a peer group
RVP is used by PRP and PBP to propagate messages

67. Rendezvous Advertisement
describes a peer that acts as a rendezvous peer for a given group
these ads are published so that other peers that are looking for rendezvous peers can find them

68. Discovery Service (From Examples)
Creates an application, creates a pipe advertisement and opens an input pipe to that pipe, waits.. Another peer discover the pipe ad, creates an output pipe to the pipe..
It can be extended
Default discovery service parameters:
peerID: sender Id
type: peer, group or advertisement
attribute: attribute name to narrow the query (must match an element name in the associated XML document)
value: value of the attribute

69. Membership Service (From Examples)
The service allows a peer to establish an identity within a peer group
Once identity established, a credential is available that allows the peer to prove that it rightfully has that identity

70. JXTA Service (From Examples)
publish Module Class ad
add a pipe ad to Module Spec ad and publish it
Other peers discover the Module Spec ad and using the pipe ad they can communicate with the service (Ama gonderdigin mesajin icinde ne var. Bunu PRP ile belirleyebilirsin hatta WSDL de kullanabilirsin, sen kendin bu protocolleri uygulayan peerlar yaziyorsun)

71. JXTA Search
JXTA Search is an open network framework based on the JXTA framework for distributed information routing that extends the JXTA framework

72. Objective
to provide a common distributed query mechanism for devices effectively p2p-ing the Web via JXTA
Like our work on JADE. They wrapped JXTA peers

73. JXTA Search Network
Communication over the JXTA Search Network is via Query Routing Protocol
QRP defines mechanisms for sending, responding queries as well as meta-data for nodes in the network
consists of the following participants:
JXTA Search Information Providers: JXTA peers or Web Servers responds to QRP requests
JXTA Search Consumers: JXTA peers or Web sites with HTTP client interface to JXTA
JXTA Search Hub: handles message routing between consumers and providers. Providers register to hub

74. JXTA Search Network
Consumers send requests to the JXTA Search Network via the nearest JXTA Search hub
Hub decides which of the provider should receive the query
Hub sends the query to the provider, receives the responses and send them back to the consumer

75. JXTA Search Network
JXTA Search provides efficient mechanism for distributing queries across a wide network of peers (wide search)
Deep search that is the content in a particular peer is also handled

76. Architecture

77. Architecture JXTA Search Provider Service JXTA Search Consumer Service
JXTA Search Registration Service: sends requests for registration to the hub and maintains the registration file for the provider
JXTA Search Hub Service:
JXTA Search Router: routes queries, collects results and returns to the consumer
JXTA Search Resolver: matches queries to providers

78. An example network

79. Design Goals Simplicity: Any client and server can be incorporated
Structure: All queries to the JXTA Search Network are XML messages conforming to a queryspace in which providers register templates describing the structure of queries they are accepting
Extensibility: arbitrary queryspaces can be used
Scalability

80. Queryspaces
Like XML namespaces, queryspaces do not necessarily reference to the actual content, they are simply identifiers used by providers and consumers to find each other
JXTA Search protocol makes no assumptions about the syntax (no validation) or semantics of queryspaces

81. Queryspaces Queryspaces should incorporate:
Structure: DTD or XML-Schema
Semantics: Provider and Consumers must also agree on the meaning of exchanged messages
the protocol simply ensures that the provider receive queries that match their queryspaces

82. QRP (Query Message) <request xmlns= http://search.jxta.org
xmlns:t=
query-uuid= 1C8DAC3036A811D584AEC2C23
query-space= >
<t:query>
<t:text>
sunw
</t:text>
</t:query>
</request>
Meaning should be anything

83. QRP (Response Message)
<responses xmlns=
xmlns:t=
query-uuid= 1C8DAC3036A811D584AEC2C23 >
<response>
<data>
<t:ticker>
SUNW
</t:ticker>
<t:price>
20.59
</t:price>
</data>
</response>
</responses>

84. QRP (Registration) <register xmlns= http://search.jxta.org >
<title>JXTA Stock Quote Provider</title>
<link>
<description>Given a ticker symbol, returns a 15-minute delayed quote
</description>
<!– the URL or pipe ID of the provider -->
<query-server>jxta://
A D5047CF403C5700D44AE68F9FB626DD3F18E
</query-server>
<query-space uri="
<predicate>
<query>
<text>sunw aol orcl</text>
</query>
</predicate>
</query-space>
</register>

85. Router (JXTA Router) Opens an output pipe to the provider end point
Sends the message to the provider end point using the pipe
Accepts responses from providers on a dedicated input pipe

86. Messages
The messages are arbitrary XML, enabling the network to provide implicit support for any XML protocol to be carried as payload

87. Some implementations
CORE: JXTA Protocols are implemented for Perl, C, Python, Smalltalk, Tini
Services: XML-RPC for JXTA, SOAP for JXTA, p2p- , RMI for JXTA, Web services for JXTA.. (Most of them are not complete) (optional P2P services that run on the JXTA Platform)