Experience has shown us that object-oriented technology alone is not enough to guarantee that the systems we develop will be flexible and adaptable. Even "welldesigned " object-oriented software may be difficult to understand and adapt to new requirements. We propose a conceptual framework that will help yield more flexible object-oriented systems by encouraging explicit separation of computational and compositional elements. We distinguish between components that adhere to an architectural style, scripts that specify compositions, and glue that may be needed to adapt components' interfaces and contracts. We also discuss a prototype of an experimental composition language called PICCOLA that attempts to combine proven ideas from scripting languages, coordination models and languages, glue techniques, and architectural specification. 1 Introduction The last decade has shown that object-oriented technology alone is not enough to cope with the rapidly changing requirements of ...

Traditional software development approaches do not cope well with the evolving requirements of open systems. We argue that such systems are best viewed as flexible compositions of "software components" designed to work together as part of a component framework that formalizes a class of applications with a common software architecture.

An approach to arrangement of component responsibilities in a componentbased software system is proposed, in which black-box components constitute the major building blocks and perform the main part of computation while whitebox adapter components enhance their interoperability. We recommend a technique in which components contribute to the construction of the adapters in a structured way. A component supplies one or more customizable classes to be used in implementation of the portion of the adapter associated with that component. Through various examples we investigate the advantages and feasibility of using customizable adapters that compensate for the inevitable gaps between interacting components' interfaces. Their usage allows a blackbox component to be designed as concise as possible, i.e. providing a (minimal) interface that is confined to its functionality, and assuming the most convenient interface from the components it makes use of. An important outcome of this conciseness ...

It is generally acknowledged that separation of concerns is a key requirement for effective software engineering: it helps in managing the complexity of software and supports the maintainability of a software system. Separation of concerns makes only sense if the realizations in software of these concerns can be composed together effectively into a working program. The ability to compose systems from independently developed components that can be adapted and extended easily is a long-standing goal in the software engineering discipline. However, both research and practice have shown that composability of software is far from trivial and fails repeatedly. Typically this occurs when components exhibit complex behavior, in particular when multiple concerns are involved in a single component. We believe that, to address the composability problems, we need a better understanding of the requirements involved in successful composition, and in addition define the situations where composition fails. To this aim, in this paper we (a) introduce a general model of composing systems from multiple concerns, (b) introduce a number of requirements for design-level composability and (c) define a category of composability problems that are inherent for given composition models, which we term as composition anomalies.

Mobile code is being investigated by many researchers as an alternative for the implementation of more flexible distributed applications. A number of programming paradigms based on mobile code have been developed. This paper focuses on implementation of distributed services using the messenger paradigm. With the messenger approach which combines the potential of mobile code, runtime code generation 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. The service is published with its operational interface. The client interprets, at run time, the service's operational interface and collects from it the information required to interact appropriately with the service. Keywords: distributed service, messenger,messenger interface description language. INTRODUCTION Distributed applications are expected to run in large, heterogeneous, asynchronous and dynamic envi...

Abstract not found

Abstract. Software Adaptation promotes the use of specific computational entities called adaptors that guarantee software components will interact in the right way, not only at the signature level, but also at the behavioral, semantic and service levels. Adaptation techniques have proceeded by computing adaptors for closed systems made up of a fixed set of components. This is not satisfactory when the systems may evolve, with components entering or leaving it at any time. To enable adaptation on such systems, we propose one implementation of adaptors under.NET platform and we show how using an ontology one adaptor can be improved in order to achieve a runtime adaptation at service level in a developed system when a component is missing or replaced by other. This capability will increase the Quality of Service (QoS), making the system be Fault Tolerant.