Java client for NanoSparqlServer REST API

[thompsonbry]

Implement a Java client for the NanoSparqlServer? REST API.

A variety of people have expressed an interest in a BigdataRepositoryConnection? implementation which can be used to access a remote standalone database instance. People are used to this pattern with the openrdf platform and the HttpRepositoryConnection?.

The BigdataSail? and BigdataRepository? both have additional methods which are necessary for high performance, especially the getReadOnlyConnection() method. There are also extension methods for reporting the timestamp associated with a commit point and managing certain aspects of truth maintenance. Appropriate interfaces will need to be declared for these methods and an alternative implementation of those interfaces derived for the NSS REST API.

There is no requirement for this when embedding bigdata inside of the same JVM. You simply use the BigdataSail? and wrap it as a BigdataRepository?.

There is little requirement for this in scale-out as any node in a cluster can obtain a JiniClient?, connect to the BigdataFederation?, and resolve the desired triple or quad store, and wrap that AbstractTripleStore? as a BigdataSail?.

[thompsonbry]

Mike,

Let's to this from scratch. I can help to extract the HTTP request support out of the NSS test suite and provide the project level support for a separate module and JAR.

Bryan

[thompsonbry]

MikeP wrote: I've just committed a first pass of the RemoteRepository? (aka the NanoSparqlClient?). Please refer to TestNanoSparqlClient? for guidance on how to use it. The only glaring hole right now is the ability to do an update operation that takes a collection of statements on the remove side. The pattern for update on the NSS is delete by query plus a post of statements to add. You can specify specific statements to delete by using a construct query with no where clause:

prefix bd: <http://bigdata.com/rdf#> construct { bd:Mike bd:likes bd:RDF } {}

But I haven't written a utility yet to automatically build these construct queries from a collection of statements.

[thompsonbry]

The above is in Commit Revision r6123 of the 1.1.x maintenance branch.

[thompsonbry]

Mike wrote: changing from java.net to httpcomponents.

Bryan wrote: I have committed some fixes to build.properties and build.xml in order to fix CI, which was broken by the new http components dependencies.

We should run the NSS test suite against the WAR. Also the SPARQL 1.0, 1.1, UPDATE, Federated Query, etc. test suites. We need that to verify the WAR distribution. E.g., whether the http components dependencies are making it into the WAR such that Federated Query will work.

Committed revision r6144.

[thompsonbry]

Ok. CI is running cleanly now against the new dependencies.

[thompsonbry]

RemoteRepository? now uses a shared connection manager by default and will use the caller's connection manager if you use the appropriate constructor.

I am going to change the prepareTuple and prepareGraph operations to do incremental materialization of the results. This will be an API change for the latter (GraphQueryResult? versus Graph).

Committed revision r6171

[thompsonbry]

Modified the RemoteRepository? to use an pattern for the connect options which can be overridden.

Integrated access to the ClientConnectionManager? into the QueryEngine?. The ClientConnectionManager? is lazily obtained from a factory and is shutdown() when the QueryEngine? is shutdown.

Refactored the RemoteServiceCallImpl? to use the RemoteRepository?, which is now backed by the http components package. This required a change in the ServiceRegistry? API.

The RemoteRepository? now uses more sophisticated defaults for the Accept header. There is a new class to support this (AcceptHeaderFactory?).

Committed revision r6195.

[thompsonbry]

Changed how we handle the configuration of the ClientConnectionManager? and removed all of the RemoteRepository? constructors except the one in which the caller specifies both the ClientConnectionManager? and the Executor. These resources MUST be explicitly managed. Bigdata does that internally by hanging them off of the QueryEngine? and the IIndexManager respectively. Remote applications need to provide their own management for those resources.

Changed the ServiceFactory#create?() method, replacing the parameters with an interface to make furture versioning of this information painless. Added access to the ClientConnectionManager? and the IServiceOptions so these are now both available to the ServiceCall? (assuming that the ServiceFactory? implementation passes them through).

Committed revision r6208.