For reference: Sesame's architecture has some similarities to what you
propose. Each Sesame server exposes its datasets via HTTP (a superset of
the SPARQL graph-store API afaik).
You can query and update the datasets via SPARQL, but at the same time
you can also use the Sesame client API directly and work with a
HTTPRepository that represents the remote dataset (a Sesame Repository
roughly translates to a Jena Model). I don't know if and how it handles
state and transactions though.
The Sesame documentation gives an overview how it looks like:
http://www.openrdf.org/doc/sesame2/users/ch03.html
I would be interested in something similar in Jena. Is jena-client going
in that direction?
Sören
Am 28.03.2013 21:42, schrieb Claude Warren:
USE CASES AND GOALS
*
Use Cases
All use cases are shared data across multiple endpoints.
1.
Multiple SPARQL servers utilizing a single RDF server.
2.
Multiple Model based applications utilizing a single RDF server such as
a mix of live data feeds, bath update feeds, and report generation.
3.
Mix of SPARQL and Model based applications using a single RDF server.
(e.g. automated sensors feeding live data into the graph while the SPARQL
endpoint retrieves it)
Goals
1.
Shared data across multiple JVMs.
2.
Shared data across multiple Model oriented applications with minimal
changes to existing code.
3.
ACID or eventual consistency determined by underlying Model/Graph
implementation.
4.
Graph protocol on the wire.
http://jena.apache.org/documentation/javadoc/jena/index.html?com/hp/hpl/jena/graph/Graph.html
5.
Model protocol on the wire.
http://jena.apache.org/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Model.html
6.
Provide stateful connections to the underlying Model/Graph. This will
be necessary to support transactions in the Model.
*
