You are on page 1of 87

| 

Ô  

@ Introduction
@ JXTA Architecture
@ JXTA Concepts
@ JXTA Protocols
@ JXTA Search
î  | 

@ 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
î  | 

@ P2P is ?  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

    
î | 

@ 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:
6   

     

         
 



  


   
|   
 

@ 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
À  
@ 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)

   

@ It includes implementation of
integrated applications such as:
P2P instant messaging
document and resource sharing
entertainment
content management and delivery
P2P email systems
distributed auction systems

   
@ 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

 À   

@ Implementations that wish to be


JXTA compliant must implement all
of the JXTA Core specification

À  À  

@ Implementing these services will


provide greater interoperability and
functionality

 
| 
@ 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
|   
@ 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
|   

@ 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
|   
@ 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
@ ü 
    
 
  
|   
@ The core peer groups services provided by JXTA
Implementation:
    : for discovering resources such as peers, peer
groups, pipes and services, implements Peer Discovery Protocol
ÿ
    : used by current members to reject or accept
a new membership application
  : For example, a peer receiving the request
provides the requesting peers    and information about
the request being made to determine if the access is permitted
   create and manage pipe connections between the
peer group members, implements Pipe Binding Protocol
†    used to send generic query requests to other
peers (the status of service, state of a pipe endpoint) implements
Peer Resolver Protocol
ÿ    allow one peer to monitor other members of
the same group, implements Peer Information Protocol
 À  
@ 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)
 À  
@ Ônce 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. (*)
 À  
@ 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
 À     
@ 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
ÿ 
@ an abstraction, used to represent any piece of
that implements a G  in the JXTA
world, for example ³Network Services´
@ used to define the code to be executed
@ The   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
ÿ 
@ 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:
ÿ  primarily used to advertise the existence of a
behaviour
ÿ     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
ÿ 6    implementation of a given module
specification. There can be multiple implementation for a given
specification. (similar to implementation part of WSDL)
ÿ 

@ 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

!  À  
@ 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
| 
@ 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)
| 
@ 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
| 

] 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
| 
@     connects exactly two pipe
endpoints
@   connects one output pipe to
multiple input pipes. All propagation is within
the peer group
@    point-to-point pipes with
secure communication channel
ÿ
@ 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 SÔAP or XML-RPC can be used)
binary

   

@ 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

   
@ 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)

   
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
| 
   
6xs:element name="PA" type="jxta:PA"/>
6xs:complexType name="PA">
6xs:sequence>
6xs:element name="PID" type="JXTAID"/>
6xs:element name="GID" type="JXTAID"/>
6xs:element name="Name" type="xs:string" minÔccurs="0"/>
6xs:element name="Desc" type="xs:anyType" minÔccurs="0"/>
6xs:element name="Svc" type="jxta:serviceParams"
minÔccurs="0" maxÔccurs="unbounded"/>
6xs:sequence>
6/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
| 
   !" 
|   
   
6xs:element name="PGA" type="jxta:PGA"/>
6xs:complexType name="PGA">
6xs:sequence>
6xs:element name="GID" type="jxta:JXTAID"/>
6xs:element name="MSID" type="jxta:JXTAID"/>
6xs:element name="Name" type="xs:string" minÔccurs="0"/>
6xs:element name="Desc" type="xs:anyType" minÔccurs="0"/>
6xs:element name="Svc" type="jxta:serviceParam" minÔccurs="0"
maxÔccurs="unbounded"/>
6/xs:sequence>
6/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
ÿ  
   
6xs:element name="MCA" type="jxta:MCA"/>
6xs:complexType name="MCA">
6xs:sequence>
6xs:element name="MCID" type="jxta:JXTAID"/>
6xs:element name="Name" type="xs:string" minÔccurs="0"/?
6xs:element name="Desc" type="xs:anyType" minÔccurs="0"/>
6/xs:sequence>
6/xs:complexType>

@ MCID: module class Id


@ name: name of the module, used for search
@ Desc: description, used for search
ÿ  
   !" 
6jxta:MCA xmlns:jxta="http://jxta.org">
6MCID>
urn:jxta:uuid-
587B29A1AA9341FAA7C2BE16B2C05E6F05
6/MCID>
6Name>
JXTAMÔD:JXTA-EX1
6/Name>
6Desc>
Tutorial example to use JXTA module
advertisement Framework
6/Desc>
6/jxta:MCA>
ÿ À    
   
6xs:element name="MSA" type="jxta:MSA"/>
6xs:complexType name="MSA">
6xs:sequence>
6xs:element name="MSID" type="jxta:JXTAID"/>
6xs:element name="Vers" type="xs:string"/>
6xs:element name="Name" type="xs:string" minÔccurs="0"/>
6xs:element name="Desc" type="xs:anyType" minÔccurs="0"/>
6xs:element name="Crtr" type="xs:string" minÔccurs="0"/>
6xs:element name="SURI" type="xs:anyURI" minÔccurs="0"/>
6xs:element name="Parm" type="xs:anyType" minÔccurs="0"/>
6xs:element ref="jxta:PipeAdvertisement" minÔccurs="0"/>
6xs:element name="Proxy" type="xs:anyURI" minÔccurs="0"/>
6xs:element name="Auth" type="jxta:JXTAID" minÔccurs="0"/>
6/xs:sequence>
6/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: Ôptional Module Spec Id of a proxy module
@ Auth: Ôptional Module Spec Id of an authenticator module
ÿ À    
   
!" 
6jxta:MSA xmlns:jxta="http://jxta.org">
6MSID>
urn:jxta:uuid-
587B29A1AA9341FAA7C2BE16B2C05E6F95A4FB83225E40A1BC2C93D80A
3AAF1D06
6/MSID>
6Name>JXTASPEC:JXTA-EX16/Name>
6Crtr>sun.com6/Crtr>
6SURI>http://www.jxta.org/Ex16/SURI>
6Vers>Version 1.06/Vers>
6jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
6Id>

urn:jxta:uuid9CCCDF5AD8154D3D87A391210404E59BE4B888209A2
241A4A162A10916074A9504
6/Id>
6Type>JxtaUnicast6/Type>
6Name>JXTA-EX16/Name>
6/jxta:PipeAdvertisement>
6/jxta:MSA>
ÿ     
   
6xs:element name="MIA" type="jxta:MIA"/>
6xs:complexType name="MIA">
6xs:sequence>
6xs:element name="MSID" type="jxta:JXTAID"/>
6xs:element name="Comp" type="xs:anyType"/>
6xs:element name="Code" type="xs:anyType"/>
6xs:element name="PURI" type="xs:anyURI" minÔccurs="0"/>
6xs:element name="Prov" type="xs:string" minÔccurs="0"/>
6xs:element name="Desc" type="xs:anyType" minÔccurs="0"/>
6xs:element name="Parm" type="xs:anyType" minÔccurs="0"/>
6/xs:sequence>
6/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. Ôther 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
ÿ     
   
!" 
6jxta:MIA xmlns:jxta="http://jxta.org">
6MSID>urn:jxta:uuid-
DEADBEEFDEAFBABAFEEDBABE0000000102066/MSID>
6Comp>
6Efmt>JDK1.46/Efmt>
6Bind>V1.0 Ref Impl6/Bind>
6/Comp>
6Code>net.jxta.impl.peergroup.ShadowPeerGroup6/Code>
6PURI>http://www.jxta.org/download/jxta.jar6/PURI>
6Prov>sun.com6/Prov>
6Desc>
Default NetPeerGroup reference implementation.
6/Desc>
6/jxta:MIA>
| 
   
6xs:element name="PipeAdvertisment" type="jxta:PipeAdvertisment"/>
6xs:complexType name="PipeAdvertisement">
6xs:sequence>
6xs:element name="Id" type="jxta:JXTAID"/>
6xs:element name="Type" type="xs:string"/>
6xs:element name="Name" type="xs:string" minÔccurs="0"/>
6/xs:sequence>
6/xs:complexType>
@ Id: JXTA id
@ Type: unicast, unicast secure or propagate
@ name: name
| 
   !" 
6jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
6Id>
urn:jxta:uuid-
9CCCDF5AD8154D3D87A391210404E59BE4B888209A
2241A4A162A10916074A9504
6/Id>
6Type>
JxtaUnicast
6/Type>
6Name>
JXTA-EX1
6/Name>
6/jxta:PipeAdvertisement>
À 
@ 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 obtained after authentication (Membership Service)
@ Groups use authentication and credentials to control access and
enable security
 
  
 Ô  # 
@ 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.
† # | 
] 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)

|  
|  
@ 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)
|  
@ enable developers to build and deploy
interoperable services
@ ALL ARE ASYNCHRÔNÔUS
@ 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
| $  | 

@ 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
$  %  ÿ

] Type: 0, 1, 2
] Threshold: Max number of ads that each peer provide
] PeerAdv: ad of the requestor
] Attribute, Value: constraining the search space
$  %  !" 
6jxta:DiscoveryQuery>
6Type>26/Type>
6Threshold>16/Threshold>
6Attr>Name6/Attr>
6Value>*sidus*6/Value>
6PeerAdv>
<?xml version="1.0"?>
<!DÔCTYPE jxta:PA>
<jxta:PA xmlns:jxta="http://jxta.org">
<PID>
urn:jxta:uuid-
59616261646162614A7874615032503304BD268FA4764960AB9
3A5D7F15044503
</PID>
^^^     
  ^^^
</jxta:PA>
6/PeerAdv>
6/jxta:DiscoveryQuery>
|     | 

@ Ônce 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.
| †  | 
@ 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
†  %  ÿ
@ this message is used to send resolver query to the named handler on one or more
peers
6xs:element name="ResolverQuery" type="jxta:ResolverQuery"/>
6xs:complexType name="ResolverQuery">
6xs:all>
6xs:element ref="jxta:Cred" minÔccurs="0"/>
6xs:element name="SrcPeerID" type="jxta:JXTAID"/>
6!-- This could be extended with a pattern restriction -->
6xs:element name="HandlerName" type="xs:string"/>
6xs:element name="QueryID" type="xs:string"/>
6xs:element name="HC" type="xs:unsignedInt"/>
6xs:element name="Query" type="xs:anyType"/>
6/xs:all>
6/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
†  %  " 
†  † ÿ
6xs:element name="ResolverResponse" type="ResolverResponse"/>
6xs:complexType name="ResolverResponse">
6xs:all>
6xs:element ref="jxta:Cred" minÔccurs="0"/>
6xs:element name="HandlerName" type="xs:string"/>
6xs:element name="QueryID" type="xs:string"/>
6xs:element name="Response" type="xs:anyType"/>
6/xs:all>
6/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.
|   |  ||

@ used by peers to bind a pipe ads to


pipe endpoints
| †  ÿ

@ 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
!  †  |  !†|

@ enable one peer to find route


information from relay peers
† # | 

@ responsible for propagating


messages within a peer group
@ RVP is used by PRP and PBP to
propagate messages
† # 
   
@ 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
$  À  & !" 
@ 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
ÿ  À  & !" 

@ The service allows a peer to


establish an identity within a peer
group
@ Ônce identity established, a
credential is available that allows
the peer to prove that it rightfully
has that identity

À  & !" 
@ publish Module Class ad
@ add a pipe ad to Module Spec ad and
publish it
@ Ôther 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)

À 

JXTA Search is an open network framework


based on the JXTA framework for
distributed information routing that extends
the JXTA framework
Ô 

@ 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

À   
@ 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:
à  6       JXTA peers
or Web Servers responds to QRP requests
à     JXTA peers or Web
sites with HTTP client interface to JXTA
¦ à  
handles message routing
between consumers and providers. Providers
register to hub

À   
@ 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

À   

@ 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

  

  
@ 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

"   
$   
@ 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
%  
@ 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
%  

@ 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
%†|%  ÿ
6request xmlns= http://search.jxta.org
xmlns:t= http://search.jxta.org/text
query-uuid= 1C8DAC3036A811D584AEC2C23
query-space= http://search.jxta.org/text >
6t:query>
6t:text>
sunw
6/t:text>
6/t:query>
6/request>

Meaning should be anything


%†|† ÿ
6responses xmlns= http://search.jxta.org
xmlns:t= http://search.jxta.org/tickerqs
query-uuid= 1C8DAC3036A811D584AEC2C23 >
6response>
6data>
6t:ticker>
SUNW
6/t:ticker>
6t:price>
20.59
6/t:price>
6/data>
6/response>
6/responses>
%†|†    
6register xmlns= http://search.jxta.org >
6title>JXTA Stock Quote Provider6/title>
6link>http://search.jxta.org6/link>
6description>Given a ticker symbol, returns a 15-minute delayed quote
6/description>
6!± the URL or pipe ID of the provider -->
6query-server>jxta://
59616261646162614A757874614D5047CF403C5700D44AE68F9FB626DD3F18E500000
0000000000000000000000000000000000000000000000000000000401
6/query-server>
6query-space uri="http://search.jxta.org/text">
6predicate>
6query>
6text>sunw aol orcl6/text>
6/query>
6/predicate>
6/query-space>
6/register>
†  
†  

@ Ôpens 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
ÿ

@ The messages are arbitrary XML,


enabling the network to provide
implicit support for any XML
protocol to be carried as payload
À     
@ CÔRE: JXTA Protocols are
implemented for Perl, C, Python,
Smalltalk, Tini
@ Services: XML-RPC for JXTA, SÔAP
for JXTA, p2p-email, RMI for JXTA,
Web services for JXTA.. (Most of
them are not complete) (optional
P2P services that run on the JXTA
Platform)

You might also like