-In this paper we explore the perspective of Logic Programming as a Service (LPaaS), with a broad notion of “service” going beyond the mere handling of the logic engine lifecycle, knowledge base management, reasoning queries execution, etc. In particular, we present tuProlog as-a-service, a Prolog engine based on the tuProlog core made available as an encapsulated service to effectively support the spreading of intelligence in pervasive systems-mainly, Internet-of-Things (IoT) application scenarios.
Today applications are more and more pervasive and intelligent, calling for situated intelligence—light-weight, effective intelligence chunks placed where and when needed to locally tackle the specific reasoning needs in complex distributed systems. This is particularly true in the fast-growing field of the Internet-of-Things (IoT), where connectivity and interoperability are just the basic steps towards higher-level, customised, variously-situated services.
The complexity of IoT system engineering calls for suitable, easily deployable infrastructures, meant to make the designers’ and developers’ task easier by providing commonlyrequired services to applications. Such infrastructures should (i) be both statically and dynamically (easily) configurable, so as to match the application needs; (ii) govern components and applications interaction; (iii) encapsulate intelligence in suitable forms for applications’ exploitation.
In this scenario, where software engineering, programming languages, and distributed artificial intelligence meet, logicbased languages have the potential to play a prominent role both as intelligence providers and technology integrators.
For the former, typical LP features – such as programs as logic theories, computation as deduction, and programming with relations and inference – make logic languages a natural choice for building intelligent components. In the context of IoT, this also implies that logic-based technologies should be implemented taking strongly into account specific engineering criteria such as deployability, scalability, and interoperability.
For the latter, logic languages already proved to be
effective as both communication and coordination languages [
The tuProlog [
In the remainder of the paper, after recalling the main features of the tuProlog technology, we outline the general architecture for Logic Programming as a Service (LPaaS) – without limiting ourselves to the case where “as a service” means “as a Web/Cloud Service” – aimed at fully managing the Prolog engine lifecycle (either dedicated or not to a given client application), the knowledge base management, and the query execution. Then, we focus on the tuProlog case, taking iOS as our experimental platform – where the actual instantiation of the as-a-service paradigm is much closer to a SOA-/Cloudoriented interpretation – and discuss some simple application examples.
II. tuPROLOG IN A NUTSHELL
tuProlog [
Minimality means that the tuProlog core contains only the Prolog engine essentials – roughly speaking, the reasoning engine and the required basic mechanisms – whereas any other feature is implemented via libraries: users can configure their system by dynamically loading/unloading libraries at any time.
Each library provides a package of related predicates, functors, and operators; new libraries can also be easily developed, either in Prolog or in Java/.NET language (or a hybrid mix of the two) as a suitable Java/.NET class, extending the tuProlog Library class and following simple naming conventions. Library-defined predicates, functors and operators are indistinguishable from tuProlog built-ins—actually, most of the perceived built-ins are actually provided by some preloaded library.
Easy deployability means that, generally speaking, installing is just a matter of making the JAR archive/.NET assembly available in the desired location: the only exception is when the hosting platform imposes its install procedure, as in the case of Android/iOS app (for which going through the Android/iOS installer is mandatory).
In addition, tuProlog is compatible with major
interoperability standards such as TCP/IP, RMI, and CORBA, and
is exploited as the enabling technology inside the TuCSoN
coordination infrastructure [
Coherently with the view outlined above, this paper looks forward to the idea of providing Logic Programming as a Service (LPaaS), conceptually situated inside the Software as a Service layer of, e.g., a typical Cloud-based environment. Nevertheless, the first step to achieve such a goal is to carefully design the architecture of a logic programming engine according to the general software engineering principles of modularity, encapsulation, and reusability. The architecture would provide the conceptual foundation for the “as a service” paradigm in the context of heterogeneous computational environments— e.g., as a RESTful Web Service, as a Cloud-hosted app, etc.
In the LPaaS context, according to the broad acceptation of term “service” described in Section I, the basic functionality to be provided is the ability to reason over logic theories, which translates into the ability to submit queries and retrieve results; related functionalities include the creation and configuration of the reasoner (the logic engine) with the proper knowledge base.
The interface is then supposed to define the API to provide such functionalities, namely: • • create engine: to instantiate a dedicated engine; reset engine: to reset the engine to the initial state and possibly the empty knowledge base; set theory: to load the knowledge base into the engine; query: to submit queries and retrieve (possibly multiple) results.
Further degrees of freedom include whether multiple engines could be allowed, whether a given engine should/should not be reserved to a given client application, etc.
If the Prolog language is adopted, such functionalities have to be tailored to the Prolog-specific behaviour, assumptions, and syntax, and APIs have to be mapped onto suitable Prolog predicates. In the next section we specialise our approach to the specific case of the tuProlog system, which provides not only a light-weight Prolog engine particularly featured for this kind of applications, but also a multi-paradigm and multilanguage working environment, thus paving the way towards further forms of interaction and expressiveness.
Among the different platforms supported by tuProlog, in this paper we take the iOS platform as our reference (a) because of its adoption in pervasive contexts, (b) for the availability of several sorts of smart devices (phones, watches, etc.) that constitute a challenging testbed, and (c) for its architectural similarity with more specific SOA/Cloud-oriented notions of “as a service”.
As a challenging application context for LPaaS, here we focus on the development of the tuProlog service for iOS, for both Objective-C and Swift applications. The service is embedded in a tuProlog app, acting as the service provider for all other applications running on the mobile device. Its API obviously adheres to the above-presented API, tailored to the Prolog syntax plus some convenience mechanisms—namely: where: • • • • • create engine: for convenience, this functionality is just embedded in the first call to the service; reset engine: mapped onto the reset primitive; set theory: mapped onto the theory primitive; query: mapped onto a set of primitives, namely query to issue the query, result and solution to retrieve the query result, and nextSol to explore further solutions.
A nice peculiarity of the iOS platform, which is one of the main reasons to choose it in our experiments, is the built-in URL scheme functionality, which provides a simple and effective way for applications’ inter-communication via a user-defined, URL-based protocol. In short, all is needed to communicate with an app is to create an appropriatelyformatted URL and ask the system to open it; on the opposite side, the custom scheme needs to be declared and properly implemented—see Fig. 1.
In the tuProlog case, two custom URL schemes need to be defined—one for incoming requests, to be processed by the tuProlog Mobile App and encoding the above API; and another for the query results, to be processed by the client app.
The tuProlog app implements the following URL scheme: tuPrologMobile://?src=srcURL& command=argument& dst=dstURL srcURL is the client URL scheme: as a result, a new Prolog engine is created in tuProlog Mobile and associated with that client; command is one of theory, query, nextSol, reset, with argument respectively being theory (the Prolog theory to be set in the engine, or the link where to donwload it1), query (the text of the query), nextSol, reset; dstURL is the URL scheme of the client to which the result must be sent, possibly different from srcURL; if null, the result is shown in tuProlog app console. On the other hand, the query result returned by the tuProlog service is encoded by the following URL scheme: dstURL://command=commandresult dstURL is the URL scheme of the client receiving the result; command is one of the below four (result, solution, nextSol, reset), with the respective commandresult. The specific syntax of commandresult varies with command, namely: dstURL://?result=result& engine=engineVersion& engineAge=engineAge dstURL://?solution=solution& engine=engineVersion& engineAge=engineAge dstURL://?nextSol=nextSolution&
engine=engineVersion dstURL://?reset=OK result is either Yes or No for success or failure, respectively; engineVersion is the version of the tuProlog system; engineAge can be new or still for a dedicated or cached engine, respectively; solution is the solution of the query; nextSolution is the next solution of the query; error contains potential errors.
Such a URL scheme is a first step towards a more SOA/Cloudoriented interpretation of the LPaaS paradigm, with respect to the more general notion envisioned for tuProlog—where, essentially, “as a service” is interpreted according to the general software engineering principles of modularity, encapsulation, and reusability. In fact, making LPaaS available on a Web Server, a Cloud infrastructure, or other communication protocols adopted in IoT scenarios is just a matter of designing and deploying a suitable wrapper API, translating e.g. RESTful requests to the appropriate library method calls.
Fig. 3. The multi-language toy example: Swift app using Java entities V.
Fig. 2 shows one first, typical application scenario: the client is a Swift/Objective-C application that provides a GUI for the computation of the symbolic derivative, while the symbolic computation is delegated to the tuProlog service. The Apple Watch extension (WatchKit) is also supported, so as to replicate the client GUI on the the iWatchr(which, in principle, could also play a more active role).
From the user’s side, the first step is to create a dedicated Prolog engine, loaded with the proper logic theory: tuPrologMobile://?src=tuPrologMobileClient& theory=dExpr(T,DT) :- dTerm(T,DT). dExpr(E+T,[DE+DT]) :- dExpr(E,DE), dTerm(T,DT). dExpr(E-T,[DE-DT]) :- dExpr(E,DE), dTerm(T,DT). dTerm(F,DF) :- dFactor(F,DF). dTerm(T*F,[[DT*F]+[T*DF]]) :- dTerm(T,DT), dFactor(F,DF). dTerm(T/F,[[F*DT]-[T*DF]]/[F*F]) :- dTerm(T,DT), dFactor(F,DF). dFactor(x,1). dFactor(N,0) :- number(N). dFactor([E],DE) :- dExpr(E,DE). dFactor(-E,-DE) :- dExpr(E,DE). dFactor(sin(E), [cos(E)*DE] ) :- dExpr(E,DE).
dFactor(cos(E), [-sin(E)*DE] ) :- dExpr(E,DE).
The engine can now be queried via the top-level predicate dExpr(+function, ?derivative). For instance, the request to derive the cos x · sin x function translates into the URL: tuPrologMobile://?src=myTuPrologMobileClient&
query=dExpr(cos(x)*sin(x), D).&dst=myTuPrologMobileClient whose answer, − sin2 x + cos2 x, is returned (in a nonsimplified form) as the URL: tuPrologMobileClient://?solution=yes.
D / [’+’([’*’([’*’(’-’(sin(x)),1)],sin(x))], [’*’(cos(x),[’*’(cos(x),1)])])] dExpr(’*’(cos(x),sin(x)), [’+’([’*’([’*’(’-’(sin(x)),1)],sin(x))], [’*’(cos(x),[’*’(cos(x),1)])])]) &errors=&engine=2p Mobile - 3.0 beta &engineAge=still This URL encodes both the variable binding and the whole solution: in particular, the Prolog variable D, which contains the computed derivative, results
D / [’+’([’*’([’*’(’-’(sin(x)),1)], sin(x))], [’*’(cos(x), [’*’(cos(x),1)])]) ]
Technically, the client app, written in Objective-C, triggers the iOS service based on the provided URL, while on the other side the server app, written in Java, parses the command, creates the Prolog engine, performs the required activity and returns the result.
More complex scenarios in a multi-language and multiplatform perspective could exploit tuProlog multi-paradigm programming support (OOLibrary) in a broader sense, with Swift or Objective-C apps interacting with Java entities. Fig. 3, for instance, shows a toy Swift app which creates Java objects, calls some methods, and elaborates the (Java) result back in Swift.
More precisely, as detailed in the following code, a Java string with the “ member(X, [a,d]).” text is first bound to the Prolog variable Q, then a Java Prolog engine is bound to the Prolog variable P and used to solve the query Q, binding the result to the Prolog variable S; this result is finally converted back to a Java string via toString, binding the final result (yes in this case) to the Prolog variable SOL. tuprologmobile://?src=null&query= new_object(’java.lang.String’, [’member(X, [a,d]).’], Q), new_object(’alice.tuprolog.Prolog’, [], P), P <- solve(Q) returns S,
S toString returns SOL&dst=null As shown in Fig. 3, the result is exploited by the client Swift application for its own purposes–here, trivially, just to print it in its console.
In a wider perspective, this approach fits particularly well those pervasive application scenarios where intelligence needs to be spread onto a broad set of heterogeneous devices, yet the choice of where logic computation should actually take place depends on many conditions—such as the available computational power, the available bandwidth, the instability of the connection, the need for situatedness.
In the IoT context, for instance, the Home Manager project
[
While Home Manager devices are supposed to be equipped with enough computational power to support their participation to the MAS and to perform the required reasoning, yet, in a more realistic scenario, some supposedly-smart devices could be not powerful enough to actually hold the computation locally—or, it could be impractical to do so because of the complexity of the required configuration. On the other hand, when enough computational power is available on the devices, the need for situatedness (along with the software engineering principles of locality and encapsulation) could instead suggest to compute directly on the Home Manager devices by querying situated Prolog engines reasoning on locally-available data.
In the overall, Home Manager – and, more generally, the smart home scenario – clearly shows how LPaaS could be an effective way to tackle multiple different aspects – from deployment to maintenance, cost issues, hardware requirements, etc. – while efficiently spreading intelligence where and when needed in pervasive contexts.
VI.
Many Prolog systems offer some form of support for
the HTTP protocol and for the exploitation of Prolog as a
service. The (Semantic) Web is one of the most promising
application areas for SWI-Prolog [
Logic programming has also been used for the composition
of Semantic Web Services: in [
While PiLLoW is an add-on library, aimed at directly
handling HTTP, CGI and other internet protocols, tuProlog
does not provide such services directly: rather, its modular
and Java-based architecture makes it easy both to embed it
in other applications, and, more generally, exploit it as a
service through its API. Other features, if necessary, could be
developed in the form of suitable tuProlog libraries and loaded
by need—for instance, as in the case of the RDF library [
VII.
Pervasive and situated systems of any sort are increasingly demanding intelligence to be scattered throughout the computational devices populating the physical environment— as clearly demonstrated by IoT scenarios like smart homes, personal healthcare assistants, energy grids, etc. To meet such a requirement, light-weight logic programming engines are a crucial need, aimed at providing the reasoning services ondemand to the most heterogeneous client applications. In its turn, this requires the logic engine to be modular, multiplatform, and multi-language—as tuProlog is.
Then, making available such a logic programming service according to the different application needs, onto heterogeneous infrastructures, and across different interaction paradigms is a matter of designing suitable wrapper interfaces around the tuProlog service API—as we have done with the iOS platform. Accordingly, future work is devoted to further extend the reach of the LPaaS paradigm considering both traditional SOA infrastructures – e.g., tuProlog as a RESTful web service – and pervasive deployment scenarios from the IoT landscape—e.g., making tuProlog available over Bluetooth Low Energy connections.
Also, building a specialised tuProlog-oriented middleware, dealing with heterogeneous platforms, as well as with distribution, life-cycle, interoperation, and coordination of multiple, situated Prolog engines – possibly based onto the existing TuCSoN middleware – is a goal for our future research, aimed at exploring the full potential of logic-based technologies in the context of IoT scenarios and applications.
Authors would like to thank Dipl. Eng. Alberto Sita for his contribution to this project and his work to the new prototype of the iOS tuProlog app. Also, we would like to thank Asia Mariani for her help in fixing the last version of the paper.