A dynamic system is one that changes its configuration as it runs. It is a system into which we can drop new components that then cooperate with the existing ones. We are concerned with formally defining architectures for such systems and with realistically validating designs for applications that run on those architectures. We describe a generic architecture based on the familiar registry services of CORBA, DCOM and Jini. We illustrate this architecture by formally describing a simple point-of-sale system built according to this architecture. We then look at the sorts of global properties that a designer of applications would wish a robust system to have and discuss variations on the architecture which make validation of applications more practical. Keywords Architecture Modelling, Dynamic Systems, Reconfigurable Systems, Formal Models, Validation 1

Abstract. Designing systems of asynchronous web services is challenging. Addressing the design in terms of component reuse helps address important questions that need to be answered if dynamic configuration of business solutions from web services is to be achieved. The fact that the components are web services doesn’t mean that all the problems of reuse have been solved. An architecture for dealing with reuse and dynamic reconfiguration, based on stateless services and stateful messages, is investigated. A notation for describing the flow of documents in such a system is introduced. This is shown to be effective at describing the behaviour of components, a necessary part of designing reusable components, especially those that participate in long-running, asynchronous interactions. 1

When a new component is added to an existing, distributed system, it has to co-operate with existing components in a way that doesn’t interfere badly with the original system. Adding new components to an existing system is simplified if their communication is asynchronous. It allows for looser coupling. Unfortunately, the fact that the communication between components is asynchronous adds to the difficulty of reasoning about their behaviour. This paper gives an illustrative example of a simple distributed system with asynchronous behaviour and discusses how its behaviour can be described and reasoned about in terms of goals. This formalises what we believe to be contemporary engineering practice. Experimental support for reasoning, including animation, is particularly appropriate and practical in these circumstances, because the properties which we must reason about are emergent rather than compositional. 1

Abstract. This paper provides some results and analysis of several negotiation algorithms. We have used a tournament-based approach to evaluation and applied this within a community of Buyers and Sellers in a simulated car hire scenario. An automated negotiation environment has been developed and the various negotiation algorithms made to compete against each other. In a single tournament, each algorithm was used as both a Buyer-negotiator and a Sellernegotiator. Each negotiating algorithm accommodates the parameters for negotiation as a set of desirable goals, represented as examples of product specifications. It was the task of each negotiating algorithm to get the best deal possible from every one of their opposites (i.e. Buyer versus Seller) in the sense of being close to the examples they were given as goals. One algorithm proved to be superior to the others against which it was made to compete. 1

Software Engineers continue to search for efficient ways to build high quality systems. Two contrasting techniques that promise to help with the effective construction of high quality systems are the use of formal models during design and the use of components during development. In this paper, we take the position that these techniques work well together. Hardware Engineers have shown that building systems from components has brought enormous benefits. Using components permits hardware engineers to consider systems at an abstract level, making it possible for them to build and reason about systems that would otherwise be too large and complex to understand. It also enables them to make effective reuse of existing designs. It seems reasonable to expect that using components in software development will also bring advantages. Formal methods provide a means to reason about a program (or system) enabling the creation of programs which can be proved to meet their specifications. However,...

this paper is that of a retail business activity. A typical component in that example is a (virtual) shop that we describe as four applications around one database (take a glance at Figure 2, which we will describe fully later). Because the basic component that we propose to build from has the characteristics of being active (it comprises one or more applications), being persistent (it comprises one or more databases) and being large, we shall use the term capability-server for it, to draw attention to these significant aspects. If we just used the term component or application, we might convey the impression that that we recommend the technique for use at a more detailed level than we shall address here. The term capability-server is intended to capture the notion that capabilities are being provided, where a capability is access to information or to processing. Another significant assumption we shall make is that capability-servers communicate with each other by sending (probably very rich) messages asynchronously. That is to say, the messages may take some time to arrive. The sending capability-server will not wait for a reply but will be able to service a reply, if any, asynchronously at some later time. We conjecture that capability-servers, communicating asynchronously in this way can be used to map either the business processes to be described, or the highest level of system architecture that we (as system architects) believe will implement the business processes. These models may or may not be the same. We introduce a type of model, which we may refer to either as a services diagram or a

Formal methods are a nice idea, but the size and complexity of real systems means that they are impractical. We propose that a reasonable alternative to attempting to specify and verify the system in its entirety is to build and evaluate an abstract model(s) of aspects of the system that are perceived as important. Using a model will not provide proof of the system, but it can help to find shortcomings and errors at an early stage. Executing the model should also give a measure of confidence in the final product. Many systems today are built from communicating components so that the task of the developers is becoming fitting these components together to form the required system. We show how a formal model can be sympathetic to this type of architecture using our tool, RolEnact and explain how this may be related to a COM implementation. 1 Introduction Nobody would deny that widespread use of formal methods in software development would lead to a great improvement in quality and reli...

The documentation of an architecture is as important as the architecture itself. Tasked with communicating the structure and behaviour of a system and its constituent components to various stakeholders, the documentation is not trivial to produce. It becomes even harder in open, modular systems where components can be replaced and reused in each progressive build. How should documentation for such systems be produced and how can it be made to easily evolve along with the system it describes? We propose that there is a close mapping between the system architecture and its documentation. We describe a relational model for the architecture of open systems, paying close attention to the property that certain components can be reused or replaced. We then use ideas from storytelling and a discourse theory called Rhetorical Structure Theory (RST) to propose a narrative-based approach to architecture documentation; giving both a generic narrative template for component descriptions and a RST-based relational model for the document architecture. We show how the two models (system and documentation) map onto each other and use this mapping to demonstrate how document fragments can be stored, automatically extracted and collated to closely reflect the system’s architecture.

This paper addresses these issues, with the objective taking a particular view of the options available

This paper presents a formal notation for modelling asynchronous web services composition, using context and coordination mechanisms. Our notation specifies the messages that can be handled by different web services, and describes a system of inter-related web services as the flow of documents between them. The notation allows the typical web services composition pattern, asynchronous messaging, and has the capability to deal with long-running service-to-service interactions and dynamic configuration behaviors.