This document describes the structure of a hybrid Java-Prolog system making use of JPC and related libraries. The main components and their interactions are illustrated in figure 1. A description of them follows below.
At the top level of our architecture we have hybrid applications consisting of both Java and Prolog components. From the user perspective, these applications can be launched either as a Java program with embedded Prolog modules, or as a Prolog program with embedded Java components. Such applications can be developed on top of two different layers. With increasing levels of abstractions, these layers are (1) JPC, a library providing manual and explicit integration and (2) LogicObjects, an integration framework (implemented on top of JPC) providing a high degree of integration automation and transparency. The choice of the preferred abstraction layer to use is left to the programmer as it depends on the nature of the application.
The LogicObjects Framework
LogicObjects is an integration frameworks aiming to simplify the integration of hybrid Java-Prolog systems. Its goal is to reach an oblivious integration from both the Java and Prolog perspective.
Among other features, LogicObjects achieve a transparent and semi-automatic integration of Prolog and Java language by providing a simple mechanism for inferring the appropriate mappings between distinct kinds of Java and Prolog artefacts (e.g., Java methods and Prolog predicates, etc.).
The JPC Library
JPC is a high level inter-operability library for Java and Prolog. The main JPC components are (1) a Prolog VM abstraction, (2) a Java-Prolog conversion API and (3) an embedded Prolog database.
A Prolog VM Abstraction
Several integration libraries rely on the notion of a Prolog engine as a convenient abstraction for interacting with a Prolog virtual machine from Java.
JPC also makes use of such abstraction. A JPC Prolog engine provides a Java programmer with an API for interacting with Prolog. At the same time, it attempts to find a compromise between (1) offering convenient features facilitating the interaction from Java programs and (2) not assuming a specific implementation architecture of the underlying Prolog engine.
The JPC abstract Prolog engine is vendor-agnostic and thus requires a driver to connect to a specific Prolog implementation.
As part of our Prolog engine abstraction, we provide a set of classes reifying Prolog data types, inspired by similar JPL library classes:
- Term: An abstract Prolog term.
- Atom: A sequence of characters representing a Prolog atom.
- Compound: A compound term consisting of a name and a list of arguments.
- IntegerTerm: A Prolog integer term.
- FloatTerm: A Prolog float term.
- Var: A Prolog variable.
- JRef: A Java reference term. A special kind of term wrapping a Java reference.
A Java-Prolog Conversion API
Often, Prolog queries involve more complex data types than simple numeric or atomic primitives. In a Java-Prolog system, a common problem is how to represent in a Prolog query an artefact from the object-oriented world, or what is the most adequate representation of a Prolog term in the object-oriented world. These problems are often far from trivial in architectures where the Prolog engine is not embedded in a JVM. JPC provides a convenient conversion API, inspired in the Google's Gson library, for translating between Java and Prolog artefacts.
An Embedded Prolog Database
JPC uses an embedded Prolog database running on the JVM and supporting the storage of Java object references (JRef terms) in addition to standard Prolog terms. Several core interoperability features rely on this component. Although it is currently not intended to be used directly by the programmer, it is mentioned here since it can give an insight on the internal implementation of several JPC features. The current implementation lacks many of the features of a full Prolog system. It supports assertion and retraction of facts, unification, term indexing and backtracking. At the moment, it does not support rules, operators and many other standard and de facto Prolog features. Although its current features are enough to support the JPC internal requirements, this engine may evolve in the future towards a standalone embedded Prolog system.
Drivers are used to link the JPC abstract Prolog engine to a concrete Prolog engine. They can be built from scratch, or on top of existing Java-Prolog bridge libraries for the target Prolog engine. Those bridge libraries can be made available by the Prolog engine provider (e.g., JPL) or by third parties (e.g., PDT Connector, InterProlog). At the moment, JPC follows the second approach: existing drivers are currently implemented on top of the JPL, InterProlog, and PDT Connector libraries. Native JPC drivers are planned for the future.
At the lowest level of our architecture there are the concrete Prolog engines. JPC does not make any assumption regarding the architecture of a concrete Prolog engine. They may be embedded in a JVM, running as a separate program on a local machine, or even running on a remote server.
Although JPC and LogicObjects can work with "standard" Prolog engines, they also include a significant number of advanced features that facilitate the integration with Prolog programs written in Logtalk.