- A middleware for dynamic evolution of code (LuckyJ).
The LuckyJ environment, allows client programs
to specify and locate services based on properties that clients
specify. In
addition, the services can be upgraded during execution without halting
or
provoking an error in the client program. This run-time
environment
acts as a middleware layer that allows programs to deposit a
specification
of their behaviour at run-time, and specifications that describe a
service
required. This is an important feature of self-organising applications
since
the application transparently adapts to new (or updated) services
introduced
into the environment. This environment currently only allows the
description
of basic specification relying on an ontology shared among all the
participating
services.
- Specification carrying code as a basic interaction
mechanism.
Entities carry a specification of the
functional as well as non-functional capabilities they offer to the
community, and
a proof that their specification is correct. The specification is
expressed using a specification language, e.g., a higher-order
logical language, it defines a theory comprised of: functions, axioms
and theorems, conveying the semantical part of the specification.
Before interacting with
a requesting entity, a principal may prove (through run-time proof
checking) some of its own theorem on the submitted theory. This allows
a principal
to interact with another principal only if it can prove that the way it
intends to work corresponds to what is expected. The important thing to
note here is that entities do not share any common API related to the
offered/requested service.
- A flexible modular architecture for autonomous systems
interacting through specifications.
This architecture, derived from LuckyJ (see
above), allows entities to carry specifications expressed using
different kinds
of specification language, to perform the corresponding matching, and
method calls. This architecture implements simple primitives for an
entity to register its specifications, or for requesting a service, and
for the environment
to execute the corresponding requested code once it has been found. The
underlying model is modular enough to allow easy integration of new
specification languages.
- A prototype including specifications expressed either in
Prolog, or as regular expressions.
The above architecture currently allows specifications written in
Prolog, or as regular expressions. In the case of Prolog, the
middleware calls SWI Prolog tool to decide about the conformance of two
specifications, in the case of regular expressions we have implemented
a tool that checks two regular expressions, and is able to transform
them into Java code.
- A preliminary set of tools for managing specifications, and
codes.
This set of tools helps: 1. to specify correct specifications in Prolog
or as regular expressions (Regex), 2. to test whether the specification
will correctly match a request or an announced specification and to
transform
them into XML files (SpecEditor); 3. to manually handle addition and
removal
of entities from the system (useful for testing and debugging).
- MiniVM.
In order to minimises the basic execution layer that needs to
be run on all devices participating in an self-organising application,
we have implemented a "mini" Java virtual machine where common
program services such as compilation, class loading and garbage
collection are extracted
and run as services that client programs locate and exploit in a
self-organising fashion. In addition, this VM allows core
services to evolve as easily as middleware services. The MiniVM is
based on the Lana programming model and is implemented using the Joeq
virtual machine. In a first stage, the
compiler and class loader were extracted from the Joeq code base, the
compiler
was modified to generate address neutral code, and a linker layer was
added
to replace the relocatable addresses in the code image with fixed
addresses. The Lana object-oriented programming model is added on top
of this. The Lana model suits well self-organising applications,
since it contains a discovery layer that allows programs to locate
devices in their vicinity, and to announce and locate services using a
message board that each device carries. In addition, communication
between programs is secure and asynchronous. When a method call is
made, a security key is generated for the caller that allows it to
asynchronously detect a reply to the call, even if a network
disconnection occurs during the method execution. The MiniVM approach
allows programs to search their network for required services, and to
simplify
the environment so that all programs can share basic services such as
compilation and garbage collection.