366 research outputs found
First Smart Spaces
No full textThis document describes the Gloss software currently implemented. The description of the Gloss demonstrator for multi-surface interaction can be found in D17. The ongoing integration activity for the work described in D17and D8 constitutes our development of infrastructure for a first smart space. In this report, the focus is on infrastructure to support the implementation of location aware services. A local architecture provides a framework for constructing Gloss applications, termed assemblies, that run on individual physical nodes. A global architecture defines an overlay network for linking individual assemblies. Both local and global architectures are under active development
A methodology for developing and deploying distributed applications
No full textWe describe a methodology for developing and deploying distributed Java applications using a reflective middleware system called RAFDA. We illustrate the methodology by describing how it has been used to develop a peer-to-peer infrastructure, and explain the benefits relative to other techniques. The strengths of the approach are that the application logic can be designed and implemented completely independently of distribution concerns, easing the development task, and that this gives great flexibility to alter distribution decisions late in the development cycle
A flexible, policy-aware middleware system
No full textMiddleware augments operating systems and network infrastructure to assist in
the creation of distributed applications in a heterogeneous environment. Current
middleware systems exhibit some or all of the following five main problems:
1. Decisions must be made early in the design process.
2. Applications are inflexible to dynamic changes in their distribution.
3. Application development is complex and error-prone.
4. Existing systems force an unnatural encoding of application-level semantics.
5. Approaches to the specification of distribution policy are limited.
This thesis defines a taxonomy of existing middleware systems and describes their
limitations. The requirements that must be met by a third generation middleware system
are defined and implemented by a system called the RAFDA Run-Time (RRT). The RRT
allows control over the extent to which inter-address-space communication is exposed to
programmers, aiding the creation, maintenance and evolution of distributed applications.
The RRT permits the introduction of distribution into applications quickly and
with minimal programmer effort, allowing for quick application prototyping.
Programmers can conceal or expose the distributed nature of applications as required. The RRT allows instances of arbitrary application classes to be exposed to remote access as Web Services, provides control over the parameter-passing semantics applied to
remote method calls and permits the creation of flexible distribution policies. The design of the RRT is described and evaluated qualitatively in the context of a case study based around the implementation of a peer-to-peer overlay network. A prototype implementation of the RRT is examined and evaluated quantitatively.
Programmers determine the trade off between flexibility and simplicity offered by
the RRT on a per-application basis, by concealing or exposing inter-address-space
communication. The RRT is a middleware system that adapts to the needs of applications, rather than forcing distributed applications to adapt to the needs of the middleware system
Autonomic management in a distributed storage system
No full textThis thesis investigates the application of autonomic management to a distributed storage
system. Effects on performance and resource consumption were measured in experiments,
which were carried out in a local area test-bed. The experiments were conducted with
components of one specific distributed storage system, but seek to be applicable to a wide range of such systems, in particular those exposed to varying conditions.
The perceived characteristics of distributed storage systems depend on their configuration
parameters and on various dynamic conditions. For a given set of conditions, one specific configuration may be better than another with respect to measures such as resource
consumption and performance. Here, configuration parameter values were set dynamically
and the results compared with a static configuration. It was hypothesised that under non-changing conditions this would allow the system to converge on a configuration that was
more suitable than any that could be set a priori. Furthermore, the system could react to
a change in conditions by adopting a more appropriate configuration. Autonomic management was applied to the peer-to-peer (P2P) and data retrieval components of ASA, a
distributed storage system. The effects were measured experimentally for various workload and churn patterns. The management policies and mechanisms were implemented
using a generic autonomic management framework developed during this work.
The motivation for both groups of experiments was to test management policies with the objective to avoid unsatisfactory situations with respect to resource consumption and performance. Such unsatisfactory situations occur when either the P2P layer or the data retrieval mechanism is configured statically. In a statically configured P2P system two unsatisfactory situations can be identified. The first arises when the frequency with which P2P node states are verified is low and membership churn is high. The P2P node state becomes inaccurate due to a high membership churn, leading to errors during the routing process and a reduction in performance. In this situation it is desirable to increase the frequency to increase P2P state accuracy. The converse situation arises when the frequency is high and churn is low. In this situation network resources are used unnecessarily, which may also reduce performance, making it desirable to decrease the frequency.
In ASA’s data retrieval mechanism similar unsatisfactory situations can be identified with respect to the degree of concurrency (DOC). The DOC controls the eagerness with which multiple redundant replicas are retrieved. An unsatisfactory situation arises when the DOC is low and there is a large variation in the times taken to retrieve replicas. In this situation it is desirable to increase the DOC, because by retrieving more replicas in parallel a
result can be returned to the user sooner. The converse situation arises when the DOC is
high, there is little variation in retrieval time and there is a network bottleneck close to the requesting client. In this situation it is desirable to decrease the DOC, since the low variation removes any benefit in parallel retrieval, and the bottleneck means that decreasing parallelism reduces both bandwidth consumption and elapsed time for the user.
The experimental evaluations of autonomic management show promising results, and suggest several future research topics. These include optimisations of the managed mechanisms, alternative management policies, different evaluation methods, and the application of developed management mechanisms to other facets of a distributed storage system. The findings of this thesis could be exploited in building other distributed storage systems that focus on harnessing storage on user workstations, since these are particularly likely to be exposed to varying, unpredictable conditions
Cache Coherence and Storage Management in a Persistent Object System
No full textA distributed architecture for the support of programs written in the persistent programming language Napier is described. The architecture consists of a central server containing the stable persistent store and a collection of clients, each executing Napier processes. Since each client has a cache of objects, some of which may be shared with other clients, a protocol is required to ensure that the caches are coherent and that any access of an object will be to the most up-to- date copy. This architecture is explicated by following the lifecycle of an object from its ‘birth’ inside a client, through its life in the persistent store and its migration into other clients. Using this vehicle, the coherency protocol and client/server architecture are illustrated and explained
A Framework for Comparing Type Systems for Database Programming Languages
No full textSeveral proposals have been published in recent years for database programming languages (DBPLs), many of which have been object-oriented. Our goal in this paper is not to argue for or against specific solutions, but simply to provide a framework for comparing certain critical points of type system design. This framework may be used in the description of a DBPL. It is our hope that the framework will promote clear communication among designers and developers of DBPLs. 1 Introduction At the Second Object-Oriented Database Workshop [OO88], the first author posed a set of questions as a way of urging people to be clear when talking about types and/or classes. This brief paper expands on those questions in an effort to provide a framework for describing type systems that can be used to compare programming languages in a meaningful manner. We have divided the questions to be asked into five areas. The first is discussed in Section 2 and has to do with the nature of the type system. Section..
A middleware framework for constraint-based deployment and autonomic management of distributed applications
No full textSubmitted to Middleware 04 Funded by the EPSRC UK grant GR/S44501 "Secure LocationIndependent Autonomic Storage Architectures"We propose a middleware framework for deployment and subsequent autonomic management of component-based distributed applications. An initial deployment goal is specified using a declarative constraint language, expressing constraints over aspects such as component-host mappings and component interconnection topology. A constraint solver is used to find a configuration that satisfies the goal, and the configuration is deployed automatically. The deployed application is instrumented to allow subsequent autonomic management. If, during execution, the manager detects that the original goal is no longer being met, the satisfy/deploy process can be repeated automatically in order to generate a revised deployment that does meet the goal
Current directions in hyper-programming
No full textThe traditional representation of a program is as a linear sequence of text. At some stage in the execution sequence the source text is checked for type correctness and its translated form is linked to values in the environment. When this is performed early in the execution process, confidence in the correctness of the program is raised. During program execution, tools such as debuggers are used to inspect the running state of programs. Relating this state to the linear text is often problematical. We have developed a technique, hyperprogramming, that allows the representations of source programs to include direct links (hyper-links) to values, including code, that already exist in the environment. Hyperprogramming achieves our two objectives of being able to link earlier than before, at program composition time, and to represent sharing and thus closure and through this the run-time state of a program. This paper reviews our work on hyper-programming and proposes some current research areas
A generic storage API
No full textSubmitted to ACSC 2004 This work was supported by EPSRC grant GR/R45154 "Bulk Storage of XML Documents"We present a generic API suitable for provision of highly generic storage facilities that can be tailored to produce various individually customised storage infrastructures. The paper identifies a candidate set of minimal storage system building blocks, which are sufficiently simple to avoid encapsulating policy where it cannot be customised by applications, and composable to build highly flexible storage architectures. Four main generic components are defined: the store, the namer, the caster and the interpreter. It is hypothesised that these are sufficiently general that they could act as building blocks for any information storage and retrieval system. The essential characteristics of each are defined by an interface, which may be implemented by multiple implementing classes
A framework for constraint-based deployment and autonomic management of distributed applications (extended abstract)
No full textThis work is supported by EPSRC Grants GR/M78403, GR/R51872, GR/S44501 and by EC Framework V IST-2001-32360We propose a framework for the deployment and subsequent autonomic management of component-based distributed applications. An initial deployment goal is specified using a declarative constraint language, expressing constraints over aspects such as component-host mappings and component interconnection topology. A constraint solver is used to find a configuration that satisfies the goal, and the configuration is deployed automatically. The deployed application is instrumented to allow subsequent autonomic management. If, during execution, the manager detects that the original goal is no longer being met, the satisfy/deploy process can be repeated automatically in order to generate a revised deployment that does meet the goal.Peer reviewe
- …
