We are witnessing the spread of data-driven organizations. In particular, enterprise software is migrating from legacy monolithic data systems to microservices, which embrace the distributed nature of data. Despite o ering many bene ts, microservices pose several challenges in the development and maintenance of information systems. Techniques like Domain-Driven Design and Data Mesh emerged to ease data and system integration by infusing domain knowledge within the developing process. In this scenario, knowledge representation and reasoning (KRR) can come to the rescue. Thus, in this paper, we present the Java Knowledge Interface (JKI), whose goal is allowing Java programmers to semantically lift the applications' data model (compile time) and state (runtime) with respect to an OWL2 ontology.
We are witnessing the spread of data-driven organizations. In particular,
enterprise software is migrating from legacy monolithic data systems to
microservices, which embrace the distributed nature of data. Despite o ering many
bene ts, microservices pose several challenges in the development and
maintenance of information systems. Microservices have to speed up the velocity of the
software lifecycle, supported by the adoption of novel techniques for continuous
delivery and integration. Moreover, di erent independent teams often develop
microservices, which do not necessarily share the exact requirements. In
practice, the adoption of microservices may lead to small incremental changes that
can integrate di erent data products [
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 3 https://martinfowler.com/articles/data-mesh-principles.html
In this scenario, knowledge representation and reasoning (KRR) can come
to the rescue. Indeed, ontologies can model the application domains to ensure
semantic interoperability among di erent data systems. Intuitively, the
combination of KRR and software engineering (SE) have been studied already [
In this paper, we present the Java Knowledge Interface (JKI), which falls
into Ontology-driven development [
Outline. Section 2 de nes the proposed JKI. Section 3 describes the implemented proof of concept. Section 4 draws the conclusions. 2
In this section, we present the Java Knowledge Interface (JKI). Figure 1 shows
an overview of JKI. As mentioned before, JKI aims at running a multitude of
reasoning tasks over Java applications. In particular, JKI must enable two
inference scenarios: (1) Static, i.e., applying a given reasoning task to the application
data model at compile time. Java applications rely on a speci c data model
describing the domain addressed by the software program. JKI requires to map
relevant Java classes (i.e., the application data model) to corresponding OWL
classes in the given TBox. Notably, not all classes of the application model need
to be mapped to the ontology. (2) Dynamic, i.e., executing a given reasoning
task over the application state at runtime. Given a generic running Java
application, its runtime state is represented by instances of classes of the model
that are handled and interconnected in-memory (heap and stack ). JKI should be
4 we invite the reader to consult [
The obtained KG o ers an abstraction to reason on the domain logic coherence over the implementation details of one or more applications. In particular, we distinguish two scenarios (A) Intra-Application Inference, where JKI is executing a given reasoning task over a KG resulting from the state lifting of an application. (B) Inter-Application Inference, where JKI is executing a given reasoning task over a KG resulting from the integration of the lifted state of n di erent applications. Intuitively, all four combinations are possible. Indeed, the JKI users might be interested to verify the compliance of a single application data model to the ontological speci cation (1A) or check if a static alignment exists across applications (e.g., di erent microservices in a distributed architecture) (1B). On the other hand, the JKI users might want to reason about a single application state (2A) or the integration of many (2B). 3
To validate JKI we developed a proof-of-concept (POC)5 that exploits the Java
Debug Interface (JDI)6, and OWL API [
The POC consists of two examples, i.e., app.artmarket and app.eshop, which respectively represents a paint shop and e-commerce. These examples are designed to show the bene ts of the lifted states for debugging the application state. The E-Shop demo shows how the integration between the application state and external data allows validating (consistency checking) the discounts. For example, including in the ontology, an axiom about discounts available only to particular customers allows evaluating, at runtime, the validity (consistency) of the application state. The Art Market demo shows how an ontology allows reasoning over the knowledge that is not explicitly represented in the classes. For example, each individual of the class Artist associated to a Paint can be axiomatically inferenced as an instance of the Painter subclass, thus enabling querying considering external knowledge about Painters.
The applications data models are made available to JKI using a set of maps that are con gured to bind IRIs of the ontology to Java classes (to generate individuals) and their elds (to generate data and object properties). Multiple property relations from the same instance are stored in named lists.
The JKI is implemented using the JDI API to connect to the Java application and place breakpoints to collect state snapshots. Indeed, using JDI we do not need to modify the monitored Java application. The only requirement is to run the application in debug mode, where it is possible to receive updates 5 https://github.com/marioscrock/java-reasoning 6 https://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/ from the JVM via socket. Once reached a breakpoint event, the JVM execution is suspended and a JKI component (implementing the InspectToAxiom interface) incrementally inspects the application state and generates ABox axioms considering a given con guration.
Using OWL API, the POC allows its user to programmatically: (i) add other axioms to the generated KG, and (ii) answer Description Logic queries on the KG. The POC periodically runs a reasoning routine every time the JVM is suspended for a breakpoint. A bu er is kept to ensure that previously added ABox axioms (generated by the last inspection of application instances) are deleted and only the active instances are left in the KG. 4
In this paper, we presented a proof-of-concept implementation of a Knowledge
Interface for Java programs. JKI supports two kinds of reasoning, i.e., static
reasoning about the application data model at compile-time, and dynamic reasoning
on the application state at runtime. We showcased the feasibility of JKI with
two examples, i.e., an Art Market and an E-Shop. As future work, we plan to
(i) design an annotation-based mechanism to map the application data model to
the OWL classes, (ii) enable the usage of SHACL shapes to validate the
semantically lifted state of the application, (iii) integrate other forms of application
data within the KG, i.e., traces, logs, and metrics [