From Filtered Push Wiki
Jump to: navigation, search

Class Diagrams


API Documentation

See Javadocs: http://filteredpush.sourceforge.net/docs/node/


FPNetworkAccessPoint Concrete implementation of NetworkAccessPoint for a FilteredPush network instance. Has two apis that are exposed via a SOAP webservice FPNetworkAccessPointWebService

  1. acceptMessage: Takes an FPMessage and invokes the triage processor to process the message (plan and run the appropriate job for that message). Returns a uuid to the client that invoked this method as a handle for this message.
  2. checkForMessages: Takes a topic (the uuid handle of the message that was previously submitted to acceptMessage) and invokes the appropriate MessageRetriever implementing class (depending on the messaging system implementation, JMS or MySQL currently) to retrieve messages on that handle. In the case of an interest or a query will retreive messages that pertain to the interest or messages that are results of the query.


FPTriageProcessor Concrete implementation of TriageProcessor, the access point for a Triage component for FilteredPush networks. Triage invokes the appropriate JobPlanner and JobRunner implementations with the FPMessage provided by the access point.


FPJobRunner Concrete implementation of a JobRunner for instances of a FilteredPush network. When runJob() is invoked by the triage processor, it adds the job to a queue and executes the next job in line.


StaticApplePieJobPlanner creates job plans for ApplePie based on one message type resulting in one job plan. The planJob() method invoked by the triage processor before calling JobRunner.runJob() examines a message, and produces a job plan for acting upon the message based upon the type of the message. When a message of an unknown type is presented, returns an instance of ErrorJob. Below are the AbstractJob implementations for ApplePie and the conditions required for the JobPlanner to return that specific Job implementation:

  1. PingJob: this job is planned if the FPMessage has messageType = BaseFPMessageType.PING
  2. ApplePieAnnotationJob: this job is planned if the FPMessage has messageType = BaseFPMessageType.ANNOTATION
  3. ApplePieSparqlQueryJob: this job is planned if the FPMessage has messageType = BaseFPMessageType.QUERY
  4. ApplePieRegisterInterestJob: this job is planned if the FPMessage has messageType = ApplePieMessageType.REGISTER_INTEREST


An FPMessage has the following components:

  • messageId: a uuid that identifies the message.
  • inResponseTo: if this message is related to annother message (such as one of many results associated with a query message) this contains the uuid of the original (parent) message.
  • scheme: describes the message's content (i.e. kvp, sparql, rdf/xml, etc). This allows a single job to have different behavior depending on message content. For example, an interest may be expressed as kvp or sparql and the ApplePieRegisterInterest job will behave differently in each case.
  • content: contains the message content (currently as a String). See above (scheme) for types of message content.
  • type: The message type. Some of these message types can be found as constants in the ApplePieMessageType class (in FP-API-Library). The message type is used by JobPlanner to determine the most appropriate job to execute.
  • status: not yet implemented
  • ClientIdentity: identifies the message's sender, not yet fully implemented.
  • time: message creation time.


The identity of a client that wishes to interact with a filtered push network


ApplePieAnnotationJob is a job implementaion that will treat the content of an FPMessage as an Apple Pie annotation. The message is stored in the messaging system as key value pairs extracted from the message content serialized as RDF/XML. Also stores the triples that make up the annotation in the annotation triple store.

Currently the annotation triples are inserted via the sparql endpoint Fuseki configured to use Jena TDB


ApplePieSparqlQueryJob will take the content of a message with scheme SPARQL and message type QUERY and launch a SPARQL query against the triple store containing the annotation triples. The results are then placed into an FPMessage to be retreived later by a MessageRetriver implemenation.

Currently SPARQL queries are launched against the sparql endpoint Fuseki.


ApplePieRegisterInterestJob allows clients to register an interest expressed as key value pairs to be matched (e.g. collectionCode=GH). This interest is then stored in the messaging system.