Showing papers by "Jean-Yves Girard published in 1999"

On the meaning of logical rules I : Syntax versus semantics

Abstract: « Oui c’est imbecile ce que je dis ! Seulement je ne sais pas comment concilier tout ca. Il est sur que je ne me sens libre que parce que j’ai fait mes classes et que je ne sors de la fugue que parce que je la sais. »

Typed Lambda Calculi and Applications

Abstract: This short paper gives a quick overview of CLF, a distributed object coordination middleware, and two applications of that platform to workflow. The driving concepts behind CLF derive from a reflection on proof search in Linear Logic, and in particular, the systematic exploitation of its resource conscious nature. 1 CLF: A Coordination Middleware CLF is born from a reflection on the application of Linear Logic to distributed object coordination. It exploits the resource-conscious nature of Linear Logic in the framework of the concurrent logic programming paradigm, where computations are identified with proof-search [And92]. Turning a theoretical model of resource manipulation into a concrete distributed object coordination middleware required two main steps: – First, the notions of “resources” and “objects” had to be integrated. This was achieved through a modification of the traditional object model of computation, making plain the role of objects as resource managers. – Second, the concurrent logic programming paradigm of proof search had to be adapted to this new object model. This was realized by a scripting language based on Linear Logic formulae to express coordination. 1.1 The CLF Object Model The CLF object model enriches the traditional one by viewing objects as resource managers, thus separating, inside the object state, the resources themselves from their management state. Primitives are introduced to (i) inquire and negotiate objects capabilities in terms of resource availability, (ii) perform basic transaction operations over the resources of several objects (two-phase commit) and (iii) request resource insertion. This enriched interaction model (Figure 1) is characterized by a set of 8 interaction verbs (similar to KQML performatives) together with a protocol describing correct sequences of invocations of these verbs, and their intended meaning in terms of resource manipulations. Figure 2 gives an overview of the verbs and the protocol. The interface of a CLF object distinguishes between “CLF services”, accessed through the CLF interaction protocol, and regular methods, accessed through the traditional request/answer protocol. J.-Y. Girard (Ed.): TLCA’99, LNCS 1581, pp. 1–5, 1999. c © Springer-Verlag Berlin Heidelberg 1999 2 Jean-Marc Andreoli 1.2 The CLF Coordination Scripting Facility The CLF coordination scripting facility takes full advantage of the object model. It allows high-level declarative specifications of coordinated invocations of CLF object services. A coordination is viewed here as a complex block of inter-related manipulations (removal, insertion, etc.) of the resources held by a set of objects (called the participants of the coordination). CLF scripts describe, using Linear Logic formulae, the expected global behavior of such blocks in terms of resulting resource transformations, but abstracts away the detailed sequencing of invocations of the CLF interaction verbs required to achieve such a behavior. It is this abstraction feature which considerably simplifies the design and verification of coordination scripts and makes them highly platform independent and hence, portable. The abstract operational semantics of CLF scripts is given in terms of proof search. Currently, the fragment of Linear Logic used by the CLF scripting language is a small subset of LinLog [And92], which is itself a “complete” fragment of Linear Logic in terms of proof search (complete in the sense that proof search in full Linear Logic can be reduced without loss to proof search in LinLog). Extensions of CLF to larger fragments of LinLog are possible, and may lead to further refinements of the object model. 2 The Demonstration: Applications of the CLF There are two ways to demonstrate a middleware tool such as CLF: (i) focus on the middleware platform itself, but this is rather aimed at a somewhat specialized audience (developers of distributed object-based applications); (ii) show applications (or rather prototype applications) which have been developed using the platform. We propose to demonstrate here two prototype applications developed using CLF. The first one, called XFolder, is a lightweight workflow management system; the second one called XPect [AP98], is a generic electronic commerce broker. 2.1 XFolder: a Lightweight Workflow Management System XFolder uses the metaphor of the well-known circulation folder envelope to organize lightweight workflow within an organization or across several independent organizations (with possible access restrictions between them). A circulation folder consists of a set of documents, enclosed in an envelope, and a route, usually specified on the envelope, and describing the expected path of the envelope through different services (or people) of the organization(s) and the tasks to be performed at each stop. Whenever a user gets hold of the envelope, s/he can perform the current task assigned to it (e.g. read, create, modify, annotate a document, sign a sheet, insert a memo etc.), and, possibly, modify the route (e.g. extend it or change some tasks), then forward it. XFolder implements an electronic version of the traditional circulation folder, with additional features allowed by this “virtualization”. The architecture of the The Coordination Language Facility and Applications 3 system is described in Figure 3. The documents contained in the envelope are held in electronic form in heterogeneous document repositories implemented as CLF objects (the resources of which are the documents). The status of the individual folders (route, current active task in the route, assignment of tasks etc.) are held in a specific CLF object, the XFolder manager (the resources of which are the virtual envelopes). CLF scripts handle the notification of available tasks to each user, implement the task status transformation as tasks are performed, and take care of migrating documents across different repositories when needed (i.e. when a firewall or some access restriction prevents a document reference from being directly shared between users). 2.2 XPect: an Electronic Commerce Broker XPect realises the functionality of a broker for electronic commerce. It handles the coordination of the different partners involved in an electronic commerce transaction: customers, bankers, providers, delivery providers etc. Basically, the customer submits a query to the broker, describing items of interest. The broker browses through the catalogs of the different providers to extract offers matching the query constraints (description of good, required options, price limits etc.). The user may then select a set of different offers for purchase. This is different from the “shopping basket” of traditional electronic commerce systems in the sense that the selected items are considered as a whole: either all of them are available at the condition of the offers, and the commercial transaction is continued, or the whole transaction is cancelled (but the customer can always resume the search phase). This atomic behavior is ensured even across independent providers (e.g. with queries of the form “24x36mm camera from provider A and a matching 50mm lens from provider B”, or “10 hardcopies of a book X from bookshop A and a 24-hour delivery of the whole set from provider B”). XPect is implemented as a CLF application. The architecture of the system is described in Figure 4. The CLF objects involved are the providers, offering virtual or hard goods classified in catalogs, the financial services (credit cards, electronic cash etc.) and the customer management services. CLF scripts are used to implement the different phases of the electronic commerce transaction.