Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

peerware.dispatcher.* (32)peerware.dispatcher.implementation.* (13)
peerware.peerapplication.* (15)peerware.utility.* (35)

peerware: Javadoc index of package peerware.


Package Samples:

peerware.dispatcher
peerware.dispatcher.implementation
peerware.peerapplication
peerware.utility

Classes:

LocalData: Makes available methods to manage and query the local data structure, such as local search and local subscription. A local data structure is a graph of nodes and documents organized such a forest of trees (see documentation) stored locally on every peers (excepted light Peers, like PDA, that have no local data structure). A Node can be inserted or deleted from the local data stucture with the insertNode 55 and removeNode 55 methods, while a Document with the placeIn 55 and removeFrom 55 methods. It can be notified that an Event is occurred on specified Item by using the publish 55 method. It's ...
GlobalView: Makes available methods to access and manipulate the global data structure (a merge of all the local data structures belonging to the Peers currently connected), such as global search and global subscription. A global data structure is a graph of Nodes and Documents organized such a forest of trees (see documentation) stored locally on every peers (excepted "light" Peer that have no local data structure). It's possible to search globally Nodes or Documents and to handle their projection with an Action . This search can be performed synchronously with the execute 55 method or asynchronously by using ...
Action: Specifies a behavior to have when processing Nodes and Documents in a local data structure, that match the criteria of a global search 55 or local search 55 . It represents the possibility to execute remotely a specified code in order to manipulate Nodes , Documents and their contents to obtain particular aims. With the method setDataFilter 55 , it's possible to add an user Data Filter, in order to improve the filtering performance. PeerEvents can be generated into an Action, but to publish them the only way is to put them into a queue (see enqueueEvent 55 ); at the end of the Action the delivering ...
PeerEvent: Specifies the structure of a Peerware Event. When an event (such as create, delete, ...) occurs to an Item , an instance of this class is created and sent throught the dispatching system to every subscribed Peer . Every instance will contain "system information" about the type of Event occurred, all the fully specified names of the Item on which the Event is occurred, the focus path (i.e. the meaningsfull path for the Event on the Item ),the PeerId of the Peer where the Event is occurred, the event version (a progressive number that allow to order events of a Peer ) and the Header, if the Item ...
Peer: This class is used by a peer to manage its connections to other peers , to get a reference to the local data handler and to the global data viewer . Through this class a peer may also set some security information 55 related to the peer 's current user and specify a strategy 55 for handling the subscriptions after leaving a peer 's net. A Peer is univocally identified by a PeerID , which is either automatically generated by calling a constructor 55 of this class or can be given as parameter by using another constructor 55 . This latter case is used in a reconnection: the given PeerID (passed throught ...
ActionDesc: Represents an Action descriptor, giving informations about the code relocation strategy and the URI from where the eventual missing classes can be retrieved. The only way to instantiate this class is to invoke the Peer.createActionDesc 55 method. By setting respectively the constants ALL 55 , TOFETCH 55 and LOCAL 55 through the method setRelocationStrategy 55 (Attention: by default will be set the strategy LOCAL 55 ), the Action code can be shipped together with all his classes, with only a subset of them (and if necessary the other classes can be fetched later), or alone. Through the methods getActionGroup ...
ConnectionAccepted: This message is used to accept a new connection with another Peer that tries to connect to the net. The connection is accepted only if in the Peer which receives the request is available almost one of the type of comunication protocols present in the received ConnectionRequest message. In other words, the Peer , which receives the request, decides the protocol to comunicate, if there is no protocol match (between the two Peers ), the connection is refused with the message ConnectionDenied . The accepted connection message contains the list of the Node s existing in the requesting Peer , the list ...
InChannelManager: It's a Thread, that has to manage the comunication between the local Peer and other ones; it's abstract and thus can be implemented in different ways for every connection type(TCP, RMI...); it represents a channel between Peer s. This Thread is created by the dispatcher in the processNewConnection 55 method. Pay attention: the constructor of the implementations MUST be WITHOUT parameters. The custom parameters can be passed to the implementations through the setCustomParameter 55 method. The implementetion must have the reference to the Dispacher and the PeerID and they are set with the setDispatcher ...
NodeFilter: Specifies the interface that an Object used to filter Nodes must implement. An Object implementing this interface is given as paramether to all this package's methods where a set of Nodes must be filtered in order to get a reduced set. It is up to the programmer to implement every time this interface to obtain the desired selection behaviour. In detail the programmer has to implement the match 55 method which is called to determine if a single Node match the criteria. When the system must select some Nodes from a set of ones, it calls the match 55 method as many times as the number of Nodes , every ...
ItemCallback: Specifies the interface that an Object, used to process incoming answers to a global executeAsynch 55 or a local executeAsynch 55 previously done, must implement. Every time an asynchronous execute is started, it is also specified an object implementing this interface that has to process the Item s returned. It is up to the programmer to write a class implementing this interface to obtain the desidered behavior. In details the programmer has to implement the processItem 55 method, which is called to process every single Item resulting from the execute. This class will process the Item produced ...
EventFilter: Specifies what must implement a class used to filter Events . An Object implementing this interface is used in the local subscribe 55 , in the global subscribe 55 , in the executeAndSubscribe 55 and in the executeAndSubscribe 55 , in order to let the Peer system be able to select the events in which the subscription is interested.
LDManager: Makes available methods to manage and query the local repository through the IRepository interface. This class allows to realize locally in the IRepository these operations: insertNode 55 , removeNode 55 , placeIn 55 , removeFrom 55 , execute 55 , executeAndSubscribe 55 and publish 55 .
EventCallback: Specifies what a class used to process incoming Events must implement. Every time a Event matching a local subscription 55 or a global subscription 55 arrives to the Peer, it will be processed invoking the processEvent 55 method. In every event subscription is given an implementation of this class that is used by the peer runtime system to manage the incoming Events matching the subscription.
StoredEventsRequestTable: This table stores all the informations about StoredEventsRequest messages previously sent. It's used to route back the StoredEventsReply messages and to know if the reply coming from a neighbor Peer is the last expected one (in such case a StoredEventsReply message will be delivered to the Peer that sent the StoredEventsRequest message to this one. If a neighbor Peer replies with a message that says that a Peer storing the events was found, the current Peer will deliver the message without waiting, and will discard all the other reply message referring to that request.
Document: This class stores Document 's informations and makes available methods to manage this content. A Document is composed by a Label, that is given by the getLabel 55 method, by a Header , that is given by the getHeader 55 method, by a list of Paths (at least 1), that is given by the getPaths 55 method, by a list of fully specified names, its Label plus its Paths, that is given by the getFullNames 55 method, and by a Content, that is an Object reachable through the getContent 55 method. This is a subclass of Item .
ConnectionRequest: This message is used to request a new connection to another Peer already connected to the net and represents the first step of the connection negotiation; contains the address of the sending Peer , the list of the Node s existing in the sending Peer and the the list of type of the comunication protocol (i.e.: TCP/IP, UDP, RMI...) available in the Peer which sends this message to another Peer . This list is used to decide, during the connection negotiation, which comunication protocol is to utilize. This message is generated in the Dispatcher.connect 55 method, received and handled by the ConnectionServer ...
AnswerMessage: Represents the answer to a global synchronous or asynchronous execute; contains an Item List that is the result of the execute, the identifier of the execution, a boolean value indicating if it's the last answer or not, in other words, if the execution in the Peer from which comes the answer, is finished or not. When the Peer , that has sent the execution, receives this message and only if the answer is referred to an asynchronous execution, the ItemCallback used to process the Item List through the InternAnswerProxy is added into the message and delivered to the CallbackManager .
SimpleItemFilter: It's a String based implementation of the ItemFilter that filters out Item s; it has two different methods to perform the matching on Nodes (see match(String) 55 ) or on Documents (see match(Header) 55 ). The wildcard * is allowed at the beginning or at the end of the filter Strings. Example: the String "/test" matches the filters "*" or "/te*", but not "/test/*" (that filters out all the sub Node of "/test"). For both cases, Nodes and Documents , could be used the String SimpleItemFilter.NOMATCH that forces the filter to match nothing.
ByteCodeItemFilter: It's a String based implementation of the ItemFilter that filters out Item s; it has two different methods to perform the matching on Nodes (see match(String) 55 ) or on Documents (see match(Header) 55 ). The wildcard * is allowed at the beginning or at the end of the filter Strings. Example: the String "/test" matches the filters "*" or "/te*", but not "/test/*" (that filters out all the sub Node of "/test"). For both cases, Nodes and Documents , could be used the String SimpleItemFilter.NOMATCH that forces the filter to match nothing.
ExternProxy: Specifies what must implement a class used to send messages to the other connected Peers ; it's created by the InChannelManager in the getExternProxy 55 method. This class with the PeerID of the Peer to which is referred, is stored by the dispatcher in the ConnectionTable .
ExecuteMessage: It's used to send to the other connected Peer s a global synchronous or asynchronous execute; contains the NodeFilter , ItemFilter and Action Descriptor that are parameter necessary to perform the execution in a Peer , the identifier of the execution to send and the context, that is a Serializable class containing a user certificate and some parameter values used to access the local data and the repository in another connected Peer .
AnswerRoutingTable: This Table stores all the informations about every sent global synchronous and asynchronous execute: i.e. to which Peer s the execute has been sent, the execute identifier and the PeerProxy used to route back the AnswerMessage referring to the sent execute. It's used to route back the AnswerMessage and to know if the answer coming from another Peer is the last one (that means that the execute in that Peer is finished). In the local Peer that allows to know when a sent global execute is finished; this information is very important for the synchronous global execute.
IRepository: Specifies the interface that a repository must implement, to be used in a Peerware system. The repository is used to store and retrieve Nodes and Documents . A Node is basically a Document container (equivalent to a directory in a file system), it is linked to at most one parent Node and may have different child Nodes . A Document must be contained at least into a node , but could be shared by more than one Node . Specifying an interface and not giving an implemented repository, allows every Peer to choose and use the repository implementation right to its own needings.

Home | Contact Us | Privacy Policy | Terms of Service