Embed Size (px)
Citation preview
Project JXTA
Outline
Introduction JXTA Architecture JXTA Concepts JXTA Protocols JXTA Search
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
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
JXTA Virtual Network
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)
JXTA Architecture
JXTA Architecture Layers
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
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)
Application Layer
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 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
JXTA Core Specification
Implementations that wish to be JXTA compliant must implement all of the JXTA Core specification
JXTA Standard Services
Implementing these services will provide greater interoperability and functionality
JXTA Concepts
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
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
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
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
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
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)
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. (*)
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
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
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
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)
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
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
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)
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
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
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
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
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
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)
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
Peer Advertisement
<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:sequence>
</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
Peer Advertisement (Example)
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
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
Module Class Advertisement (Example)
<jxta:MCA xmlns:jxta="http://jxta.org"><MCID>
urn:jxta:uuid-587B29A1AA9341FAA7C2BE16B2C05E6F05</MCID><Name>
JXTAMOD:JXTA-EX1</Name><Desc>
Tutorial example to use JXTA module advertisement Framework</Desc>
</jxta:MCA>
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
Module Specification Advertisement (Example)
<jxta:MSA xmlns:jxta="http://jxta.org"><MSID>
urn:jxta:uuid-587B29A1AA9341FAA7C2BE16B2C05E6F95A4FB83225E40A1BC2C93D80A3AAF1D06</MSID><Name>JXTASPEC:JXTA-EX1</Name><Crtr>sun.com</Crtr><SURI>http://www.jxta.org/Ex1</SURI><Vers>Version 1.0</Vers><jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
<Id>
urn:jxta:uuid9CCCDF5AD8154D3D87A391210404E59BE4B888209A2241A4A162A10916074A9504
</Id><Type>JxtaUnicast</Type><Name>JXTA-EX1</Name>
</jxta:PipeAdvertisement></jxta:MSA>
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
Module Implementation Advertisement (Example)
<jxta:MIA xmlns:jxta="http://jxta.org"><MSID>urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000010206</MSID><Comp>
<Efmt>JDK1.4</Efmt><Bind>V1.0 Ref Impl</Bind>
</Comp><Code>net.jxta.impl.peergroup.ShadowPeerGroup</Code><PURI>http://www.jxta.org/download/jxta.jar</PURI><Prov>sun.com</Prov><Desc>
Default NetPeerGroup reference implementation.</Desc>
</jxta:MIA>
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
Pipe Advertisement (Example)
<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org"><Id>
urn:jxta:uuid-9CCCDF5AD8154D3D87A391210404E59BE4B888209A2241A4A162A10916074A9504</Id><Type>
JxtaUnicast</Type><Name>
JXTA-EX1</Name>
</jxta:PipeAdvertisement>
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
Network Architecture
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.
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)
JXTA Protocols
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)
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
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
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
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="http://jxta.org"><PID>
urn:jxta:uuid-
59616261646162614A7874615032503304BD268FA4764960AB93A5D7F15044503
</PID>... remainder omitted for brevity ...</jxta:PA>
</PeerAdv></jxta:DiscoveryQuery>
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.
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
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
Resolver Query (example)
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.
Pipe Binding Protocol (PBP)
used by peers to bind a pipe ads to pipe endpoints
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
Endpoint Routing Protocol (ERP)
enable one peer to find route information from relay peers
Rendezvous Protocol
responsible for propagating messages within a peer group
RVP is used by PRP and PBP to propagate messages
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
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
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
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)
JXTA Search
JXTA Search is an open network framework based on the JXTA framework for distributed information routing that extends the JXTA framework
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
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
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
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
Architecture
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
An example network
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
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
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
QRP (Query Message)
<request xmlns= http://search.jxta.orgxmlns:t= http://search.jxta.org/textquery-uuid= 1C8DAC3036A811D584AEC2C23query-space= http://search.jxta.org/text >
<t:query><t:text> sunw</t:text>
</t:query></request>
Meaning should be anything
QRP (Response Message)
<responses xmlns= http://search.jxta.orgxmlns:t= http://search.jxta.org/tickerqsquery-uuid= 1C8DAC3036A811D584AEC2C23 >
<response><data> <t:ticker> SUNW </t:ticker>
<t:price> 20.59 </t:price></data>
</response></responses>
QRP (Registration)
<register xmlns= http://search.jxta.org ><title>JXTA Stock Quote Provider</title><link>http://search.jxta.org</link><description>Given a ticker symbol, returns a 15-minute delayed quote</description><!– the URL or pipe ID of the provider --><query-server>jxta://
59616261646162614A757874614D5047CF403C5700D44AE68F9FB626DD3F18E5000000000000000000000000000000000000000000000000000000000000401</query-server><query-space uri="http://search.jxta.org/text"><predicate><query><text>sunw aol orcl</text></query></predicate>
</query-space></register>
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
Messages
The messages are arbitrary XML, enabling the network to provide implicit support for any XML protocol to be carried as payload
Some implementations
CORE: JXTA Protocols are implemented for Perl, C, Python, Smalltalk, Tini
Services: XML-RPC for JXTA, SOAP 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)
