On 03/06/15 19:07, Rob Vesse wrote:
Answers inline:
On 03/06/2015 18:25, "Juan Sequeda" <[email protected]> wrote:
Is there any documentation that describes how SERVICE federation is
implemented,
http://jena.apache.org/documentation/query/service.html
what optimizations exist,
No optimisations are used AFAIK, Andy may know differently
Nothing to add - it's "basic federated query", not a perfect solution to
the federated query problem.
I would +1 Claude's comments about service availability.
In the real world, the remote system may be unavailable for all sorts of
reasons, and their drivers (e.g. business context) may not match the app
making the SERVICE call.
So the remote may go offline for a day to do upgrades at a time when
they know their business apps don't need the service.
However, if you are writing a 24x7 UI-based dashboard app, you have
different business drivers.
Nothing SPARQL-specific here. The real world copies data around for a
reason.
Andy
is caching done and if so, how, etc?
No permanent caching
The entire SERVICE result is cached temporarily into memory before further
query processing. This is primarily done in case there is a
circular/chained SERVICE clause as that can cause nasty things to happen
(e.g. you can DOS Fuseki or the remote service by sending particularly
crafted queries). However the retrieved results are then drained in a
streaming fashion and not cached beyond that.
Rob
Can anybody report on the use of SERVICE Federation in practice?
Thanks
Juan
