1 / 87

Project JXTA

Project JXTA. Outline. Introduction JXTA Architecture JXTA Concepts JXTA Protocols JXTA Search. What is Project JXTA?.

cindyevans
Télécharger la présentation

Project JXTA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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="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>

  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="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>

  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="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>

  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="http://jxta.org"> <Id> urn:jxta:uuid-9CCCDF5AD8154D3D87A391210404E59BE4B888209A2241A4A162A10916074A9504 </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.

More Related