Peyman Oreizy’s research while affiliated with University of California, Davis and other places

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. In this paper, we chart the history, evolution, and shortcomings of REST, as well as several related architectural styles that it inspired, from the perspective of a chain of doctoral dissertations produced by the University of California's Institute for Software Research at UC Irvine. These successive theses share a common theme: extending the insights of REST to new domains and, in their own way, exploring the boundary of software engineering as it applies to decentralized software architectures and architectural design. We conclude with discussion of the circumstances, environment, and organizational characteristics that gave rise to this body of work.

Software architecture research has yielded a variety of powerful techniques for assisting in the design, implementation, and long-term evolution of complex, heterogeneous, distributed, multi-user applications. Since software development environments are themselves applications with these characteristics, it is natural to examine the effectiveness of an architectural approach to constructing and changing them. We report on our experience in creating a family of related environments in this manner. The environments encompass a range of services and include commercial off-the-shelf products as well as custom-built tools. The particular architectural approach adopted is fully reflexive: the environments are used in their own construction and evolution. We also report on some engineering experiences, in particular with our use of XML as the vehicle for supporting a common and extensible representation of architectural models, including the model of the environment itself.

Runtime software adaptability - the ability to change an application's behavior during runtime - is an increasingly important capability for systems, both to support continuous operation and to support a good user experience. Achieving such adaptability may be very hard or easy; the degree of difficulty will largely reflect choices made in a system's architecture. Some architectural styles are much more supportive of dynamic change than others. This paper examines a range of styles and assesses them with respect to a four-element evaluation framework, called BASE. The framework considers how a style supports changes to behavior, state, its execution context, and supports asynchrony of change. Styles considered include REST, event-based, service-oriented, and peer-to-peer.

Our ICSE 1998 paper showed how an application can be adapted at runtime by manipulating its architectural model. In particular, our paper demonstrated the beneficial role of (1) software connectors in aiding runtime change, (2) an explicit architectural model fielded with the system and used as the basis for runtime change, and (3) architectural style in providing both structural and behavioral constraints over runtime change. This paper examines runtime evolution in the decade hence. A broad framework for studying and describing evolution is introduced that serves to unify the wide range of work now found in the field of dynamic software adaptation. This paper also looks to the future, identifying what we believe to be highly promising directions.

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 inter-component 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.

Introduction Developers frequently confront a dilemma that may be characterized by the following: 90% of the functionality requested by our customer is available in an existing off-the-shelf application, but the missing 10% is vital to the customer. Unfortunately, we cannot customize or adapt the existing application to meet our customer's needs--we have no choice but to buid a custom solution from scratch." As a result, a relatively small change in functionality necessitates a disproportionately large amount of effort, and curtails the opportunity for software reuse. This undesirable outcome may have been avoided if the off-the-shelf application supported decentralized software evolution, which we define as the ability to evolve software independent of the original software vendor. Decentralized software evolution (hereafter abbreviated DSE) provides a means for third-party software vendors to customize existing applications for particular domains and customers. This capabili

In order to support architecture-centric tool integration within the ArchStudio 2.0 Integrated Development Environment (IDE), we adopted Extensible Markup Language (XML) to represent the shared architecture-in-progress. Since ArchStudio is an architectural style-based development environment that incorporates an extensive number of tools, including commercial off-the-shelf products, we developed a new, vendor-neutral, ADL-neutral interchange format called Extensible Architecture description Language (xADL), as well as a "vocabulary" specific to the C2 style (xC2). This paper outlines our vision for representing architectures as hypertext, the design rationale behind xADL and xC2, and summarizes our engineering experience with this strategy.

This paper briefly explores application consistency in the context of decentralized software evolution. We begin in section 2 by surveying common strategies for dealing with application consistency in DSE. Section 3 proposes a new strategy based on resource models. Section 4 considers related work on nonDSE techniques for assuring consistency that could potentially be adapted to DSE

Self-adaptive software requires high dependability robustness, adaptability, and availability. The article describes an infrastructure supporting two simultaneous processes in self-adaptive software: system evolution, the consistent application of change over time, and system adaptation, the cycle of detecting changing circumstances and planning and deploying responsive modifications

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