Seventeen years after its initial publication at ICSE 2000, the Representational State Transfer (REST) architectural style continues to hold significance as both a guide for understanding how the World Wide Web is designed to work and an example of how principled design, through the application of architectural styles, can impact the development and understanding of large-scale software architecture. However, REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework.

Reducing the costs and risks associated with changing complex software systems has been a principal concern of software engineering research and development. One facet of this effort concerns decentralized software evolution (DSE), which, simply stated, enables third-parties to evolve a software application independent of the organization that originally developed it. Popular approaches to DSE include application programming interfaces or APIs, software plug-ins, and scripting languages. Application vendors employ DSE as a means of attracting additional users to their applications-and, consequentially, increasing their market share-since it opens up the possibility that a third-party modified version of the application would satisfy the needs of end-users unsatisfied with the original version. This benefits everyone involved: the original application vendor sells more product since customization constitutes use; third-party developers deliver a product in less time and with lower cost by reusing software as opposed to building it from scratch; and customers receive a higher quality product, customized to suit their needs, in less time and with lower cost. By increasing the opportunity for buying and customizing software instead of building it from scratch, DSE attacks Brook's essential difficulties of software development.

Continuous availability is a critical requirement for an important class of software systems. For these systems, runtime system evolution can mitigate the costs and risks associated with shutting down and restarting the system for an update. We present an architecture-based approach to runtime software evolution and highlight the role of software connectors in supporting runtime change. An initial implementation of a tool suite for supporting the runtime modification of software architectures, called ArchStudio, is presented.

Reuse of large-grain software components offers the potential for significant savings in application development cost and time.Successful comuonent reuse and substitutability depends both on qualities of the &mponents reused as well as the sofiware context in which the reuse is attempted.Disciplined approaches to the structure and design of software applications offers the potential of providing a hospitable setting for such reuse+ We present the results of a series of exercises designed to determine how well "offthe-shelf" components could be reused in applications designed in accordance with the C2 software architectural style.The exercises involved the reuse of two user-interface constraint solvers, two graphics toolkits, a World Wide Web browser, and a persistent object manager.A subset of these components was used to construct numemus variations of a single application (thus an application family).The exercises also included construction of a simple development environment for locating and downloading a component off the Web and incorporating it into an application.The paper summarizes the style rules that facilitate reuse and presents the results from the exercises.The exercises were successful in a variety of dimensions; one conclusion is that the C2 style offers significant reuse potential to application developers.At the same time, wider trials and additional tool support are needed' Index Terms -software reuse, architectural styles, messagebased architectures, component-based development, graphical user interfaces (GUI).

Software architectures enable large-scale software development. Component reuse and substitutability, two key aspects of large-scale development, must be planned for during software design. Object-oriented (OO) type theory supports reuse by structuring inter-component relationships and verifying those relationships through type checking in an architecture definition language (ADL). In this paper, we identify the issues and discuss the ramifications of applying OO type theory to the C2 architectural style. This work stems from a series of experiments that were conducted to investigate component reuse and substitutability in C2. We also discuss the limits of applicability of OO typing to C2 and how we addressed them in the C2 ADL.

While a large fraction of application code is devoted to graphical user interface (GUI) functions, support for reuse in this domain has largely been confined to the creation of GUI toolkits ("widgets"). We present a novel architectural style directed at supporting larger grain reuse and flexible system composition. Moreover, the style supports design of distributed, concurrent applications. Asynchronous notification messages and asynchronous request messages are the sole basis for intercomponent communication. A key aspect of the style is that components are not built with any dependencies on what typically would be considered lower-level components, such as user interface toolkits. Indeed, all components are oblivious to the existence of any components to which notification messages are sent. While our focus has been on applications involving graphical user interfaces, the style has the potential for broader applicability. Several trial applications using the style are described.