Some background on this.

An example use case:

A Kafka-Fuseki connector which take data, patches or SPARQL updates from a Kafka topic (that is, anything that can POSTed to a dataset). Kafka messages have a header so there is a content-type header and the message is sent into Fuseki dispatch.

This is CQRS style systems - event-sourcing - data mesh.

Kafka has state. A Fuseki can stop, then sync up when it starts, or have a customized view of the overall event history or CQRS-style reliable systems.

https://martinfowler.com/bliki/CQRS.html​
https://martinfowler.com/eaaDev/EventSourcing.html​
https://www.thoughtworks.com/en-gb/what-we-do/data-and-ai/data-mesh

Not all Fuseki installations want to have all the Kakfa client code (it looks to be 5 Mbytes + extra dependencies but as you add features, more jars are needed).

So the base issue is how to have plugins? And how do they find information about the server and its configuration?

Jena system initialization works for getting extra jars to wire themselves into the various registries. SHACL compact syntax wires itself into the parser registry. Adding a new operation to Fuseki works this way (see TestFusekiCustomOperation).

Jena system initialization does not provide a way for the code to interact with building a server. For example, it can't (in any sensible way) get to see the configuration before the server is built, nor do addition assembler declarations in a configuration file get to run in some defined way.

The Kafka-Fuseki connector needs configuration
* Need to know where the Kafka bootstrap server is
* Associate the Kafka topic with a dataset
* Have a state management area (to track the offsets processed)

That's an assembler. Ideally, it should, optionally, be possible to put that in the Fuseki configuration file. Whether is it same-file or separate-file is a convenience issue for operation.

That's just one example of a module. Modules could pick just certain points and log system information, or add system control functionality. By being in the server build lifecycle that can even add servlets or servlet filters.

Fuseki modules are an extension point. A module implements an interface that has call points for calls during Fuseki server building which expose the server datastructures.

    Andy

Yes - this is £job related work.

Reply via email to