Event-based systems are developed and used to integrate components in loosely coupled systems. Research and product development focused so far on e#ciency issues but neglected methodological support to build such systems. In this article, the modular design and implementation of an event system is presented which supports scopes and event mappings, two new and powerful structuring methods that facilitate engineering and coordination of components in event-based systems. We give a

Event notification services enable loose coupling and they are therefore becoming an essential part of distributed systems' design. However, the development of event services follows the early stages of programming language evolution, disregarding the need for efficient mechanisms to structure event-based applications. In this paper, the well-known notion of scopes is introduced to event-based systems. We show that limiting the visibility of events is a simple yet powerful mechanism that allows to identify application structure and offers a module construct for the loosely coupled components in event-based systems. We are able to customize the semantics of scoped event notification services by binding meta-objects to the application structure that reify important aspects of notification delivery, like interface mappings and transmission policies. The scoping concept facilitates design and implementation by offering encapsulation and adaption of syntax and semantics of eventbased systems.

Abstract. The increasing popularity of XML Web services motivates us to examine if it is feasible to substitute one vendor service for another when using a Web-based application, assuming that these services are “derived from ” a common base. If such substitution were possible, end users could use the same application with a variety of back-end vendor services, and the vendors themselves could compete on price, quality, availability, etc. Interoperability with substituted services is non-trivial, however, and four types of incompatibilities may arise during such interoperation – structural, value, encoding and semantic. We address these incompatibilities three-fold: (1) static and dynamic analysis tools to infer whether an application is compatible with a substituted service, (2) semiautomatically generated middleware components called cross-stubs that actually resolve incompatibilities and enable interoperation with substituted services, and (3) a lightweight mechanism called multi-option types to enable applications to be written from the ground up in an interoperation-friendly manner. Using real applications and services as examples, we both demonstrate and evaluate our tools and techniques for enabling interoperation with substituted services. 1

Upgrading the software of long-lived, highly-available distributed systems is di#cult. It is not possible to upgrade all the nodes in a system at once, since some nodes may be unavailable and halting the system for an upgrade is unacceptable. Instead, upgrades may happen gradually, and there may be long periods of time when di#erent nodes are running di#erent software versions and need to communicate using incompatible protocols. We present a methodology and infrastructure that address these challenges and make it possible to upgrade distributed systems automatically while limiting service disruption.

Motivation: The biggest public domain biological sequence archive exceeds 6Gbases of DNA 1 and much larger sequence amounts are held by industrial labs. The amount of data is growing exponentially but sequence search technologies still rely on flat file storage and high-throughput parallel computers reading all data sequentially to find sequence similarities or patterns. This issue is not addressed by existing database technologies. Results: We explored DNA and protein sequence indexing using transient and persistent suffix trees and tested our retrieval methods with human, worm and bacterial DNA, and protein data sets. Our index structure is designed in Java and takes advantage of orthogonal persistence for Java, PJama. Our exact sequence search methods deliver excellent performance and will complement our existing genome map applets by showing sequence query hits in genomic context. 1

We render runtime system adaptations by design-level concepts such that running systems can be adapted and examined at a higher level of abstraction. The overall idea is to express design decisions as applications of design operators to be carried out at runtime. Design operators can implement design patterns for use at run-time. Applications of design operators are made explicit as design elements in the running system such that they can be traced, reconfigured, and made undone. This approach enables reflective designs: on one side, design operators employ re-flection to perform runtime adaptations; on the other side, design elements provide an additional reflection protocol to examine and configure performed adaptations. Our approach helps understanding the development and the maintenance of the class of software systems that cannot tolerate downtime or frequent shutdown-revise-startup cycles. We have designed and implemented a class library for programming with reflective designs in Squeak/Smalltalk. Our library employs reflection and dynamic aspect-

. Current enterprise infrastructures based on CORBA have to rely on ad-hoc mechanisms for system software evolution. The CORBA services specifications do not address the problems associated with evolving modern software systems, leaving the programmer to manage the complexity. The DRASTIC system provides a run-time environment in which the evolution of software is directly supported. With reference to DRASTIC, this paper describes how CORBA may be extended to more effectively support software evolution. 1 Introduction OMG's CORBA [Obj95a] defines a concept called the domain. CORBA domains can be of many types: management domains; naming domains and language domains, to name just three. However, CORBA does not directly address the issue of software evolution. The complexities involved in handling CORBA system evolution are exposed to the programmer and CORBA offers no means of constraining the effects of evolution. The DRASTIC 1 project is developing and demonstrating a new systems s...

This paper describes the first version of the distributed programming architecture for the Grumps 1 project. The architecture consists of objects that communicate in terms of both asynchronous and synchronous events. A novel three-level extensible naming scheme is discussed that allows Grumps developers to deploy systems that can refer to entities not identified at the time when the Grumps system and application-level code were implemented. Examples detailing how the topology of a Grumps system may be changed at run-time and how new object implementations may be distributed during system execution are given. The separation of policy from mechanism is shown to be a major part of how system evolution is supported and this is made even more flexible when expressed through the use of Java interfaces for crucial core concepts. 1

Abstract. In an environment of constant change, driven by competition and innovation, a service can rarely remain stable- especially when it depends on other services to fulfill its functionality. However, uncontrolled changes can easily break the existing relationships between a service and its environment (its customers and providers). In this paper we present an approach that allows for the controlled evolution of a service by leveraging the loosely-coupled nature of the SOA paradigm. More specifically, we formalize the notion of contracts between interacting services that enable their independent evolution and we investigate under which criteria can changes to a contract-bound service, or even to the contract itself, be transparent to the environment of the service.

Abstract. Current enterprise infrastructures based on CORBA have to rely on ad-hoc mechanisms for system software evolution. The CORBA services speci cations do not address the problems associated with evolving modern software systems, leaving the programmer to manage the complexity. The DRASTIC system provides a run-time environment in which the evolution of software is directly supported. With reference to DRASTIC, this paper describes how CORBA may be extended to more e ectively support software evolution. 1