This paper describes a new prototype of a semantic Service Oriented Architecture (SOA) called Spec Services. Instead of publishing their API through a protocol like SOAP, as Web Services do, services can register to a service manager a powerful syntactic description or even semantic description of their capabilities. The client entity will then send a syntactic or semantic description of its requirements to the service manager, which will try to find an appropriate formerly registered service and bind them together. Today our service manager can deal with two languages: regular expressions, which is probably the most powerful syntactic-only description language; Prolog, which is only semantic. Nevertheless, this implementation is made, since its beginning, with evolution in mind, i.e. to easily support integration of new additional formal languages.
This report defines synchronised Petri nets with inhibitor arcs and an extension of these nets that integrates real-time constraints. The semantics of these nets is given by a transition system built using Structured Operational Semantics (SOS) rules. This report is part of a larger framework that attempts to attach real-time constraints to the CO-OPN/2 language.
The rapid expansion of Java programs into software market is often not supported by a proper development methodology. Here, we present a formal development methodology well-suited for Java dependable distributed applications. It is based on the stepwise refinement of model-oriented formal specifications, and enables validation of the obtained system wrt the client's requirements. Three refinement steps have been identified in the case of fault-tolerant distributed applications: first, starting from informal requirements, an initial formal specification is derived. It does not depend on implementation constraints and provides a centralized solution, second, dependability and distribution constraints are integrated; third, the Java implementation is realised. The CO-OPN/2 language is used to express specifications formally; and the dependability and distribution design is based on the Coordinated Atomic action concept. The methodology and the three refinement steps are presented through a very simple fault-tolerant distributed Java application.
Mobile software agents require a distributed execution environment in which they can command the use of many resources like memory, CPU time and bandwidth. While current research seems to concentrate on roaming agents at the application level and tries to define suitable high–level environments, we think that such an execution environment must be rooted at a very low-level. We argue that these environments have very in common with distributed micro-kernels, and that therefore one should position them even below current operating systems. In this paper we report on the implementation of such a micro-kernel built for communications messengers (messengers are autonomous threads of control that can travel through the network: they are the low-level elements from which higher-level agents can be built). We present our viewpoint and describe the current state and some implementation considerations of our Messenger Operating System prototype MOS.
This working paper lists some ideas on how to apply category theory to agents, and multi-agent systems. It focuses more on the distributivity and compositionality of agents, as well as on the emergence of sociality and properties, than on the intelligence or on the ability of agents to reason. It presents some categorical notions, and explains informally how they can be connected with agents and multi-agent systems.
The messenger paradigm is an alternative to computer communication based on the exchange of programs called messengers which are afterwards executed, instead of messages that are interpreted. The communication by messenger paradigm can be used to implement both low level software such as communication protocols and high level software such as distributed applications. Using the messenger paradigm for computer communication requires that each host be "equipped" with a runtime environment called messenger platform that can execute messengers that reach the platform. MØ is one such platform. MOS is a distributed micro-kernel designed for the efficient execution of messengers and implemented on i386 machines; it contains a MØ platform. It supports the concurrent execution of messengers on a given node. Messengers running on the same node can exchange data through a common store. Messenger behavior is expressed in the MØ messenger language understood by all messenger platforms. MØ is an interpreted language. Messengers see the memory provided by a MOS as a set of dictionaries where information is stored as pairs consisting of a key and a value. The key is used to access the value associated to a given information. In this paper, we present a memory consistency model, called access consistency, that is well suited to implement a distributed shared memory to extend the common store available for messengers running on the same MOS node to spawn a network of MOS nodes; i.e. to allow messengers to share information irrespecive of their physical location in the network.
Mobile code is more and more accepted as a promising alternative for structuring distributed applications. The messenger paradigm is the approach to mobile code used in this paper. Messengers are threads of control that can move in a network of messenger platforms to search for resources and information they need to accomplish their task. They are expressed in the MØ messenger language and are interpreted by messenger platforms. MØ is one such platform. We present in this paper an architecture for distributed services in a messenger environment, i.e., for services implemented with messengers and that are designed to run in a network of messenger platforms. The interaction between a service and its consummers (for example between a server and a client) requires that the interaction interface be known by the two parties before interaction can occur. The classical approach is to establish this interface at development time, making it quite impossible for a client to interact with a service for which it has not been prepared for. With the combined potential of mobile code and code interpretation, it is no longer necessary to know the service interface at development time in order to implement a client that can interact appropriately with the service. In fact, the service is published with its operational interface which describes the necessary information to interact with it. The client discovers the service at run time time, interprets its interface description and collects from it at that moment the necessary information to interact with the service. A service interface is described in an interface description language that is understood by the service clients. Moreover, the use of mobile code and the ability to generate and interpret code on-the-fly make it useless to predefine a protocol in order to achieve interaction between a service and its client. The service can unilateraly move code on the client side where it is executed.
This technical report presents the syntax and semantics, in terms of transition system, of the messenger paradigm as it has been presented in [8]. Messengers are mobile agents able to collaborate and to coordinate their work, but are not considered as intelligent agents. More precisely, messengers are mobile codes exchanged between messenger platforms. Arriving messengers are immediately executed (interpreted) by platforms. Messengers communicate by the means of a global store, synchronize their execution using process queues, create new messengers and move themselves across the network using appropriate instructions. The purpose of this mathematical formalization is to give a mathematical definition to the basic ingredients of the messenger paradigm: communication through global store, synchronization through process queues, creation of new messengers, and mobility. This formalization is neither concerned with families of messengers collaborating to solve a common goal, nor with the notion of messenger taking part to a service. Further work will be concerned with the choice of a formalism well suited for messengers' specifications.
In this document we give an overview of the CO-OPN/1.5 (Concurrent Object-Oriented Petri Nets) specification language and describe the features of each tool provided in the SANDS/1.5 (Structured Algebraic Net Development System) development environment. The CO-OPN/1.5 language is a specification language devised to support the development of large concurrent systems. The underlying formalisms of the language are algebraic specifications and Petri nets in which tokens correspond to algebraic values. Furthermore, in order to deal with large specifications, some structuring principles have been introduced and in particular, object-orientation paradigm has been adopted for the Petri nets. This means that a CO-OPN/1.5 specification is a collection of objects which interact concurrently. Interaction between the objects is achieved by means of synchronization expressions which allow the designer to select the object interaction policies. The development system provides many different tools such as a syntax checker, a simulator, a property verifier based on temporal logic, a graphic editor, a transformation tool supporting the derivation of specifications, an Ada translator which allows to analyze Ada programs in the CO-OPN/1.5 framework, and a MIMD compiler.
This report proposes to employ messengers, initially developed in the context of communication protocols, as a fundamental component of the architecture of distributed operating systems. Current microkernels offer non-local services which require the collaboration of neighboring machines or special servers and are implemented using special protocols. These protocols are hard-wired into the microkernel and can not easily be changed, which is problematic for interworking and scaling. We propose a modified software architecture for operating systems where all non-local services are implemented outside the basic software coat that hides the hardware. The key element of such an architecture are messengers i.e., worm-like programs exchanged between neighboring machines: they represent an intermediate layer between the basic computing platform and the operating system to support. Operating systems are still run in native mode but under the control of messengers. An important element of this architecture is a currency mechanism used to control the resource allocation of messengers and the implemented operating systems.
