Nonostante la popolarita` del World Wide Web come piattaforma di sviluppo, una adeguata descrizione dei suoi principi architetturali e criteri di progettazione e` stata ottenuta solo recentemente, grazie alla introduzione dello stile architetturale REST (Representational State Transfer), che definisce la risorsa come la fondamentale astrazione della informazione. Difatti, i linguaggi e gli strumenti correntemente usati per programmare il Web soffrono in genere della mancanza di una corretta comprensione dei suoi vincoli architetturali e progettuali, e di una difformita` tra le astrazioni di programmazione che rende difficile sfruttare appieno le potenzialita` del Web. I linguaggi dichiarativi sono particolarmente adatti alla costruzione di sistemi di programmazione rispettosi della architettura e dei principi del Web. Tra le tecnologie di programmazione logica, tuProlog e` espressamente progettato per essere uno dei componenti abilitanti di infrastrutture basate su Internet: le sue proprieta` ingegneristiche lo rendono peraltro adatto per il Web, dove la programmazione logica permette la modifica del comportamento delle risorse a tempo di esecuzione. Di conseguenza, questo articolo presenta un modello di programmazione logica per risorse Web basato su Prolog e delinea un framework per sviluppare applicazioni Web fondato su quel modello.
Despite the popularity of the World Wide Web as a development platform, a proper description of its architectural principles and design criteria has been achieved only recently, by the introduction of the Representational State Transfer (REST) architectural style which defines the resource as the key abstraction of information. In fact, languages and tools currently used for Web programming generally suffer from a lack of proper understanding of its architecture and design constraints, and from an abstraction mismatch that makes it hard to exploit the Web potential. Declarative languages are well-suited for a programming system aimed at being respectful of the Web architecture and principles. Among logic technologies, tuProlog has been explicitly designed to be one of the enabling components of Internet-based infrastructures: its engineering properties make it suitable for use on the Web, where logic programming allows modification of resource behaviour at runtime. Accordingly, in this paper we present a Prolog-based logic model for programming Web resources, and outline a framework for developing Web applications grounded on that model. 1
Despite the World Wide Web steadily gaining popularity
as the platform of choice for the development and fruition
of many kinds of Internet-based systems, a proper
description of the Web architectural principles and design criteria
has been achieved only recently, by the introduction of the
Representational State Transfer (REST) architectural style
for distributed hypermedia systems [
Yet, from the early years of procedural CGI scripts to
the modern days of object-oriented frameworks, Web
application programming has always focussed on different
abstractions, such as page [
Declarative programming has never been accepted into
the Web mainstream, even though logic languages have
shown they could effectively handle both communication
and co-ordination in a network-based context [
Accordingly, we define a resource programming model
(called Web Logic Programming [
Web Logic Programming (WebLP) [
REST defines a resource as any conceptual target of an hypertext reference. Any information that can be named can be a resource, including virtual (e.g. a document) and nonvirtual (e.g. a person) objects. Starting from this abstract definition, the main properties of resources can be easily determined: a name (in the form of an URI); data, representing the resource state; and behaviour, to be used, for instance, to change state or manage the interaction with other resources. The defining elements of resources can be easily mapped onto elements of well-known logic programming languages such as Prolog. For each resource R we specify its name N (R) as the single quoted atom containing the resource URI identifier; data and behaviour can be further recognised as facts and rules, respectively, in a logic theory T (R) containing the knowledge base associated to the resource.
In particular, if adopted resource names are descriptive
and have a definite structure varying in predictable ways
[
To account for the possible complexity of Web computations that may involve more information than it is enclosed in a single isolated resource, the context C(R) is introduced as the locus of computation associated with each resource. The context of a resource is defined by the composition of the theories associated with the resources linked to names which are encompassed by that resource name, including the theory associated with the resource itself. Given a resource R with a name N (R) so that:
N (R) ⊆ N (R1) ⊆ . . . ⊆ N (Rn) the associated context C(R) is generated by composition:
C(R) = T (R) · T (R1) · . . . · T (Rn) where any theory T (Ri), containing the knowledge base associated to the resource Ri, can be empty – for instance when there is no entity associated to the name N (Ri). 2.2
According to REST, the Web computation model revolves
around transactions in the HTTP protocol. Each
transaction starts with a request, containing the two key elements
of Web computations: the method information, that
indicates how the sender expects the receiver to process the
request, and the scope information, that indicates on which
part of the data set the receiver should apply the method
[
Adopting a logic programming view of the Web computation model, for each HTTP transaction the request can be translated to represent a deduction by retaining the scope information to indicate the target theory, and by mapping the method information onto a proper logic goal. Then, the computation takes place on the server side of the HTTP transaction, in the context associated to the resource target of the request. Finally, the information resulting from goal solution is translated again into a suitable representation and sent back in the HTTP response.
A computation invoked by a goal G on a resource R
triggers the deduction of G on the context C(R). The
composition of theories forming C(R) is then traversed in a
very similar way as units in Contextual Logic
Programming (CtxLP) [
As an example, consider the user jdoe in a bookshelf sharing application, where her shelf is represented by the resource S, identified by the URI http://example.com/jdoe/shelf. Suppose that, according to a proper naming scheme, the resource B for biology books lives at /jdoe/shelf/biology. When a GET request is issued for that resource, a predicate pick biology books/1 is ultimately invoked on B, depending on a pick books/3 predicate that is neither defined in B nor in S. The theory chain in C(B) is then traversed backwards up to the http://example.com resource, as depicted in Figure 1, where a suitable definition for pick books/3 is finally found. Definitions for other predicates invoked by it are then searched starting from the context of the root resource, rather than C(B) where the computation originally started.
The fixed structure of URIs as resource identifiers makes the composition of theories forming a context static, differently from CtxLP, where it was possible to push or pop units from the context stack at runtime. The structure of identifiers and resources in the Web architecture also dictates a unique direction in which the theories associated to resources composing a context can be traversed: from the outermost (associated with the resource on which the computation has been invoked) to the innermost, passing through the theories belonging to each of the composing resources, until the host resource is finally involved. 2.3
The behaviour of a resource can be regarded as dynamic under two independent aspects. First, two or more URIs can be associated to the same resource at any time: that is, the names N1(R), . . . , Nm(R) may identify the same resource R, thus the same knowledge base contained in the theory T (R) associated to the resource. Each different name Ni(R) also identifies a different context Ci(R) that the same resource R may live within, (see Figure 2); therefore, predicates that are used in T (R), but are not defined there, may behave in different ways based on the definition given by the context where the resource is called.
The second dynamic aspect of a resource comes from the ability to express behavioural rules as first-class abstractions in a logic programming language: on the one hand, well-known logic mechanisms for state manipulation (the assertz/1 and retract/1 predicates) can be exploited to change the knowledge base associated to a resource; on the other, the HTTP protocol itself allows changing a resource by means of a PUT request, whose content should be considered as a modified version of the target resource that has to replace (or be merged with) the original version residing on the server.
As an example, imagine a reading wish list in the previous bookshelf application. Usually, when a book is added, the resource representing the wish list could check local libraries for book availability, and possibly borrow it on user’s behalf; if no book can be found, the resource could check its availability in online bookstores, reporting its price to the user for future purchase. During the period of time when an online bookstore offers discounts, the wish list resource should react to the insertion of new books so as to check that store first instead of libraries.
The Web application could then be instructed to change the behaviour of wish list resources by issuing HTTP PUT requests that modify the computational representation of those resources. The PUT requests would carry the new rules in the content, so that wish list resources would accordingly modify their knowledge base. The application could programmatically restore the old behaviour at the end of the discount period, by sending another PUT request containing the previous rule set for each wish list resource. 3
tuProlog: Logic Technology for the Web
tuProlog is a minimal Java-based system explicitly
designed to integrate configurable and scalable Prolog
components into standard Internet applications, and to be used
as the core enabling technology for the provision of basic
coordination capabilities into complex Internet-based
infrastructures [
With the aim of sketching a WebLP framework, a
minimal Prolog engine such as tuProlog would need to be
augmented with a construct very similar to logic contexts,
for which various implementation techniques exist,
ranging from the least intrusive meta-interpretation to the most
effective virtual machine enhancing. With a similar
intent, the architecture of tuProlog has been recently
reengineered to feature the malleability property [
The pervasive integration with Java featured by tuProlog
[
The development of tuProlog as a server-side Web technology and of the WebLP framework will be the main focus of our activity in the near future. Afterwards, we also plan to explore possible extensions of the programming model, mostly based on experience in building a variety of applications on the framework.