Project%20JXTA - PowerPoint PPT Presentation

Title: Project%20JXTA


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 email 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 peers 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

• ltxselement name"PA" type"jxtaPA"/gt
• ltxscomplexType name"PA"gt
• ltxssequencegt
• ltxselement name"PID" type"JXTAID"/gt
• ltxselement name"GID" type"JXTAID"/gt
• ltxselement name"Name" type"xsstring"
  minOccurs"0"/gt
• ltxselement name"Desc" type"xsanyType"
  minOccurs"0"/gt
• ltxselement name"Svc" type"jxtaserviceParams
  " minOccurs"0" maxOccurs"unbounded"/gt
• ltxssequencegt
• lt/xscomplexTypegt
• 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

• ltxselement name"PGA" type"jxtaPGA"/gt
• ltxscomplexType name"PGA"gt
• ltxssequencegt
• ltxselement name"GID" type"jxtaJXTAID"/gt
• ltxselement name"MSID" type"jxtaJXTAID"/gt
• ltxselement name"Name" type"xsstring"
  minOccurs"0"/gt
• ltxselement name"Desc" type"xsanyType"
  minOccurs"0"/gt
• ltxselement name"Svc" type"jxtaserviceParam"
  minOccurs"0" maxOccurs"unbounded"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• 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

• ltxselement name"MCA" type"jxtaMCA"/gt
• ltxscomplexType name"MCA"gt
• ltxssequencegt
• ltxselement name"MCID" type"jxtaJXTAID"/gt
• ltxselement name"Name" type"xsstring"
  minOccurs"0"/?
• ltxselement name"Desc" type"xsanyType"
  minOccurs"0"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• MCID module class Id
• name name of the module, used for search
• Desc description, used for search

41
Module Class Advertisement (Example)

• ltjxtaMCA xmlnsjxta"http//jxta.org"gt
• ltMCIDgt
• urnjxtauuid-587B29A1AA9341FAA7C2BE16B2C05E6F05
  
• lt/MCIDgt
• ltNamegt
• JXTAMODJXTA-EX1
• lt/Namegt
• ltDescgt
• Tutorial example to use JXTA module
  advertisement Framework
• lt/Descgt
• lt/jxtaMCAgt

42
Module Specification Advertisement

• ltxselement name"MSA" type"jxtaMSA"/gt
• ltxscomplexType name"MSA"gt
• ltxssequencegt
• ltxselement name"MSID" type"jxtaJXTAID"/gt
• ltxselement name"Vers" type"xsstring"/gt
• ltxselement name"Name" type"xsstring"
  minOccurs"0"/gt
• ltxselement name"Desc" type"xsanyType"
  minOccurs"0"/gt
• ltxselement name"Crtr" type"xsstring"
  minOccurs"0"/gt
• ltxselement name"SURI" type"xsanyURI"
  minOccurs"0"/gt
• ltxselement name"Parm" type"xsanyType"
  minOccurs"0"/gt
• ltxselement ref"jxtaPipeAdvertisement"
  minOccurs"0"/gt
• ltxselement name"Proxy" type"xsanyURI"
  minOccurs"0"/gt
• ltxselement name"Auth" type"jxtaJXTAID"
  minOccurs"0"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• 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

43
Module Specification Advertisement (Example)

• ltjxtaMSA xmlnsjxta"http//jxta.org"gt
• ltMSIDgt
• urnjxtauuid-587B29A1AA9341FAA7C2BE16B2C05E6F95
  A4FB83225E40A1BC2C93D80A3AAF1D06
• lt/MSIDgt
• ltNamegtJXTASPECJXTA-EX1lt/Namegt
• ltCrtrgtsun.comlt/Crtrgt
• ltSURIgthttp//www.jxta.org/Ex1lt/SURIgt
• ltVersgtVersion 1.0lt/Versgt
• ltjxtaPipeAdvertisement xmlnsjxta"http//jxta.o
  rg"gt
• ltIdgt
• urnjxtauuid9CCCDF5AD8154D3D87A391210404E59BE4
  B888209A2241A4A162A10916074A9504
• lt/Idgt
• ltTypegtJxtaUnicastlt/Typegt
• ltNamegtJXTA-EX1lt/Namegt
• lt/jxtaPipeAdvertisementgt
• lt/jxtaMSAgt

44
Module Implementation Advertisement

• ltxselement name"MIA" type"jxtaMIA"/gt
• ltxscomplexType name"MIA"gt
• ltxssequencegt
• ltxselement name"MSID" type"jxtaJXTAID"/gt
• ltxselement name"Comp" type"xsanyType"/gt
• ltxselement name"Code" type"xsanyType"/gt
• ltxselement name"PURI" type"xsanyURI"
  minOccurs"0"/gt
• ltxselement name"Prov" type"xsstring"
  minOccurs"0"/gt
• ltxselement name"Desc" type"xsanyType"
  minOccurs"0"/gt
• ltxselement name"Parm" type"xsanyType"
  minOccurs"0"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• 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)

• ltjxtaMIA xmlnsjxta"http//jxta.org"gt
• ltMSIDgturnjxtauuid-DEADBEEFDEAFBABAFEEDBABE00000
  0010206lt/MSIDgt
• ltCompgt
• ltEfmtgtJDK1.4lt/Efmtgt
• ltBindgtV1.0 Ref Impllt/Bindgt
• lt/Compgt
• ltCodegtnet.jxta.impl.peergroup.ShadowPeerGrouplt/Co
  degt
• ltPURIgthttp//www.jxta.org/download/jxta.jarlt/PURI
  gt
• ltProvgtsun.comlt/Provgt
• ltDescgt
• Default NetPeerGroup reference implementation.
• lt/Descgt
• lt/jxtaMIAgt

46
Pipe Advertisement

• ltxselement name"PipeAdvertisment"
  type"jxtaPipeAdvertisment"/gt
• ltxscomplexType name"PipeAdvertisement"gt
• ltxssequencegt
• ltxselement name"Id" type"jxtaJXTAID"/gt
• ltxselement name"Type" type"xsstring"/gt
• ltxselement name"Name" type"xsstring"
  minOccurs"0"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• Id JXTA id
• Type unicast, unicast secure or propagate
• name name

47
Pipe Advertisement (Example)

• ltjxtaPipeAdvertisement xmlnsjxta"http//jxta.or
  g"gt
• ltIdgt
• urnjxtauuid-9CCCDF5AD8154D3D87A391210404E59BE4
  B888209A2241A4A162A10916074A9504
• lt/Idgt
• ltTypegt
• JxtaUnicast
• lt/Typegt
• ltNamegt
• JXTA-EX1
• lt/Namegt
• lt/jxtaPipeAdvertisementgt

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 senders 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 isnt 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

• ltjxtaDiscoveryQuerygt
• ltTypegt2lt/Typegt
• ltThresholdgt1lt/Thresholdgt
• ltAttrgtNamelt/Attrgt
• ltValuegtsiduslt/Valuegt
• ltPeerAdvgt
• lt?xml version"1.0"?gt
• lt!DOCTYPE jxtaPAgt
• ltjxtaPA xmlnsjxta"http//jxta.org"gt
• ltPIDgt
• urnjxtauuid- 59616261646162614A7874615032
  503304BD268FA4764960AB93A5D7F15044503
• lt/PIDgt
• ... remainder omitted for brevity ...
• lt/jxtaPAgt
• lt/PeerAdvgt
• lt/jxtaDiscoveryQuerygt

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
• ltxselement name"ResolverQuery"
  type"jxtaResolverQuery"/gt
• ltxscomplexType name"ResolverQuery"gt
• ltxsallgt
• ltxselement ref"jxtaCred" minOccurs"0"/gt
• ltxselement name"SrcPeerID" type"jxtaJXTAID"/gt
  
• lt!-- This could be extended with a pattern
  restriction --gt
• ltxselement name"HandlerName"
  type"xsstring"/gt
• ltxselement name"QueryID" type"xsstring"/gt
• ltxselement name"HC" type"xsunsignedInt"/gt
• ltxselement name"Query" type"xsanyType"/gt
• lt/xsallgt
• lt/xscomplexTypegt
• 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

• ltxselement name"ResolverResponse"
  type"ResolverResponse"/gt
• ltxscomplexType name"ResolverResponse"gt
• ltxsallgt
• ltxselement ref"jxtaCred" minOccurs"0"/gt
• ltxselement name"HandlerName"
  type"xsstring"/gt
• ltxselement name"QueryID" type"xsstring"/gt
• ltxselement name"Response" type"xsanyType"/gt
• lt/xsallgt
• lt/xscomplexTypegt
• jxtaCred 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)

• ltrequest xmlns http//search.jxta.org
• xmlnst http//search.jxta.org/text
• query-uuid 1C8DAC3036A811D584AEC2C23
• query-space http//search.jxta.org/text gt
• lttquerygt
• ltttextgt
• sunw
• lt/ttextgt
• lt/tquerygt
• lt/requestgt
• Meaning should be anything

83
QRP (Response Message)

• ltresponses xmlns http//search.jxta.org
• xmlnst http//search.jxta.org/tickerqs
• query-uuid 1C8DAC3036A811D584AEC2C23 gt
• ltresponsegt
• ltdatagt
• ltttickergt
• SUNW
• lt/ttickergt
• lttpricegt
• 20.59
• lt/tpricegt
• lt/datagt
• lt/responsegt
• lt/responsesgt

84
QRP (Registration)

• ltregister xmlns http//search.jxta.org gt
• lttitlegtJXTA Stock Quote Providerlt/titlegt
• ltlinkgthttp//search.jxta.orglt/linkgt
• ltdescriptiongtGiven a ticker symbol, returns a
  15-minute delayed quote
• lt/descriptiongt
• lt! the URL or pipe ID of the provider --gt
• ltquery-servergtjxta//
• 59616261646162614A757874614D5047CF403C5700D44AE68
  F9FB626DD3F18E500000000000000000000000000000000000
  0000000000000000000000000401
• lt/query-servergt
• ltquery-space uri"http//search.jxta.org/text"gt
• ltpredicategt
• ltquerygt
• lttextgtsunw aol orcllt/textgt
• lt/querygt
• lt/predicategt
• lt/query-spacegt
• lt/registergt

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-email, RMI for JXTA, Web services for JXTA..
  (Most of them are not complete) (optional P2P
  services that run on the JXTA Platform)