Evolving Fuseki

[afs]

Currently, the UI for Fuseki works with a webapp container. Fuseki does not make use of the webapp container environment.

There is also Fuseki packaged without using a webapp container but it does not have the UI or the server side functionality that needs.

An advantage of the simpler packaging is that it is easier to add customization and extensions using Fuseki modules.

By adding the stats and admin server side functions, as modules, Fuseki can evolve as one server base. The war file would be retained as an additional packing with the fixed functionality it currently has.

Fuseki main

The first step is to switch the jar file fuseki-server.jar in the Fuseki download to be Fuseki main with admin functionality and UI. Thsi gives the same user functionality as the Jena 5.2.0 fuseki-server.jar.

• Create a Fuseki module for the server administration function. This manages the "run" area.
• Include the browser-side UI and serve the pages.
• Provide Shiro support.

This could start with a new maven module jena-fuseki-server-app.

There is functionality that can be extracted as modules, such as the Prometheus metrics, but later.

New functionality for fuseki-server.jar is not a goal for the first step.

Later

Once the Fuseki is changed over, there are various things that can be done. Here are some possibilities:

• Be able to set the run area from the command line, and be able to set an admin password in a manner that is convenient and safe for deployments.

• A Fuseki modules for GeoSPARQL, bring together Fuseki main code line and the GeoSPARQL code when using a configuration file.

• Server information. Current the stats are part of the admin interface. The stats should be provided independently.

• Modular functionality e.g. having a query UI (no update or adding data) with no admin. This may be componentizing the UI or making the UI responding to the functions the server makes available.

• At sometime, we should consider making Fuseki start as either datasets configured from a configuation file, or one from from the command line. Currently, both can be used at the same time.

Maven modules

Currently:

Module	Functionality
jena-fuseki-core	The servlets that make up Fuseki, configuration file parsing, Prometheus. No Jetty specific code.
jena-fuseki-main	Fuseki modules, Jetty specific security code.
jena-fuseki-access	Per-graph access control
jena-fuseki-ui
jena-fuseki-webapp	The web container application
jena-fuseki-fulljar	The webapp, packaged with Jetty as a single runnable jar.
jena-fuseki-war	Produce the war file.
apache-jena-fuseki	Downlaod zip file for Fuseki
jena-fuseki-docker	Ket to build a container.
jena-fuseki-server	Packages jena-fuseki-main as a shaded runnable jar with Jetty.

[Ostrzyciel]

I like the idea, a lot.

I'm not sure if this is part of this vision, but I think that this system could be used as the default base for Semantic Web applications built on Jena. Instead of writing a Java application from scratch that embeds Fuseki, I could just develop a Fuseki module that adds the use case-specific functionality. Of course, this would only make sense if writing these modules was sufficiently easy and well-documented.

Something like Spark jobs: https://spark.apache.org/docs/latest/submitting-applications.html

In the far, far future, maybe it would even make sense to support bindings to non-JVM languages, like Python in Spark? Just an idea, I'm not sure if it even makes sense.

Or maybe modules defined in some declarative manner? Something like this: https://atomgraph.com/products/linkeddatahub/

These non-JVM module types could be supported by third-party code.

[Ostrzyciel]

Oh, and I'd add HA Fuseki to the list of potential modules: https://afs.github.io/rdf-delta/ha-fuseki.html

[namedgraph]

I like the modules idea but once again I would encourage to consider basing Fuseki on JAX-RS which is a REST abstraction layer above the raw servlet API. I am familiar and quite satisfied with the Jersey implementation.

Tedious operations such as content negotiation would be supported by the framework out-of-the-box. Format (de)serializers would be easily pluggable in using providers and shared between the server- and the client-side. There's is definitely a larger number of users that would be familiar with JAX-RS as the HTTP framework than Jena's custom HTTP classes.

Looks like classes such as this one would lend themselves well to a JAX-RS based refactoring: https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/ServletBase.java

[afs]

namedgraph replays one side of an old discussion.

Fuseki having its own HTTP handling has been an advantage because details matter and the opportunities it gives e.g. #2462.

FusekiModules are about componentizing a database engine.

One could write a module to used/provided JAX-RS.